We would like to minimise the amount of code exposed in the product we have developed and an obvious option is to configure our build setting to use the All Symbols for Strip Style.
Some investigation with an AI tool reports there are possible problems doing so.
ContentFilter: non-global → all — risky. The NetworkExtension and XPC subsystems load your bundle and look up classes by name through the ObjC runtime, which uses __objc_classlist and friends (not the Mach-O symbol table), so in principle all works. In practice it occasionally breaks bundle loading in edge cases. If you try this, test specifically that systemextensionsctl activates the bundle and the filter actually traps packets.
Is it safe to use All Symbols with a content filter or do we need to accept Non-Global symbols?
Thanks,
Dave
That LLM summary gels with my understanding:
- NE load providers via their class name.
- That’s done using Objective-C runtime data structures.
- Which are not the same as symbols.
- Thus stripping symbols shouldn’t cause problems.
I’m not aware of any “bundle loading in edge cases” that apply in to NE providers, so this is definitely one of those “suck it and see” moments.
Having said that, there are definite downsides to stripping all your symbols:
- You’ll need a
.dSYMfile to get anything meaningful from a crash report. No more glancing at a crash report to get a rough idea of what’s going on. Rather, you have to symbolicate before you look at anything. - Likewise for any in-the-field debugging.
- If your goal is to hide how your code words, you don’t gain as much as you think. First, lots of info still ends up in the Objective-C and Swift runtime structures. I talk more about that in this thread. Second, LLM-based disassembly tools are remarkably powerful these days.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"