Re: executable obfuscator?
Re: executable obfuscator?
- Subject: Re: executable obfuscator?
- From: leenoori <email@hidden>
- Date: Mon, 11 Dec 2006 12:00:56 +0100
El 11/12/2006, a las 7:44, Laurence Harris escribió:
Okay, so maybe you can make a few people work a little harder, and
you discourage some of the amateur hackers, but is the real benefit
of that worth making a lot more work for yourself and your localizers?
I understand your doubts and that's why I asked the original
question... if lightly obfuscating strings was a just a simple matter
of using a macro then there'd really be no reason not to do it; but
if it is going to make localization burdensome then the benefit/cost
ratio starts to get unattractive.
Thinking a bit more about the problem, you have the executable and
one or more localizations:
*------------* *-----------------*
| Executable |-->| Localization(s) |
*------------* *-----------------*
The localizable strings file is totally out in the open and difficult
to protect without obfuscating or encrypting its contents. The
executable is somewhat of a "black box", but the goal here is to stop
a skilled hacker from breaking into the box and reverse engineering
it. Impossible of course, so you can only hope to throw up enough
obstacles that they'll give up and pick an easier target. You also
need to make sure that the cost to you of putting these obstacles in
place does not outweight the potential benefits; it other words it
had better be pretty damn easy to do or it's just not going to be
worth it.
Basically, in the localizable strings files you need human readable
keys (not numbers) and human readable strings (not encrypted). In
order for the executable to access those keys you therefore have to
somewhere replicate the key names in your executable, and that lands
you squarely back where you started (with unencrypted key names in
your executable).
So it seems that the only way to do this relatively securely without
inconveniencing localizers is the following:
* Security requires that all keys in the executable are always used
in encrypted form.
* So security consequently requires that your keys be encrypted in
the localizable strings files as well.
* But convenience for your localizable strings requires that keys be
human readable, so this means you have to maintain a set of files
with unencrypted keys and distribute those to localizers.
* This in turn requires you to write a helper tool/script to automate
the process of moving between the encrypted and the unencrypted
version of the files.
* And that in turn means that you and your localizers can't use tools
like AppleGlot (worst case), or that at the very least you have to
modify your working pattern with those tools.
* You also need convenience when working with encrypted keys in the
source code, and that means using macros.
* You also need a convenient way to generate those macros.
And weighing up all that I really can't see a way to make it viable.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden