decompilieren verhindern, erschweren?

00Albert

Hi

ich wollt ein kleines Konsolenprogramm schreiben, das einen Sensiblen Vorgang abarbeiten soll. Mein Problem dabei wäre jetzt, das man Programme ja decompilieren kann. Auch wenn das aufwendig ist, wäre die Möglichkeit gegeben den Ursprünglichen Inhalt des Programms zu entschlüsseln.

Meine Frage wäre jetzt kann man das irgendwie verhindern oder erschweren? Ich dacht dabei erst an C, da Java und die anderen Bytecode sprachen ja noch leichter zu entschlüsseln sind... oder was gibt es sonst für Sprachen die geeignet wären?

mfg

verhindern ist unmöglich

00Albert

nagut aber wie erschwert man sowas? ich nhem nämlich nicht an, das es irgendein verschlüsselungs tool gibt was man einfach nur drüberlaufen läßt etc.

akari

Hallo

Es gibt Laufzeit-Packprogramme, wo das Programm nach dem Kompilieren extra noch gepackt wird und erst zur Laufzeit on the fly wieder entpackt wird. Das ist zwar eigentlich nicht zum "verschleiern" gedacht hilft aber auch.
Ansonsten sind immer verrückte Pointeroperationen hilfreich, die schon im Quellcode wirr aussehen.

bis bald
akari

akari schrieb:

Es gibt Laufzeit-Packprogramme, wo das Programm nach dem Kompilieren extra noch gepackt wird und erst zur Laufzeit on the fly wieder entpackt wird.

Richtig, da wäre z.B. upx zu nennen

Allerdings gibt es auch kommerzielle Anwendungen, die in der Tat verschlüsseln (und bei denen das Verhindern der Erstellung eines Dekompilats auch das hauptsächliche Ziel ist). Sicher sind die aber meines Wissens alle nicht; werden alle früher oder später gecrackt.

da gibts schon einige thread dazu

00Albert

nunja es reicht mir ein hinreichender schutz Es soll den angreifer nur so lange beschäftigen, das er die Lust daran verliert oder es zu teuer wird ...

Ich hab ja schon überlegt ob man nicht einfach eine veraltete sprache benutzt sowas wie Pascal aber ich vermute als compilat ist es letrzendlich immer das selbe ergebnis, egal welche sprache man benutzt.

pale dog

00Albert schrieb:

Ich dacht dabei erst an C, da Java und die anderen Bytecode sprachen ja noch leichter zu entschlüsseln sind

ich kenne kein programm, das aus einem image (exe) wieder astreinen c-code machen kann (ganz im gegensatz zu java-decompilern, die teilweise den original-quelltext wieder hervorzaubern können).
es gibt aber tolle disassembler, die versuchen, das programm nebenbei zu entschlüsseln und den asm-output mit hilfreichen kommentaren bestücken.
also, so'n exe-packer, wie akari vorgeschlagen hat, ist schon mal nicht schlecht. du solltest aber bedenken, dass es auch tools gibt, die laufende prozesse tracen, einfrieren und snapshots davon speichern können.

pale dog schrieb:

also, so'n exe-packer, wie akari vorgeschlagen hat, ist schon mal nicht schlecht.

Du weißt schon, dass die "freien" Packer auch so gut wie alle eine Entpackfunktion besitzen? Wie akari schon gesagt hat: Das Ziel ist es bei denen nicht, irgendetwas zu verschleiern. Und jeder Cracker, der über das Scriptkiddy-Level hinaus ist, wird sich von sowas garantiert keine 20 Minuten aufhalten lassen

00Albert

ich hab mal etwas rumgesucht und bin darauf gestoßen: Obfuskatoren

Das sollen Programme sein die das eigentliche Programm verschleiern... hat wer sowas schonmal ausprobiert und kann sagen was es taugt?

Anscheinet gibt es für die ganzen Byte-code-Sprachen einen oder mehrere aber für normales (Ansi)C hab ich nichts gefunden ...
Achso und die forensuche war nicht sehr aufschlußreich

xindon

Wenn du nich grad für Debug kompilierst, werden doch eh nicht die Variablen/Methoden/etc.-Namen gespeichert, oder? Deswegen ist ein Obfuscator da ja ziemlich sinnlos.

00Albert

ich weiß es nicht drum frug ich

Gibt viele Tricks um die Anwesenheit eines Debuggers zu erkennen und dann etwas anderes zu tun, oder Assembler-Sequenzen die den Disassembler austricksen. Aber das sind alles nur Stolpersteine die einen Cracker nicht abhalten, sondern motivieren weiterzumachen. Alles was du dir erkaufst ist etwas mehr Zeit bis es jemand geschafft hat.
Mit den heutigen Disassemblern und Debuggern ist es sehr einfach Assembler-Code/den Programmfluss nachzuvollziehen.

Wenn du es den Leuten schwer machen willst, dann schreib dir ne VM und schreib dein Programm in einem Bytecode für diese VM (bzw. ich einer Sprache die dann in diesen Bytecode übersetzt wird). Das ganze packst du dann zusammen in eine Exe und kannst den Bytecode und dessen Ausführung mit oben genannten Tricks noch beliebig "verschnörkeln".
Das ist natürlich ein sehr teures und aufwendiges Verfahren aber es ist auch sehr effektiv.

thordk

die "sensible" funktionalität auf einen sicheren server auslagern, schon hat kein anwender mehr zugriff drauf. verteilte systeme gibs nicht ohne grund.

CStoll

00Albert schrieb:

Anscheinet gibt es für die ganzen Byte-code-Sprachen einen oder mehrere aber für normales (Ansi)C hab ich nichts gefunden ...
Achso und die forensuche war nicht sehr aufschlußreich

Für C wird der Obfuscator doch schon mitgeliefert (auch wenn er sich da "Compiler" nennt :D). *scnr* Aus einem compilierten Programm (ohne Debug-Informationen) kannst du zwar wieder einen C-Quelltext produzieren (und es gibt auch keinen Weg, das zu verhindern), aber der wird in den meisten Fällen nicht viel Ähnlichkeit mit dem haben, was du geschrieben hast (das fängt damit an, daß die Variablennamen unterwegs verlorengegangen sind, und hört bei verschiedenen Möglichkeiten auf, wie bestimmte Anweisungen optimiert und umgeordnet werden können).

00Albert

ok, dann anders gefragt...

Gibt es grobe schätzungen wie lange ein Versierter Cracker braucht um aus einer Exe datei den C-code so zu extrahieren, das er den inhalt des Programmes nachvollziehen, bzw. reproduzieren kann?

Denn ich nhem an je länger ein Programm ist um so länger dauert das entschlüsseln des inhaltes auch

Jo.. junk code ist sicher ne gute sache.. (ich hab schon programme gesehen, da war fast alles junk.. das treibt den haertesten cracker inden wahnsinn) was nicht heisst, das er aufhoert.. wie lange das braucht.. nen guter cracker?? ne woche vl..

thordk

da kann man nicht wirklich ne zeitangabe geben. nen cracker wird nicht das gesamte programm verstehen woll. alles was der cracker will, ist gezielt eine bestimmte stelle des programms zu finden. vielleicht die stelle, an der eine registrierung überprüft wird. oder die stelle, an der ein passwort gespeichert ist. ein versierter cracker wird sowas sehr schnell finden, da er genau weiss, wo und wie er zu suchen hat.

solange man sensible daten nicht an stellen auslagert, auf die niemand zugriff hat, wird man diese niemals ausreichend verschleiern können. selbst eine 2048 bit starke verschlüsselung ist nicht einen pfifferling wert, wenn der unverschlüsselte wert zu irgendeinem zeitpunkt auf dem anwenderrechner vorliegt.

bin deshalb der radikalen meinung, dass jegliches verschleiern von inhalten überflüssiger non-sense ist. sollte eine funktionalität kritisch und schützenswert sein, so muss sie ausgelagert werden. alles andere ist vergebliche lebesmüh.

00Albert

naja ich werde kein password in der datei stehen haben sondern es ist viel mehr eine verarbeitungsvorschrift wie das passwort gebildet wird und es zeigt auf sogenannte schlüsseldateien, die halt benötigt werden um das ganze zu komplettieren.