Manual and Walk Through
This page provides an overview of idb's features and also acts as a basic manual for its use. Questions or improvements are welcome! To illustrate the features of idb, the screenshots are based on the analysis of either iGoat or the Damn Vulnerable iOS Application (DVIA) which are both great resources to familiarize yourself with iOS app vulnerabilities.
Follow the Getting Started guide to configure your environment and install all of idb's prerequisites.
Note: When starting idb on OS X with ruby 2.1 the menu bar might not appear until you switch to a different app and back to idb. Any pointers on how to fix that would be greatly appreciated.
The first time you star-up idb, visit the preference Dialog in the 'File' (or 'ruby') menu. In the 'Device Config' tab you can configure how to connect to your iDevice. The 'SSH directly' option performs a regular TCP connection to the device's SSH rvice while the 'SSH via USB' option uses usbmuxd to connect to your iDevice via USB. Note that you still need to have an SSH server running on the device even if you are connecting via USB. All that usbmuxd does is forward the TCP connection via USB; so the 'hostname' field becomes no longer relevant.
The second tab of the settings dialog controls the optional port forwarding between the host running idb ('client') and the iDevice ('server'). The forwarding settings follow the SSH naming conventions so 'Remote' forwarding opens up a port on the server and forwards it to the given host and port starting from the client. Conversely, 'Local' forwarding opens up a port on the client and forwards incoming connection to the specified host and port on the server side. You can specify an arbitrary number of each forward type. This function is particularly useful for investigating traffic from the device, e.g., using an intercepting HTTP proxy. For example, assume your proxy is running on the client and listens on port 8080 then you can define
remote:8080 -> localhost:8080
as a remote forward which will open port 8080 on the device and forwards all incoming connections to port 8080 on the host running idb. Now you simply configure the proxy server on the device as localhost:8080 and you are good to go!
Finally, the last tab of the preferences allows you to set external editors which are currently limited to a SQLite editor.
After all connection parameters are configured, you connect to the device by clicking the "USB Device" option in the "Devices" menu. This establishes the SSH connection via the specified method. Once the connection succeeds, a status dialog opens up which lists all the tools that idb requires on the device. Each tool can be installed by simply clicking the corresponding "Install" button. Once all tools are installed, close the dialog. Connecting to the device enables some of the basic functions such as the "Log" and the "Pasteboard" monitor. Different components of idb are activated when certain selections or actions are performed in the UI.
The next step after connecting to the device is selecting the application you would like to assess. For this, you click on the "Select App..." button and select the desired application from the dialog. Note that additional functions have now been enabled. In addition, some basic information on the application is extracted from its Info.plist file and displayed in the 'App Details' box:
- Bundle ID
- Bundle Name
- UUID
- Registered URL Schemes
- Platform Version
- SDK Version
- Minimum OS Version
In order to enable idb's remaining functions, the analysis of the application binary has to be triggered by clicking the 'Analyze Binary' button. This will download the application binary and perform some basic analysis to extract information such as:
-
Encryption?: Is a segment of the app marked as encrypted. -
Cryptid: If so, which cryptid is assigned to that segments. -
PIE: Is the application compiled as a Position-Independent Executable (PIE) and thus takes advantage of ASLR. -
Stack Canaries: Are stack canaries enabled for the application. -
ARC: Does the application use Automatic Reference Counting (ARC).
If the application binary is encrypted, idb uses Stefan Esser's dumpdecryoted to decrypt it before analyzing it.
Now that all functions of idb are enabled, let us walk through the different idb features.
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.
In order to determine the DataProtection class, idb uses a small helper utility which is available at: https://github.com/dmayer/protectionclassviewer
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.
The URL handler tab provides two main functions. The first tab 'URL Schemes' can be used to list all URL schemes registered by the application. By clicking an entry in the list, it is transferred to the text box on the right side. Using that text box any URL handler can be invoked on the device. Simply enter the URL and click the 'Open' button. Note that the device needs to be unlocked for the URL handler to trigger correctly.
Input received via URL schemes is often used in unsafe ways which can lead to vulnerabilities including memory corruption flaws. idb includes a basic fuzzer that can be used to fuzz input data via URL schemes. On the 'Fuzzer' tab, the list on the upper left holds the list of fuzzz strings. Below, is a text box to specify the fuzz template. Use $@$ to mark potential injection points. For example, if a valid URL is dvia://configure?input1=hello&input2=woot you could specify dvia://configure?input1=$@$&input2=$@$ as the template to fuzz both of the intended inputs (of course you can fuzz any part of the URL you like). For each position, idb will cycle through all the possible fuzz inputs and launch the URL handler (which launches the app) and then wait for a few seconds before killing it. In order to detect a crash, idb monitors the /var/mobile/Library/Logs/CrashReporter folder for new crash reports for the application in question.
The fuzz results re displayed on the right side: for each input, a Boolean value indicates if the app crashed (true) or not (false). If a crash occurred, the crash report can be viewed using the XCode Organizer or similar tools. Obviously, there is plenty of room for improvements here.
Once "Analyze App Binary" was clicked on the left side of the GUI, the "Application Binary" tab becomes fully active. It provides three functions: display shared libraries, display strings, and extract class signatures and functions.
The "Shared Libraries" tab allows you list all the external libraries the app references. This allows for the easy discovery of any suspicious frameworks that may be in use by the app. Internally, idb uses otool to analyze the binary. Since idb runs otool on the host, this is an OS X feature only at this point. There are plans for moving the analysis onto the device which will make the feature available for other platforms as well.
Application binaries frequently include data of interest such as API keys, credentials, encryption keys, URLs, etc. The strings tab extracts all strings in the (decrypted!) application binary and displays them right in the UI.
When reversing, instrumenting, or simply trying to understand an app, knowing all of the classes and method signatures of the app is of great help. idb provides a convenient way for obtaining these from compiled iOS applications. Under the hood, this function uses cycript and the weak_classdump script by Elias Limneos. To use this, simply click the "Dump Classes" button in idb while the device is unlocked.
This will launch the app with cycript attached and dump all the class information. Depending on the size of the application, this process will take up to several minutes. There is no visual feedback that class information is being dumped, but the device will play the "locking" sound once the dump is complete. In some rare instances the app may crash during this process which may lead to an incomplete class dump.
At any time during the process the "List Results" button can be used to retrieve all of the class information that has been collected thus far. To gain a full list, you should wait until the execution of weak_classdump is finished. The results will look similar to this:
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.
In order to get a full mirror of the current application sandbox, 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.
- 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.
This tab groups several miscellaneous tools.
The screen shot utility is a simple wizard that can be used to test whether an app is disclosing sensitive data in the automatic backgrounding screenshots taken by iOS. After starting the wizard, the "Launch Application" button can be used to launch the app under investigation (make sure the device screen is on and not locked):
After clicking "Continue", the next screen asks you to background the application by clicking the home button on the device. Once you did, click "Continue" to see whether a screenshot was found. If it was, idb downloads it and allows you to open it in your default image viewer. If no screenshot is found, a corresponding message is displayed.
Installing new CA certificates on the iDevice can be cumbersome at times. This function aims at making the process faster by automatically making the respective certificate accessible to the iDevice.
First, if your iDevice is set up to go through Burp Suite, clicking "Install Burp Cert" will automatically launch a URL handler on the device which redirects to http://burp/cert and allows the installation of the Burp CA cert with one click (make sure the device screen is on and not locked).
Second, for all other certificates, you can use the "Certificate Manager".
In order to install a new certificate, click on "Import" and select the desired certificate file. Both PEM and DER formats are supported. After selecting the file, idb will internally serve the file on an HTTP server and trigger a URL handler on the device in order to install it. After installation, use the "Refresh" button to update the certificate list.
Finally, clicking "Delete", will remove the file from the iDevice's trust store.
The /etc/hosts file editor provides a simple way to modify the host applications connect to. In order to intercept traffic for an app, one would typically use a tool such as Burp Suite and set the iOS system proxy to make the app connect to it. However, when the app does not respect proxy settings or communicates via non-HTTP protocols, this may fail. In these instances modifying the /etc/hosts may help in pointing the app at a running proxy instance which then forwards traffic to the actual server expected by the app.
idb's interface is very simple. The "Load" button retrieves the current /etc/hosts file from the device and displays it. After making the desired modifications, clicking "Save" will store the new file on the device.
The Log tab can be used to view the syslog of the iDevice. Besides system messages, it also includes any log statements that apps produce using NSLog which often disclose sensitive data. Internally, the log view uses idevicesyslog which is part of libmobiledevice. Clicking the start button will launch idevicesyslog and stream severity-highlighted log messages right into idb.
idb provides a convenient way for dumping the content of the iOS Keychain. Navigate to the "Keychain" tab and click the Dump Keychain button to extract and display all keychain entries. Under the hood idb uses the keychain_dump utility which is part of the iphone-dataprotection forensics tools.
The right-most tab provides a way to monitor the iOS Pasteboard in near real-time. By default, only the main (default) pasteboard is monitored. By adding additional pasteboard names to the list on the right side, also private pasteboards can be monitored. After clicking the start button, a custom utility will watch for any changes to the iOS pasteboards. If a change is detected, the new pasteboard value and the corresponding time stamp are displayed on the left side of the tab.
In order to monitor the pasteboard, idb uses a small helper utility which is available at: https://github.com/dmayer/pbwatcher