obfuscate only some classes

[felipejfc]

it would be very useful if one could use a inverse filter, like -F X -F Y and only classes X and Y would get obfuscated

[ayufan]

Good idea. Maybe you would have time to prepare PR?

[wiktor]

@ayufan I have a problem with -F parameter.

If it is negative filter (that is !SomeClass), it works as intended. If it is positive filter, it works but does not make any sense. By default all classes and protocols by default are obfuscated.

I have a proposition with -F parameter.

• If it is not set, works the same way as current version. That is obfuscates all classes and protocols.
• If set, it changes behaviour of shouldClassBeObfuscated to return NO by default.

What do you think?

[wiktor]

One more question: why -F param does not affect obfuscating categories? Is there anything special about them that -F could not filter those?

[juliengdt]

Hey, i paste my ass here, very interesting stuff.

For myself, it would be cleverer to add flag for avoiding obfuscation on folder path. For ex i have a pod folder, it would be interesting to not obfuscate it, because it's open source and it's your stuff which is critical.

And because about performance, it would be soooooo much better to avoir some classes (like again podfile / pod folder )

[wiktor]

@juliengdt You can provide multiple -F parameters. You can list recursively all header files from that folder, remove ".h" and prepare long "-F Class1 -F Class2 ..." argument list.

[juliengdt]

@wiktor well ... it's a bit disappointing, when i saw my pod Folder : 3500 .h ....

[ayufan]

@juliengdt You can try to use something like that:

find . -name '*.h' -exec bash -c 'echo "-F $(basename "{}" .h)"' \;

[juliengdt]

@ayufan I totally agree, but have an option for file and another for folder could be great, on my developer side =) , but i keep this option on a note ! thx

[ayufan]

We are currently working on deobfuscating dSYMs so they could be easily uploaded to services like Crashlytics and BugSense. Maybe you would have some time to implement it? I would help you to identify places where options should be added.

[wiktor]

@ayufan I might take a look at it. Could you spawn separate issue for that with all info?

Back to -F filters. I needed to fork and change ios-class-guard to work differently. To only obfuscate classes that I'm interested in and skip others. Currently if class is ignored with -i arg then all properties along with types are being added to ignored symbols. That's no-no for me.

Example: class ignored_class { NotIgnoredClass *_property. } in this case NotIgnoredClass would be ignored (via visitProperty -> visitType).

That's why I added option to skip classes at all if they are not in -F argument rather than add them along with their props and methods to ignored symbols list. But I keep it as company's private fork.

BTW have you noticed that class-dump repository is borked somehow and cannot be mirrored?

[neuralmer]

We (PreEmptive Solutions) forked iOS Class Guard, creating a new product, called PreEmptive Protection for iOS - Rename (or PPiOS-Rename), that fixes issues mentioned here and a number of others.

@felipejfc

In ios-class-guard, by default everything is included for renaming. PPiOS-Rename works similarly, so you will need to exclude everything first, and then include your two classes with something like:

ppios-rename --analyze -F '!*' -F X -F Y path/to/your.app

@wiktor

1. PPiOS-Rename will warn you if you use a positive filter without first including a negative filter. You, too, can get your desired behavior by first excluding everything, and then including only your classes. Assuming all of your classes all start with WG, you can get what you want with something like:

   ppios-rename --analyze -F '!*' -F 'WG*' path/to/your.app

2. PPiOS-Rename supports excluding categories with -F, using the undecorated name of the category. For example, if the program reports something like Adding @category NSString+MyCategory, exclude the category with:

   ppios-rename --analyze -F MyCategory path/to/your.app

3. In ios-class-guard, exclusion of classes via negative class filters also excludes classes when used as types of properties in excluded classes. PPiOS-Rename eliminated this type of propagation, which I think you are observing in visitType().
4. Regarding the class-dump repository being borked - yes, there's a corrupt commit. We had to rewrite a substantial part of the history, to fix it in our fork.

@juliengdt

Currently, we only support excluding by name. The analysis phase is performed on the linked binary, and cannot distinguish between pod-classes and non-pod-classes automatically. Classes, etc. in well-behaved pods should all start with a consistent prefix. These can either be excluded with -F '!ABC*', where ABC is the class name prefix, or, alternatively, you can exclude everything and include only your classes, as described above.

@ayufan

dSYM de-obfuscation is available in PPiOS-Rename by doing something like:

# assumes "symbols.map" in the current directory
ppios-rename --translate-dsym myapp.app.dSYM myapp.app-deob.dSYM

This has been tested with HockeyApp and NewRelic.

Please note that PPiOS-Rename changes the way the obfuscation process is integrated into the build (to make it easier to use), so you'll probably need to make changes to your build, and to pay attention to the new/changed argument names.

Please give it a try, and let us know how it works for you.