PureBoard

Bei "fs:[$18];" muss ich passen ...

Das ergab eine sehr kurze Suche danach:
http://stackoverflow.com/questions/2704 ... t-programm
... und damit auch:
http://en.wikipedia.org/wiki/Win32_Thre ... tion_Block

FS ist eigentlich ein offset register aus der 16bit Zeit, das von 32bit-Windows aber noch verwendet wird um einen Zeiger auf den thread information block zu speichern (siehe wikipedia-link von c4s).

> mov eax, fs:[$18];

An offset $18 von FS aus steht nochmals die Adresse des TIB (also ein pointer zu sich selbst). Auch das ist glaube ich ein Artefakt aus der 16bit Zeit. "fs:[$18]" greift auf den Speicher relativ zum Inhalt des FS-Registers zu. Jedenfalls ist danach die Adresse des TIB in eax und man braucht nicht mehr FS zum Zugriff.

> mov eax, [eax+$30];

An offset $30 steht die Adresse des Process Environment Block (PEB)
http://undocumented.ntinternals.net/Use ... s/PEB.html

> movzx eax, byte ptr [eax+2];

Das Byte an offst 2 im PEB wird dann gelesen. Das wäre dann "BeingDebugged" nach dem obigen link (BOOLEAN ist ein byte).


Das sieht für mich irgendwie stark nach einem sehr umständlichen Weg aus, IsDebuggerPresent_() aufzurufen. Das sollte eigentlich das gleiche Ergebnis liefern.

freak hat geschrieben:Das sieht für mich irgendwie stark nach einem sehr umständlichen Weg aus, IsDebuggerPresent_() aufzurufen. Das sollte eigentlich das gleiche Ergebnis liefern.

Du trägst deinen Namen zu recht, denn genau darum gehts. Naja, fast. Ganz genau möchte ich meine eigene IsDebuggerPresent()-Routine schreiben bzw. es hardcoded im Quelltext platzieren.
Das ganze basiert auf diesem Artikel: http://www.michael-puff.de/Artikel/AntiCracking_1.shtml

Darin wird auch korrekterweise angemerkt das die Standard API-Funktion IsDebuggerPresent() auch für Anfänger leicht zu erkennen und zu umgehen ist ("Leuchtturm").
Tatsächlich gibt es sogar eine Erweiterung für OllyDbg die das von Haus aus kann: http://www.openrce.org/downloads/detail ... gerPresent

Jetzt fasse ich deinen Post nochmal kurz zusammen:

- TIB und PEB sind beides undokumentierte NT Strukturen
- Im FS-Register mit Offset $18 liegt der Pointer zum TIB
- Im TIB liegt der Pointer zum PEB
- Im PEB mit Offset $2 befindet sich der Wert den IsDebuggerPresent() zurückgibt

Zwei Fragen:

1.) Wie bekomme ich die Adresse des TIB ohne das FS-Register?
2.) Der ASM-Code ist so nicht 64Bit kompatibel. Korrekt?

Du willst IsDebuggerPresent nachbauen?
Bringt ganix. Im Regelfall wird das Debug-Flag nämlich einfach entfernt, somit ist es egal ob du IsDebuggerPresent nutzt oder es nachbaust, beide werden melden das kein Debugger läuft.

Für OllyDbg gibt es ettliche Plugins, die verschiedenste Erkennungsmethoden lahmlegen.

Ach Thorium, mach doch nicht alle meine Hoffnungen wieder mit gnadenlosem Realismus nieder

Gibt es denn noch andere Möglichkeiten herauszufinden ob das Programm in einem Debugger läuft?
Ich hatte mir bspw. gedacht die Liste der laufenden Prozesse zu holen und zu prüfen ob "ollydbg.exe" oder "windbg.exe" ausgeführt werden.
Allerdings ist es kein Verbrechen einen Debugger laufen zu haben deshalb müsste ich wissen ob darin gerade mein eigenes Programm läuft.

Es gibt einige möglichkeiten aber alle die ich kenne sind recht nutzlos, da es Plugins und tools ginbt, welche die automatisch aushebeln.

Nach meiner erfahrung muss man sehr viel Zeit und Arbeit investieren um was neues hinzubekommen, was nicht automatisch von nem Tool ausgehebelt wird. Ist halt immer die Frage ob sich das am Ende lohnt und oft gibt's halt auch Nachteile für den user, wie z.b. Beim durchgehen der prozessliste. Auch hierfür gibt's Plugins die .exe Name und fenstertitel von ollydbg ändern.

Die Frage ist was du schützen willst, wenn's ein keyalgo ist bietet sich eine VM an. Kostet zwar Zeit die zu entwickeln aber da ist dann nix mit automatisch aushebeln, da muss der Cracker dann selbst rann.

Thorium hat geschrieben:Auch hierfür gibt's Plugins die .exe Name und fenstertitel von ollydbg ändern.

Ist mir klar aber das könnte man bspw. mit einem MD5 Datei-FingerPrint umgehen.

Thorium hat geschrieben:Die Frage ist was du schützen willst, wenn's ein keyalgo ist bietet sich eine VM an. Kostet zwar Zeit die zu entwickeln aber da ist dann nix mit automatisch aushebeln, da muss der Cracker dann selbst rann.

Mit VM meinst du sicherlich eine "Virtuelle Maschine" aber wie genau man damit einen keyalgo schützen könnte kann ich nicht nachvollziehen

Ja eine virtuelle maschine.
wie man damit schützt ist simpel. Delikaten Code schreibst du für deine VM mit deinem instruktionssatz. Der Code kann dann nicht einfach disassembliert werden, weil deine VM natürlich keinen x86 Code ausführt sondern was auch immer du dir ausgedacht hast. Um nun gezielt Änderungen am Code vornehmen zu können muss de Cracker erstmal deine VM verstehen, wie die Instruktionen aufgebaut sind, was sie bedeutet. Das macht es natürlich ungemein schwer einen keyalgo zu verstehen. Zumal deiner Phantasie keine Grenzen gesetzt sind um es möglichst komplex und undurchsichtig zu gestalten. Solche VMs sind mittlerweile die grundlage aller professioneller kopierschutzsysteme.

Klingt sehr interessant. Auch wenn ich natürlich Kosten/Nutzen abwäge und sowas für die meisten Projekte nicht in Frage kommt
hätte ich Lust mich damit mit mal näher zu befassen. Gibt es da entsprechende Tutorials oder eine Art Crashkurs um das Ganze mal
besser zu veranschaulichen?