The iOS app Display Recorder claims to be able to record the screen of an iOS device, even while it is in the background. Given that UIGetScreenImage() is private API and will lead to a rejection on application submission when detected by the static analysis Apple runs, how were they able to do this recording in an approved application?
Additionally, the app causes a red bar to appear at the top of the screen while it records, similar to the native iOS’s phone call functionality.
I’ve been an iOS developer for awhile, and I’m a bit stumped at how this was even done, even down to the detail of putting the red bar at the top when outside of the app. I was under the impression we basically had no control of what’s happening when the app runs in the background, short of some key pieces of functionality (like audio playing, etc).
Even if the developer tapped into private API/libraries to accomplish this, how were they able to do this in a way that wasn’t detected during review? My apologies if I’m missing something obvious that was introduced with a later version of iOS here.
Looked into it and it doesnt link against IOSurface. I did however find that it uses
dlsym, and after some more reverse engineering, I found this:So, as you see here, after each framework path are the strings of the symbols that it loads from each framework, dynamically. This is to avoid getting in trouble for linking against a Private Framework. Since it is loaded in at runtime, a static analyzer cannot tell that this app uses it, thereby escaping detection.
It does look like my initial suspicion was correct; it is using IOSurface to sneak past sandbox restrictions to have raw screen access. It also uses
UIGetScreenImage, which I assume is for the second method of generating video. It also uses some IOKit functions and IOMobileFramebuffer functions. It looks like the app is grabbing an IOSurface from theIOMobileFramebufferGetLayerDefaultSurfacefunction. Not quite sure what it uses IOKit for though.In conclusion, this app uses some sneaky techniques to avoid detection by static analyzers: it doesn’t link against the private frameworks but instead grabs the symbols dynamically. It uses a combination of IOSurface and IOMobileFramebuffer to record the video, or
UIGetScreenImagefor the other mode. It is a tricky app that WILL get pulled from the AppStore, so if you want it, you better get it now.UPDATE:
It appears that this app was indeed pulled from the AppStore. If you were lucky enough to grab a copy before it was pulled, that’s great. I know that I’m glad I got it.
Apple probably justified its decision by stating that the app used private APIs and it could be viewed as a potential security problem (an app that watches you as you type in your iTunes password is one example, scary thought). I wonder if this will lead to a change in their reviewing process, but we will likely never know. One thing that is interesting to me is that there are still many more tricks developers could potentially use to hide their app’s behavior from static analysis. No reviewing process is perfect, but they can do pretty well. Even if Apple automatically refuses apps that link against the
dlsymsymbol, there are methods that can be used to bypass detection.UPDATE 2:
Apparently, there is another version of this application in the AppStore now. It is called “Disp Recorder” and has the same exact icon as the first. The GUI looks almost identical to the original one with a few minor changes. I haven’t yet reversed the newer one, but I’d be willing to bet that they used the same techniques to hide the illegal behavior. I will update this answer once I reverse the new version. The new one costs $5, but if you have ever wanted a screen recording app on an unjailbroken device, you should grab it before it is pulled.
UPDATE 3:
It looks as if I was very much correct with how this application works. There is an open-source implementation of this on GitHub by @coolstarorg called RecordMyScreen. If you still wonder how this app works, I suggest you go check it out.