The first tab of idb’s interface provides an easy way to analyze data stored in common file types. At the moment,
this includes plist files, SQLite databases, and HTTP request caches (
Cache.db). The functionality provided by idb
for each of the file types is similar: You can automatically search the entire app directory for the specific file
type, list the results including their
DataProtection class (encryption!), and view the files by simply
double-clicking a result entry. Click the “Refresh” button at the bottom to retrieve the list.
For iOS 8+, Each storage related tab displays the “Default Data Protection” of the app which is set via app entitlements.
This class defines the default protection class used for files created by the app. In order to determine the
DataProtection class for each file,
idb uses a small helper utility which is available at:
Plist files are used by most iOS application for structured data storage. Typically they are accessed via iOS’s
NSUserDefaults which automatically persists the data on the file system in the form of
.plist files (XML or binary).
SQLite support has been part of the iOS SDK since early on. SQLite databases are stored on the file system (generally unencrypted) and can be queried using a limited set of SQL.
The automatic request and response caching performed by
NSURLConnection can disclose sensitive data on the file
system. Specifically, it stores request and response data in a
Cache.db file, an unencrypted sqlite database.
File System Browser
The file system browser provides an easy to use interface for browsing the app’s sandbox. All directories and files
are listed in a familiar tree and list structure. The details pane at the bottom displays file permissions and the
DataProtection class which applies to the file. This way one can easily verify that sensitive files are properly
protected. Moreover, double-clicking on any file will automatically download and open it on the idb host with the
application that is associated with the file extension. At the bottom of this tab is a section for displaying the
“Default Data Protection” of the app, the default encryption class of files created by this app.
Git + Rsync
In order to get a full mirror of the current application sandbox (and the data directory on iOS 8+), the Git+Rsync function can be used. It uses rsync to create an exact mirror of the remote file system on the idb host. In addition, the entire directory structure is checked into a dedicated git repository. When performing subsequent syncs using Git+Rsync, new revisions are created in the git repo and thus changes in the application directory can be tracked. The directory where the git repository is held can easily be changed in the user interface. This can, e.g., be used to compare or keep track of installations on different devices.
- Git+Rsync: Performs a sync and checks a new revision into git.
- Open Folder: Opens the local mirror with the most recent revision checked out.
- Open gitk: Opens gitk to explore the git repo.
idb provides a convenient way for dumping, editing, and deleting the content of the iOS Keychain. Below is an overview screenshot of the keychain tab followed by a more detailed description of the different keychain features.
Dump the Keychain
Dumping the keychain works by simply clicking the “Dump Keychain” button in idb. The returned data includes Entitlement Groups, Account, Service, Protection class, User Presence requirement, create and modification date. User presence is a new feature in iOS which requires a user to authenticate either via TouchID or by entering their passcode in order to access a keychain item. Note that there is no known way for bypassing this check since data is in fact encrypted under the passcode and this processing happens in hardware through the Secure Enclave.
View Keychain Entries
When selecting an entry in the table shown above, the data can be viewed as text, hexdump, or parsed as XML in the case of binary plist data.
Parsed Binary Plist View
There is a decent number of applications that store binary plist data inside the keychain and it can be rather painful to read it in its string presentation. This screen attempts to detect if a keychain item consists of a binary plist, converts it to a regular (xml) plist, and displays the data.
Deleting a keychain item as simple as it sounds: simply select the entry and click the “Delete” button.
For editing keychain items idb goes with a simple yet flexible approach. After selecting a keychain item, one can display its content either as plain text, or as Base64 encoded data. The plain text version allows quick editing of text-based keychain entries while the Base64 version can be used to edit binary data. Implementing a proper binary/hex editor inside of idb did not seem like a reasonable effort. Instead, by providing the data in Base64 format any external editor can be used to modify the data. After editing, simply paste the new Base64 data into idb and hit save.