Delphi-PRAXiS - Delphi Anwendungsspeicher schützen

Seite 2 von 2

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)

- - Delphi Anwendungsspeicher schützen (https://www.delphipraxis.net/120693-anwendungsspeicher-schuetzen.html)

Re: Anwendungsspeicher schützen

Was meinst du mit dem "richtigen Zeitpunkt"? Ich habe einen Haltepunkt auf die OnClick-Routine des Buttons gesetzt und bei dessen Erreichen den TControl.DefaultHandler-Haltepunkt aktiviert. Dort empfängt man dann hintereinander zweimal WM_SETTEXT: Einmal mit dem String 'Calculating' und beim zweiten Mal mit dem Zahlenstring. Letzteren verändert man dann.

Edit: Was ist an der zweiten Datei anders?

Re: Anwendungsspeicher schützen

Zitat:

Zitat von Apollonius

Sorry, war mein Fehler - hab da gerade was in meinem Kopf nicht beachtet. Vergiss die Aussage

Zitat:

Zitat von Apollonius

Edit: Was ist an der zweiten Datei anders?

Irgendwie ist heute nicht mein Tag - hab die falsche Version hochgeladen :oops:. Jetzt ist aber die Version online, die ich eigendlich hochladen wollte. Hab das handling etwas verändert und noch ein paar Überprüfungen eingebaut.

Re: Anwendungsspeicher schützen

Das ist jetzt mit meiner ursprünglichen Methode tatsächlich schwierig. Es geht aber auf andere Weise recht einfach: Über den Haltepunkt bei TControl.DefaultHandler erhält man alle möglichen Adressen des Labels. Diese notiert man sich. Dann wartet man, bis man am Ende der OnClick-Routine des Buttons ist (Hast du diese eigentlich von Hand verändert? Dieses einfach call direkt gefolgt von einem ret sieht nicht nach dem Delphi-Compiler aus.) und schaut dort nach, ob an den notierten Adressen tatsächlich ein Label steht. Falls ja, ändert man einfach die Zeichenkette, auf die FText zeigt. An dieser Stelle sind alle deine Überprüfungen bereits abgelaufen.

Re: Anwendungsspeicher schützen

Zitat:

Zitat von Apollonius

Also die Exe an sich hab ich nachträglich nicht mehr geändert, nur noch zwei Resourcen gelöscht, sonst nichts. Also das was am Ende an Code rauskommt ist wirklich vom Delphi-Compiler. Im Quelltext gibt es kaum direkte Assembler-Anweisen. Die Exe ist ja relativ groß und das hat auch einen Grund.

Da ich ja Labels verwende, ist die Anwendung trotzdem relativ einfach zu knacken, da man ja - wie du schon sagst, einfach WM_GETTEXT und WM_SETTEXT abfangen und weiterverarbeiten kann. Wenn ich das ganze aber z.B. per OpenGL alles selbst zeichne und die Windows-Botschaften nichts mehr mit der Anzeige zu tun haben, wirds wahrscheinlich noch schwerer. Ich hab die Anwendung innerhalb von ca. 20 Minuten zusammengestrickt, das wäre mit OGL ohne entsprechendes Framework nicht so schnell gegangen.

Das mit Pointer auf Label überprüfen ist eine sehr gute Idee, da diese Methode bei mir im Moment noch funktioniert. Ich erstelle zwar bei jedem Button-Click jeweils ein neues Label und lösche die alten, jedoch bekommen die neuen Labels natürlich auch noch die WM_SETTEXT-Anweisungen.

Jetzt ist natürlich noch die Frage ob man durch Modifizieren des Assembler-Codes relativ einfach das Knacken kann, also sozusagen wirklich als Crack. Also wenn interesse daran besteht, kann ich meine Methode auch verraten.

[Edit]Ach noch was: wenn du den Label-Text im Nachhinein drückst änderst und nochmal auf "Anzeigen" klickst, sollte es einen Fehler ausgeben[/Edit]

Re: Anwendungsspeicher schützen

Ich glaube, dass das Knacken durch ein Framework wie die VCL oder auch OpenGL vereinfacht wird. Es gibt für einen Cracker einfach zu viele Möglichkeiten, sich einzuhängen. Beispielsweise war ich ja bei deinem Programm gar nicht auf die Fensternachrichten angewiesen, sondern lediglich darauf, die Labeladressen herauszufinden. Das hätte ich auch tun können, indem ich in TObject.NewInstance die übergebene Klassenreferenz ansehe. Allein dadurch, dass das Programm in Delphi geschrieben ist und ich Delphi recht gut kenne und beherrsche, kann ich mir sehr viel Arbeit ersparen.
Andererseits ist das Beispielprogramm natürlich nicht realistisch. Wenn ich es darauf angelegt hätte, möglichst schnell eine Lösung zu erzielen, hätte ich auch einfach DrawText hooken können. Eine reine Manipulation der Programmoberfläche wird in den wenigsten Fällen das Ziel eines Angriffs sein.

Die Idee, bei jedem Klick neue Labels zu erstellen, finde ich ziemlich clever. Damit hättest du mich fast genarrt.

Re: Anwendungsspeicher schützen

Es geht ja darum, wie du schon sagst, den Inhalt einer Variable zu ändern und nicht die Ausgabe des Inhaltes. Doch der Zugriff auf die Variable bzw. das Ändern der Variable ist bei mir garnicht Hard-Coded im Programm drinnen. Nichtmal die Variable ist hard-coded.

Im Anhang hab ich mal das Projekt incl. Source hochgeladen. Ich hab mal wieder meine eigene ScriptEngine missbraucht ;-).
Um das Projekt zu erstellen, muss man folgende Schritte durchführen.

Das Archiv in einen Ordner entpacken
ScriptEngine.exe starten und darin die Quelltextdatei "Program1.scs" im Unterordner "Projects" öffnen
Dann wählt man unter File den Punkt Save compiled bytecode
Im Save-Dialog speichert man die Datei im Ordner Data unter dem Dateinamen Test.dat
Nun öffnet man das Projekt SecureData.dpr in Delphi
Bei dem {-$DEFINE INTERN} löscht man das Minus
Kompilieren aus Ausführen
Dann drückt man den Button "Compress" und wählt die Datei "Test.dat" im Ordner "Data" aus
Das Programm wieder schließen und den Unterordner "Data" öffnen
Dort dann die Datei "make.bat" ausführen
Projekt neu kompilieren und nochmal starten
In der Überschrift der Form sollte jetzt eine Zahl stehen: diese sollte man sich merken
Programm schließen und Quelltext die Zeile p := FRunTime.FindFunction(xx); suchen, wobei xx eine Zahl ist
die beiden xx durch die gerade gemerkte Zahl ersetzen, die Zeile {$DEFINE INTERN} wieder auskommentieren und erstellen
FERTIG war noch nicht schwer ;-)

Ich hab die Methode mit meiner Script-Engine gewählt, da ich mir dachte: wenn jetzt jemand den ASM-Code modifziert, damit er die Berechnung aushebelt, funktioniert die komplette ScriptEngine nicht mehr. Wenn jetzt das Programm auch noch auf die ScriptEngine aufbaut bzw. sie intensiv nutzt, wird dann das Programm unnutzbar.

Re: Anwendungsspeicher schützen

Ich habe schon vermutet, dass die Scriptengine irgendwie beteiligt ist, da ich einen entsprechenden String gesehen habe. Wenn man den Code kompilieren würde, wäre es wahrscheinlich recht einfach, die Abfragen zu umgehen. Aber weil das ganze in einem Interpreter ausgeführt wird, ist das natürlich nicht so leicht.

Re: Anwendungsspeicher schützen

Eben, dadurch das ein Interpretor davor hängt, muss man nicht mehr ganz so sehr drauf achten, ob man den resultierenden ASM-Code einfacher oder schwerer ändern kann - und dadurch, dass keine Konstanten, die im Script stehen, im ASM-Code auftauchen, ist es schon etwas leichter. Zudem könnte man noch ein Encryption-Modul vor die ScriptEngine schalten, mit der der Arbeitsspeicher automatisch verschlüsselt wird.

Re: Anwendungsspeicher schützen

Umgekehrt wird natürlich ein Schuh draus, wenn der Angreifer deine Script-Engine kennt. Denn dann kann er wiederum den Bytecode abgreifen und verändern.

Seite 2 von 2