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.