How does the iOS app Display Recorder record the screen without using private API?

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.

Solution 1:

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:

/System/Library/Frameworks/IOKit.framework/IOKit
IOServiceGetMatchingServices
IOServiceGetMatchingService
IOServiceMatching
IOMasterPort
IOIteratorNext
IORegistryEntryCreateCFProperty
IOObjectRelease
/System/Library/Frameworks/UIKit.framework/UIKit
UIGetScreenImage
/System/Library/PrivateFrameworks/IOMobileFramebuffer.framework/IOMobileFramebuffer
IOMobileFramebufferOpen
IOMobileFramebufferGetLayerDefaultSurface
/System/Library/PrivateFrameworks/IOSurface.framework/IOSurface
IOSurfaceAcceleratorCreate
IOSurfaceAcceleratorTransferSurface
IOSurfaceLock
IOSurfaceUnlock
IOSurfaceGetWidth
IOSurfaceGetHeight
IOSurfaceCreate
IOSurfaceGetBaseAddress

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 the IOMobileFramebufferGetLayerDefaultSurface function. 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 UIGetScreenImage for 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 dlsym symbol, 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.

Solution 2:

@C0deH4cker's suggestion of the IOSurface framework is just crazy enough to work. IOSurface provides a kernel interface (allowing an app to slip out of its sandbox quietly), for a rectangular pixel buffer (screen grabs), that can be converted to a CGImage or UIImage using framework-related methods.

Even apple suggests that the framework's raison d'être is to:

Contain low-level interfaces for sharing graphics surfaces between applications.

Best part is, it's not legal in iOS. The framework used to be called CoreSurface in iOS 2.x, which was quickly and quietly deprecated in 3.x, only to be replaced by iOSurface. I guess the fact that it's private and unlisted in the iOS references meant that the app store testers didn't test for it. Interesting.