Anwendungsspeicher schützen

[webtom]

Ist es möglich, den Anwendungsspeicher meiner Software zur Laufzeit zu schützen, so dass man diesen nicht mit anderer Software auslesen kann, z.B. WinHex oder ähnliches. Der Lesezugriff auf meinen eigenen Anwendungsspeicher sollte für alle anderen Anwendungen gesperrt sein.

Ich meine dabei aber nicht das Verschlüsseln von Codeblöcken durch ASM oder ähnliches. Lediglich der von meiner Anwendung genutzte Arbeitsspeicher sollte nur von meiner Applikation gelesen und genutzt werden können.

Vielen Dank im Voraus für Hilfe zu diesem Thema.

[gsh]

ich will einfach mal ganz ehrlich dazu sagen ... nein

Etwas übertrieben aber effektiv:
Ich stelle auf voll Memory Dump und dann provoziere ich einen Bluescreen während deine anwendung läuft und schon hab ich alles.

[Hedge]

Ist es denn möglich bestimmte Variablen so zu schützen, dass sie zumindest nicht manipuliert werden können? Durch Verschlüsselung oder sowas?

[Tyrael Y.]

Auf meinem Rechner kann ich, wann immer ich will alles machen was ich will.
Es gibt zudem noch so tolle Tools wie SoftICE.
Es gibt auch in der selben Art Hardware.

Fazit: Wenn man es unbedingt möchte, kann man alles aus dem Speicher lesen.

[Hedge]

kann man es zumindest so schützen, dass nur Jemand der richtig viel Ahnung vom cracken hat es auch schaffen würde die Variablen zu manipulieren.

Bei mir gehts hauptsächlich darum eine Anwendung vor Script-Kiddies zu schützen.

[Apollonius]

Gegen einen Administrator kannst du deine Anwendung nicht schützen. Es wäre ja auch reichlich bescheuert, wenn eine Admin nicht volle Rechte über ein laufendes Programm erlangen könnte.

[Luckie]

Man könnte erstmal das Debuggen erschweren: http://www.michael-puff.de/Artikel/AntiCracking_1.shtml

[Hedge]

Ah, danke für den Tipp.

Da mein Programm Daten an einen Server senden soll, würde ich Jemanden 'flaggen' bei dem ein Debugger erkannt wurde.

Kann es auch dem Normal-User i-wie versehentlich passieren, dass i-was bei ihm als Debugger erkannt wird ohne, dass er einen Crack-Versuch unternehmen wollte?

[WS1976]

Hallo,

ich weiss nicht genau was du schützen willst, aber vielleicht wäre es ein Ansatz kritische Daten nur temporär im Speicher zu halten und zwar nur dann wenn sie gebraucht werden.

Das würde die Chance durch einen Dump an die Daten zu kommen erheblich verringern.

Grüsse
Rainer

[Hedge]

Die Daten können gelesen werden so viel sie wollen.

Jedoch sollen sich nicht geändert werden können.

Es geht dabei um einige Integer-Variablen.

Hilft mir vielleicht Mutex weiter?

[Macci]

Hallo,

alles was du tun musst, ist, deine Variablen, die du schützen möchtest, verschlüsselt (am besten mit einer Art Checksumme) zu speichern, und sie immer nur bei Bedarf kurzzeitig entschlüsseln. Ein Skriptkiddie knackt sowas bestimmt nicht (ich denke, die meisten hier im Forum würde es ebenfalls nicht schaffen, wenn du es richtig machst).

[Hedge]

Die Variablen können nur inkrementiert werden. Das müsste eine Checksumme unnötig machen, weil ich ja nur schauen brauch ob die Variable sich mehr als +1 verändert hat seit dem letzten Aufruf meiner Funktion, aber danke für den Tipp :)

[brechi]

das IsDebuggerPresent von Luckie bringt im Grudne gar nichts. Jedes gemoddete OllyDbg bzw jedes einfache plugin (und vill sogar OllyDbg in der neusten Version) macht einfach ein "mov [$7ffde000], 0" am Anfang und das Debugflag ist auf 0, egal wie es ausgelesen wird.

Ich denke es geht um ein Spiel bei dem der Punktestand nicht verändert werden sollte. Dazu kannst du di Variable am besten einmal "verschlüsseln" in dem du sie mit irgend einem wert mit XOR verknüpst. Einfach zum schlüsseln / entschlüsseln vorher XOR aufrufen :)

Das doopellte Speichern (um dnan zu vergleichen ob die erhöht wurde) bringt nichts, da TSearch immer ALLE Variablen anzeigt. Dann patchedm an eben beide weg.

[Hedge]

Zitat:

Zitat von brechi

das IsDebuggerPresent von Luckie bringt im Grudne gar nichts. Jedes gemoddete OllyDbg bzw jedes einfache plugin (und vill sogar OllyDbg in der neusten Version) macht einfach ein "mov [$7ffde000], 0" am Anfang und das Debugflag ist auf 0, egal wie es ausgelesen wird.

Ich denke es geht um ein Spiel bei dem der Punktestand nicht verändert werden sollte. Dazu kannst du di Variable am besten einmal "verschlüsseln" in dem du sie mit irgend einem wert mit XOR verknüpst. Einfach zum schlüsseln / entschlüsseln vorher XOR aufrufen :)

Das doopellte Speichern (um dnan zu vergleichen ob die erhöht wurde) bringt nichts, da TSearch immer ALLE Variablen anzeigt. Dann patchedm an eben beide weg.

Ja, hab auch schon erfahren, dass das mit dem DebugFlag nix mehr bringt.

Wäre es nicht ziemlich trivial rauszufinden wie die Variable verschlüsselt ist, wenn ich sie nur einmal mit einem XOR verknüpfe?

[brechi]

Naja, glaub bei AOE2 oder so wurde das auch gemacht. Meisten wird TSearch genommen um die Adresse rauszufinden. Man erspielt dann z.B. 100 Punkte und sucht dann mit TSearch nach einem Integer-Wert von 100. Dann spielt man weiter bis man z.b. 150 hat. Aus allen Anfangsergebnissen wird dann rausgefiltert wo der Wert jetzt 150 ist. Das macht man bis man nur noch wenige Adressen hat. Dort ist dann die Variable. Wenn du jetzt zweimal die Variable speicherst bringt dir das nicht. Dann bekommt man zwei Ergebnisse.

TSearch erlaubt dir auch nach "Incrementierten Variablen" zu suchen. Man liest einmal alle Speicheradresen aus, und dann wenn sich er Punktestand ändert sucht man nach allen Variablen bei dem sich der Wert erhöht hat.

Durch ein einfaches XOR vor und nach dem verarbeiten der Variable funktioniert beides nicht mehr. (Eine gexorte Variable kann kleiner werden wenn sich der Punktestand erhöht)

Dafür gibt es natürlich noch eine Suche bei der man angibt: Hat sich verändert bzw. hat sich nicht verändert. Damit kann man die dann natürlich wieder finden. Im grunde ist es also nur ein kleiner Schutz.

[Macci]

Zitat:

Zitat von Hedge

Wäre es nicht ziemlich trivial rauszufinden wie die Variable verschlüsselt ist, wenn ich sie nur einmal mit einem XOR verknüpfe?

Deswegen würde ich noch zusätzlich eine Prüfsumme abspeichern. So kannst du beim Zugreifen auf die Variable gleich herausfinden ob sie verändert wurde. Das sollte ausreichen um die meisten Angreifer davon abzuhalten, dein Proggy zu manipulieren.

Ich würde es so machen:

Delphi-Quellcode:

unit SaveIntUnit;

interface

uses Windows;

type TSaveInt = class
private
    check : integer;
    FValue: integer;
    procedure SetValue(const Value: integer);
    function GetValue:integer;
public
    constructor Create(Value:integer);
    property Value:integer read GetValue write SetValue;
end;

var xor_code:integer;


implementation

{ TSaveInt }

constructor TSaveInt.Create(Value: integer);
begin
  if xor_code=0 then begin
     Randomize;
     xor_code := Random($40000000) + $40000000;
  end;
  Self.Value := Value;
end;

function TSaveInt.GetValue: integer;
begin
  result := FValue XOR xor_code;
  if (FValue mod $ABCD) * 7 + $DEF0 <> check then
     ExitProcess(0);
end;

procedure TSaveInt.SetValue(const Value: integer);
begin
  FValue := Value XOR xor_code;
  check := (FValue mod $ABCD) * 7 + $DEF0;
end;

end.

und so verwenden:

Delphi-Quellcode:

var wert : TSaveInt;
begin
  wert := TSaveInt.Create(100);
  ShowMessage(IntToStr(wert.value));
  wert.value := -100;
  ShowMessage(IntToStr(wert.value));
  wert.Free;

Viele grüsse,
Macci

[Hedge]

Ah..danke.

Das Prinzip verstehe ich und es macht auch Sinn, aber 3 Fragen hätte ich noch:

1. Sollte xor_code nicht ein Element der Klasse TSaveInt sein, weil es ja an einigen Stellen benutzt wird und für jede Instanz einen anderen Wert übergeben kriegt.

2. Was bedeutet ein '$' am Anfang von Integern?

3. Auf der Zeile werd ich nicht ganz schlau:

Delphi-Quellcode:

if (FValue mod $ABCD) * 7 + $DEF0

soll ich mir für $ABCD und $DEF0 einfach nen eigenen Wert ausdenken?

[Macci]

Hallo,

zu deinen Fragen:

Zitat:

Zitat von Hedge

1. Sollte xor_code nicht ein Element der Klasse TSaveInt sein, weil es ja an einigen Stellen benutzt wird und für jede Instanz einen anderen Wert übergeben kriegt.

Nein, das geht nicht (da würde sich die Katze in den Schwanz beißen). Irgendwo MUSS ja etwas im Klartext gespeichert sein, und wenn du es dennoch anders versuchen würdest, würdest du dich in einer Endlosen Rekursion von Constructoren wiederfinden. Aber keine Sorge: Mit TSearch oder ähnlichen Proggys kann man diese Variable nicht so leicht aufspüren, weil ihr Wert keinerlei Bedeutung, mit der Angreifer irgendwas anfangen könnte, für die Variablen in deinem Programm hat.
Edit: xor_code hat übrigens nur einen einzeigen Wert für das ganze Programm (nicht für jede Instanz von TSaveInt einen eigenen).

Zitat:

Zitat von Hedge

2. Was bedeutet ein '$' am Anfang von Integern?

Dass eine Hexadezimale Zahl folgt.

Zitat:

Zitat von Hedge

3. Auf der Zeile werd ich nicht ganz schlau:

Delphi-Quellcode:

if (FValue mod $ABCD) * 7 + $DEF0

soll ich mir für $ABCD und $DEF0 einfach nen eigenen Wert ausdenken?

Du kannst dir dafür natürlich auch eigene Werte ausdenken, wenn du befürchten musst, dass der Angreifer hier im Delphiforum mitliest.

Viele Grüsse,
Macci

[Hedge]

OK, das habe ich jetzt soweit verstanden, aber da kommen 2 neue Fragen auf
(Sorry dafür, aber ich will auch verstehen was ich da tue).

Warum benutzt du Hex-Werte und nicht normale Integer?

Hat xor_code := Random($40000000) + $40000000; eine spezielle Bedeutung oder ist es einfach nur so gedacht, dass der Integer keinen Überlauf kriegt?

[Macci]

Zitat:

Zitat von Hedge

OK, das habe ich jetzt soweit verstanden, aber da kommen 2 neue Fragen auf
(Sorry dafür, aber ich will auch verstehen was ich da tue).

Warum benutzt du Hex-Werte und nicht normale Integer?

Weil $40000000 schöner aussieht als 1073741824 ;-) Außerdem kann ich mir mehr darunter vorstellen.

Zitat:

Zitat von Hedge

Hat xor_code := Random($40000000) + $40000000; eine spezielle Bedeutung oder ist es einfach nur so gedacht, dass der Integer keinen Überlauf kriegt?

Ja, ich möchte dass eine positive Zahl rauskommt, allerdings soll das höchstwertige Bit dieser Zahl (nicht das Vorzeichenbit) eine 1 sein (deswegen "+ $40000000"), damit die ursprüngliche Ganzzahl möglichst gut verschleiert wird.

[Hedge]

Ah danke.
Nur noch eine Sache, dann sind wir durch :)

Die Variablen check und FValue liegen ja hintereinander im Speicher. Könnte das gefährlich werden, wenn wir mal nicht von Script-Kiddies sondern Hobby-Cheatern ausgehen ?

[zero_x]

Hallo webtom,

es ist schwierig einen gute Schutz zu programmieren, denn alles, was der Computer verarbeitet wird in Assemblersprache übersetzt und ausgegeführt. Man kann somit alles sehen und modifizieren. Das Skript von Macci ist schon mal ein guter Ansatz, jedoch würde ich daruaf achten, dass man nie direkte Abfrage macht! Ich betone extra "nie". Tools wie beispielsweise TSearch eignen sich eigentlich nur für das Auffinden der Variablen bzw. dessen Adressen zu patchen und hat garnichts mit diesen Thema zutun. Wenn du dich für das Thema "Sicherheit von Anwendungen" auseinander setzen möchtest würde ich dir raten Assembler zu lernen, um zu verstehen wo die Probleme liegen.

Um dem Cracker die Arbeit zu erschweren gibt es einige Trick, womit es schwieriger wird. Es gibt extra "Exploits", also das man sich Fehler von Debuggern, wie beispielsweise Ollydbg, ausnutzt und ihn zu crashen/abzustürzen zu lassen. Auch einfach unsinnigen Code, ja es hört sich doof an, in den Code einzubringen hat auch Vorteile. Strings würde ich immer Verschlüsseln, da dies sehr gute Anhaltspunkte für Breakpoints sind! Packing ist auch eine gute Methodik sich zu schützen.

Um es nochmals kurz und knapp zu fassen: es gib keinen hundertprozentigen Schutzen gegen debugging. Mit ein wenig kriminelle Energie und Programmiererfahrungen ist es möglich. Ein Katz- und Mausspiel. Soweit meine Worte dazu. ;)

zero_x

[Hedge]

Zitat:

Hallo webtom,

Antwortest du wirklich auf den ersten Beitrag ? :cheers:

Bei meinem Tool möchte ich Debugger nicht unbedingt zum Abschmieren bringen. Früher oder später werden bei meinem Projekt immer Daten an einen Server übertragen. Wenn die Daten inkonsistent sind oder einfach nur merkwürdig, dann wird beim übertragen der Daten der User geflagged und Online kann ich dann wesentlich besser die Leute rausschmeißen oder on-the-fly (ohne dass user das tool updaten müssen) ändern wie solche Leute erkannt werden.
Wenn man jedes mal den Debugger abschmieren lässt, dann versuchens einige so lange bis sie es geschafft haben das zu umgehen, aber wenn sie nach ein paar Tagen gebanned werden, dann können sie nicht so schnell ausprobieren das System zu betrügen, weil sie ja erstmal nicht wissen ob es geklappt hat oder nicht.

[brechi]

Hedge, Scriptkiddies (also die die mit TSearch umgehen können) haben mit der Methode von Macci (übrigens eigentlich einfach aber super gelöst) kaum noch eine chance. Die Adresse werden sie vill noch ermitteln können. Um das zu erschweren könnte man einen timer mitlaufen lassen, der den XOR wert in kleinen Intervallen abändern somit ist auch der selbe Wert (z.B. 100) nach unterschiedlichen Zeitabfragen im Speicher anders verschlüsselt. (Aber den OVerhead für eine Integer Variable oO, selbst ein Object ist da fast zu viel).

Was sind Hobby Cheater? Welche die debuggen können? Dann werden die das aber umgehen können.

[Hedge]

Zitat:

Was sind Hobby Cheater? Welche die debuggen können? Dann werden die das aber umgehen können.

Ja, genau solche meine ich.
Im Speziellen: Es muss verhindert werden, dass Jemand eine Callback-Funktion selbst auslösen kann oder zumindest dass erkannt wird, dass die Callback-Funktion (oder eine der folgenden die mit den Variablen arbeiten) nicht vom Programm selbst sondern künstlich ausgelöst wurde.

Es wurde ja schon in den Raum geworfen möglichst viel sinnlosen Code unterzubringen.

Aber hilft das denn auch bei dem Problem mit den Funktionen die nicht von außen aufgerufen werden sollen?

[zero_x]

Hallo Hedge,

Zitat:

Zitat von Hedge

Zitat:

Hallo webtom,

Antwortest du wirklich auf den ersten Beitrag ? :cheers:

Nein, ich spreche ihn darauf an, sowie ich dich. Dies mache ich aus absicht, damit es zu keinen Verwechslungen kommt!


Hallo brechi,

entschuldige, aber was du redest ist völliger Schwachsinn :!: Um es kurz zu erläutern: das Programm TSearch sucht nach Adressen
der Variablen im Arbeitsspeicher bzw. von einem Programm. Man kann eine beliegige Zahl eingeben und Programm druchsuchen durchsuchen lassen. Es werden zunächst mehr als ein Variable ausgegeben, da im Programm selber auch andere Variable angelegt werden. Man kann somit nicht die direkte Variable finden und die Stelle patchen, denn man kann nicht eindeutig feststellen welche Variable es ist! :warn:

zero_x

[Macci]

Zitat:

Zitat von Hedge

Ah danke.
Nur noch eine Sache, dann sind wir durch :)

Die Variablen check und FValue liegen ja hintereinander im Speicher. Könnte das gefährlich werden, wenn wir mal nicht von Script-Kiddies sondern Hobby-Cheatern ausgehen ?

Hallo,

wie andere hier schon geschrieben haben, reicht mein Schutz gegen Skriptkiddies locker aus. Auch wenn jemand die Binary disassemblieren kann, ist es nicht so einfach, wie es vielleicht hier klingt, das Programm entsprechend zu manipulieren. Die richtige Stelle im Assemblercode zu finden (welcher lockere mehrere Hundert oder Tausend Seiten lang ist), ist nicht so einfach. Klar ist, dass du ein Programm niemals 100%-ig schützen kannst, und auch klar ist, dass richtige Profis so gut wie jede Sperre durchbrechen können. Aber wenn du Skriptkiddies und Hobbycheater abhalten willst, müsste mein Code genügen, evtl. kannst du noch ein paar unnötige Variablen oder unnötigen Quellcode einführen. Anstatt das Spiel mit "ExitProcess" zu beenden (diese Stelle lässt sich im Assemblercode nämlich aufspüren), könntest du stattdessen irgendeine subtile Änderung im Spielverlauf durchführen, oder einen für den Angreifer ungünstigen Wert zurückliefern (z.B. mit "result = 0;").

Viele Grüsse,
Macci

[zero_x]

Hallo Macci,

wenn man eine Anwendung cracken oder modifizieren möchte braucht man nicht den Assemblercode alles durchulesen, sondern muss einfach die richtigen Breakpoint an der richtigen Stelle setzen.

Nch eine wichtige Anmerkung: Abfragen mit direkten if, also das vergleichen von zwei Werten würde ich immer meiden, denn wenn man beispielsweise einen Lizenzschüssel(der sich aus einen Namen generiert) hat mit einem Algorithmus berechnet und anschließend es mit if Abfragt wird im Stack dann schon der richtige Lizenzschlüssel geschrieben und ist im Assemblercode bzw. in den Registern direkt sichtbar!

zero_x

[Macci]

Zitat:

Zitat von zero_x

die richtigen Breakpoint an der richtigen Stelle setzen

Du hast natürlich Recht, aber genau diese richtigen Stellen zu finden, ist eben das schwere daran (Wenn man beim Lotto gewinnen will, muss man auch "nur" die richtigen Kreuze an die richtige Stelle setzen ;-)). Nicht unmöglich, das ist klar, aber auch nicht gerade leicht zu schaffen (wenn der Code geschickt verschleiert ist).

Was das direkte IF betrifft: Wie würdest du es dann machen? Kleines Codebeispiel wäre hilfreich :-)

Viele Grüsse,
Macci

[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.

Wenn man nun ein Passwort hat und dies mit einem anderen Vergleichen möchte und man dies mit einer direkten if-Abfrage macht ist es sehr unsinnig, weil dann schon das richtige Passwort verraten wird und mit einem anderen vergleicht wird. An dieser Stelle kann man das richtige Passwort auslesen oder die Abfrage patchen. Das würde somit keinen als so großen Sinn machen. Wenn man jetzt nun das Passwort stelle für Stelle abfragt macht das um einiges mehr Sinn, denn der Cracker wird schnell die Lust an der Sache verlieren und wird alles verwirrender für ihn. Machen wir mal ein einfaches Beispiel in Assembler:

Delphi-Quellcode:

004013BA    C745 FC 0500000>MOV     [DWORD EBP-4], 5
004013C1    837D FC 05      CMP     [DWORD EBP-4], 123
004013C5    75 26           JNZ     SHORT 004013ED
004013C7    C74424 04 00004>MOV     [DWORD ESP+4], 00440000          ; ASCII "Richtig!"

Nun, was sehen wir hier? In der ersten Zeile ist unser falsches Passwort: "5". In der zweiten Zeile wird dieses mit "123" Verglichen, falls es falsch ist wird auf eine andere Adresse gesprungen. Ansonsten wird "Richtig" ausgegeben. Somit ist es sehr einfach dies zu patchen. Auf das Theme möchte ich nicht weiter eingehen, da es sonst zu kompliziert wird. Ich möchte einfach nur darauf hinaus, dass wenn man etwas 1 zu 1 vergleicht ist alles sichtbar! Bei Strings oder Lizenzschlüsseln kann man sich das schon denken ... .

Also ich würde dazu raten das Passwort nicht direkt im Code zu programmieren, sondern zur Laufzeit ein Passwort zu generieren mit einem Algorithmus. Das Passwort nicht 1 zu 1 abfragen, sondern stückweise. Wie du das machen möchtest bleibt dir überlassen.

zero_x :wink:

[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: