Blog von eddy14

Code makers and breakers (SFT geknackt)

Nun, wie soll ich anfangen? Soll ich wieder berichten, dass mir langweilig war? Nee, das kommt in jedem Blogpost vor (verdammt, jetzt habe ich es doch getan!).

Als ich gerade damit beschäftigt war die Software von der Firma, bei der ich zurzeit Praktikum mache, etwas sicherer vor Crackern zu machen, fiel mir auf, dass ich nicht so viel Ahnung davon habe. Hm,  Software sicherer machen … hm das kann ich nicht so gut … aber die Sicherheit zu brechen, das macht Spaß!

Software sichern … hm … Ich mein, “sichern” im typischen Sinne kann man es ja nicht einmal. Es liegt in der Natur der Sache, dass ein ausführbares Programm analysierbar bleibt. Nur wie kann man es so erschweren, dass jeder Reverser die Lust verliert?

Auf der Suche nach der Antwort lud ich mir ein paar CrackMe’s runter, um unter dem Vorwand von “Anti Debugging Technik erlernen” etwas bei der Arbeit cracken zu können

Acht Stunden und unzählige fertige CrackMe’s später fuhr ich nach Hause … ich war immernoch hungrig nach mehr … mehr hardcore Assembler … mehr Geheimnisse entlüften … mehr Glückgsgefühle … mehr davon. Ich kramte auf meinem USB-Stick rum, und fand eine alte version des SFT-Loaders (“SFT Loader 2006″). Nach meinem letzten Beitrag über DLC, und über RSDF, dachte ich mir, es wäre doch praktisch meine Kenntnisse im Gebiet der Analyse von unbekannten Formaten auszuweiten. Diese SFT Dateien bieten einige Warez-Seiten an. Kennt das überhaupt noch jemand? Einige wenige Seiten scheinen das noch anzubieten. Wie auch immer, meinen Spaß hatte ich jedenfalls damit

In der SFT Datei sind (verschlüsselt) Host, Username, Passwort, Dateinamen und einige Optionen hinterlegt. Sodass dieses Programm es entschlüsseln, und dann von den FTP-Servern die Dateien herunterladen kann. Das wollte ich unbedingt mal analysieren, sollte doch sicher spaßig werden?

SFT Loader 2006

Gesagt getan. In einer Woche (á 8 Stunden) und noch etwas mehr, war ich fertig. Man, hat das lange gedauert. Ich habe mit einem Aufwand von 1-2 Tagen gerechnet, aber eine Codestelle im Programm hat meinen Kopf gefickt (ja, ich benutze sonst nie diesen Ausdruck, aber dieses Dateiformat hats echt verdient!). Beim reversen wurde mir immer wieder mal schwindelig und ich hielt meinen Kopf fest, damit sich meine Umgebung nicht mehr so merkwürdig bewegt! (und das ist kein Witz!)

Nun, das SFT Format ist viel cooler als DLC … nein, nicht sicherer. Sondern etwas komplexer … also spaßiger zu reversen

Wer nichts über die Struktur des Formats lernen möchte, der möge das hier überspringen und an das Ende des Artikels springen … dort findet ihr einen SFT Decrypter (Ja, ihr könnt mich hassen, dass ich das tue …)

Als aller erstes sollte klar werden, es ist wieder Security-by-Obscurity. Es gibt keinen Weg daran vorbei, wenn man versucht, auf dem Rechner des Users Daten zu verarbeiten, von dem der Nutzer aber nichts wissen soll. Der SFT-Loader MUSS zwangsweise irgendwann die Daten entschlüsseln. Was ich nun mache ist es, zu analysieren wie dieses Programm es genau macht. Wie generiert es sich seinen Schlüssel? Welche Algorithmen werden verwendet? In welcher Stelle der Datei befinden sich die Daten? Dazu bedient man sich des Reverse Engineering.

Kerckhoffs Prinzip besagt, dass die Sicherheit eines Verschlüsselungsverfahrens auf die Geheimhaltung des Schlüssels beruhen muss, nicht auf die des Algorithmus. In unserem Fall muss jedoch das Programm das Passwort ja wissen, um den Inhalt zu entschlüsseln. Irgendwoher muss es das Passwort ja kriegen. Sei es, indem es sich das selbst generiert (siehe weiter unten) oder ob es einen hardcoded key verwendet. Die Sicherheit ist die selbe, solange ich alles rekonstruieren kann.

Nun, zurück zum Dateiformat: jede SFT Datei hat einen Header. Die ist immer 0×40 (=> 64) Bytes lang. Sie fängt (immer?) mit “A” an, gefolgt von einem 0xFF Byte, und dann “2SFT04″. Es sollte klar sein, wofür “SFT” steht. Die “2″ ist mir noch nicht ganz klar. Die “04″ allerdings steht für die Dateiversion. Soweit ich weiß, ist dies die aktuellste Version des Formats. (Jedenfalls war es das 2006)

SFT Header

Danach folgen weitere 0xFFs bis die 0×40 Bytes voll sind. Nun ist der Header fertig, und der eigentliche Content folgt. Dieser ist mit zlib komprimiert. Einfach dekomprimieren (am einfachsten mit einem Python script) und schon hat man den dekomprimierten Inhalt. Dieser ist allerdings noch verschlüsselt. Der Algorithmus für die Verschlüsselung ist RC4. Wobei wie immer die Sicherheit des Algorithmus ziemlich egal ist, solange der Schlüssel irgendwo abgespeichert ist.
Der Schlüssel für RC4 ergibt sich aus dem SHA1 Wert des Headers. Dafür schneidet man den ersten Byte (also das “A”) des Headers heraus, fügt ans Ende zwei 0xFF hinzu und hasht es dann mit SHA1. Das Resultat ist unser Key. Gewöhnlicher Weise ist es immer die selbe:

7CBEB0CF896EC8DE4F54A2850E6C73B38E95EA06

Mit diesem Key entschlüsseln wir den Dateiinhalt. Und es erscheint uns der serialisierte (aber entschlüsselte) Inhalt der Datei.

Entschlüsselter Inhalt

Von hier an ist es nicht mehr viel. Man kann einfach den Inhalt splitten, und die einzelnen Werte auslesen. Die einzelnen Base64-Strings die dort zu finden sind, sind entweder mit dem SHA512 Hash von “SFT Loader Reloaded” oder “callstackapi”, (mit dem RC4 Algorithmus) zu entschlüsseln. Hierbei hatte ich ein paar Probleme, da meine python library einen Fehler drin hatte (man, ich musste den verdammten RC4 Algorithmus fast nachbauen um den Fehler zu finden … der Programmierer hat vergessen beim crypten i und j wieder auf 0 zu setzen, siehe The Pseudo-Random Generation Algorithm)

Nach einigem rumprobieren und surfen fand ich heraus, dass der Programmierer eine nicht-standardisierte Verschlüsselung verwendet, die nirgendwo dokumentiert ist. Das wäre natürlich der total Krampf im Arsch (ja, ich weiß dass es falsch übersetzt ist) den ganzen Algorithmus auch noch zu reversen. Aber glücklicherweise fand ich diese Komponente, welches wohl dieses Verfahren überhaupt erfunden hat. Sie nennt sich RCx und ist ein selbstprogrammierter Algorithmus, angelehnt an RC5. Also entweder wollte ich ein Delphi Programm schreiben (und diese Komponente verwenden), Strings entschlüsseln und an mein Programm pipen lassen, oder den ganzen Algorithmus selbst implementieren. Ersteres fiel weg, da ich keinem User aufzwingen möchte, Wine zu installieren. Also baute ich den Algorithmus nach. Nach rund 92 Zeilen Code, und 2 Tage debugging (Python hat wohl kein “Byte” als Dateityp, das war wie ein Tritt in die Weichteile) war meine kleine RCx Klasse fertig. Damit kann man wahrlich die einzelnen Werte endgültig entschlüsseln.

Vorerst knöpft man sich das “Header” Element vor (siehe Bild oben). Aus diesem ergibt sich ein String wie folgt:

SFT0#2#D7D05C8DEED489B6C6981D9A6E8D79315C8F2D41A7AC229B385C2A2B73A7959C65F07C7D7CE4F1D6CA7A79E0C2A4847E5587079ACF

SFT am Anfang zeigt uns wieder, dass es korrekt entschlüsselt wurde (mit dem erwähnten RCx Algorithmus). Die “0″ direkt danach gibt an, ob ein Passwort notwendig ist (in diesem Fall also nicht). Ich weiß nicht genau wofür die nachfolgende “2″ ist (Maximale Threads oder so ?) aber alles nach dem letzten “#” ist der Wert, den es zu entschlüsseln gilt. Dafür wurde ein (selbstentwickeltes?) XOR und Salt-System genutzt. Der Salt-Wert ist “callstackapi”. Hierdran wird einfach das eingegebene Passwort angehangen, oder ggf. nichts angehangen. Den XOR-Algorithmus kann man wie folgt beschreiben:

def YurryXOR(key):
raw_key = hashlib.sha512(key).digest()
raw_key = raw_key[:(len(raw_key)/2)]
result = []
key = key*10
for i in range(0, len(raw_key)):
result.append(chr(ord(raw_key[i]) ^ ord(key[i])))
return ”.join(result)

Kleine Erklärung: Der key ist das erwähnte callstackapi+password. Daraus wird ein SHA512 Wert generiert. Die letzte Hälfte wird rausgelöscht. Nun wird der nicht-gehashte Key mit dem gehashten geXORed. Und das Ergebnis ist unser Key.

de5a015215664d925bf3e9f97477caee4ef7a44f6a3d0ee08bf70f1f326e41c7

Sowas in der Art (btw, ich benutze für diese Demonstration diese Testdatei).

Das ist unser Yurry-Key (die habe ich nach meinem Schatz benannt. Haiiii schatziii <3 ). Mit dieser kann man ganz schmutzige Sachen machen (nein, nicht mit meinem Schatz du Perverser! Ich meine den Key!). Haben wir diesen erstmal, stehen uns alle Wege offen. Diesen Key können wir an unser Header-Element anwenden, und somit erhalten wir einen Wert, der exakt so aussieht wie das hier:

{1F945Z9B-3ZA9-4Q13-A5DB-KDKDKFLDSHGVFBV}

(Anfangs sind noch 20 zufällige Bytes, die angehanden wurden. Das ist wohl so eine Eigenschaft vom Algorithmus. Die kann man gefahrlos rauslöschen).

Das sieht aus wie eine Seriennummer, ist es aber nicht. Dieser Wert wird nur verwendet, um zu schauen ob der User das richtige Passwort eingegeben hat.

Mit dem gleichen Algorithmus und dem gleichen Key, ist es nun möglich alle anderen Elemente zu entschlüsseln (Host, Username, Passwort etc.)

sft-decrypter

Das wars auch schon. Man kann noch durch alle Dateinamen gehen, wenn man möchte. Ich denke, das werde ich bei Gelegenheit mal machen, und dem PyLoad Projekt ein SFT-Plugin schenken (auch wenn dies kein Dateiformat für One-Click-Hoster ist).

Nachdem letztens schon wieder ein Hacker Selbstmord begangen hat, ist mir der Fall Tron (ein Hacker der Verschlüsselungen geknackt hatte) wieder eingefallen. Um exakter zu sein, dass was er den Polizisten bei einer Hausdurchsuchung mal sagte: “Man kann das Anwenden
von mathematischen Formeln doch nicht unter Strafe stellen?!” (aus dem Buch “Tron – Tod eines Hackers”).

Ich schreibe später eventuell ein Reverse Engineering Paper hierdrüber, da dieses Target ziemlich lehrreich war!

Ein letztes noch: Es ging hier natürlich wiedermal nicht um das Endresultat, sondern um den Weg. Denn an Username&Passwort der SFT Datei, käme man auch durch Sniffer, Proxies oder ein paar Spielereien mit der Hosts-Datei. Wie J. J. Abrams bereits einmal sagte, es geht nicht um das Ende (die Auflösung des Ganzen). Sondern die Zeit, die man damit verbringt (Gemeint war die Serie Lost, aber passt auch hierzu!).

Verschließt eure Augen nicht vor der Wahrheit! Speichert eure sensiblen Daten nicht in einem undurchsichtigen proprietären Dateiformat. Das ist wie mit WEP. Indem nun jeder Witzbold in ein WEP-Netzwerk einbrechen kann, hat man den Leuten die Augen geöffnet: Verwendet nicht WEP! Und viele (wenn auch bei weitem nicht jeder) haben die Gefahr erkannt. Indem man aber nun einfach sturr und blind bleibt, und meint, weil WEP gebrochen wurde, wäre die ganze Sicherheit um WEP kaputt, irrt sich. Es war schon immer unsicher, nur wurde diesmal einfach nur bewiesen, dass es so ist. Und wer meint ich hätte mit diesen frei zugänglichen Informationen irgendetwas kaputt gemacht, ist naiv. Ich habe nur Informationen veröffentlicht, die jeder SFT User auf dem Rechner hat. Nur hat es wohl keiner vorher einer Analyse unterzogen. Wie dem auch sei:

DOWNLOAD: SFT-DECRYPTER

oder: SFT-DECRYPTER + GUI (benötigt Java) von Seji

//edit 17.07.09 >>> kleines Update. Bugfixxes und ein paar Feature-Requests (Ordner und Dateiname anzeigen) wurden realisiert. Es werden nicht alle Dateinamen und Ordner angezeigt, sondern nur die ersten, habe gerade keine Lust das noch einzubauen. Dennoch viel Spaß

This entry was posted on Friday, July 10th, 2009 at 11:25 and is filed under IT Security, Reverse Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.