We are working with an iOS app where we have enabled the “Generate Debug Symbols” setting to true in Xcode. As a result, the .dSYM files are generated and utilized in Firebase Crashlytics for crash reporting.
However, we received a note in our Vulnerability Assessment report indicating a potential security concern. The report mentions that the .ipa file could be reverse-engineered due to the presence of debug symbols, and that such symbols should not be included in a released app. We could not find any security-related information about this flag, “Generate Debug Symbols,” in Apple’s documentation.
Could you please clarify if enabling the “Generate Debug Symbols” flag in Xcode for a production app creates any security vulnerabilities, such as the one described in the report?
The report mentions the following vulnerability: TEST-0219: Testing for Debugging Symbols
The concern raised is that debugging symbols, while useful for crash symbolication, may be leveraged to reverse-engineer the app and should not be present in a production release.
Your prompt confirmation on this matter would be greatly appreciated. Thank you in advance for your assistance.
There’s no good way for folks here on the forums to address questions like this, because we don’t understand the circumstances associated with your app. However, I can provide some basic background.
To start, you need to understand the different types of symbols that may be involved. I’ve collected a bunch of info on this topic into Understanding Mach-O Symbols.
There is some symbolic information that you can’t strip:
-
Symbols used by the dynamic linker for imports and exports
-
The information used by the Objective-C and Swift language runtimes
The best you can do there is to obfuscate your side of the equation. Apple doesn’t have tools for this.
For Swift, you have some control above runtime information via the Reflection Metadata Level build setting.
Beyond that, Apple is OK with you stripping as many or as few symbols as you want. It may result in you getting hard-to-understand crash reports, but you can fix those as long as you have the appropriate .dSYM file. We document the process for doing that in Adding identifiable symbol names to a crash report.
I can’t comment as to whether your third-party analytics service behaves similarly. That’s something you should ask them.
If you’re building with Xcode, there are numerous build settings that control how symbols are stripped. If you search the Build settings reference you’ll find a bunch of relevant build settings, including Strip Linked Product, Strip Style, Strip Swift Symbols, Strip Debug Symbols During Copy, Deployment Postprocessing, Enable Testability, and Additional Strip Flags. The exact relationship between those settings is complex.
You can also strip and inspect symbols using various command-line tools. See An Apple Library Primer for a list of tools and links to their documentation.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"