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

In diesem Post werde ich etwas über mein aktuelles Freizeitprojekt “HearthstoneCalc” berichten. Ich werde fortsetzende Posts über das Tool danach richten, wie interessiert Ihr Leser an den Artikeln seid. Schauen wir mal

Ich interessiere mich schon länger für Spiele KIs und bin der Überzeugung, dass Computer bei der Planung von Spielzügen weit effektiver sind als ein menschliches Gehirn. Dabei geht es nicht um die Kreativität die ein menschlicher Spieler an den Tag legt, sondern die reine rationale Beurteilung der Spielsituation. Schachcomputer sind inzwischen ungeschlagen, weil sie einfach Unmengen an Situationen vorraussehen und bewerten können. Seid einiger Zeit fasziniert mich das Spiel “Hearthstone“, ein Rundenbasiertes Kartenspiel ähnlich Magic oder Yu-Gi-Oh. Man kann Diener oder Zauber spielen, die eigenen Heldenfähigkeiten nutzen oder mit Waffen die Kontrolle über das Board behalten. Der Spielverlauf wird später nochmal genauer erklärt, jetzt geht es erstmal um das Programm “HearthstoneCalc”.

Ziel des Programms ist es, alle möglichen Züge zu eruieren und den besten auszuwählen. Dabei sollte das Programm den aktuellen Spielstatus auslesen, die Berechnungen durchführen und den Spielzug selbstständig ausführen. Im Gegensatz zu Spielen mit perfekten Informationen wie Schach oder Vier-Gewinnt haben wir bei Hearthstone drei große Probleme:

1. Die gegnerischen Karten sind unbekannt. Zwar werden von den Spielern meist ähnliche und als effektiv geltende Decks gespielt, allerdings varieren auch hier die Karten. Die Karten des Gegners die er auf der Hand hat sind verdeckt und bieten daher keine perfekten Informationen über zukünftige Spielzüge
2. “Hearthstone braucht keinen Skill, sondern nur Glück“. An diesem Zitat ist leider viel wahres dran. Viele Zauber wirken auf alle Einheiten verteilt und viel Schaden (z.B. von explodierenden Bomben) ist variabel. Glück gehört einfach zum Spiel dazu, daher kann man den Ausgang eines Zuges nicht effektiv berechnen. Man muss mit Wahrscheinlichkeiten rechnen, und davon nicht wenige. Später gibt es ein Beispiel, wie komplex ein solcher Zug sein kann.
3. Manche Decks verfolgen eine spezielle Strategie und sammeln daher Karten, um einen großen Zug zu machen. Solch eine “Strategie” bringt man dem Computer schlecht bei, vorallem da er nebenher darauf achten muss, nicht gegen den Gegner zu verlieren.

Ihr merkt, das Projekt wird komplex. Und ein solches Projekt fängt man am besten an, indem man abstrahiert und vereinfacht. Ein solch einfaches Modell kann dann später erweitert werden. Effektiv heißt das auf die beiden oberen Punkte bezogen: Wir schauen zunächst nur den aktuellen Zug unseres Spielers an und lassen die mögliche gegnerische Reaktion außer Acht. Zudem berechnen wir nur die Züge ohne Wahrscheinlichkeiten bzw Rechnen mit dem schlimmsten Ausgang für uns.

Weiterlesen

7 people like this post.

Like

Unlike

Die Cyber Security Challenge Germany Qualifikation hat erneut ihre Pforten geöffnet. In den kommenden drei Monaten kann man in den 12 Aufgaben rund um Web-Security, Exploiting, Reverse Engineering, Cryptografie, Stegografie und Forensik sein können unter Beweis stellen. Warum ich dafür Werbung mache? Es ist ein cooles Event und die Aufgaben sind anspruchsvoll genug um Vorlesungen mit rumrätseln zu füllen. Man beschäftigt sich mit Themen, die einem noch nicht so geläufig sind und trifft coole Leute die Ahnung von Security haben.

Vorraussetzungen sind einzig, dass man zwischen 18 und 31 Jahre ist, noch keinen Master-Abschluss hat und aus Deutschland kommt. Für Östereich und Schweiz laufen übrigens ähnliche Qualifikationen, die dann im EuroCTF gipfeln.

Schaut vorbei und vielleicht sieht man sich in Berlin

P.S. Es werden demnächst wieder andere Beiträge kommen. Freut euch schonmal auf Deobfuscation in C# und ein bisschen Crypto-Analyse eines Online-Account-Checkers.

16 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

Gab schon lange nichts mehr zu Android RE, das muss sich ändern Ein guter Freund fragte mich nach einem Hack für das Androidspiel World Conqueror 2. Über das Spiel selbst kann ich euch nichts erzählen, dann ich hab es bisher nicht gespielt. Wichtig ist nur, dass es Medallien gibt die man per “In App Purchase” (IAP) kaufen kann. Mit diesen Medallien kann man sich Abzeichen kaufen, welche wiederrum Boni auf Rohstoffe und Kampfeinheiten geben. Ohne diese Boni ist das Spiel irgendwann nicht mehr zu schaffen, das typische Free-To-Play and Pay-To-Win Prinzip. Aber wir schaffen uns heute Abhilfe.

Wir decompilen die App gewohnt mit Apktool und Dex2Jar und stellen fest, dass das eigentliche Spiel in nativem Code vorliegt. Für uns heißt das mehr Arbeit, natives Debugging und stundenlange Suche in ARM-Opcodes. Aber zum Glück gibt es eine Schnittstelle des nativen Programmes zu dem einfach zu analysierenden Java-Code. Denn die Google-Käufe werden natürlich über normales Java abgewickelt und müssen dann ihren Weg in die native Bibliothek finden. Dazu finden sich folgende Funktionen im Java-Code:

private static native void AddMedal(int paramInt);
private static native void CallNativeError();
private static native void CallNativeExit();
public static void DeviceNotMatch();
// *Snip*
public static native void PurchaseSuccess(int paramInt);

Das “native”-Schlüsselwort sagt dabei, dass sich die Funktion nicht im Java-Code befindet, sondern in einer nativen Bibliothek zu finden ist. Wenn wir diese mit IDA Pro öffnen, finden wir u.a. folgenden Code:

Weiterlesen

4 people like this post.

Like

Unlike