hide python code !

[Slawomir Nowaczyk]

On Wed, 16 Aug 2006 18:35:37 -0700
enigmadude <enigmadude at rock.com> wrote:

#> Slawomir Nowaczyk wrote:
#> > On Thu, 10 Aug 2006 17:35:27 -0700
#> > enigmadude <enigmadude at rock.com> wrote:
#> >
#> > #> 2. I've never done this, but you might be able to encrypt or otherwise
#> > #> turn you modules into binary form, and then use a clever import
#> > #> hook.
#> >
#> > Please observe that whatever the "clever import hook" is, it actually
#> > needs to know the way to *decrypt* the module (secret key or
#> > whatever). It means that if somebody decompiles the importing code, he
#> > can just as well decompile the "hidden" one.

Please do not top-post...

#> I'm pretty sure that just because someone is familiar with the PGP
#> sources, for example, doesn't mean that they have the necessary keys to
#> access other people's data across the internet. Also, I'm pretty sure I
#> know how a prison door lock works, but if I'm behind bars and don't
#> have the key, I'm still screwed.
#> 
#> I believe the same things applies here. Just because you can see the
#> import code, depending upon what it does, if it requires (for example)
#> a key in order to decrypt the binary data before the modules can be
#> loaded, then no matter how much you understand the import code, the
#> data itself (that is the binary encrypted modules) is still useless to
#> you.

Not really. The thing is, whatever data is actually required to
perform the decryption, *must* be available in the importing code...
as this code needs to -- by definition -- be able to decrypt the
binaries into a form understandable by the CPU. After all, the code is
supposed to actually work.

As far as your analogy goes, you *do* have a key to the prison door,
because you are *expected* to be able to let yourself out.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk at cs.lth.se )

War doesn't determine who's right, war determines who's left.