Bei der Analyse eines Programm sties ich heute Mittag auf eine String-Encryption der wildesten Art. In dem heutigen Post wird es um die Entschlüsselung dieser String-Encryption mit Mitteln der Code-Injection gehen.

Bei der String-Decryption wurde ein Offset der verschlüsselten Daten in EBX übergeben und im Gegenzug spucke die Funktion den entschlüsselten String in EAX wieder aus. Eine solche Entschlüsselung wurde in dieser Form schon oft gesehn und ist weiter nichts besonders. Folglich vermutete ich ein XOR decrypt in irgend einer Art. Daher staunte ich nicht schlecht, als ich mit einer unglaublich langen und mit mehreren Subfunktionen durchzogenen Methode stand. Eigentlich baut man die String-Decryption nach, aber in diesem Fall gab ich es nach 20 Minuten auf. Aus der Adresse (!) des Offsets wurden nach Bitshifting-Operationen Offsets in andere Speicherbereiche errechnet, die wiederrum mit in die Decryption einflossen. Diese Speicherbereiche wurden wiederrum erst zur Laufzeit berechnet etc etc. Das dumpen dieser ganzen Daten stellte sich als schwierig herraus, daher verfolgte ich einen anderen Ansatz: Code Injection!

Die Idee dahinter ist schnell erklärt: Anstatt dass man die String-Decrypt-Funktion rekonstruiert um sie im Programm zu verwenden, ruft man die Decrypt-Funktion direkt im zu crackenden Programm auf. Man schreibt also Shellcode der nichts anderes macht als einen String zu entschlüsseln. In diesem Fall ist der Umfang des Shellcodes beschränkt, denn wir müssen nur den gewünschten Offset in EBX laden, die Funktion aufrufen und das Resultat aus EAX auswerten. Uns werden dabei noch einige Steine in den Weg gelegt, aber über die steigen wir nach und nach drüber. Fangen wir erstmal damit an, wie der Shellcode überhaupt ins Programm gelangt und ausgeführt wird.

Weiterlesen

7 people like this post.

Like

Unlike

Egal ob Browsergame oder Multiplayer PvP, Onlinespiele sind in der heutigen Zeit sehr gefragt. Es macht einfach mehr Spass, gemeinsam mit Freunden zu Spielen, statt sich mit einer pseudoklugen KI an der Seite herrum zu schlagen. Der Trend geht klar Richtung Onlinespiele, was wiederrum auch Gamehacker anlockt. In dem heutigen Artikel werden Grundlagen besprochen, auf die man beim Programmieren achten sollte. Anschaulich wird das ganze durch Beispiele erklärt.

Das Spektrum von Hacks, über Bots und Exploits ist zu groß, als dass man es alles in einem Artikel abdecken könnte. Daher werden primär nur Echtzeit-Onlinespiele betrachtet. Diese Techniken lassen sich aber beliebig auf andere Multiplayer-Spiele übertragen. Und noch kurz zu den verwendeten Begriffen in diesem Artikel:

• Server: Dabei handelt es sich um einen zentralen (!) Server, der das eigentliche Spiel hostet. Er nimmt Daten von anderen Spielern entgegen und verteilt die “Änderungen” im Spiel an alle verbundenen Clients. In machen Spielen wird der Server auch als “Host” bezeichnet, was im Prinzip nichts anderes bedeutet.
• Client: Ein Spieler, der mit dem Server verbunden ist und aktiv Stati (Schießen, Laufen) an den Server sendet

Der wohl bedeutenste Grundsatz dürfte sein: Traue nie den vom Client empfangenden Daten. Der Client schickt, wie schon oben erwähnt, in regelmäsigen Abständen Daten wie seine eigene Position und seine Attribute an den Server. Wenn ein Gamehacker die Welt-Position des Clients verändert, wird diese auch zum Server gesendet. Wenn der Server diese Daten nun ungeprüft übernimmt, haben wir einen sog. Teleport-Hack. Solche Teleport-Hacks befanden sich u.a. in großen Onlinespielen wie Metin 2.

Während sich der entstehende Vorteil durch Teleportierungen noch in Grenzen hält, hört der Spass bei sog. Masskill-Hacks auf. Dabei sendet der Client die Nachricht “Ich habe XX Schaden am Gegner Y gemacht”. Der Server übernimmt dieses ungeprüft und tötet den Gegner Y. In Battlefield 3 ist dieser Hack inzwischen gefixxt, die Kollisionserkennung ist allerdings immernoch Clientseitig. So sind “Instant Kills” möglich, indem man einfach den Schaden, den eine Waffe verursacht, ins unendliche erhöht. Daher die Regel Nummer 2: Auf Plausibilität prüfen! Im Falle einer clientbasierten Kollisionserkennung kann man durch Wände schießen. Wenn der Server nun einmalig prüft, ob Spieler X den Spieler Y überhaupt treffen kann, wären solche Hacks schon verhindert. Warum das nicht gemacht wird? Weil solche Checks relativ viel Rechenleistung brauchen und einen Server mit 64 Spielern überfordern würde.

Weiterlesen

8 people like this post.

Like

Unlike

Form Grabbing in Firefox. Das ist nichts neues und es gibt zuhauf Beispiele mit dokumentierem Sourcecode. Warum also ein Artikel drüber verfassen? Ein guter Bekannter zeige mir ein Video von einem Form-Grabber in Firefox und fragte mich wie das geht. Ich hatte mich nie damit beschäftigt und nur ein paar Ansätze im Kopf, doch das interesse war geweckt. Wie schaffen es Bots, Daten aus Website-Formularen so gezielt auszulesen?

In dem folgenden Artikel wird ein Proof of Concept von einem Form-Grabber mit injecteter DLL erstellt. Das besondere im Vergleich zu den 100 anderen Proof of Concepts ist hierbei, dass die injectete DLL Managed ist und somit erst ein CLRHost für das Ausführen von .NET Code reingeladen werden muss. Das Konzept sollte aus den vorherigen Artikeln wie diesem und diesem bekannt sein.

Fangen wir mit etwas Theorie an: Es gibt zwei Wege Daten aus Webformularen auszulesen. Diese Formulare sind intern auch nur Textfelder, die man markieren und kopieren kann wie man es aus Windows gewohnt ist. Das heißt im Umkehrschluss auch, dass diese Felder ein Handle und eine Windows-Klasse besitzen müssen. Mit diesem Handle können wir von externen Programmen Firefox dazu auffordern, uns den Textinhalt dieses Handles zurückzugeben. Der große Nachteil ist, dass man sich erstmal zu diesem Handle “Vorzuhangeln” muss. Hier muss man über mehrere UI Elemente und Knoten mit Unterknoten laufen, bis man am gewünschten Ziel angekommen ist. Sehr elegant ist das nicht und für jede Seite müsste dieser Pfad eingeprogrammiert werden! Wer weiteres über diesen Ansatz lesen möchte, dem sei die WM_GETTEXT Message und dieser Stackoverflowpost ans Herz gelegt. Eleganter, und vor allem universal für jede Seite ist das Abfangen von der GET/POST Request bevor diese über SSL unkenntlich gemacht wird. Und genau dieser Ansatz ist verblüffend einfach und zielführend!

Die später geschriebene DLL hängt sich an die sog. PR_Write Funktion der nss3.dll von Firefox. Diese wird verwendet, um Streams jeder Art zu beschreiben. Sei es ein Filestream welcher auf die Festplatte schreibt, oder ein Netstream welcher an eine TCP Verbindung gerichtet ist. Wie unschwer zu erkennen ist, nimmt diese Funktion drei Parameter entgegen. Der erste ist das Stream-Handle, was nicht weiter besprochen wird. Das zweite Argument enthält einen Zeiger auf einen Buffer (Zwischenspeicher), in welchem sich die zu schreibenden Daten befinden. Das dritte Argument gibt schließlich an, wieviele Daten aus dem Zwischenspeicher in den Stream geschrieben werden sollen.

Setzt man mit OllyDBG einen Breakpoint an der PR_Write Funktion, so lassen sich alle drei Argumente schön im Stack anschauen. Das deutet daraufhin, dass es sich bei der PR_Write Funktion um eine cdecl-Calling-Convention handelt. Die später für uns wichtige Calling Convention gibt an, wie die Parameter der Funktion übergeben werden. Dabei gibt es viel Möglichkeiten: Parameter können sich in Registern befinden oder auch der Reihe nach auf den Stack geladen werden. Letzeres ist wohl hier der Fall.

Schön zu sehen sind die 3 Stackargumente in umgekehrter Reinfolge. Die Return-Adresse befinder sich ganz Oben auf dem Stack, danach folgt der Zeiger auf den Stream und der Zeiger auf den Buffer. Als drittes Argument kann man die Länge des Buffers, in diesem Fall 0×221 Bytes sehen. Links im Stack Window ist die Buffer-Adresse geöffnet. Hier sieht man klar die POST Request die gesendet wird, mit allen GET und POST Parametern. (GetParam=NotSoSecret, PostParam=VeryS3cret).

Weiterlesen

11 people like this post.

Like

Unlike

Aus ist es mit .NET, Windows und grafischen Oberflächen! Easysurfer is Python-Begeistert und steuert Hardware an! Weg mit dem Klickibunti-Kram, gebt mir einen Lötkolben und ein paar Drähte! Nein, ganz so schlimm hat es mich nicht erwischt. Dennoch folgt jetzt ein Beitrag, der sich dieses mal etwas hardwarenäher abspielt.

Ich gebe zu dass ich von Elektrotechnik keine Ahnung habe. Vielleicht finde ich es gerade deshalb so toll einen Geldscheinprüfer in der Hand zu haben und ein Protokoll zu implementieren. Man schickt ein Befehl und der Prüfer fängt an zu Blinken, zu surren und schließlich einen Geldschein zu verschlucken. Toll!

Genug der Euphorie, es stellt sich die Frage: Woher hat er so ein Ding? Und wozu braucht er es überhaupt? Ein Freund und ich bauen mit minimalistischer Hardware ein Art Bitcoin-Transfer-Automat. Die Idee dahinter ist simple: Der Kunde wählt einen Betrag und eine Bitcoin-Adresse aus, der Automat frisst die Scheine und transferiert den entsprechenden Betrag in Bitcoin an die eingelese Adresse. Es wird zu gegebener Zeit einen vollen Artikel zu diesem Projekt geben, aber heute ist der Geldscheinprüfer dran.

Es handelt sich um einen Apex 7000 der Firma Pyramid Technologies. Die genauen Spezifikationen interessieren uns gerade wenig, wir wollen das Ding anschließen und Programmieren. Im Lieferumfang waren 2 Kabel dabei: Ein USB zu 6-Pin-Kabel mit welchem man die Firmware flashen und einstellen kann, sowie ein USB zu 18-Pin Kabel, welches noch zusätzlich mit Strom über ein 4 Pin-Kabel vom Netzteil versorgt wird. Wer sich jetzt unter meinem untechnischen gebrabbel nichts vorstellen kann hat hier noch ein frisch fotografiertes Bild:

Nachdem der PC aufgeschraubt, ein Stromkabel geklaut und die Treiber installiert sind kann es losgehen. Angesprochen wird das Teil über einen seriellen COM-Port. Das Gerät sendet keine Daten raus, sofern wir sie nicht anfordern (pollen). Daher schauen wir erstmal ein Blick in die PDF, in welcher das Transferprotokoll beschrieben ist: RS-232 Serial Interface Specifications.

Weiterlesen

8 people like this post.

Like

Unlike

Die letzen Tage habe ich wieder viel mit Siedler 3 verbracht. Allerdings nicht mit Spielen, sondern mit Reversing und Coding.

Durch einige Tricks habe ich es geschafft, einzelne UI Elemente zu “kontrollieren” und Aktionen mit ihnen durchzuführen, die eigentlich nur nach einem Mausklick auf das jeweilige Element erfolgen. Denn die “neue” Lobby wird über das LAN-Menu laufen, nur dass der Bildschrim komplett ersetzt wird. Um aber ein Spiel aus dem LAN-Modus zu starten, sind folgende Schritte notwendig:

• Spieler klickt auf den Adapter in der ersten Listview (DirectPlay Adapter)
• Spieler klickt in die Textbox und gibt die IP des Hosts ein
• Spieler klickt auf “Suche Spiele” -> Spiele werden angezeigt
• Spieler wählt ein Spiel aus der Lisview aus
• Spieler klingt auf “Mitspielen”.

Diese 5 Schritte kann ich nun per Programmcode aufrufen, auch wenn es noch nicht immer klappt (Bei einem Fehlerdialog hängt sich das Programm auf, da dieser eigentlich nicht vom UIThread aufgerufen wird etc).

Das bedeutet, dass einer neuen Lobby nun nichts mehr im Wege steht. Oder doch? Die eigentliche UI für die Lobby muss ja noch geschrieben werden. Und dabei kann (wegen des alten GDI standarts, leider nicht mal GDI+) auch keine UI Library verwendet werden. Selber schreiben heißt die Devise! In den letzten Tagen habe ich daher einige Basis UI Klassen angefertigt (TextLabel, Button, ListView) um daraus eine Lobby zu konstruieren. Das Resultat:

Weiterlesen

9 people like this post.

Like

Unlike