Code obfuscation / decompilers?

Stephen Hansen stephen at cerebralmaelstrom.com
Sat Oct 7 02:32:25 EDT 2000


Do you know what I think? You are choosing the wrong tool for the job.
Python is an interpreted language, and as such, is available to the
end-user. Sure, you can freeze, compile into byte-code, and what not,
but those are not really sufficient for your needs.

This doesn't seem to be a situation where Python is the best thing to
use, if the 'obfuscation' is so important to you... but a sugguestion,
anyways...

Store your key-encryption code in a C extention-module that you load,
and distribute in a compiled form. Now, don't store /just/ the test code
in there, like:

	if cmodule.isvalidated():
		print "You registered!"
	else:
		pritn "You didn't register!"

That wouldn't help you, because the person could just change the
function call.. what you should also do is wrap some essential
functionality into that cmodule; not most of it, and perhaps the piece
where speed is most important... You can still have an 'isvalidated'
function, but then when you call

	cmodule.sendmessage(message)

To do some important task that is central to your program's proper
operation, then it will check for validation and break if its not valid.

That's the only way I can think you could possibly accomplish 
your task.

--Stephn

In article <39deba0b_2 at corp.newsfeeds.com>, "Joshua Muskovitz"
<josh at open.com> wrote:

>> This is a hopeless task: at some point your application must finally
>> come down to a yes/no decision -- yes, it *can* toggle that bit
>> (because the license is valid) or no, it *can not* toggle that bit (the
>> license doesn't conform).
>>
>> And at that point, the hacker simply changes your code to say "yes,"
>> all the time.
> 
> Yes, the same logic applies to the lock on m front door.  Anyone who
> comes all the way to my door intending to come in, is going to come in. 
> The lock only has to be good enough to force them to go through a
> window.  Any more is a waste.
> 
> I'm trying to avoid tempting those people who are otherwise honest, but
> might "just be curious".  Also, as I said previously, sometimes we are
> forced to live with the mistakes of others.  Sometimes these include
> poor designs.  To argue over whether it should have been done that way
> in the first place is basically peeing into the wind.  It is what it is,
> and so the questions stand.
> 
> Having looked at the output of dis.dis() on my code, it is obvious that
> there is a lot of information still in there which could be removed
> without affecting the behavior of the code.  The names of local
> variables is an obvious place to start.  Their original names contain
> big clues as to their purpose.  Names like "key", "count", "validtags"
> are a lot more useful to someone perusing the code than "foo", "bar",
> "gronk", or even "_1", "_2",
> "_3".  Randomizing the order of the list of constants would help to
> reduce one's ability to see patterns in the data.  Shuffling the order
> of instructions, adding in jumps, small amounts of dead code, removing
> line numbers, all of these techniques could be done such that you could
> obfuscate the same chunk of code multiple times and get different
> results each time.
> 
> Ah well.  It would appear that the answer is "no, there aren't any handy
> code obfuscators out there."  Maybe I'll write one, if I get a chance.
> 
> -- j
> 
> 
> 
> 
> 
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----



More information about the Python-list mailing list