[python-de] .pyc und .pyo

Christian Tismer tismer at appliedbiometrics.com
Mon Feb 15 12:43:30 EST 1999


Martin v. Loewis wrote:
Status: RO

> 
> > Da kommt halt Maschinencode für eine Stackmaschine zurück.
> > Man kann durchaus etwas Python-ähnliches draus erzeugen,
> > aber das braucht schon mehr als einen schlauen Nutzer, da
> > brauchste 'nen alten Hacker.
> 
> Wenn jetzt jemand, sagen wir, einen Decompiler erzeugen würde, ...
> würde derjenige dann ausgebuht werden?

Ganz im Gegentum, ich fände das prima.

Nicht daß ich favorisiere, daß jetzt jedermann herumhäckt,
aber mit den vorhandenen Tools und etwas Gehirnschmalz
ist es eh nur relativ wenig Arbeit, also macht man eine
Tugend draus.

Der Maschinencode ist von sich aus schon äußerst lesbar,
und es ist 1.) sowieso möglich, eine Quelle zu erzeugen,
die zu diesem Code gehört, sowie 2.) recht wahrscheinlich,
daß man ein dem Original recht ähnliches Stück Python
bekommen könnte.

Ein kompiliertes .exe ist da wesentlich weniger zugänglich,
Quellcodeerzeugung für etwa C oder C++ dürfte dem Original
recht unähnlich sein, und was ich so kenne erzeugt auch
nur Assembler-Code. 

Also wie soll man Python-Code vor dem lieben Leser schützen?

Wie schon erwähnt, kann eine Permutation der Opcodes
recht nützlich sein. Dies kann auch so subtil gemacht werden,
daß man "richtig aussehende" Programme bekommt, die nur
nicht richtig laufen. Man permutiere etwa die Bedeutung
einiger binärer Operatoren, addiere gewisse Offsets
zu Sprungadressen, permutiere die Indizierung lokaler
Variablen, ...

Einfacher ist es, den Python-Code mit Zlib komprimiert
zu halten, vor der Ausführung zu entpacken und das
Entpacken vielleicht ein wenig zu verschleiern, indem
man den Zlib-String ein wenig scrambled.

Sicher ist das alles nicht. Als relativ sicher empfinde
ich, wenn man beide Techniken anwendet, weil sich der
komprimierte Code einer statistischen Opcodeanalyse 
entzieht, und die Dekomprimierung nur klappt, wenn
man die Opcodes kennt. Wenn dies dann auch noch 
kundenspezifisch generiert wird, hat man eine relativ
große Hürde aufgebaut, weil die Public-Domain-Tools
nutzlos sind. 

Was die Chance bietet, sich das Knacken des
eigenen Programms bezahlen zu lasssen :-)

> P.S. Nein, noch habe ich keinen. Und für Java gibt es schon länger
> welche...

Ok, wer macht den Anfang?

Vorschlag: Wie wär's gleich mit einem Zusatzmodul zum Schützen,
welches man importieren kann? Das enthält dann einen
alternativen Interpreter und am besten auch noch ein 
modifiziertes Zlib...

Was habt Ihr sonst noch an Ideen zum Programmschutz?

Möglichkeiten gibt es sicher viele. Eins fällt mir gerade ein
(mit dem Hintergedanken von "Winnowing and Shuffing"):
Erzeuge viele viele Versionen eines Programmstückes, und auf
subtile Weise wird dann die eine "richtige" ausgeführt?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://pgp.ai.mit.edu/
     we're tired of banana software - shipped green, ripens at home



__________________________________________________
Python-de Liste  -  python-de at starship.skyport.net
http://starship.skyport.net/mailman/listinfo/python-de



More information about the Python-de mailing list