-
Notifications
You must be signed in to change notification settings - Fork 548
AntiClassDump
AntiClassDump
is a pass designed to defeat class-dump
for targets using Modern ObjC Runtime.
In short, it cleans up traces of ObjC classes in IR so neither ObjC runtime or class-dump to extract them.
Then it generates code to dynamically create and register classes.
By design acd uses a two-stage pattern to solve the issue of class dependency calculation while not forcing LTO. Traditionally LTO is enforced for the pass to calculate class dependency correctly
Most of the ObjC structs are left intact, the exception being method lists.Only +initialize
is kept (Or created from scratch if there isn't one). And +initialize
is where all Stage1 magic take place. Note in order to save ourselves from the trouble of deallocating and re-allocating class pairs, we only handle methods at stage 1.
Stage 2 takes place at LTO stage where we can, and did, calculate the dependency graph. During this stage existing ObjC structures are wiped out completely, we create completely new initialize routines from scratch and use llvm.global_ctors
to mark our initializer as constructors for the backend/linker to handle
Enable AntiClassDump
By default AntiClassDump used +initialize
as insert point, adding this flag to false uses +load
. This is mainly for adjusting bootstrapping sequence. For example there is a binary linking to a framework. Both obfuscated with ACD. If you send message to class in the framework in binary's +load
, ObjC runtime will throw an exception since framework's +load
is not called yet. In this case you should change framework's flags to use +initialize
instead of +load
Various System Libraries, for example storyboard depends on methods/setters/getters, which is wiped by Anti-ClassDump, try per file CFLAGS instead of global CFLAGS, and turn off ACD for this kind of classes