Anwendungsspeicher schützen

[Apollonius]

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?

[littleDave]

Zitat von Apollonius:

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.

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

Zitat von Apollonius:

Edit: Was ist an der zweiten Datei anders?

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

[Apollonius]

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.

[littleDave]

Zitat von Apollonius:

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.

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]

[Apollonius]

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.

[littleDave]

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.

[Apollonius]

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.

[littleDave]

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.

[Apollonius]

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.