Analysiert: PS3-Emulator als Schafspelz
Seite 2: Ein Blick hinter die Kulissen des Emulators
Ein Blick hinter die Kulissen
Beim Durchsehen der Logfiles von ProcMon und Wireshark wird schnell klar, dass bei der Ausführung von PSeMu3_Setup.exe weit mehr geschieht, als das bloße Extrahieren der (in verschlüsselter Form gespeicherten) Emulator-Dateien.
Zunächst wird in Users\<user name>\AppData\Local\Temp ein weiteres Unterverzeichnis angelegt, welches einen in Abhängigkeit von der Systemzeit generierten Zufallsnamen erhält. Der Installer kopiert die von ihm benötigten NSIS-Plugins hinein, um sie bei Bedarf mittels der Funktion LoadLibraryEx zu laden. Da die aufzurufende DLL-Datei systemfremd ist und sich zudem nicht in einem Standardverzeichnis beziehungsweise nicht in demselben Verzeichnis wie das aufrufende Programm befindet, wird beim Aufruf von LoadLibraryEx der Parameter LOAD_WITH_ALTERED_SEARCH_PATH sowie der absolute Pfad der DLL-Datei übergeben.
Der offene Quellcode des NSIS ermöglicht das Schreiben eigener Plug-ins/DLLs. Neben der Verwendung bereits verfügbarer, von anderen NSIS-Usern geschriebener Laufzeitbibliotheken (unter anderem System.dll und md5dll.dll) extrahiert der Installer auch eine von den Machern des Setups vermutlich selbstgeschriebene math.dll, auf die ich später noch einmal zurückkomme.
Im ProcMon fällt mir die Verwendung von inetc.dll auf. Dabei handelt es sich um ein NSIS-Plugin, welches Funktionen für den Up- und Download von Dateien bereitstellt. Ich beschließe, dass sich an dieser Stelle ein Blick ins Wireshark-Logfile lohnt. Und tatsächlich: Das Logfile zeigt mir eine HTTP-GET-Anfrage an einen Account von Amazons Cloudfront-Service. Die Cloudfront-Server können Inhalte – wie in diesem Fall eine Datei namens bitool.dll – zum Download zur Verfügung stellen. Laut Amazon richtet sich dieses Angebot eigentlich an Entwickler und Unternehmer. Nun ja, im weitesten Sinne treffen, wie wir noch sehen werden, beide Begriffe auf die PSeMu3-Macher zu.
Es ist naheliegend, dass es sich bei der heruntergeladenen DLL-Datei wiederum um ein NSIS-Plugin handelt. Im ProcMon-Log findet sich die Bestätigung dieser These: bitool.dll wird nach dem Download in das Verzeichnis Users\<user name>\AppData\Local\Temp kopiert und von dort aus ebenso wie die übrigen Plugins mit LoadLibraryEx() aufgerufen.
Einmal die Seriennummer, bitte
Im Malware-Analyse-Tool Immunity Debugger setze ich einen Breakpoint auf einen Call, der auf die LoadLibraryEx- und GetProcAddress-Funktionsaufrufe folgt und der die jeweils benötigten Funktionen der NSIS-DLL-Dateien aufruft. Ich führe das Setup aus, bis bitool.dll geladen und erstmalig aufgerufen wird und lande auf diese Weise am Einsprungspunkt einer Funktion namens ReadV1 der bitool.dll. Diese erzeugt eine anonyme Pipe. Der CreateProcess()-Aufruf startet das systemeigene Kommandozeilen-Tool wmic.exe. Die Befehlskette wmic bios get serialnumber, version fragt über die Kommandozeile die Computer-Seriennummer aus dem BIOS ab. Mit ReadFile() liest das Setup die zurückgelieferte Information aus der Leseseite der Pipe aus.
Hierbei handelt es sich um eine gebräuchliche Anti-VM-Technik, da virtuelle Maschinen hier fast immer Strings zurückliefern, welche sie als solche enttarnen. Im Falle meiner VirtualBox verrät mich der zurückgelieferte String VBOX. Ohne zu untersuchen, ob die Überprüfung der soeben ermittelten Seriennummer im Programm oder serverseitig stattfindet, lege ich einen neuen Sicherungspunkt an. Kurzerhand patche ich den verräterischen String im Debugger, das heißt, ich ändere vier Bytes: Aus VBOX wird im Hex-Dump kurzerhand ASUS. Dann lasse ich das Setup einmal ungepatcht und einmal gepatcht weiterlaufen um zu schauen, ob Unterschiede im nachfolgenden Programmfluss zu beobachten sind.
Zunächst einmal bleibt der Programmablauf identisch: Das Setup sendet im nächsten Schritt eine GET-Anfrage an einen zweiten Amazon-Cloudfront-Account. Dieses Mal werden diverse Parameter übergeben, von denen zwei vorab unter Zuhilfenahme der bereits erwähnten math.dll verschlüsselt beziehungsweise mittels md5dll.dll in einen Hash umgewandelt wurden: Zum einen eine Zahlenkombination zur Identifikation (vermutlich generiert aus einer zuvor abgefragten GUID, Parameter uid), zum anderen das Ergebnis des WMIC-Aufrufs (Computer-Seriennummer; Parameter v1, passend zum Funktionsnamen ReadV1 in bitool.dll). Des Weiteren werden die Affiliate- und Software-ID sowie die Versionsnummer des PSeMu3-Installers übermittelt. Angesichts des Begriffs Affiliate bleiben kaum noch Zweifel daran, worum es hier geht: Um das Einstreichen von Provisionen durch die Vermittlung bestimmter Software.
Der Cloudfront-Server antwortet auf die Anfrage, indem er eine XML-Datei zurücksendet. Diese wird als binsischeck654.xml unter Users\<user name>\AppData\Local\Temp gespeichert. Die Struktur der Datei ist nebenstehendem Screenshot zu entnehmen, welcher auch den ursprünglichen GET-Request samt der übermittelten Parameter zeigt.
Mittels des (legitimen) NSIS-Plugins xml.dll wird das Dokument geparst, und der Befehl ReadAnyregistry innerhalb der Bitool-Funktion liest die abzufragenden Werte aus der Registry aus. Neben der Präsenz sämtlicher gängiger Anti-Viren-Programme auf dem System fragt der Befehl auch Keys ab, welche von bestimmten Adware-Anwendungen bei der (De-) Installation erzeugt werden. In meinem Fall wurde unter anderem nach den Browser-Erweiterungen Wajam, SearchProtect, Appshat und IMinent sowie nach dem angeblichen Tune Up-Tool PC Optimizer Pro gesucht.
Nach der Durchführung aller Checks werden die Ergebnisse in einer neu erzeugten temporären Datei unter Users\<user name>\AppData\Local\Temp\ gespeichert und nebst weiteren Systeminformationen, wie etwa der Betriebssystem-Version, installierten Browsern, dem Standardbrowser sowie der momentanen Startseite des Internet Explorers, an den Cloudfront-Server zurückgesendet.
Nun erfolgt eine Auswertung der empfangenen Informationen durch den Server. Ziel ist es vermutlich, Adware bereitzustellen, die auf dem Zielrechner noch nicht installiert ist beziehungsweise war und die vom installierten Anti-Viren-Programm möglichst nicht als solche erkannt wird. Auf diese Weise erhöht sich die Wahrscheinlichkeit einer erfolgreichen Adware-Installation. Im letzten Schritt sendet der Server eine weitere XML-Datei zurück, welche als binsis142.xml gespeichert wird.
Vier Bytes machen den Unterschied
An dieser Stelle kommt der Unterschied zwischen der Ausführung in einer virtuellen Maschine und auf einem physischen PC zum Tragen, welchen ich dank meines vier Byte großen Patchs beobachten kann. Er besteht letztendlich darin, dass während der Installationsroutine des PS3-Emulators in der VM mit dem gepatchten ASUS-Strings die zuvor anhand des Registry-Checks ausgewählte Adware im Installer-Fenster auftaucht.
Zu diesem Zweck wird der sogenannte Better Installer der Firma Somoto heruntergeladen und in einer weiteren .tmp-Datei mit Zufallsnamen gespeichert. Als Affiliates, also Teilnehmer an einem Partnerprogramm von Somoto, verdienen die PSeMu3-Macher bei jeder Installation von Adware mittels des Better Installers Geld. Erkennt der Installer die VM hingegen über den VBOX-String, wäre die Installation der Adware für die Anbieter wertlos und folglich will sich die Werbe-Software erst gar nicht auf dem Computer einnisten.
Mithilfe von Funktionen aus der bereits bekannten bitool.dll sowie dem NSIS-XML-Plugin xml.dll wird die Datei binsis142.xml geparst und deren Inhalt während des Installationsvorgangs von PSeMu3 angezeigt. Dabei will sich etwa die Mystartsearch-Suche als Standard-Suchanbieter im Webbrowser einnisten.
Die Entscheidung des Users für oder gegen eine Installation der angebotenen Adware fragt eine Funktion aus der bitool.dll ab. Per ShellExecute() wird anschließend der Better Installer über die Kommandozeile aufgerufen. Dieser lädt die Software herunter und führt sie aus.
Ehe ich mich versehe, ist Mystartsearch meine neue Startseite in allen Browsern und ein lustig blinkendes blaues Icon auf der rechten Seite der Taskleiste verkündet optimalen Schutz beim Surfen durch die Adware Search Protect.
