[Tutor] Need help with encoder & decryption keys

Andreas Kostyrka andreas at kostyrka.org
Mon Mar 3 14:28:11 CET 2008


And if it's a string constant, in many cases running strings (Unix 
program) on the pyc file will reveal it too.

All this basically turns down to the problem, that it's hard to embed an 
encryption key in a program, so that it's not possible to extract it.

Notice the the current crop of HDDVD/Blueray decrypters, that tend to 
derive their copy of the key by extracting it from legal software players.

(Hint: it's a basically unsolvable problem, notice how the industry 
"solved" it by making that kind of analysis illegal, DMCA is the hint here.)

If you want to have "typical" C program security for embedded key data, 
the only thing that you can do is to make a Pyrex module (Which gets 
compiled to C, and is loaded as an .so shared library).

As pointed out above, this is not really safe, it just makes it slightly 
harder to extract the data.

Some thoughts:

1.) the data cannot be made accessible to Python, or else you can read 
it out. That means decryption/encryption needs to be done in Pyrex/C. 
PLUS Pyrex should not use any Python functions/modules to achieve the 
goal. (import secretmodule ; print secretmodule.value. OR: import md5 ; 
md5.md5 = myLoggingMd5Replacement )

2.) the stuff done in your C module cannot be to trivial, or an attacker 
that is determinated can easily remove references to the module.

So to summarize: Your idea usually makes no sense. It clearly falls into 
the "know what you are doing and why" ** n category, with n > 1 ;)
There might be technical or legal reasons to do that, BUT they are 
really, really seldom.

And this category question is usually not really appropriate for a 
tutoring mailing list :)

The only way to make sure something is not compromised is to avoid 
giving it out completely, and put it on your own servers. Again, the 
above thoughts apply. Plus consider that your program is running in an 
environment that you do not control: E.g. even if you communicate via 
SSL and check certificates, and embed the CA certificate into your app 
so that it cannot be easily replaced. Consider loading a small wrapper 
for SSL_read/SSL_write via LD_PRELOAD. Oops, the user just learned the 
complete clear text of your communication. Worse if it's to simple he 
can just replace the data, worst case by loading a wrapper around 
openssl that mimics the server.

It's no fun, and the easiest way is to give your users the access (e.g. 
the source code). This stops the crowd that has to prove itself for the 
fun of breaking a security system. (And yes, there are people that do 
that). Then put your rules into the LICENSE. That lays out the rules 
what is allowed. And in some cases, add some lines that check 
"licenses", so a customer cannot claim that he ran your program 
unauthorized by mistake. Not much more you can do here, sorry.

Making it hard to remove the license check means just that the fun crowd 
might get motivated into breaking it. Leaving out at least some checks 
means that users can claim that they ran a copy of your program by 
mistake. That might have legal ramifications, and worse, in many cases 
(if you are not a member of BSA), you wouldn't want to sue a customer 
anyway, right? (Nothing surer to piss off a customer than to sue him.)

Andreas

Kent Johnson wrote:
> Trey Keown wrote:
>> is it
>> possible to decompile things within a .pyc file?
> 
> Yes, it is possible. There is a commercial service that will do this, 
> for older versions of Python at least.
> 
> To figure out a secret key kept in a .pyc file it might be enough to 
> disassemble functions in the module; that can be done with the standard 
> dis module.
> 
> And of course if you stored the secrets as module globals all you have 
> to do is import the module and print the value...
> 
> Kent
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor


More information about the Tutor mailing list