Re: Private Frameworks
Re: Private Frameworks
- Subject: Re: Private Frameworks
- From: John Stiles <email@hidden>
- Date: Sun, 13 Jan 2008 20:28:35 -0800
Honestly, unless you are going to obscure the contents of your nibs
entirely, I am not sure I see a point in trying to hide the
outlet/action names anyway. If they can open the nib and immediately see
that the action for the "Register Now" button is really "runFoobar123",
it's still a little too easy to actually deter anyone :)
Now, if you're into playing mind games, you can always use setAction and
setTarget in -awakeFromNib, after the fact, to /redirect/ the actions on
your most sensitive buttons and controls (or just leave them unwired in
the nib and always set the actions programmatically). But that's really
up to you; I'm not sure if the benefit outweighs the extra effort on
your part .
glenn andreas wrote:
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