Anwendungsspeicher schützen

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