Re: Private Frameworks

FROM : glenn andreas
DATE : Sun Jan 13 23:06:43 2008

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_removed>
  <http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next 
generation of fractal art