Re: Private Frameworks
Re: Private Frameworks
- Subject: Re: Private Frameworks
- From: John Stiles <email@hidden>
- Date: Sun, 13 Jan 2008 13:18:23 -0800
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.
Kyle Sluder wrote:
On Jan 13, 2008 10:57 AM, Stefan <email@hidden> wrote:
To protect code at least a bit, you might wish to write C-Code, which
discloses fewer
details.
I would consider it a bad engineering decision (to put it mildly) to
choose a language based on the virtually nonexistent impedance it may
place on someone's desire to reverse-engineer the library. If someone
wants to disassemble your code and figure out what it does, they will,
regardless of what language you choose. Choosing C over Objective-C
gives no advantage in this regard, while sacrificing everything it
offers.
--Kyle Sluder
_______________________________________________
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
_______________________________________________
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