Skip to content

MASTG-TEST-0219: Testing for Debugging Symbols

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Overview

This test case checks for debugging symbols in all binaries contained in the app.

Debugging symbols are added by the compiler to ease development and allow symbolication of crashes. However, they can also be used to reverse engineer the app and should not be present in a released app. Symbolication can also be performed with a separate dSYM file.

To manage debugging symbols in Xcode, developers can adjust the following build settings:

Note that in compiled iOS applications, symbol names may undergo name mangling and additional obfuscation techniques to further obscure them, making reverse engineering more challenging. While demangling tools can decode standard mangled names (see Demangling Symbols), they may not effectively reverse custom obfuscation methods.

Steps

  1. Apply Exploring the App Package to extract the contents from the IPA file.
  2. For all executables and libraries of the app, use Obtaining Debugging Symbols to verify there are no debugging symbols present.

Observation

The output should contain a list of symbols for each executable and library.

Evaluation

The test fails if there are symbols marked as debug symbols in the output.

Before releasing an iOS app, verify that the "Build Settings" > "Apple Clang - Code Generation" > "Generate Debug Symbols" setting is set to "No". Additionally, utilize tools like the ones used in Obtaining Debugging Symbols to inspect the final binaries for any residual debugging symbols.

For release builds, it's advisable to set "Build Settings" > "Build Options > "Debug Information Format" to "DWARF with dSYM File" and ensure that the dSYM files are securely stored and not distributed with the app. This approach facilitates post-release crash analysis without exposing debugging symbols in the distributed binary.