Heute geht es mal wieder um Malware, genauer gesagt um das Android Remote-Administration-Tool DroidJack. Für dieses überteuerte Tool wird es zwar keinen Leak geben, aber dafür ein paar Infos über den Crackschutz. Getreu nach dem Motto: “Guter Ansatz, schlechte Implementierung”.

DroidJack wirft dem Benutzer beim Öffnen des Programms einen Login-Bildschrim entgegen. Durch sniffen wird schnell klar, dass die Logindaten mitsamt Hardware-ID an die Access/DJ4.php des Servers geschickt wird. Ein Punkt gibts bereits Abzug, es wird kein HTTPS verwendet

Java-Programme lassen sich, ähnlich wie .NET, einfach analysieren. Zumindest solange der Java-Zwischencode nicht verunstaltet wurde, denn in dem Fall versagen die gängigen Decompiler. Die meisten dieser Codeverunstalter-Tools (Obfuscatoren) ändern die Typenbezeichner, Klassennamen, Methoden und alles sonst, was Informationen enthalten könnte. Der hier verwendete Obfuscator schaffte es aber zugleich, Fehler beim Decompilen zu erzeugen. Somit musste ich mich mit dem Java-VM-Bytecode arbeiten, der ähnlich wie MSIL aufgebau ist. Da mir das zu blöd war, schaute ich mir erstmal die DJ4.php Datei an.

Diese liefert im Falle einer gültigen HWID in Kombination mit validen Zugangsdaten ein zeitbasiertes Token zurück. Wenn dieses Token gültig ist, startet DroidJack das eigentliche RAT. Also spielte ich ein bisschen mit den übergebenen Post-Parametern rum, in der Hoffnung ein Error zu erzeugen und somit mehr über den PHP Code herrauszufinden. Und siehe da, ich bekam plötzlich ein gültiges Token zurück! Ich weiß ehrlich gesagt nicht wie man es schafft, einen solchen PHP Code zu produzieren. Man muss sich schon viel Mühe geben, dass man im Falle eines Fehlers einfach eine gültige Session ausgespuckt wird Wie genau das Token generiert wird weiß ich nicht, aber es ist mir auch egal. Jetzt bleibt nur die Frage offen: wie schaffe ich es, dass das Programm eine ungültige Abfrage an den Server sendet?

Hier boten sich verschiedenste Möglichkeiten an: Ein Hook in der WinSocks-Methode send(), welche die abgeschickte HTTP Request im Nachhinein verändert. Oder die übliche Manipulation der Host-Datei, um droidjack.net auf einen lokalen Server umzuleiten, der wiederrum ein gültiges Token zurückgibt. Da ich letztere Variante noch nie automatisiert ausgeführt hatte (und auch keine Lust hatte, eine DLL Injection zu schreiben), wurde der lokale Server implementiert. Der Flow des C#-Programms sieht dabei wie folgt aus:

1. Es wird sichergestellt dass sich kein Eintrag mit der Droidjack-Seite in der Host-Datei befindet
2. Eine ungültige Request wird an den Server geschickt, um ein Token zu erhalten
3. Über die Host-Datei wird eingestellt, dass die Droidjack-Domain auf Localhost (127.0.0.1) auflöst
4. Ein minimalistischer HTTP Server in C# wird gestartet, der auf jede Request das Token zurückgibt
5. DroidJack wird gestartet und das Einloggen mit beliebigen Daten ist innerhalb von ca. 5 Min möglich

Fazit: Es reicht nicht nur, das Java-Program abzusichern. Das Gesammtpaket sollte stimmen, und da ist der Server mit eingeschlossen

Greez