![]() |
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:
|
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:
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
Liste der Anhänge anzeigen (Anzahl: 1)
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.
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.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz