ios-class-guard design

[ayufan]

Last week we had an internal discussion about new features and whether they should be in separate commands or should be implemented in current ios-class-guard binary. Here are proposals:

1. Implement any action as separate tools: a. ios-class-guard-obfuscate <symbols.h> - main action to process iOS binary and generate symbol's map b. ios-class-guard-symbolicate <symbols.json> - additional tool to convert deobfuscate crash dumps c. ios-class-guard-dsym <dSYM> <symbols.json> - additional tool to deobfuscate dSYM
2. Add top level commands to ios-class guard: a. ios-class-guard obfuscate <symbols.h> b. ios-class-guard symbolicate <symbols.json> c. ios-class-guard dsym <dSYM> <symbols.json> d. ios-class-guard help [command], ie.: ios-class-guard help obfuscate
3. Use switches (current method): a. ios-class-guard [options] -O symbols.h -m symbols.json - main action b. ios-class-guard -c crashdump -m symbols_1.0.0.json - crash dumps c. ios-class-guard -D <dSYM> -m symbols.json -O <dSYM.new> - deobfuscate dSYM d. ios-class-guard - help

Which one do you prefer? I personally would opt for option 2, because of commonness of such approach, ie.: vagrant, github client, docker, etc.

[wiktor]

(2)

[Earlz]

We (PreEmptive Solutions) forked iOS Class Guard, creating a new product, called PreEmptive Protection for iOS - Rename (or PPiOS-Rename), that includes the 2nd design. The top level commands implemented are as follows:

ppios-rename --analyze [options] <Mach-O file>
ppios-rename --obfuscate-sources [options]
ppios-rename --translate-crashdump [options] <input file> <output file>
ppios-rename --translate-dsym [options] <input dSYM> <output dSYM>
ppios-rename --list-arches <Mach-O file>
ppios-rename --version
ppios-rename --help