Protecting Python source

Discussion in 'Python' started by Alan Sheehan, Nov 26, 2004.

  1. Alan Sheehan

    Alan Sheehan Guest

    Hi pythonistas,

    I am looking for methods of deploying applications with end users so
    that the python code is tamper proof. What are my options ?

    I understand I can supply .pyc or .pyo files but they can easily be
    reverse engineered I am told.

    Is it possible to load the scripts from zip files where the zip files
    are password protected ?

    Any other ideas ?

    Many thanks,

    Alan Sheehan, Nov 26, 2004
    1. Advertisements

  2. To get more meaningful answers, please expand on what exactly you mean with
    "tamper proof". What is the attacker scenario? Are there passwords for external
    systems embedded in the Python source code, or what's the deal about it?

    -- Gerhard

    Version: GnuPG v1.2.4 (GNU/Linux)

    -----END PGP SIGNATURE-----
    Gerhard Haering, Nov 26, 2004
    1. Advertisements

  3. Alan Sheehan

    Nick Coghlan Guest

    If all you want to prevent is casual user tinkering, just shipping compiled
    bytecode is probably enough. (yes it *can* be decompiled, but a casual user
    isn't going to bother, any more than they bother disassembling standard binaries).

    For slightly greater obfuscation, push the key parts you wish to obscure into a
    C/C++ extension module.

    There's nothing to be done to stop the determined cracker, though, as anyone who
    can effectively reverse engineer pure C++ programs is going to be able to figure
    out how to interpret .pyc files pretty quickly.
    Since the interpreter needs to read your zipfile, there are potential problems
    with that. I believe it could be done, though. You'd need a C extension module
    which knew the password and installed a custom import hook to handle opening the
    zip file. And disassembling the extension module would also give an attacker
    the password, thus allowing them access to the zipfile.

    So, as Gerhard said, it really depends on what you mean by "tamper proof".

    Nick Coghlan, Nov 26, 2004
  4. For py2exe created distributions, the simplest and imo most effective
    thing is to specify a different extension for the source archive, maybe
    app.lib instead of This way, there's at least no hint that
    is is a zip archive.

    For passwords, aren't there lots of zipfile password crackers out there?
    And even in a password protected zipfile you are still able to see the
    filenames iirc, and unless that has changed.

    Thomas Heller, Nov 26, 2004
  5. Alan Sheehan

    Josef Meile Guest

    I am looking for methods of deploying applications with end users so
    You could try to obfuscate the code with the pyobfuscate package. The
    scripts will be easy to reverse, but difficult to understand. I haven't
    tried it because I haven't had this need, but it shoul work:

    Josef Meile, Nov 26, 2004
  6. Alan Sheehan

    RCS Guest

    An interesting question is, what makes your source code so innovative as
    to mandate this tamper proof thing?

    Just wondering.

    RCS, Nov 27, 2004
  7. Like for any other language, the code you distribute _can_ be
    decompiled, analyzed, studied, and modified, by any attacker determined
    enough to bypass the technical and legal barriers. If your code is
    worth protecting, then it's worth attacking.

    Like for any other language, a solid solution is to put crucial parts of
    your application on a server that is entirely under your control,
    accessed by the rest of the application (the part that you distribute)
    via any distributed processing technology -- Corba, XML-RPC, pyro,
    whatever. The pluses and minuses are obvious: your application will run
    only with network access (which is more and more widely available but
    not yet universal); OTOH, you can exert fine control on who and when can
    access the crucial parts (by subscription, pay per use, whatever
    business model you fancy). It's the only approach that can be made as
    solid as the server you use, which is _very_ solid. Even burning some
    algorithms into a dedicated chip is less robust, since chips _do_ get
    reverse engineered / decompiled too.

    If all you want is to make the barriers as high as reasonably feasible,
    crypted archives with a dedicated pyrex-coded module to decrypt and make
    them accessible to the main program is one way. Legal barriers however
    tend to work better than technical ones, which may be perceived as
    interesting challenges and stimulate attacks. Note that just about any
    piece of software that's widespread, whatever language and protection
    scheme it may have used, is available in cracked form in the `warez'
    circuits. Go server-side as much as you can, and rely on the awesome
    coercive powers of the state for the rest -- "go legal, young man".

    Alex Martelli, Nov 27, 2004
  8. Use Pyrex in order to convert the critical parts to C modules ...


    Armin Steinhoff, Nov 29, 2004
  9. Alan Sheehan

    Peter Maas Guest

    I can think of 3 reasons to prevent tampering:

    - You need money and want to sell your software on a "per seat" basis.

    - You don't want customers to fiddle with your code and then innocently
    call for support and demand "bug fixes" for free.

    - Your customer demands closed source because the code contains trade

    Protecting source has nothing to do with innovation. It's about making
    Peter Maas, Nov 29, 2004
  10. Alan Sheehan

    Craig Ringer Guest

    If you mean that you therefore must add built-in copy-protection, then
    sure. Users will always get around it if they really want to, so
    tamper-resistance is probably closer to the truth, but it'll slow them

    On the other hand, one can license software per-seat quite effectively
    without software enforcement, or with only informative software
    enforcement ("By the way, you appear to be over your seat count."). In
    many cases this is good enough - the user can always crack / steal your
    software, tamper resistant or not (witness: the games industry), and
    code without copy protection is a LOT friendly.

    For example, my employer currently relies on software that has a dongle.
    The software manufacturer has gone out of business, so if that dongle
    dies we're in trouble, as development of a replacement is moving slowly.
    In future, if we're given the choice between a product that's superior
    in price or functionality but has opressive copy protection and one
    that's more limited or more expensive, but has no software enforcement
    of copy protection, we'll buy the inferior or overpriced one.

    We're quite capable of monitoring our own license compliance. Those who
    aren't are also generally quite capable of 'fixing' the software, tamper
    resistant or not, so I really don't see the point.
    There, what you really want is tamper-evident code not tamper-proof
    code. That's quite a bit more practical IMO, and may be a good place to
    look at digital signing.
    My understanding is that that's never guaranteed safe, no? Or are
    restrictions against reverse engineering now commonly enforcable?
    Craig Ringer, Nov 29, 2004
  11. Alan Sheehan

    Peter Maas Guest

    It's not guaranteed but if protection works in 99.9% of all instal-
    lations it makes sense, at least if you are not producing highly
    visible software like Windows.

    Reverse engineering may be possible but in most cases it is a huge
    effort. Think of the samba project which builds Windows server
    software by analyzing network packets and this is probably easier
    than to analyze machine code.

    If the "reverse engineering" argument boils down to "protecting source
    doesn't make sense" then why does Microsoft try so hard to protect
    its sources?
    Peter Maas, Nov 29, 2004
  12. To avoid embarassment.
    Grant Edwards, Nov 29, 2004
  13. Alan Sheehan

    Dave Reed Guest

    +1 QOTW
    Dave Reed, Nov 29, 2004
  14. +1 QOTW
    Marco Aschwanden, Nov 30, 2004
  15. Alan Sheehan

    Peter Maas Guest

    :) This cannot be the whole truth otherwise they wouldn't release
    embarrasing binaries.
    Peter Maas, Nov 30, 2004
  16. Alan Sheehan

    Guest Guest


    Damn you!! Coke is so hard to clean off a keyboard!!

    Good laugh, thankyou so much :-D
    Gustavo Córdova Avila <>
    *Tel:* +52 (81) 8130-1919 ext. 127
    Integraciones del Norte, S.A. de C.V.
    Padua #6047, Colonia Satélite Acueducto
    Monterrey, Nuevo León, México.
    Guest, Nov 30, 2004
  17. Alan Sheehan

    Peter Hansen Guest

    Yeah, I hate the way the powder builds up between the keys.


    You meant the _drink_...

    Peter Hansen, Nov 30, 2004
  18. Alan Sheehan

    Lucas Raab Guest

    Nice. Very nice!!
    Lucas Raab, Nov 30, 2004
  19. +1 QOTW (Everyone else was doing it, I just wanted to be popular!)
    Leif K-Brooks, Nov 30, 2004
  20. Alan Sheehan


    Jul 28, 2014
    Likes Received:
    I know I'm responding to an old post, but we've developed a new solution I thought I'd share. You could deploy a customer loader with your script using signet ( Signet will scan your source and it's dependencies and calculate sha1 hashes which it embeds in a custom loader for your script. You deliver two files to your user, the loader and your script. The loader when run will re-verify the hashes before transferring control to your script. If your script or it's dependencies have been tampered with, it will emit an error and refuse to run the script.
    jamercee, Jul 28, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.