Hacking and Securing iOS Applications

Chapter 6. Unobliterating Files

Think of a normal filesystem as a large notebook. When a file is deleted, many think the page is blacked out with a Sharpie, like classified documents about Area 51. What’s actually happening behind the scenes is more akin to taking a thin red pen and writing a huge X across the page. Files are marked for deletion, but the content remains in the notebook. Anyone who knows what page to look at can easily read its contents, in spite of the red X marking the page as deleted. This is how most courtroom lawyers, both on Boston Legal and in real life, are able to present shocking evidence of deleted files that have been recovered from a suspect’s computer. Apple knows this too, and in iOS 4, began taking special measures to prevent files from being recovered after they are deleted by using an ingenious approach to filesystem encryption. This technique has not been perfected, however, leaving files still somewhat of a nuisance to get rid of.

As you’ve learned, iOS 4 and 5 use an encrypted filesystem. Every single file on the filesystem is encrypted with a unique key. This key is stored in an attribute on the filesystem named cprotect. The actual encryption key used to encrypt the file is itself encrypted (through what is known as an AES-Wrap) with either the Dkey, stored in the effaceable area of the NAND, or with one of the protection class keys. When a file is deleted, the cprotect attribute for the file is discarded. Without the encryption key in this ...