Re: Private Frameworks
Re: Private Frameworks
- Subject: Re: Private Frameworks
- From: glenn andreas <email@hidden>
- Date: Sun, 13 Jan 2008 16:06:43 -0600
On Jan 13, 2008, at 3:18 PM, John Stiles wrote:
Honestly, I can't say I fully agree---having full symbol information
for every method/function in a program makes reverse-engineering
much, much simpler.
However, if it is important to you, you can get a lot of mileage out
of strategic #defines to rename your classes, methods and categories
to meaningless names. Obviously you can't do this if you are
implementing delegate methods or subclassing built-in methods, but
you can still obscure your tracks relatively well. e.g. imagine a
header, included everywhere, that did:
#define MyBigClass _1
#define MyOtherClass _2
#define updateMyObject _3
#define withSomeOtherValue _4
#define myInfo a0
#define setMyInfo setA0
#define otherInfo a1
#define setOtherInfo setA1
etc.
I've never actually done this in ObjC but I've done it with C and
had good results. I guess the biggest constraint is that you have to
still honor KVO/KVC naming conventions, etc., so you'll still need
"set" in front of some names.
Actually the biggest constraint is that this approach will break your
nibs, since they refer to the "plain" names (rather than the symbol
processed names).
In theory, this could be done at link time (or shortly afterwards),
since all of these class symbols and selectors end up being an entry
in the string table. It seems definitely possible to write a tool to
find these strings (by walking all the object-c runtime info in the
executable) and obscure them (so long as your app and frameworks
obscure the strings the same way, because that's how your app
ultimately refers to classes in your framework).
Of course, this would also then need to go into your NIBs and do the
same thing. You'd also need a list of things that correspond to other
external frameworks (which is fairly straightforward to obtain) to
make sure that you don't obscure selectors like "release" or any of
the various delegate methods that would be called from the framework.
There are also cases of "synthesized" selectors that you'd need to
check for (for example, one pattern of handling validation is to
prefix the selector with "validate" or "can" and call that method, so
"doSomething:" becomes "validateDoSomething:"). With a decent set of
patterns, you could handle these (as well as all the KVO/KVC
requirements)
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next
generation of fractal art
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden