Capturing Ghosts: Using inotify to defeat an Android DRM system
Apart from our typical application penetration testing engagements, clients sometimes come to us looking to test the resiliancy of various security mechanisms they want to apply to their applications. This was the case a few weeks ago when one of our larger clients approached us and asked us to test a copy protection, DRM solution for one of their Android applications.
Attacking copy protection is usually a combination of both static and dynamic analysis. This includes looking at the reverse-engineered source code to figure out how the copy protection worked and to find any encryption keys, as well as, watching the application transform into the unencrypted version.
Our first step was to reverse engineer the target .apk file using dex2jar and JD-GUI to see the obfuscation.
While the file was heavily obfuscated, it was traceable. In addition, the hashed method names seem to eventually trace calls to a native library that was referencing a hashed file in the assets directory.
Below is the redacted file in the assets directory of the target .apk.
The best way to watch the interaction live, apart from a debugger, was surprisingly simple - using LogCat.
By watching LogCat while the obfuscated application started up, we observed that the obfuscated file in the assets directory appeared to be the .dex file, containing the Android bytecode:
DextOpt, which optimizes the .dex file, is operating on a .dex with the same name as the file in the asset directory. This .dex file is then written into the /data/data/{app}/files directory temporarily and then deleted as the application starts up.
This sure looks like the de-obfuscated, decrypted file. But how to get it before its deleted from the file system?
Enter the Linux inotify API, which has been in every Linux kernel since 2.6.13, including the Android kernel. Inotify allows you to monitor a file or directory and react to events such as when files are created, opened, closed, updated or deleted. And since I do all my testing on a rooted device, accessing this to monitor the /data/data/{app}/files directory of the target app would be pretty simple to do.
Based on the excellent information found here and in the code for Inotifywait-for-Android by Rohan McGovern, I was able to code a small inotify-based tool that, when run as root, would copy the .dex file to my SD card before it is deleted.
A sample of the code I used, borrowing from both of the above examples:
I simply ran this as root on my device, then started the target app and voila, captured the unobfuscated .dex file:
After renaming this to classes.dex and repackaging the .apk using a self signed certificate, I had a DRM-free copy of the application that would run on my device.
Since then, members of my team have found at least one other way to defeat this kind of copy protection. The biggest issues appear to be that under Android, you cannot operate on a file in memory only - it has to be temporarily written to disk.
We have also used similar techniques to capture temporary cryptographic keys and credentials from iOS applications.
The moral of the story is that writing un-obfuscated data to disk, even temporarily, will always be the achilles heel of copy protection and DRM on mobile devices.