Archive for Jun. 2011
Guten Tag alles zusammen.
-Ich bin Rastajan und seit 2006 in der internationalen sowie der deutschen Szene aktiv.
-Ich beschäftige mich zum größten Teil mit Grafik Design, Reversing Engineering und dem Entwickeln von Programmen.
-Ich werde hier in Zukunft auch einige Papers und Artikel veröffentlichen!
Gruß, Rastajan.
Heute wird es um einen simplen Triggerbot gehen. Simple daher, weil eine extremst simple Technik verwendet wird. Um den Triggerbot “exakt” zu haben, müsste man man trigonometrischen Funktionen und Winkeln rechnen, aber wir machen es uns einfacher.
Wir berechnen, ob sich unsere Bildschirmmitte (Da wo wir hinschießen 
) sich in einem Radius zur Mitte des Spielers befindet. Dieser Radius wird aus dem Mainroot-Bone und dem Neckbone gebildet und davon die Hälfte zu der Mainroot-Position in Y-Richtung dazu addiert.Das ganze klingt kompliziert, aber eine kleine Grafik sollte ein bisschen Klarheit schaffen:
So, endlich habe ich es (nicht) geschafft. Der Status ist, dass ich das Programm mit enormem Aufwand patchen und somit aktivieren könnte. Dabei müsste ich entweder ein Auth-Server emulieren, welcher mit dem Client verschlüsselt kommuniziert, oder “einfach” 200 Funktionen patchen. Dazu gleich mehr, aber zurück zum Anfang 
Durch die in Teil II beschriebene Methode ließ ich mir die ausgehenden Daten an den Server sowie die einkommenden Daten ausgeben. Diese Messageboxen wurden so platziert, dass die Ausgaben direkt nach dem entschlüsseln bzw. direkt vor dem verschlüsseln stattfinden. In Kombination mit dem Sourcecode ergab sich dann folgendes Bild:
// Direkt nach dem Socket-Connect str = null; if (this.DecryptKey != null) { str = this.MD5INBase64(buffer); // das Byte-Array in ein MD5-Hash umwandeln this.DecryptKey = str; // } // Dieses hier passiert nach der ersten Request: this.c("_SET_ENCRYPTION_:" + CryptoHelper.EncryptRijndeal(this.DecryptKey, "93ksmwldofneksifoemfkdjroeskmq", SaltVERSION1, "MD5", 1, IVVERSION1, 0x80)); |
Und weiter geht es
Mir ist in der Nacht die Idee gekommen, einfach per Reflexil die IL-Codes so umzubiegen, dass mir die geprüfte Serial in einer MessageBox ausgegeben wird. Auf diesen Patch möchte ich als erstes etwas genauer eingehen, damit nicht so erfahrene User auch etwas davon haben
Im Grunde geht es um diesen Teil des Sources:
for (int i = 1; i < 20; i++) // Das ganze 20 Mal { buffer[0] = (byte) i; string str5 = this.a("2q3D2e52qD25" + str + Convert.ToBase64String(buffer), true); MessageBox.Show("In Loop"); if (A_1.Replace("-", null).ToUpper().Trim() == this.b(str2 + str3 + a.b(e) + str5, true).ToUpper()) { return true; // Check ist erfolgreich } } return false; // Serial stimmt NICHT überein |
Völlig deprimiert setze ich hiermit einen Blogpost ab, um meine RE-Ergebnisse bis hierhin zu verarbeiten und zu teilen. Dieser Blogpost wird sehr theoretisch, langwierig und schwer zu verstehen sein, aber wie schon gesagt. Reversing ist kein Ponyhof!
An dieser Stelle ein großes Lob an die Entwicker dieses Programmes. Hier ist es nicht mit einem 1-Byte-Patch und einem emulierten Server auf localhost getan, sondern mit verschlüsselten Server-Abfragen, viele verschachtelte Prüfmethoden, dynamisch generierte Forms und Prüfungen, ob das File modifiziert wurde.
Aber zum Anfang der Geschichte. Vor kurzem sah ich auf einem RE-Board eine Crackanfrage dieses .NET Programms. Es ist eine Internetcafe-Software, mit einem Server, Client und einem ServiceHoster. Nachdem ich die letzen 2 Tage im Urlaub war, fiel mir auf, dass ich diese Software schon heruntergeladen auf meinem Rechner hatte. Also ging es los:
Als erstes zückte ich, in Ermangelung des Redgate .NET Reflectors, ildasm.exe und erstellte mir einen vollständigen Dump der !733! Klassen. Nach einem kurzen suchen, wurde auch sofort folgender String gefunden:
IL_011a: ldstr “Die eingegebenen Registrierdaten sind falsch.”
In den nächsten Tagen werde ich nicht zum posten kommen, daher hier noch ein kleiner Artikel. Es handelt sich um ein relativ simples, aber dennoch extremst cooles Feature. Der Bone-ESP!
Der Bone-ESP zeigt uns einfach jeden der 20 Knochen an. In diesem Gesamtbild ergibt sie die Entfernung, sowie die Positionierung (liegen, stehend) des Spielers. Dadurch können wir auf eine Box um den Spieler oder so einfach verzichten und das ganze sieht echt gut aus (wenn man es in Bewegung sieht :P)
Vor zwei Tagen wurde auf Rebirth anscheinend die “LEAKED BINARY” von “n0ise Reverse-Socks Bin + Panel” gepostet. Der TS schrieb weiterhin, dass diese Binary infected wäre, aber nicht von Ihm oder K!llu. Zudem wäre diese Binary nur unpacked, dass man sie sich selbst decompilen kann.
Also hab ich mir die Binary geladen und durch den Reflector gedumpt. Als ich mir dann den Source in Visual Studio anschaute, fiel mir auf, dass überhauptnichts bezüglich “Reverse Socks” gemacht wird. Es gibt in dieser Binary folgende Klassen:
Also hab ich weiter die c000002.cs bearbeitet, analysiert und kommentiert. Und irgendwann ergab sich ein Bild, welches eigentlich eine ganz coole Idee ist:
In diesem Teil werden wir einen Nametag-Hack schreiben. Dieser zeigt einfach die ganze Zeit (auch durch Wände) den Namen von Gegnern über deren Köpfen an. Das ist jetzt nicht soooo spektakulär, dennoch ist es gut zum Verständnis von (später folgenden) komplexeren Aktionen.
Um es erst einmal in Pseudocode auszudrücken; Im Grunde müssen wir folgende Schritte machen:
Klingt relativ simple, oder?
Ich habe hierzu eine Klasse MW2Player, welche die Container von Entity und Clientinfo aus den vorherigen Teilen beinhaltet. Zudem gibt es ein Member “Vector2 vPosOnScreenLast”, welche jeweils geupdated wird:
Willkommen zum (richtigen) vierten Teil der Tutorialserie! Hier wird es sich endlich um Delegates (Funktionszeiger) drehen, mit denen wir eine Font registrieren werden und Text zeichnen! Dabei wird auch auf die Hürde eingegangen, das manche native Funktionen nicht von C# aufgerufen werden können.
Im letzten Teil haben wir die MemoryHelper Klasse behandelt, welche auch die Funktion “GetFunctionFromAddress<T>” enthält. Anhand dieser Funktion werden wir sofort mit dem ersten Funktionszeiger anfangen, welcher eine Font (Schriftart) der Engine registriert und uns das Handle zurückliefert. Der native C++-Code sieht dazu so aus:
typedef void* (*GetFontType_)(char* FontName, int Unknown1); |
Diese Funktion erwartet also einen FontName, sowie unbekannter zweiter Parameter als Integer. Zudem wird ein Handle, hier in Form eines void-Zeigers zurückgeliefert. Ein Void-Zeiger ist einfach ein Zeiger ohne einen bestimmten Datentyp wie Int oder Char.
