Skip to main content

Evaluate Information from Header Files

For a lot of the static and dynamic analysis of the mobile app, reviewing the header files could be very beneficial. The header files can give you some ideas about where sensitive information could be stored in the app. Additionally, for dynamic analysis, knowing which methods are being used in a specific class could help in "hooking" that class to analyze its behavior.

Note: This is a tedious task, but may prove beneficial in guiding your attacks during dynamic analysis.

To dump the headers for a binary:

  1. Ensure the binary is not encrypted.

    % otool -l $BINARY | grep -A 4 LC_ENC

    The value of "cryptid" should be 0 if the app is decrypted.

  2. Use class-dump to dump the headers to a directory:

    % class-dump-swift -H -o headers $BINARY

    This will dump the app headers to a folder called "headers".

Look for Potential Injection Issues​

Using the header files, we can evaluate if certain APIs are in use, and if so, drive some of our attacks in the Dynamic phase of testing.

SQL Injection​

Most mobile apps will use SQLite databases that are stored on the local device. In some cases, these may be encrypted, and there is no defined standard on having an identifying filename extension. So, this may require some manual intervention.

To find possible SQL calls:

% grep -riwE 'SELECT|INSERT|DELETE|UPDATE' $HEADER_DIR

Keep in mind that you will likely find the SQL calls to create the database(s) in the DATA directory. These are required by the app and are only called during installation.

XML Injection​

Using an XML parser is also common in mobile apps that communicate with a web backend. Examine the app to find potential XML injection attacks, such XXE.

% grep -riwE 'XML|ExternalEntity|Parser' $HEADER_DIR

Cross-Site Scripting (XSS)​

XSS is not as common in mobile apps, when dealing with on device web viewers, due to the sandbox that the app runs in. It is still possible in certain circumstances where WebView's and JavaScript are used. If the session cookies are stored in the system cookie jar, you will not get it through XSS.

% grep -riwE ‘file:\/\/|loadHTMLString|stringByEvaluatingJavaScriptFromString’ $HEADER_DIR