Anwendungsspeicher schützen

[Macci]

Zitat:

Zitat von zero_x

Hallo Macci und webtom,

die richtige Stelle im Assemblercode zu finden ist im Grunde sehr einfach. Wenn man einen String mit beispielsweise dem Text: "Das Passwort ist falsch" als Plaintext oder in den Ressourcen der Anwendung hat, kann man auf der Adresse vom Text einen Breakpoint setzen und die Anwendung bis zu dieser Stelle laufen lassen. Dann sollte i.d.R. die Verschlüsselung vor diesem Breakpoint stehen.

Ja, das ist aber selten der Fall (und wenn doch, dann eigentlich nur wenn es um Registriercodes geht, und nicht in dem was der TS eigentlich möchte). In meinem Codebeispiel (TSaveInt) findet sich kein String, mit dem man irgendwas anfangen könnte.

Was deinen Code betrifft: Stimmt, diese Art von Abfragen sollte man natürlich vermeiden, die meisten Programme haben zum Glück sowieso dymnamisch generierte Lizenzschlüssel, und speichern sie nicht als festen Wert.

Ich habe mal aus Langeweile ein kleines Proggy geschrieben, zu dem sich jeder der Lust hat, dazu aufgerufen fühlen soll, es zu knacken :-) Wer es schafft, bitte hier posten, wie er es gemacht hat (alles erlaubt, incl. Disassembler oder Tools wie T-Search).

[Remko]

I think this: CryptProtectMemory does exactly what the ts asks (sI was triggered because Terminal Server uses this API to crypt user passwords)

The CryptProtectMemory function encrypts memory to prevent others from viewing sensitive information in your process. For example, use the CryptProtectMemory function to encrypt memory that contains a password. Encrypting the password prevents others from viewing it when the process is paged out to the swap file. Otherwise, the password is in plaintext and viewable by others.

Various options are available:
CRYPTPROTECTMEMORY_SAME_PROCESS
Encrypt and decrypt memory in the same process. An application running in a different process will not be able to decrypt the data.

CRYPTPROTECTMEMORY_CROSS_PROCESS
Encrypt and decrypt memory in different processes. An application running in a different process will be able to decrypt the data.

CRYPTPROTECTMEMORY_SAME_LOGON
Use the same logon credentials to encrypt and decrypt memory in different processes. An application running in a different process will be able to decrypt the data. However, the process must run as the same user that encrypted the data and in the same logon session.

[zero_x]

Hallo Macci,

so wie ich festgestellt habe laufen in deinem CrackMe 4 Timer/Threads ab. Wenn man die Adresse des oberen Labels patcht arbeitet das Programm trozdem weiter, da warscheinlich eins der 4 Timer wohl eingreift. Die Verschlüsselung kann man mittels der RVA abfangen. ;)

zero_x

[brechi]

@zero_x

Glaub du hast eher net verstanden was ich sagen wollte. Wie TSearch funktioniert weiß ich schon ;)

Und bei TSearch kannst du erst nach einem unbekannten Wert suchen, diesen dann im Programm ändern und nach "veränderten" Werten suchen. So kann man theoretisch auch die geXORte Version finden. Bitte sag nicht immer voreilig ist alles Schwacshinn bzw. hast keine Ahnung.

[new32]

Hallo macci

ich ändere den Wert aus EAX vor dem Aufruf von IntToStr().
Es wird also "1" umgewandelt und dann ausgegeben.

mfg.

[brechi]

Zitat:

Zitat von zero_x

Hallo Macci,

so wie ich festgestellt habe laufen in deinem CrackMe 4 Timer/Threads ab. Wenn man die Adresse des oberen Labels patcht arbeitet das Programm trozdem weiter, da warscheinlich eins der 4 Timer wohl eingreift. Die Verschlüsselung kann man mittels der RVA abfangen. ;)

zero_x

Timer != Threads
Wie patched du bitte eine Adresse eines Labels?
Wie fängst du bitte eine Verschlüsselung mittels einer relativen virtuellen Adresse ab?


Der Code eines TTimers läuft immer im Hauptthread ab. Um an die Code der Verschlüsselung zu kommen sucht man sich schon richtigerweise die StrToInt bzw. SetText Funktion wie es new32 gemacht hat. Debugger/DeDe helfen dabei. Und wenn dann fängt man Exceptions ab aber keine relativen virtuellen Adressen. Daraus berechnet man hächtenst die absoluten virtuellen Adressen. Mit einem Hardware Breakpoint auf die XOR-Variable findet man auch die Adresse wo diese initalisiert wird. Dort könnte man einfach 0 eintragen und dann beliebige Werte für die Variable eintragen ohne sich um die Verschlüsselung zu kümmern (A XOR 0 = A).

Leider wird bei new32 Methode nur das Textfeld verändert. Man kann natürlich auch den richtigen Wert reinschreiben (ist ja nur geXORt). Als Alternative würde ich die globale Variable abändern die im oberen Label angezeigt wird. Beim nächsten Klick wird die ja sowieso übernommen. Diese Änderung wird dann auch für die globale Variable übernommen (also durch XOR verschlüsselt abgespeichert). So hätte man z.B. den Spielstand verändert.

Delphi-Quellcode:

004404EF     B9 01000000    MOV ECX,1
004404F4     90             NOP

[Macci]

Hallo new32,

Glückwunsch, das ist eine raffinierte Möglichkeit, an die ich gar nicht gedacht habe :-)
Das beweist wieder mal, dass eine Kette nur so stark ist, wie ihr schwächstes Glied ;-)

Dieser Kniff hat allerdings auch nur so elegant geklappt, weil ich die IntToStr-Funktion benutzt habe. Wenn man sein Proggy schützen will, sollte man also nicht - so wie ich *g* - eine Stanard-Funktion benutzen, die man leicht finden kann, sondern stattdessen vielleicht lieber etwas Ungewöhnliches in den Programablauf einbauen (z.B. dass in einem Strategiespiel alles Guthaben plötzlich auf 0 gesetzt wird, anstatt einer MessageBox wie "Das Spiel wurde beeinträchtigt", denn das könnte man wiederrum leicht im Assembler-Code finden.).

[littleDave]

Mich juckts gerade total in den Fingern, ich würd auch gerne mal wissen, wie leicht man das Programm hier knacken kann. Ich bin nicht so der Hackprofi, aber andere haben bestimmt mehr Ahnung. Mich würds halt einfach mal interessieren. Mir gehts dabei eher darum, dass Ziel zu erreichen mit Hilfe von ASM und weniger mit TSearch, was aber auch ok ist.

Die Regeln sind die gleichen wie gerade: Sobald nach einem Klick auf "Anzeigen" unten die Zahl 1 steht, hat man gewonnen.

Also wenn mal wer lust hat, würd ich mir freuen.

[Apollonius]

Man setzt im Debugger einen Haltepunkt auf TControl.DefaultHandler. Dort kommt man direkt an die Verarbeitung der WM_SETTEXT-Nachricht. Bevor der Zahlen-String FText zugewiesen wird, kann man ihn dann verändern.

[littleDave]

Dann muss man das aber (bei mir jedenfalls) zum richtigen Zeitpunkt machen, da vorher anhand eines Beispieltextes überprüft wird, ob WM_SETTEXT und danach WM_GETTEXT übereinstimmt.

Hab im Anhang nochmal ne neue Version, falls man die erste geschafft haben sollte :zwinker: