Malware in the Wild! Eines Abends wurde auf einem Twitch Channel ein Link im Chat gepostet. “https://bitly.com/Screenshot093 “. (ACHTUNG MALWARE!) . Dahinter steckt ein Dropbox-Direktdownload und mit einer Screenshot093.scr Datei. Eine SCR Datei, schon lange nicht mehr gesehn Eigentlich sind das sog. “Screensaver”-Installer, die allerdings einen normalen PE Header haben und damit einfach als exe umbenannt werden können.

Dahinter steckt ein .NET File, obfuscated mit der neusten .NET Reactor Version. Damit kann de4dot leider noch nicht umgehen, die AES verschlüsselten Ressourcendateien haben eine ungültige Größe. Doch ich vermutete dass die Malware nur ein Loader für weitere Schadsoftware war. Wir nutzen also den ultimativen Ansatz gegen gepackte .NET Files: Dumping. Jeder .NET Assembly wird, wenn nicht speziell dagegen vorgegangen wird, von der .NET Runtime im Speicher gehalten und kann von dort aus wieder extrahiert werden. Wenn der Packer nun die Assembly entschlüsselt und reinläd, können wir uns also einfach das entschlüsselte Image auf die Festplatte schreiben. Der Dump enthält neben der eigentlichen obfuscateten Assembly eine zusätzliche, gedroppte Assembly mit dem eindeutigen Namen “SteamStealer 5.0″. Diese Assembly enthält alles was wir gesucht haben: Ein Steam-Stealer und zwei Loader. Unobfuscated! o/

SteamStealer:
Dieses offensichtlich selbstgeschriebene Tool kopiert die beiden “ssfn*” Files sowie die loginusers.vdf, config.vdf und SteamAppData.vdf in ein Zip-Archiv. Diese sind nötig um den SteamGuard zu umgehen und Items verkaufen zu können. Dieses Archiv wird an folgende URL hochgeladen: http://prtscnhost.com/gate_new.php . Wenn das File keinen PK-Header hat, so werden wir mit der Meldung “Не могу открыть архив” belohnt. Auf Deutsch heißt das “Kann das Archiv nicht öffnen”, daher können wir annehmen dass das Archiv direkt verarbeitet, ausgelesen und in eine Datenbank eingetragen wird.

Weiterlesen

8 people like this post.

Like

Unlike

Der Werdegang von HearthstoneCalc hat einen eigenen Post verdient, in welchem dann weitere Ansätze (Monte Carlo Tree Search) vorgestellt werden. In diesem Blogeintrag geht es allerdings um das Injecten und Daten abrufen aus Hearthstone. Denn ohne Daten aus dem Spiel müssen wir HearthstoneCalc garnicht mehr weiterentwickeln.

Uns wird es zum Glück leicht gemacht. Hearthstone ist mit der Engine Unity3D geschrieben. Für Blizzard hat das den großen Vorteil, das Spiel einfach auf mobile Geräte (Tables und Smartphones, Android und iOS) portieren zu können. Für uns hat es den großen Vorteil, dass Unity .NET (genauer gesagt: Mono) verwendet. Und da die Binaries noch nicht einmal obfuscated vorliegen, haben wir ein relativ einfaches Spiel.

Der für Unity relevante Code wird in der Assembly-CSharp.dll gespeichert. Die Anzahl der Klassen überschreitet alles, was ich bisher gesehen habe. Dementsprechend fällt es am Anfang schwer, uns zurecht zu finden. Auch muss man sich zunächst an die Unity-Eigenarten gewöhnen: Jedes Objekt ist eine Entity, die wiederrum mehrere Unterentities haben kann. Oftmals haben Klassen Unterklassen, enthalten viel zu viel Renderlogik oder scheinen nie erzeugt zu werden.

Daher gilt zu klären: Welche Daten müssen wir alle Abrufen? Die Daten aus dem Spiel müssen in die Strukturen von HearthstoneCalc gebracht werden. Die wichtigste und größte Struktur ist hierbei die GameState-Klasse (Links). Sie enthält das Spielfeld mit den Monstern, die Karten des Spielers und die Infos über die jeweiligen Helden. Natürlich haben die Helden weitere Unterklassen, wie z.B. die ausgerüstete Waffe oder die gesetzen Geheimnisse. Auch Monster sind inzwischen komplexer geworden, denn sie können verschiedene Buffs besitzen und auf andere umliegende Minions Einfluss ausüben.

Die Klassen aus Hearthstone können wir nicht einfach übernehmen, denn sie enthalten viel zu viele Informationen. Diese Klassen sind nicht dafür ausgelegt, Millionen möglicher Boardzustände zu speichern. Zu diesem Problem werde ich nächsten Post über HearthstoneCalc noch mehr sagen.

Der große Vorteil von Mono ist natürlich, dass wir realtiv einfach .NET Code ausführen können. .NET Code in einem Programm ausführen? Klingt doch sehr nach CLR-Hosting!? Leider ist das nicht so einfach, denn die Unity-Klassen mögen es nicht, wenn sie außerhalb von mscorlib.dll Thread aufgrufen werden. Versucht man eine Unity-Funktion direkt aufzurufen, so erhält man folgende Fehlermeldung zu gesicht:

Weiterlesen

6 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

Annährend 3 Monate ist es her, dass ich mich an einem Keygen Me versucht habe. Ziel war es ein “Algorithmus” zu entwickeln, den man nicht durch simples Rückrechnen der Rechenoperationen brechen kann. Blogpartner tr4ceflow hat einen Artikel dazu gewidmet, der schon gute Ansätze beinhaltet. In der Zukunft werden Keygen Mes mit einem nicht so überladenen Compiler wie Visual Studio kompiliert, da viel zu viel verwirrender Mist reinkommt. Das habe ich auch dadurch gelernt

Alle 3-4 Tage werden hier neue Lösungshinweise erscheinen. Wieviele es insgesammt werden weiß ich nocht nicht.

13.09.2014:

Alle Infos von tr4ceflows Blogpost zusammengefasst: Per GetDlgItem und GetWindowTextA wird der Text aus den Textboxen Name, Serial1 und Serial2 ausgelesen. Diese werden an eine Funktion, die den eigentlichen Keycheck vornimmt übergeben (0x1E1C60). Nun muss gelten: usernameLength - 1 == strlen(key1)/4). Der Key wird nun in 4er Blöcke zerlegt und in shorts (2 byte) gespeichert. Aus 01234567 wird 0×0123 und 0×4567 . Dieses wird zu einem Float umgewandelt (0×0123 = 291d => 291.0f) und im Anschluss durch 100 geteilt. Nun wird gerechnet, und zwar mit Floats. Es werden nun alle Buchstaben durchlaufen. Dabei wird jeweils die Summe aus einer “Rechnung” gebildet und diese vom aktuellen Buchstaben abgezogen. Nun wird vergleichen, ob die Differenz in einem “Bereich” liegt, der durch die e-Funktion mit einem statischen Exponenten aus einem Array begrenzt wird. Wenn die Differenz kleiner als die expotentierte Zahl ist, so wird die Schleife Fortgesetzt. Wenn nein, so wird aus der Funktion rausgesprungen und der Key ist nicht gültig.

Ich möchte nochmal einen kleinen zusätzlichen Tipp geben: tr4ceflow hat eine Rechung aufgestellt, wie die Sache im ersten, zweiten und dritten Durchgang aussieht.

- berechne    - hex(e) / 100.0
              - hex(f) / 100.0
              - hex(g) / 100.0
- berechne die Summe 
	1. Durchgang :  hex(e) / 100.0 + hex(f) / 100.0 + hex(g) / 100.0
	2. Durchgang :  4*hex(e) / 100.0 + 2*hex(f) / 100.0 + hex(g) / 100.0
	3. Durchgang :  9*hex(e) / 100.0 + 3*hex(f) / 100.0 + hex(g) / 100.0
- hole einzelnen Buchstaben "a" aus Namen und berechne die Differenz

Schaut euch dabei mal die Vorfakoren der hex(e/f/g) an. Beim ersten Durchlauf ist dieser stets 1, beim zweiten durchlauf ist er 1,2,4, …, beim dritten Durchlauf 1,3,9,… . Kommen euch diese Folgen bekannt vor? Wenn ja, wo finden sie Anwendung? Vorallem im Zusammenhang mit einer Addition ! Dieser (relativ) große Tipp hilft hoffentlich, auf die richtige Spur zu kommen. Denn tra4ceflow hat bereits alle vorarbeit geleistet, jetzt gilt es nur noch 1+1 zusammenzuzählen.

16.09.2014:

Entspricht dem Polynom: f(x) = -0.054166*x^6 + 1.02083*x^5 -6.3125*x^4 + 10.0625*x^3 + 32.866*x^2 -106.583*x^1 + 138

Entspricht auch dem Usernamen: EASYSURF

Schaut euch mal den Y-Wert des Polynoms an den ganzen Zahlen an, also: f(1), f(2), … Vergleicht es mit EASYSURF!

18.09.2014:

Mit den obigen Zeilen ist der Hauptteil des Keygens, nämlich Key1 bereits errechnet. Das sind also einfach die Koeffizienten des Polynoms was den Usernamen bzw die ASCII Characters des Usernamens abzüglich dem letzten Buchstaben annährt. Hier der Beispielkey für EASYSURF.

Key1: fffb0066fd8903ee0cd6d65e35e7

Doch was ist mit Key 2? Dort wird ebenfalls ein Polynom verwendet. Doch welchen Wert muss es haben? Es ist ganz ähnlich. Doch das hebe ich mir für den nächsten und finalen Tipp auf

22.09.2014:

Abschliesend gibt es die volle Auflösung und auch den Sourcecode zum Keygen. Fangen wir mit dem zweiten Key an. Auch hierbei handelt es sich um encodierte Koeffizienten des Polynoms des “strlen(username) - 1″-Grades. Allerdings geht es hier auch noch um Grenzwertberechnung. Der Grenzwert Polynom2/Polynom1 gegen Unendlich muss gegen den letzten Buchstaben/10 gehen. Dabei ist bekanntlich nur größte Exponent entscheidend, welcher im Nenner, als auch im Zähler ausgeklammert wird. Beim oben genannten Key ist der größte Exponent 0xfffb, was nach umrechnen -0,0541 ergibt. Der Grenzwert, also der letzte Buchstabe, muss F = 70d sein. Die Gleichung umzustellen müsste jeder hinbekommen: x/-0,0541=7.0 => x = -0,0541*7.0 = -0.3787. Encodieren wir das wieder in unsere Short-Schreibweise, so erhalten wir: ffdb. Da die restlichen Exponenten egal sind, können wir da einfach die restlichen Koeffizenten von Key1 ranhängen. Damit erhalten wir als gültige Keykombination:
Key1 = fffb0066fd8903ee0cd6d65e35e7
Key2 = ffdb0066fd8903ee0cd6d65e35e7

Weiterlesen

3 people like this post.

Like

Unlike