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

Anderthalb Monate ist es her, seid der erste Post über Apex entstanden ist. Nun bin ich an dem Punkt angelangt, Apex als besiegt zu bezeichnen. Zwar weis ich noch lange nicht, wie all die unzähligen Apex Module arbeiten, aber es reicht für uns einen Hack zu schreiben ohne das Apex (frei nach Archimedes) unsere Kreise stört , Mir ist klar dass dieser Post vielleicht von anderen Kopiert wird und als Vorlage für andere Hacks benutzt wird, daher werde ich keinen kompletten Source posten.

Im letzten Post wurde erwähnt dass Apex uns nach dem Hook von End2DOptimized und RenderString Kicks verteilt. Auch sollte im Hinterkopf behalten werden, dass Apex uns nicht selbst kickt, sondern nur Daten an den zentralen Server weiterleitet. Des weiteren sollten wir uns in das Gedächnis rufen, dass die Detour-Library die ersten 6 Bytes einer Funktion mit einem JMP ersetzt. Das alles deutet darauf hin, dass Apex irgendwie den Funktionsanfang prüft, ob dort Hooks gesetzt sind oder nicht. Prompt wurde CheatEngine gezückt und der Debugger attached, welcher in auf Lesezugriffe am Anfang der gehookten End2DOptimized Funktion achtet. Das selbe wäre auch mit OllyDbg möglich gewesen, aber CheatEngine ist in diesem Fall bequemer zu bedienen.

Mit allein diesem Resultat fangen wir wenig an. Wichtig ist zu wissen, dass generell 0x7XXXXXXX Adressen in den Kernelspace zeigen. Mit dem Debugger finden wir, dass 0x760575B2 in der Funktion IsBadReadPointer liegt und diese wohl unseren Funktionsanfang prüft. Der Call dazu erfolgt allerdings auf dem 0x0CCXXXXX Adressbereich. Wir wissen ja inzwischen, das Apex zwei große Module in den Speicher mapped, allerdings ist keines davon annährend in diesem Bereich. Ein Glück, dass VirtualAlloc gehooked ist und wir somit die dynamischen Speicherreservierungen mitbekommen. Darin finden wir:

14:08:20 Virtual Alloc! Size: 7d90, Addr: 0xcce0000, allocType: 1000, flProtect: 40

Weiterlesen

17 people like this post.

Like

Unlike

Manchmal hat man keine Lust auf Anti-Cheats, welche permanent (und aus manch unerfindlichem Grund) Kicks verteilen. Daher beginnen wir mit dem spassigen Teil: Die LithTech Engine und der Draw Hook.

Zunächst ein paar Worte zu der Engine: Die LithTech Engine ist das Herzstück von Spielen wie FEAR, ein paar Medal of Honor Titeln, Combat Arms und Crossfire. Inzwischen ist ein SDK veröffentlicht, das für uns sowohl ein Segen als auch ein Fluch ist. Denn so lässt sich zwar die Basis-Struktur von Klassen nachvollziehen, aber es gibt keine Garantie dass diese Klassen nicht geändert wurden. So kann man sich ein SDK als grobe Orientierung vorstellen, aber nicht als Basis der Programmierung.

Am Anfang war der DirectX Hook. Man hooked dazu (wie schon von Siedler bekannt) die Funktionen EndScene und Reset, um eigene Sachen zu zeichnen. Funktioniert hat das überraschend gut, aber nur bis das Device Resettet wurde. Ein Reset passiert z.B, wenn das Fenster in den Hintergrund geschoben wird und dann wieder Fokus erlangt. Oder auch, wenn man vom der Ingame-GUI ein Match Startet. Aus unerfindlichen Gründen wurde die Font, die ich zum Zeichnen erzeuge, nicht freigegeben. Eigentlich sollte das mit Aufrufen von OnLostDevice() und OnResetDevice() die Font Freigeben bzw wieder neu allokieren. Irgendwas lief schief, so dass ich diesen Ansatz nach ein paar Stunden des Debuggens wieder aufgab.


Lassen wir also die Engine das ganze Font verwalten und Strings zeichnen übernehmen. Dazu hooken wir uns in End2DOptimized, was dank diverser Strings in der Binary leicht möglich ist. Interessanter wird es, das Rendern vorzubereiten und wieder zu beenden. Dazu bedienen wir uns das Klasse ILTDrawPrim, welche ebenfalls über Strings schnell gefunden wird. Ein Blick in das SDK liefert auch schöne Klassenmember und virtuelle Funktionen, die wir uns zu nutze machen können.

Weiterlesen

6 people like this post.

Like

Unlike

Nach einigen Problemen mit der Domain ist der Blog für ein weiteres Jahr online!

Während der Downtime war ich aber nicht faul, sondern habe weiter interessante Artikel für den Blog vorbereitet. Freut euch auf ein Keygen-Me, weitere Posts zu Apex und Wolfteam und natürlich auch zum Bitcoin-Cashier

Greez

6 people like this post.

Like

Unlike