Dann unterbiete ich das mal: Ein Versuch, Hash ist 23be5da22193ca74d2bf7c6a5322a0a6. Bin ich jetzt ein Glückspilz oder ein Spielverderber?Crackus hat geschrieben:PS: Rekord liegt immer noch bei 1.900.000
PyLotto
"Der Dumme erwartet viel. Der Denkende sagt wenig." ("Herr Keuner" -- Bertolt Brecht)
@ Trundle wie haste das gemacht???
habe ich i-wo den salt reingeschrieben?? kann man die *.so oder die *.exe dateien
entschlüsseln??
@Leonidas
hmm das programm sollte die variable count übernehmen salt dazu md5 hash daraus machen und das wieder ans pythonscript übergeben dann könnte man das script reinsetzen und ne mini C-File
habe ich i-wo den salt reingeschrieben?? kann man die *.so oder die *.exe dateien
entschlüsseln??
@Leonidas
hmm das programm sollte die variable count übernehmen salt dazu md5 hash daraus machen und das wieder ans pythonscript übergeben dann könnte man das script reinsetzen und ne mini C-File
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Die Shared Objects sind unnötig, da das Executable statisch gelinkt ist und ja, dein Salt steht in der Datei drin und lässt sich mit einem Debugger auslesen.Crackus hat geschrieben: habe ich i-wo den salt reingeschrieben?? kann man die *.so oder die *.exe dateien
entschlüsseln??
Das hat genau das gleiche Problem wie dein erster Ansatz. Ist sogar noch einfacher weil das Executable viel überschauberer ist als dein 1,7 MB großer BLOB.Crackus hat geschrieben:hmm das programm sollte die variable count übernehmen salt dazu md5 hash daraus machen und das wieder ans pythonscript übergeben dann könnte man das script reinsetzen und ne mini C-File
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Es wurde schon desöfteren hier im Forum darauf hingewiesen, dass py2exe, PyInstaller etc. keinen Schutz bieten, sondern dafür gedacht sind, dass man Python-Skripte auf Maschinen ausführen kann, auf denen kein Python installiert ist. Also dachte ich mir, dass man das doch einmal demonstrieren könnte.
PyInstaller war neu für mich, ich hatte mich zuvor nur bereits einmal ausgiebig mit py2exe befasst, aber vom Grundprinzip arbeiten die alle gleich und unterscheiden sich eben in den Details. Der Versuch, die ausführbare Datei mit 7zip zu entpacken, schlug fehl, also ist es nicht einfach ein zip-Archiv, das an die exe (bestehend aus dem Bootstrapping-Code) gehängt wird. Also habe ich in den Code von PyInstaller geschaut, um zu sehen, wie dein Skript zum Ausführen vorbereitet wird und dann ausgeführt wird. Da ich mich nicht mit den tiefsten Interna von PyInstaller befassen wollte, habe ich mich dazu entschlossen, an den Code mit Hilfe eines Debuggers (gdb) zu gelangen, da ich mich damit nicht mit dem Entpacken befassen muss. Hilfreich dabei war, dass PyInstaller mit Debug-Informationen gebaut war, die PyInstaller-Version dazu zu erraten, war nicht weiter schwer. Es hat dann also einfach gereicht, einen Breakpoint auf "launch.c:854" zu setzen, dort wird nämlich das Skript dann ausgeführt (``PyRun_SimpleString(data)``) und man kann sich den Inhalt von `data` einfach ausgeben lassen, was in dem Fall dann einfach das Skript ist. Es ist also sogar extrem einfach, an den Hash zu kommen, man muss sich nicht einmal mit Bytecode herumschlagen.
Später, nach weiterer Betrachtung des PyInstaller-Codes, habe ich dann noch diesen Entpacker geschrieben, mit dem man sehr einfach an den Quelltext von deinem Skript kommt, ohne sich mit einem Debugger herumschlagen zu müssen oder die ausführbare Datei irgendwie ausführen zu müssen.
PyInstaller war neu für mich, ich hatte mich zuvor nur bereits einmal ausgiebig mit py2exe befasst, aber vom Grundprinzip arbeiten die alle gleich und unterscheiden sich eben in den Details. Der Versuch, die ausführbare Datei mit 7zip zu entpacken, schlug fehl, also ist es nicht einfach ein zip-Archiv, das an die exe (bestehend aus dem Bootstrapping-Code) gehängt wird. Also habe ich in den Code von PyInstaller geschaut, um zu sehen, wie dein Skript zum Ausführen vorbereitet wird und dann ausgeführt wird. Da ich mich nicht mit den tiefsten Interna von PyInstaller befassen wollte, habe ich mich dazu entschlossen, an den Code mit Hilfe eines Debuggers (gdb) zu gelangen, da ich mich damit nicht mit dem Entpacken befassen muss. Hilfreich dabei war, dass PyInstaller mit Debug-Informationen gebaut war, die PyInstaller-Version dazu zu erraten, war nicht weiter schwer. Es hat dann also einfach gereicht, einen Breakpoint auf "launch.c:854" zu setzen, dort wird nämlich das Skript dann ausgeführt (``PyRun_SimpleString(data)``) und man kann sich den Inhalt von `data` einfach ausgeben lassen, was in dem Fall dann einfach das Skript ist. Es ist also sogar extrem einfach, an den Hash zu kommen, man muss sich nicht einmal mit Bytecode herumschlagen.
Später, nach weiterer Betrachtung des PyInstaller-Codes, habe ich dann noch diesen Entpacker geschrieben, mit dem man sehr einfach an den Quelltext von deinem Skript kommt, ohne sich mit einem Debugger herumschlagen zu müssen oder die ausführbare Datei irgendwie ausführen zu müssen.
"Der Dumme erwartet viel. Der Denkende sagt wenig." ("Herr Keuner" -- Bertolt Brecht)
krass ich hab zwar nur die hälfte verstanden aber echt krass^^
okay das heißt wenn man etwas wirklich "geheim" halten will sollte man noch C lernen um Python optimal gebrauchen zu können (Java file also *.class kann man sich auch anschauen ((oder??)) )
naya C wollte ich mir so oder so mal anschauen
Gibt es noch eine andere möglichkeit pythonabschnitte zu verschlüsseln??
okay das heißt wenn man etwas wirklich "geheim" halten will sollte man noch C lernen um Python optimal gebrauchen zu können (Java file also *.class kann man sich auch anschauen ((oder??)) )
naya C wollte ich mir so oder so mal anschauen
Gibt es noch eine andere möglichkeit pythonabschnitte zu verschlüsseln??
Warum möchtest du das machen? Es gab schon häufiger Diskussionen dazu hier im Forum (im Wiki gibt es auch eine Seite, die "Aufklärung betreibt"). Was gefällt dir an Open Source nicht? Denke mal darüber nach, wie du deine Zeit besser investieren kannst: Indem du dich fragst, wie man 1. Programme "verschlüsseln" kann oder 2. gute Programme schreiben kann, von denen viele andere Menschen profitieren können.
Selbst C lässt sich Deassemblieren... Damit wird zumindest ungefähr klar, was passiert. Nützen tuts dann nicht viel, aber wenn man etwas _wirklich_ erfahren will, kann man es so. Java lässt sich auch wieder Entschlüsseln, aber dann sind alle Kommentare und Variablennamen und sowas weg... Also relativ schwer dann zu verstehen. Ich halt das alles sowieso für nicht so sinnvoll...Crackus hat geschrieben:krass ich hab zwar nur die hälfte verstanden aber echt krass^^
okay das heißt wenn man etwas wirklich "geheim" halten will sollte man noch C lernen um Python optimal gebrauchen zu können (Java file also *.class kann man sich auch anschauen ((oder??)) )
naya C wollte ich mir so oder so mal anschauen
Gibt es noch eine andere möglichkeit pythonabschnitte zu verschlüsseln??
Es ist besser, wenn alle von deinem Quellcode profitieren.
- Rebecca
- User
- Beiträge: 1662
- Registriert: Freitag 3. Februar 2006, 12:28
- Wohnort: DN, Heimat: HB
- Kontaktdaten:
Crackus: Das mit dem "verschluesseln" eines Programm ist ein prinzipielles Problem: Du kannst ein Programm nicht wirkungsvoll verschluesseln, da der Benutzer es zum Ausfuehren ja wieder entschluesseln muss.
Offizielles Python-Tutorial (Deutsche Version)
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
@BlackVivi: Bei Java sind die Variablennamen fast alle noch da, es sei denn man macht aktiv etwas dagegen, in dem man zum Beispiel "Obfuscator"-Programme von Drittanbietern drüber laufen lässt.
Nur lokale Namen in Methoden sind in der Regel weg, an ``private``-Namen kommt man aber dran.
Nur lokale Namen in Methoden sind in der Regel weg, an ``private``-Namen kommt man aber dran.
Ich meine gelesen zu haben, dass der Java-Compiler einen Obfuscator anwendet... Hab mich wohl verlesen. Vielen Dank, dass du mich aufgeklärt hastBlackJack hat geschrieben:@BlackVivi: Bei Java sind die Variablennamen fast alle noch da, es sei denn man macht aktiv etwas dagegen, in dem man zum Beispiel "Obfuscator"-Programme von Drittanbietern drüber laufen lässt.
Nur lokale Namen in Methoden sind in der Regel weg, an ``private``-Namen kommt man aber dran.


Das macht die ganze Javageschichte ja noch unsicherer. Aber ich find diesen ganzen Codeschutz in 99.99% eh unnütz. Wenn deine Idee so gut ist, verdienst du damit Geld, egal ob jemand dir deinen Code stiehlt.. denn damit du so eine einzigartige Idee erstellst, dass sie schützenswert ist, musst du schon recht ... klug und gewitzt sein. Und solche Leute kommen eigentlich immer weiter im Leben oO'
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, ich habs selbst versucht, aber auf die Idee mit dem Debugger bin ich nicht gekommen. "Viel zu lernen du noch hast" wäre das Motto für mich heute.Crackus hat geschrieben:krass ich hab zwar nur die hälfte verstanden aber echt krass^^
Und wo ist C an dieser Stelle sicherer. Hast du schonmal überlegt, wie Cracker vorgehen? Viele von den gecrackten Programmen sind in C geschrieben. Sogar solche die aufwendiger geschützt sind als sich nur auf Binärcode in dem der Algorithmus versteckt ist zu stützen.Crackus hat geschrieben:okay das heißt wenn man etwas wirklich "geheim" halten will sollte man noch C lernen
C zu lernen ist sinnvoll, aber nicht aus diesen Gründen.
Wo hat Geheimhaltung von Code was mit der optimalen Nutzbarkeit von einer Programmiersprache zu tun? Sieh es ein: wenn du nicht schon Schutz auf der Hardware implementierst, wie einige Konsolen das machen hast du überhaupt keine Chance deine Geheimnisse in inrgenwelchen Binärdateien zu verstecken. Ein talentierter, motivierter Angreifer wird dahinterkommen, siehe auch die Konsolen-Hacks.Crackus hat geschrieben:um Python optimal gebrauchen zu können
Auch Chips bieten keinen effektiven Schutz. In einer c't-Ausgabe ist ein faszinierender Artikel wie Bazahlkarten-Chips geknackt wurden indem die Chips Stück für Stück auseinandergenommen worden sind und der Algorithmus rekonstruiert wurde und dann ausgehebelt wurde.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice