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@python.org > http://mail.python.org/mailman/listinfo/tutor _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
