I am an ios developer. Recently I'm using the UIDocumentInteractionController to open my file in other apps. When the code runs to a line that called the presentOpenInMenuFromRect:inView:animated method, a weird string appears in the xcode output:
AirDrop: collectionView:layout:insetForSectionAtIndex:, orientation:1, sectionInset: {0, 13, 0, 13}
And this string only appears when I run the app on ipad with ios7.0.2, and not appear in iphone4s with ios 7.1.3.
This output worries me, I have no idea why this came out. It's not a warning or an exception, and besides the output, everything runs well and the candidate apps list can show up correctly and also the file can be opened successfully by the app selected.
But why this string appears? It's definitely not from the code I wrote. Looks like it's a function signature related to Airdrop. Can anyone help me out of this?
Related
I am using UnityAds in my mobile game, to show a banner and a rewarded video.
In the editor and in Andorid works fine.
However for iOS it doesn't work, i took the logs and i noticed that for iOS is using my android gameid, this i have no idea where it comes from, i searched every file in my project, i never reference the android gameid, just the iOS one.
So it is clearing taking the id not from my initialization but from some sort of cache, anybody has an idea where is taking the gameid from? thanks
Btw
I am using Advertisement package from package manager.
You can open manually Project Folder\ProjectSettings\UnityConnectSettings.asset in text or code editor, then find
UnityAdsSettings:
m_Enabled: 0
m_InitializeOnStartup: 1
m_TestMode: 0
m_IosGameId: <---- THIS ONE
m_AndroidGameId:
m_GameIds: {}
m_GameId:
and edit it
I have an app which can open a CSV file sent from an email and it display its content within the app in a different format (note that I cannot post the code used to do this).
However, every once in a while (about 2 times out of 3!), when importing a CSV from the email, the app freeze, the code is displayed as if I had a breakpoint in appDelegate, and when I press run in the debugger, the screen in Xcode becomes grey and displays the following message:
Failed to generate disassembly for stack frame because the URL cannot be translated: x-xcode-disassembly://stack_frame?
Does anyone knows what this message is and what could be the reason for it?
Note: I am using Xcode 7, and run the app in a mini iPad with iOS 9. (not simulator)
Thank you.
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 can't record audio using the SpeakHere example app from apple. When I run the app in Simulator from within Xcode, it starts up normally, but when I press the record button, the error "Thread 1: EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)" occurs:
The log message about the missing root view controller at app startup is already there BEFORE the above error occurs and it is probably not connected to my problem.
I have downloaded the SpeakHere example project from the linked website (see top of this question), opened the fresh download in Xcode and directly started the app. I did not modify any setting and not any line of code. I've also searched on google and stackoverflow for this problem and didn't find a solution, although this problem must be very general.
I use Xcode Version 4.5.2 (4G2008a) and a MacBook Pro from late 2009 with Mac OS X 10.8.
I've also had a friend try this on his computer and he has the very same problem. He has the same OS and his XCode version is also 4.5.2.
I would now try older Xcode versions, but right now I don't like to download a few gigabytes for a trial'n'error approach on my connection.
Any help appreciated, including reports like "works for me with Xcode version ...". Thanks!
The problem occurs because in the method AQRecorder::StartRecord(CFStringRef inRecordFile), the function CFURLCreateWithString() fails and returns a pointer to nil. This is not detected and later on the code calls CFRelease() on this nil pointer, which causes the EXC_BREAKPOINT.
The purpose of the method CFURLCreateWithString() basically is to take a url string as input and return a pointer to a CFURL object as output. The problem here is that the input is not a url string. Instead, it's simply a path on the local file system without file:/ or the like as prefix. For this reason, this method fails.
The solution is to remove the not-working call to the method CFURLCreateWithString() and instead call a related method, namely CFURLCreateWithFileSystemPath(), which is prepared to take a local file system path and convert it to a CFURL:
In the method AQRecorder::StartRecord(CFStringRef inRecordFile), replace or comment out the line
url = CFURLCreateWithString(kCFAllocatorDefault, (CFStringRef)recordFile, NULL);
and insert
url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)recordFile, kCFURLPOSIXPathStyle, false);
at its place.
url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)recordFile, kCFURLPOSIXPathStyle, false);
The code above made my xcoce 4.6 compile and run in simulator, but it doesnot record my voice from my usb microphone, I test my microphone in the garash band application and sucessfully record and play my voice, and the dbmeter does not move at all, any way when I port it to the real device it work, it just can't record and play voice in my simulator.
Im not a "high level" programmer. I do not understand all this stuff really which is why I'm using phonegap instead of native programming. I'm doing nothing special. The "page" loads, there is an input box, you click it, keyboard pops up. Letters seem to work OK but as soon as you push a # or back space the whole app crashes with EXC_BAD_ACCESS.
This is in a 4.3 emulator. I do not have a device handy to try.
All the searching I've done are people talking about memory management and what not. I'm not doing any of that, nor would I have idea on how to.
Anyone know why this is happening?
Here is the offending line:
int retVal = UIApplicationMain(argc, argv, nil, #"AppDelegate");
Which is located insde Supporting Files > main.m > main()
^^-- I did not create that file. I'm not sure if phonegap created it or if it was created by xcode.
It turns out the problem WAS the fact that I was testing my code on a 4.3 SIMULATOR on an OSX LION virutal machine running on a win7 host.
I brought my code in to work the next day, hopped on one of the macs, installed xcode and ran the identical code on the simulator AND my coworkers iphone and the problem did not show up, at all!