Since my latest update of Xcode, I get repeatedly the following log in my Coredata based app:
[logging] flag(s) 0x00000020 are reserved for VFS use and do not affect behaviour when passed to sqlite3_open_v2
Is this simply log noise or is it in any way relevant to me?
Update:
This happens under Xcode 13.2.1 on an iPhone with iOS 15.4. It does not happen on a Simulator with iOS 15.2.
I'm pretty sure this is something you can ignore, that will probably be fixed when iOS 15.4 is out of beta.
According to the SQLite file-open flag documentation,
Flag value 0x00000020 is SQLITE_OPEN_AUTOPROXY, for what that's worth
This flag is one of several flags that "...have historically been ignored by sqlite3_open_v2()", however...
"...future versions of SQLite might change so that an error is raised if any of the disallowed bits are passed into sqlite3_open_v2()"
What this seems to say is that the flag has no effect and hasn't had one for a while, so it doesn't matter if Core Data is using it internally. The message probably means that iOS 15.4 has a newer version of SQLite which has started to print warnings about it but hasn't started causing errors yet.
I'd expect this to be fixed when 15.4 is released, and in the meantime I encourage you to file a bug with Apple just in case.
My main question is, how can I reverse engineer a private API function that already exists, but has been modified in a new version of iOS?
I have created an iOS application to record the screen content using IOSurface and IOMobileFramebuffer. The main functions the framebuffer use to open it are IOMobileFramebufferGetMainDisplay(connect) and IOMobileFramebufferGetLayerDefaultSurface.
These functions have been used since the very first version of the app, and they have worked on all versions of iOS 7 and 8. However, on the latest iOS 9 beta, which is beta 5, the function IOMobileFramebufferGetLayerDefaultSurface does not work. The function does not return 0, as it should when it successfully opens the framebuffer.
This other user on StackOverflow seems to also be experiencing the same issue: IOMobileFramebufferGetLayerDefaultSurface function failed on iOS 9. We have a reference to IOMobileFramebufferConnection named “_framebufferConnection” and an IOSurfaceRef named “_screenSurface” Here is the current code:
IOMobileFramebufferGetMainDisplay(&_framebufferConnection);
IOMobileFramebufferGetLayerDefaultSurface(_framebufferConnection, 0, &_screenSurface;
As stated before, these work perfectly on iOS 7-8, but on iOS 9, the second function crashes. I have also looked at the binaries with the symbols for both versions and compared them. The second parameter of the LDR is slightly different in iOS 9, when compared to the iOS 8.4.1 binary. So, back to the main question, how can I reverse engineer IOMobileFramebufferGetLayerDefaultSurface, or see how in what way it’s actually been modified on iOS 9?
To answer the question of "how in what way it’s actually been modified on iOS 9", I did some digging into IOMobileFramebufferGetLayerDefaultSurface on iOS8 vs iOS9 (GM). Here are the results of what I found:
Setup:
IOMobileFramebufferRef fb;
IOMobileFramebufferGetMainDisplay(&fb);
iOS8 Implementation:
Calls through to kern_GetLayerDefaultSurface
Which accesses underlying IOConnection
io_connect_t fbConnect = *(io_connect_t *)((char *)fb + 20)
To retrieve the IOSurfaceID via
IOSurfaceID surfaceID;
uint32_t outCount = 1;
IOConnectCallScalarMethod(fbConnect, 3, {0, 0}, 2, &surfaceID, &outCount)
Returns IOSurfaceLookup(surfaceID)
iOS9 Implementation:
Same steps as above aside from the return
Then tries to retrieve a mach port to access the surface via
io_service_t fbService = *(io_service_t *)((char *)fb + 16)
mach_port_t surfacePort;
IOServiceOpen(fbService, mach_task_self(), 3, &surfacePort)
On success, return IOSurfaceLookupFromMachPort(surfacePort)
It is on the last step that IOServiceOpen returns error 0x2c7 (unsupported function). Notice that the 3rd argument specifying the type of connection is 3 instead of the usual 0 when opening the framebuffer service. It is almost certain that this new connection type has permissions restrictions that prevent anyone but Apple from retrieving a mach port to access the IOMFB surface.
What's somewhat interesting is that the call to IOConnectCallScalarMethod still works to retrieve the ID of the IOMFB surface. However, it can no longer be accessed using IOSurfaceLookup because the surface is no longer global. It's a little surprising that it was global in the first place!
Hope this helps demystify why IOMFB can no longer be used to record the screen.
Source: My own use of LLDB with an iPhone6 running iOS 8.4 and an iPhone6+ running iOS9 GM
I believe #nevyn is correct. However, I would like to elaborate a bit more. I have looked into this exact issue extensively, and the IOMobileFramebufferGetLayerDefaultSurface function does return -536870201, while it should return 0 if it runs the function without any problems. This error is on the internet, but it only appears when users encounter generic problems with QuickTime. It could be that Apple has indeed locked up the framework completely, and needs an Apple-only entitlement to access the framebuffer. We cannot add these entitlements, since it also has to be on the provisioning profile. I currently am trying to read and interpret the disassembly and doing some reverse engineering work on the IOMobileFramebuffer binary to see if any of the parameters have changed since the last iOS version. I will surely update this answer if I discover anything. But if this is the case, I would suggest trying to find another method of trying to capture/record the screen content.
-UPDATE-
It seems as if there is evidence that this would be the case, if you read this, it shows the exact same error code, and it means that the function is "unsupported", and returns an IOKit error. At least we know what this means now. However, I am still unsure of how to fix it, or to make the function work. I will continue looking into this.
UPDATE 2
I have actually discovered a brand new class in iOS 9, "FigScreenCaptureController", and it is part of the MediaToolbox framework! What the strange thing is though, is why would Apple include this only in iOS 9? So, maybe there will be a way to record the display through this...I will be looking into this class more in depth very soon.
Not entirely correct - it's just a matter of an entitlement, as you can see if you dump the kext:
$ jtool -d __TEXT.__cstring 97.IOMobileGraphicsFamily.kext | grep com.apple
0xffffff80220c91a2: com.apple.private.allow-explicit-graphics-priority
If you self sign (jtool --sign --ent) with this , everything works well.
This does mean that on non-JB devices you can't use it. But with a jailbreak the immense power is in your hands once more.
IOMobileFramebuffer is completely locked down on iOS 9 and cannot be used from non-Apple apps anymore. AFAICT, this closes the last private API to capture the screen efficiently. ReplayKit is the only replacement, but does not allow programmatic access to the actual video data.
I am trying to build an iOS Application for 64 bit. How do I know weather it is build for 32 bit or 64 bit ?
Does Mach-O-View can help ? if Yes, where to look for it ?
Also is there any command line for it. ?
I reffered this but it does not help me to know weather this it is built or not for 64 bit.
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html#//apple_ref/doc/uid/TP40013501-CH3-SW1
Try this:
#ifdef __LP64__
// NSLog(#"64");
#else
// NSLog(#"32");
#endif
It works for OS X, but I didn't test it for iOS (I don't have an iPhone5S :( ).
Edit:
By the way, it works fine on iPhone Simulator.
I export to iOS using the mobile packager built into FlashDevelop.
It supports most of the devices (ios and droid) but it does not come up with
iPhone 5 testing size.
In order to set the device, Run.bat has to be edited like:
::set SCREEN_SIZE=NexusOne
::set SCREEN_SIZE=iPhoneRetina
set SCREEN_SIZE=iPad
::set SCREEN_SIZE=iPadRetina
::set SCREEN_SIZE=iPhone
But when I enter iPhone5 I get an error.
Are there any solutions since the new screen size is important?
Mirza
try using
set SCREEN_SIZE=iPhone5Retina
you can also see some other options here http://help.adobe.com/en_US/air/build/WSfffb011ac560372f-6fa6d7e0128cca93d31-8000.html
You can use:
Capabilities.screenResolutionX
Capabilities.screenResolutionY
to catch the resolution on whichever device your app is executed on.
you might have to type
<requestedDisplayResolution>standard</requestedDisplayResolution>
in the App Descriptor XML file.
How to detect iOS 6 and all minor versions by user agent with a simple regex or something? Would be nice to distinct between iphone and ipad as well.
This question differs from What is the iOS 6 user agent string? since I wanted help in building a regex based on the information I already know (which can be found in the linked question)
CHANGELOG
20/01/2017
UA strings update: 141 matching, 0 partially matching, and 797 invalid lines
"Mobile Safari 1.1.3 (iPhone U; CPU like Mac OS X; en)" is considered invalid even if it mentions iPhone. Actually a semi-colon is missing after the iPhone term which is suspicious.
Safari 8+ doesn't appear yet on UserAgentString.com
PREREQUISITES
The following regex is generic.
It will match Safari user agent strings (SUAS) running on a mobile device (see below supported devices list).
The regex is based on known SUAS by UserAgentString.com as of 20/01/2017.
REGEX
^(?:(?:(?:Mozilla/\d\.\d\s*\()+|Mobile\s*Safari\s*\d+(?:\.\d+)+\s*)(?:iPhone(?:\s+Simulator)?|iPad|iPod);\s*(?:U;\s*)?(?:[a-z]+(?:-[a-z]+)?;\s*)?CPU\s*(?:iPhone\s*)?(?:OS\s*\d+_\d+(?:_\d+)?\s*)?(?:like|comme)\s*Mac\s*O?S?\s*X(?:;\s*[a-z]+(?:-[a-z]+)?)?\)\s*)?(?:AppleWebKit/\d+(?:\.\d+(?:\.\d+)?|\s*\+)?\s*)?(?:\(KHTML,\s*(?:like|comme)\s*Gecko\s*\)\s*)?(?:(?:Version|CriOS)/\d+(?:\.\d+)+\s*)?(?:Mobile/\w+\s*)?(?:Safari/\d+(?:\.\d+)*.*)?$
SUPPORTED DEVICES LIST
iPhone
iPhone Simulator
iPad
iPod
EXPLANATION / CUSTOMIZATION
Lines preceded by a C can be customized.
1. ^(?:(?:(?:Mozilla/\d\.\d\s*\()+|Mobile\s*Safari\s*\d+(?:\.\d+)+\s*)
C 2. (?:iPhone(?:\s+Simulator)?|iPad|iPod);\s*
3. (?:U;\s*)?
4. (?:[a-z]+(?:-[a-z]+)?;\s*)?
5. CPU\s*
6. (?:iPhone\s*)?
C 7. (?:OS\s*\d+_\d+(?:_\d+)?\s*)?
C 8. (?:like|comme)\s*Mac\s*O?S?\s*X
9. (?:;\s*[a-z]+(?:-[a-z]+)?)?
10. \)\s*)?
11. (?:AppleWebKit/\d+(?:\.\d+(?:\.\d+)?|\s*\+)?\s*)?
C 12. (?:\(KHTML,\s*(?:like|comme)\s*Gecko\s*\)\s*)?
C 13. (?:(?:Version|CriOS)/\d+(?:\.\d+)+\s*)?
14. (?:Mobile/\w+\s*)?
15. (?:Safari/\d+(?:\.\d+)*.*)?$
line 1. UA strings may differ so this line is introduced for accepting UA strings as much as possible.
line 2. You can specify here the piped-separated list of accepted devices.
(...)
line 7. The version is indicated here. Change this line if you want a special version. Don't forget to update line 13 too. For instance, matching iOS 5.x.y use (?:OS\s*5_\d+_\d+\s*)?.
line 8. Some user agent strings are translated. The word like may be translated into a foreign language. The regexp now supports English and French. Adapt this line if you encounter other languages. Don't forget to update line 12 too.
(...)
line 12. See line 8.
line 13. See line 7. For instance, matching iOS 5.x.y use (?:Version/5\.\d+\.\d+)?\s*)?.