Re: Private Frameworks

FROM : John Stiles
DATE : Mon Jan 14 05:28:35 2008

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