Code obfuscation / decompilers?

Blake Winton bwinton at tor.dhs.org
Fri Oct 13 22:55:04 EDT 2000


On Sun, 8 Oct 2000 23:16:12 -0400, Joshua Muskovitz wrote:
>"Lokie" <anthony at lokie.co.uk> wrote:
>> Why not then make the unlock code and key one and the same?
>>
>> For example if I know the user name in advance I can use that for
>> some simple (or as complex as you want) encryption/decryption of
>> the key to unlock the application. And having that key as a Python
>> code object which can then be exec'ed to perform the unlocking
>> operations (maybe some function redirection?) hides from your
>> casual cracker the means to steal your hard work.
>
>Sigh.  Because it is not within my power to modify the form of the
>key.  If I was really trying to create an ideal system, I would start
>from scratch.  I'm not.  I'm trying to create the "least sucky"
>solution, given the constraints imposed on me.

Sure, but you could encrypt the unlock code with the key, using
another encryption system.  XOR might even work, given the seemingly
random distribution of bytes in VM bytecode...  That would stop people
who don't have the key from reverse-engineering your code.  People who
do have the key would have an easier time of it, but there's no real
way around that, since they could always run the program under a
debugger...  I guess that shifts the problem into one of "What's the
chance that people can generate a key which would decrypt the code
string into a valid one that passes the key".  And the answer depends
largely on how you encrypt the code.

>This is the difference between real world coding and theory.

Sigh.  Surely part of the fun of real world coding is using the best
of the ideas from theory, and seeing how you can map them onto
reality.  I understand that you're frustrated by all the people
offering suggestions that you can't use due to constraints beyond your
control, but maybe you can use elements of some of their suggestions
within the constraints you have.  If not, then perhaps you haven't
expressed your opinion strongly enough.  I've worked on very few
projects where people, when confronted with strong assertions about
the infeasibility of requirements, weren't willing to at least discuss
their options.  Of course, I've only been in the industry for 8 years,
so I'm sure there's a lot of stuff I haven't seen...

Later,
Blake.
-- 
9:40pm up 52 days, 21:07, 2 users, load average: 0.02, 0.09, 0.07



More information about the Python-list mailing list