Skip navigation.
 
mlRe: Private Frameworks
FROM : John Stiles
DATE : Sun Jan 13 22:18:23 2008

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 <seaside.<email_removed>> 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_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>

Related mailsAuthorDate
mlPrivate Frameworks Mitchell Hashimoto Jan 13, 09:15
mlRe: Private Frameworks Kyle Sluder Jan 13, 09:55
mlRe: Private Frameworks Philippe Casgrain Jan 13, 16:19
mlRe: Private Frameworks Stefan Jan 13, 16:57
mlRe: Private Frameworks Kyle Sluder Jan 13, 20:23
mlRe: Private Frameworks John Stiles Jan 13, 22:18
mlRe: Private Frameworks glenn andreas Jan 13, 23:06
mlRe: Private Frameworks John Stiles Jan 14, 05:28
mlRe: Private Frameworks Chris Hanson Jan 14, 06:51
mlRe: Private Frameworks Timothy Reaves Jan 15, 01:08
mlRe: Private Frameworks John Stiles Jan 15, 01:23
mlRe: Private Frameworks Alastair Houghton Jan 15, 18:13