• Skip Navigation

Blog of eddy14

Search for:

• Home
• About me
• Exploits
• Reverse Engineering
• Software
• Tutorials

Archive for the ‘Computersicherheit’ Category

Salzwasser Sauger

Düm Di Dum Düm, trararara DIIING. Ich wollte schon immer einen eigenen Introsong haben! Wer komponiert eines für mich? *liebschau*

Mir war gestern langweilig, also nahm ich ein Programm ausseinander! Ich wusste, dass meine Motivation nicht sehr stark war, deswegen wollte ich heute nur ein einfaches Programm operieren. Ich weiß leider nicht mehr von wem der Tipp kam, aber mir fiel eine gewisse Warez Seite ein, die ihre Angebote auf FTP-Server hochluden. Dafür wird ein eigens konstruierter Leecher verwendet. Auf der Webseite (die übrigens genauso hässlich ist wie das Programm) lädt man sich eine verschlüsselte “Mirror-File” herunter, die nur ein paar KB groß ist. Mit dem Leecher kann dieser nun geöffnet werden.

Wisst ihr nun, was ich mit hässlich meinte?

Die verschlüsselten Dateien haben die Endung “.swl”, deswegen rede ich hier von SWL-Dateien. Wie jeder Reverser weiß, wird zuerst das Programm auf die übliche Art benutzt. Wir klicken unten auf “Open”, es öffnet sich ein Dialogfenster und wir wählen unsere SWL-Datei aus. Nun lädt das Programm diese Datei, und zeigt uns den Inhalt an, sodass wir mit einem Druck auf “Download” das Herunterladen starten können.

So weit, so gut. Ich knackse kurz meine Finger, feuchte meine Lippen an, hole tief Luft, schaue auf die Uhr, merke mir die Zeit, gehe kurz auf die Toilette, hol mir von der Küche eine Tüte Erdnussflips und freue mich auf den Abend.

Als aller erstes will ich schauen, ob das Programm gepackt ist. Dafür verwende ich PEiD. Den entdeckten Packer lasse ich mir durch ein Stück Software automatisch entfernen, denn mir fehlt echt die Lust auf manual unpacking (und das Einlesen in das Thema erst!).

Nun kann ich es ganz bequem in meinen Debugger OllyDbg laden und anfangen. Ich mache mir natürlich Gedanken, wie ich am besten vorgehen soll, um das Geheimnis des Dateiformates zu befreien. Ich werde hier mal die übliche Vorgehensweise von mir schildern:

1. Dateiformat in einem Hexeditor ansehen um eine ungefähre Idee davon zu kriegen, wie die Datei strukturiert sein könnte.
2. Herausfinden, an welcher Codestelle der Dateiinhalt eingelesen wird
3. Herausfinden an welchem Punkt der komplette Inhalt entschlüsselt wurde
4. Zwischen diesen beiden Stellen an interessant aussehenden Stellen Breakpoints setzen
5. Etwas im Code tracen (während der Ausführung) um ein Gefühl dafür zu bekommen, was (ungefähr) geschieht
6. Nach Mustern im Code suchen, die mir Aufschluss darüber geben, WIE entschlüsselt wird (Algorithmus, Schlüssel, etc.)
7. Wichtige CALLs dokumentieren und benennen um ein besseres Verständnis für den Codeablauf zu haben. Alles was nach einem Schlüssel aussieht, in einer Text-Datei vormerken.
8. Vermutung aufstellen, und bestätigen durch eine Scriptsprache freier Wahl. Beispielsweise Rijndael im ECB Modus auf die Datei anwenden, und schauen ob das Resultat gut aussieht.
9. Wenn das allgemeine Verständnis für die Verschlüsslung da ist, einen Decrypter schreiben.

Der erste Schritt ist sehr einfach und ziemlich interessant! In einem Fall war es mir sogar mal möglich, allein durch das Ansehen des Dateiformates im Hexeditor herauszufinden wie es verschlüsselt wurde (ein einfacher XOR mit dem ersten Byte der Datei). Aber hier siehts nicht so aus:

Fast die vollständige Datei sieht verkrüppelt aus. Sieht nach Verschlüsselung aus (wer hätte das gedacht?). Allerdings befindet sich am Ende eine Webadresse und eine lange Zahl. Die sehen ziemlich wichtig aus! Eventuell ist es der Schlüssel (oder der Schlüssel wird damit generiert, oder es wird an die Seite versendet und dieser gibt uns den Key, oder es ist ein IV, oder oder oder ….). Wir müssen unbedingt solche Vermutungen aufstellen, damit uns später in dem Flut von Assemblercode Muster auffallen. Wenn wir die Webadresse aufrufen, wird uns eingeredet, es wäre ein 404. Schade, vermutlich wird diese Zahl per POST gesendet, oder so ähnlich.

Mehr ist aus dem alleinigen Ansehen des Dateiinhalt nicht zu entnehmen. Also gehen wir zu Schritt 2 über. Wir müssen herausfinden, an welcher Codestelle die Datei geöffnet wird. So wissen wir die ungefähre Stelle von der Entschlüsselung. Nun, betrachten wir noch einmal, was passiert wenn wir auf “Open” drücken. Es erscheint ein ein Öffnen-Dialog. Wieso versuchen wir nicht genau an dieser Stelle das Programm zu stoppen? Dieser Öffnen-Dialog scheint so ziemlich einzigartig zu sein.

Viele Windowsprogrammierer kennen bereits die API GetOpenFileName. Damit erstellt man dieses schöne Öffnendialog-Fenster das vielen Windows-Usern bekannt ist. Genau dort will ich ansetzen. Also tippe ich unten in die Commandbar von OllyDbg “bp GetOpenFileNameA”. Jetzt kann ich mir sicher sein, dass ich genau dann breake, wenn das Programm die Datei auswählt. Ich lass das Programm laufen, und genau so kommt es!

Schritt 3 ist nicht unbedingt Notwendig, aber dennoch hilfreich. Nach dem Öffnen der Datei zeigt das Programm eine MessageBox. Aha! Dort können wir auch breaken. “bp MessageBoxA”. Halleluja!

In Schritt 4 sollen wir nun interessante Stellen suchen. Dafür bediene ich mich der String-Suchfunktion von Ollydbg. Ich scrolle etwas rum, und finde süße Dinge wie “TDCP_twofish”. Das sieht nach der DCPCrypt Bibliothek für Delphi aus. Und “twofish” ist der Name des Algorithmus! Und von “SHA1″ ist auch die Rede. Eine Hashfunktion, auch schön! Also breake ich an den Stellen, wo diese Strings referenziert werden.

In Schritt 5 und Schritt 6 kann man Stundenlang verweilen. Es macht Spaß zu sehen, wie der Entwickler das Programm entworfen und programmiert hat. Man versteht langsam, wieso er jenes und anderes getan hat. Wenn man verfolgt, was mit den Strings passiert die eingelesen werden, dann erlangt man ziemlich schnell Erfolge. Einer meiner Tricks, um zu verfolgen was mit dem Dateiinhalt geschieht, ist es den Anfang der Datei so zu ändern, dass daraus ein String entsteht (ansonsten wäre es ein binärer Inhalt). Beispielsweise ändere ich die ersten Bytes zu “INHALT” und füge ein 00-Byte hinzu. Nun wird mir Ollydbg immer diesen String anzeigen, wenn irgendwo der Dateiinhalt referenziert wird. Ich trace also gemütlich durch den Code und knabbere ein paar Snacks.

Nach einiger Zeit bringe ich in Erfahrung, dass anscheinend ein Hash von etwas gebildet wird. Der Hash ist 20 Bytes lang. MD5 kann es nicht sein, denn dieses hätte eine Länge von 16 Bytes. Aus Erfahrung weiß ich, dass es sich bei 20 Bytes eigentlich immer um SHA handelt. Aus den Strings entnehme ich folgende (für viele merkwürdig erscheinende) Zeile:

ASCII “abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq”

Wenn man nach dem String googlet, wird man zahlreiche Indizien dafür finden, dass diese merkwürdige Anreihung von Buchstaben etwas mit SHA zu tun hat. Da kann ich euch aufklären: Viele der kryptografischen Bibliotheken verwenden einen sogenannten “SelfTest” um sich selbst auf Funktionalität zu testen. Dabei wird der Hash von einem bekannten String erstellt, und mit der (vorgefertigten) richtigen Lösung verglichen. Sind beide gleich, funktioniert die Bibliothek. Und um SHA zu testen, wird (unter anderem) der oben genannte String verwendet. Ich setze also einen Breakpoint in den CALL wo dieser String gelinkt ist, in guter Hoffnung, dass die Library sich bei der initialisierung automatisch selbst testet.

Da ich weiß, dass hier DCPCrypt verwendet wird, bediene ich mich einer sehr guten Methode, um alle wichtigen CALLs zu benennen. Somit wären wir also im siebten Schritt. Ich suche nach Mustern im Code! Zuerst lade ich mir die aktuellste Version dieser Kryptobibliothek herunter. Ich sehe mir die Datei DCPsha1.pas an, um nach einem einfach aussehenden Muster zu suchen. Ich finde die folgende Codezeile:

class function TDCP_sha1.GetHashSize: integer;
begin
Result:= 160;
end;

Das sieht doch sehr schön aus! Eine kurze Funktion, die auch noch mit einer ungewöhnlichen Zahl arbeitet. Diese Funktion gibt die Hashgröße in Bits an, aber das braucht uns eigentlich nicht interessieren (160 Bits / 8 ergibt 20 Bytes, die Größe unseres Hashes!). Nun wollen wir uns überlegen, wie wohl diese obige Funktion in Assembler aussehen könnte. Wenn wir absolut keinen Plan davon hätten, könnten wir uns die Delphi IDE installieren und ein Beispielprogramm mit dieser Library kompilieren (mit zusätzlichen Debuginformationen) und uns dann im Debugger das Resultat anschauen.

Ich kann mir aber bereits denken, wie es in Assembler aussieht. Und zwar so:

mov eax, 0A0
ret

So ungefähr. Also suche ich einfach in Olly nach dieser ersten Zeile. Rechtsklick->Search for->command->”mov eax, 0A0″. Olly wird fündig!

Weiter unten sieht man noch einen Teil des SelfTest-Strings. Wir sind also tatsächlich im Code von SHA. Wir drücken nun die Doppelpunkt-Taste auf der Tastatur, und benennen diesen CALL mit “TDCP_sha1.GetHashSize”. Der ein oder andere wird sich nun fragen “Wieso wollen wir unbedingt diese Codestelle wissen?”. Der Grund ist einfach: Die restlichen Funktionen der SHA-Klasse müssen (eigentlich) in der gleichen Reihenfolge wie im Code hier zu finden sein! Im Sourcecode von DCPCrypt folgt nun “TDCP_sha1.SelfTest”. Und “oh Wunder!”, in OllyDBG sehen wir auch direkt nach der GetHashSize Funktion den SelfTest String. Es stimmt also!

Wir machen einen Rechtsklick auf GetHashSize. Find Refernces to->Selected Command. Von den Resultaten wählen wir das Unmarkierte. Wir finden uns an so einer Stelle wieder:

Das sieht leer und düster aus. Aber da wir bereits eine dieser Stellen auf unsere GetHashSize-Methode zurückführen können, haben wir eine Ahnung wie wir den Rest der Funktionen benennen können. Wir wählen den nächsten “dd dump.*****” in der Liste, klicken Enter und hüpfen zum nächsten CALL. Es ist der SelfTest. Also benennen wir diesen. Dann gehen wir zum nächsten dd-Eintrag und bennen ihn mit “Init”. Denn dieser wäre die nächste Methode im Source-Code gewesen. Am Ende erhalten wir eine wunderbar dokumentierte Liste:

An wichtigen Stellen setze ich hier ein Breakpoint. “Init”, “Update” und “Final”. So kann ich verfolgen, aus welchem String ein Hash erzeugt wird.

Ich lasse das Programm nun laufen, wähle meine verschlüsselte SWL-Datei und breake bei einem der Methoden. Ich kann den Registern entnehmen, welche Daten/Parameter/Argumente der Methode mitgegeben wurden. So entnehme ich ihm die Information, dass aus dem folgenden String ein SHA1-Hash gebildet wird:

0×010203 + “PWsaltwaterPW” + 0×030201

Es scheint ein konstanter Wert zu sein. Ein Passwort, dass in die EXE eingebrannt wurde. Vermutlich wird der Hash als Key für die Verschlüsselung verwendet. Der Hash der sich ergibt, ist also immer konstant folgender Wert: EB EA FB E3 B6 7F 8E 98 19 EE C8 AC 7C 7A 1C CF 3A FB 4D BA

Das ist cool! Ich muss den Schlüssel also nicht selbst berechnen! (Trotzdem irgendwie langweilig und monoton ….). Ich schreibe mir diesen Key also auf, damit es mir nicht verloren geht, und ich die ganze Suche von vorne starten muss.

Plötzlich fällt mir nach einigen Minute auf, dass ich die SWL-Datei nicht mehr öffnen kann. Das Programm teilt mir mit, dass die Zeit abgelaufen sei! Wie bitte? Die Webseite des Leechers sagt mir folgendes:

Achtung:
SWL-Dateien können nur innerhalb von 60 Minuten nach Empfang geöffnet werden. Es spielt aber keine Rolle, wie lange sie dann geöffnet bleiben.

Aha! Da wir gerade eben herausgefunden haben, dass das Programm einen konstanten Key verwendet, kann ich mir sicher sein, dass nicht der Server uns einen temporären Key liefert, zum entschlüsseln dieser Datei. Es ist also der Leecher selbst, der Clientseitig entscheidet, dass wir die Datei nicht mehr verwenden dürfen. Und genau dafür war wohl die URL und die Nummer am Ende der SWL-Datei. Ich patche also kurz die Codestelle, sodass ich alle SWL-Dateien unendlich lange verwenden kann. Das wäre schonmal aus der Welt!

Wenn wir uns an die String-Funde von gerade erinnern: Es war die Rede von Twofish! Also lassen wir unsere Vermutung von dem Krypto-ANALyzer in PEiD bestätigen. Und dieser ist genau unserer Meinung: Es wird der Twofish-Algorithmus verwendet. Wir gehen genauso vor, wie gerade. Wir suchen nach Mustern. Ich öffne ein paar SourceCodes von DCPCrypt, und suche nach schönen Zeilen, die einzigartig sind.

class function TDCP_blockcipher64.GetBlockSize: integer;
begin
Result:= 64;
end;

Also suche ich nach:

mov eax, 080
retn

und ich lande genau an der richtigen Codestelle. Nun gehe ich genauso vor, wie bei SHA1. Und am Ende habe ich so einiges dokumentiert:

Ich breake natürlich an allen interessanten Stellen (so gut wie allen oben genannten). Und ich finde heraus, dass DecryptCBC aufgerufen wird. Somit weiß ich mit sehr hoher Wahrscheinlichkeit dass der CBC-Modus benutzt wird. Nachdem ich bei “Init” und “InitStr” breake (leider auf dem Bild nicht zu sehen), sehe ich im EDX Register den Schlüssel. Und, wie hätte man es sonst erwartet, ist es der Hash den wir oben berechnet hatten!

Schritt 8 => Unsere Vermutung ist also, dass der Dateiinhalt per Twofish entschlüsselt wird. Und der Key ist der konstante Hash, den wir oben herausgefunden hatten. Nun holen wir uns irgendeine Scriptsprache, für die es eine fertige Twofish-Bibliothek gibt. Leider hat es das weder Python (jedenfalls keine funktionierende) noch Ruby. Aber PHP hat mcrypt. Also greiffe ich auf PHP! Ich hatte keine Lust auf PHP, und die Einarbeitung in MCrypt, also habe ich mir schnell von den Beispielcodes etwas zusammenkopiert. Den Decrypter braucht ja sowieso niemand.

Ich finde nur noch kurz heraus, wie die Daten im Plaintext strukturiert sind, damit man sie auslesen kann (alle Daten sind per 0×01 voneinander getrennt. Ganz easy!) und es entsteht (Schritt 9) ein Decrypter:

Schachmatt! SWL wurde geknackt!

Download

Ein Teil dieses Blogeintrages wurde auf der Toilette verfasst. Normale Menschen lesen Zeitung auf dem Klo. Geeks bloggen. Vermutlich einer der Gründe wieso ich so viel Scheisse auf dem Blog produziere (Ah, ich liebe Wortspiele!)

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?

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)

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.

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.)

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ß

Real-Life

Momentan mache ich Praktikum bei einer Firma, die unter anderem Software entwickelt. Bei meinem Vorstellungsgespräch erwähnte ich meine persönliche Webseite (eine Seite unter meinem echten Namen) woraufhin diese sich dort umgesehen haben. Was war wohl auf meiner persönlichen Webseite? Na klar, das Thema Computersicherheit kam nicht zu kurz. Also bat mich meine Ansprechperson in der Firma direkt am ersten Tag, ihre Software (die btw seit über 10 Jahren entwickelt wird, respekt!) etwas sicherer vor Reverse Engineerer zu machen. Alles klar, das dürfte spaßig werden!

Nundenn, da ich generell interessiert bin, an allem was mit Sicherheit und Einbruch zu tun hat (hey, ich bin Ausländer, das liegt mir im Blut ) dachte ich mir, ich könnte in den Pausen ja mal bisschen gucken, wie die Firma strukturiert ist. Netzwerktechnisch und auch sonst.

Am ersten Tag bekam ich eine Karte, die nötig ist um die Türen öffnen können. Die Firma hat tausende von Mitarbeitern, da ist natürlich klar, dass professionelle Sicherheitssysteme eingesetzt werden. *edit* Die Kommentare hatten mal wieder Recht. Es war nur eine stinklangweilige RFID Karte Habe gerade den Shop gefunden, wo die exakt die selben Karten anbieten.

Nundenn. Ich war amüsiert davon. Meine 8-Stunden Schicht war zuende, also mache ich mich in Richtung Bahnhof (der an einem Flughafen liegt). Da ich noch ein paar Minuten warten kann, gehe ich in ein Wartezimmer.

(Das Foto wurde btw mit meiner DSi aufgenommen. Ich liebe das Teil <3 Habe es immer mit um Pi zu hören … jaja meckert nur … pi for president!)

Jedenfalls denke ich mir, total gelangweilt, “Hm, was könnte man hier so schönes machen”. Ok, ich bin an einem Flughafen, ich bin Ausländer, und habe einen Koffer dabei

Spaß beiseite … das einzig coole waren die Bewegungssensoren, die die Türen automatisch öffnen … langweilig *gähn* Dann gibts da noch diese Fernseher. Alles öde. Ich wollte mich gelangweilt an einen Platz hinsetzen und sehe das:

Also frage ich mich wie von der Stille und der Langweile betäubt, woher der Fernseher die aktuellen Daten bekommt (wann der Flug ist etc.). Oben sind die Wände “offen”, sodass man alle Kabeln sieht. Bei näherer Betrachtung des Fernsehers sehe ich folgendes:

Oh cool. Da sehe ich Kabeln. Mal näher daran gehen, oder? Dürfte cool sein zu sehen, wohin es führt.

Moment … ist das etwa … ist das? Nee oder ? Schauen wir uns das mal etwas näher an:

Das sieht doch echt aus wie ein LAN Kabel oO Was macht ein LAN Kabel am Fernseher? Und wieso ist es so “offen” und frei verlegt? Mal näher schauen

(btw, sorry für die schlechte Qualität … DSi halt )

OK, erfreuliche Nachrichten. Es ist sehr wahrscheinlich ein Ethernet Anschluss. Und noch besser: Eins ist noch frei Hallo Internet am Flughafen, ich komme…

Wenn ich mich da dranstöpsel, kann ich sehr wahrscheinlich auf das interne Netzwerk zugreiffen. Oder schlimmstenfalls nur die Ausgabe des Fernsehers manipulieren. ODER einfach so einen transportablen WLAN Router dort anstöpseln, merkt sicher sowieso keiner. So könnte ich von aussen aus, in das interne Netzwerk zugreiffen

Ich dachte mir, wäre cool zu wissen wo genau das Kabel angeschlossen ist. Man siehts nicht richtig, aber ich habe mir den Arsch aufgerissen um das Bild hier zu machen:

Während ich versuche auf dem Sitzplatz zu stehen und die Fotos zu machen, höre ich den Aufzug neben mir aufgehen, und ein Typ aus der Flughafen Security steigt aus. Ich setze mich reflexartig hin. Er schaut mich stechend an, während er raus an die Luft geht, kein Wort sagt, und seine Zigarette anzündet. Dabei schaut er öfter mal rüber. So verdächtigend. Ich bin extra noch sicher gegangen, dass mich keine Kameras beobachten. Aber ich bin gestern schon aufgefallen, als ich total auffällig Fotos von der Sicherheitskamera gemacht habe … keine 2 Minuten, und ein Securitytyp stand sehr kritisch neben mir

Danach gings ab nach Hause. Und wie es sich für einen Mann gehört, hat meine Pussy auf mich im Bett gewartet:

Phrack #66

Kill the underground, you won't kill the Hacker culture.

Die neue Phrack ist raus

http://phrack.org/issues.html?issue=66

Viel Spaß beim Lesen

YouPandora

Meine neueste Errungenschaft: Ein Programm, welches Youtube-User freezed und somit verhindert, dass dieser sich einloggen kann; je nach verwendung sogar lebenslänglich

Vorgeschichte:

Von langeweile geplagt hingen ich und Hann!bal wieder im Netz rum und überlegten uns was wir diesmal wieder hacken. Ein bisschen rumgetrödelt, bisschen gehacked und da kam uns die Idee eines XSS Wurms. Eins auf Youtube wäre cool dachten ich mir! Also gingen wir beide auf die Webseite los und wollten Vulnerabilities suchen die uns unsere Machenschaften erleichtern sollten.

Ich tippe also www.youtube.com in den Browser und möchte mich einloggen. Benutzername eingetippselt, aber Passwort vergessen

Nach ein paar Fehlversuchen meint Youtube plötzlich: Du hast zu oft vergeblich versucht, dich anzumelden. Bei einem weiteren fehlgeschlagenen Versuch wird dein Konto eventuell vorübergehend gesperrt.

Oh Gott. Wollten sie wirklich den Benutzer sperren, und nicht die IP die versucht sich dort fälchlicherweise anzumelden? Wenn dem so wäre, könnte man glatt den alten MSN Freezer im neuen Glanz wieder beleben, diesmal für Youtube (ja ich weiß, das Tool war lame, aber das Prinzip war brilliant).

Also ein paar mal mehr versucht mich unter falschen Daten anzumelden, und Youtube meldete sich mit:

Du hast zu oft vergeblich versucht, dich anzumelden. Bitte warte einen Moment, bevor du es erneut versuchst.

Und tada, mein Account war wirklich ein paar Minuten gesperrt. Um ganz sicher zu gehen bat ich Hann!bal sich in meinem Account anzumelden, aber ihn ereilte die gleiche Meldung. Also war eines sicher: Das war eine ziemlich kleine, aber lustige “Sicherheits”lücke.

Wir fingen beide an zu coden. Ich in Ruby, er in Perl. Fertig waren 2 Scripte, die uns ermöglichen jeden Benutzer von Youtube lebenslang zu sperren Möglich ist das, weil zwar der Benutzer nach ein paar Minuten freigeschaltet wird, aber das Script dann wieder versucht sich falsch anzumelden.

Hier kriegt ihr meinen und sowohl Hann!bals script:

YouPandora&YouFreeze

DLC geknackt!

Ich überlege mir nun seit Stunden “soll ich es tun oder nicht?“. Und ich habe mich entschieden: Ich tue es!

Zuerst einmal eine Kurzfassung: ich habe das DLC Format dokumentiert und ein kleiens Ruby Script geschrieben, welches eine DLC Datei entschlüsseln und die Links daraus lesen kann. Ein “Buuuh!” von den DLC-Nutzern ist zu hören und ein “Jippie-Jeah” von denen, die nicht DLC Nutzen konnten (tuxload-Nutzer und das neue PyLoad was ich mir noch ansehen möchte!). Das Script findet ihr ganz am Ende des Artikels.

So, und jetzt zu der langen Fassung:

Ich bin über zahlreiche Foren gestolpert, wo überall behauptet wurde, DLC sei nicht knackbar, es sei sicher (ein Beweis dafür wäre: es ist bis heute nicht geknackt) … und der Grund für die Sicherheit wäre, dass alles Serverseitig passiert!

FALSCH GEDACHT! Vielen (darunter auch die Entwickler des DLC Formates: das jDownloader-Team) war von Anfang an klar, dass DLC von Grund auf unsicher ist. Eine Container-Datei in dieser Art, KANN nicht sicher sein! Es ist broken-by-design. Kugelfisch hat es schon mehrfach erwähnt. Der einzige Grund, wieso DLC existiert ist, weil die Benutzer ein neues Container-Format wollten! (laut Aussage im IRC Channel vom jDownloader).

Bei Programmen wie dem RSD führte Desinformation dazu, dass Rijndael falsch verwendet wurde. Es stimmt, AES ist sicher. So lange das Passwort für die Verschlüsselung nicht bekannt ist. Nehmen wir an, jemand verschlüsselt eine Datei mit AES. Diese Datei wird nun geklaut. Es wäre nicht möglich, diese Datei zu entschlüsseln ohne das Passwort zu kennen. Bedenke: Der Algorithmus (also AES) ist bekannt und öffentlich einsehbar. Die Sicherheit beruht also nicht auf die Geheimhaltung des Algorithmus (siehe: security-through-obscurity). Wie man lesen kann, wurde AES von vielen Sicherheitsforschern nach Schwächen durchsucht (es gibt zwar welche) aber bislang gilt diese Verschlüsselung als sicher!

Mit dieser Annahme verwendet nun RSDF und (soweit ich weiß) das alte CCF (es gibt ja jetzt schon ein neues: CCF3.0) Verschlüsselungsalgorithmen wie Rijndael. Rijndael ist sicher, also muss das Dateiformat ja auch total sicher sein! Ja, aber nur so lange das Passwort geheim ist, denn nur damit kann man den Inhalt entschlüsseln. Wie jedoch, soll ein Programm wie RSD, CryptLoad oder jDownloader es schaffen, den Inhalt zu entschlüsseln, ohne das Passwort zu kennen?  Es geht nicht, also muss das Passwort für die entschlüsselung in den Programmcode (somit auch in die ausführbare Datei) “eingebrannt” werden.

So, der kluge Kopf weiß nun schon bescheid: Das ganze ist bullshit! Der Benutzer der DLC Datei soll also die Datei mit dem Passwort entschlüsseln können, ohne aber das Passwort selbst zu kennen! So gesehen gibt man also den Tausenden von Usern das Passwort mit, hofft aber dass keiner das Passwort herausfindet!

Das ganze funktioniert nur, indem man hofft, dass der Anwender nicht die nötigen Fähigkeiten hat, das jeweilige Programm zu analysieren. Schon ein einfacher Disassembler oder Decompiler ermöglicht einem die analyse solch eines Programmes. Nun versucht man also nicht mehr das Container-Format zu schützen, sondern das Programm vor der Analyse! JDownloader verwendet hierzu Obfuscatoren! Das Programm “Load!” setzt, laut Kugelfisch’s Blog, auf Protectoren und Packer und CryptLoad läuft auch nicht ganz ohne Pseudo-Schutz rum.

Wie man merkt, das ganze entwickelt sich zum Versteck-Spiel, wer sich denn nun besser gegen den bösen bösen Reverse-Engineerer schützen kann. Ironischerweise werden gerade die Warez Leute den Reverser anmachen, dieses Dateiformat offengelegt zu haben!

Ich zu meinem Teil habe schon vor Monaten (mit spärlichen Reverse-Engineering skillz) versucht RSDF zu dokumentieren (kurz nachdem es sowieso bereits gebrochen war). Nun aber, hab ich mir gedacht: RSDF ist out, CCF ist out, ich sollte mir mal DLC ansehen!

Jetzt fragen sich viele: Hey, ich habe gedacht, die Sicherheit von DLC beruht darauf, dass alles Serverseitig abläuft! Wie bereits erwähnt, es existiert keine Sicherheit: Alles was mit dem Server gemacht wird ist, eine Art “Key” abzuholen, der halt in einer Datenbank gespeichert wird. Dieser wird benötigt, um den DLC Inhalt zu entschlüsseln. Im Klartext: ohne Server, keine Entschlüsselung! Nur der Server kann auf die Datenbank zugreiffen (hier sei mal angemerkt: ich weiß nicht ob tatsächlich eine Datenbank existiert, es könnte auch sein dass aus den gesendeten Daten der neue Schlüssel berechnet wird), und nur der Server kennt die servereigene Verschlüsselung. Man müsste also quasi den Server hacken um an die Information zu kommen, was da nun im Hintergrund abläuft.

Aber wieso so voreilig? Irgendwann MÜSSEN wir doch die Rapidshare-Links auf dem Clienten (also bei dem DLC-Anwender) haben. Bekannt ist bereits die Methode mit Wireshark. Einfach mitsniffen wenn die Rapidshare-Links nach Verfügbarkeit geprüft werden. Das könnte man sogar mit ein paar Linux tools vereinfachen (sniffen, und dann die rs-links greppen … hoch lebe die Linux Shell!).

Wie erwähnt, wird der Server nur für das Abholen dieses Keys benötigt. Nur weil ein Programm nicht offline alles entschlüsseln kann, sondern einen Server braucht, spricht das nicht für Sicherheit. Denn wer hindert mich daran, genau den gleichen Server, auf die gleiche Art, zu kontaktieren?

So, wie holt man nun den genannten Key ab? Programme wie jDownloader benutzen beispielsweise folgende URL:

http://service.jdownloader.org/dlcrypt/service.php?destType=rsdc&srcType=dlc&data=[data]

Diese URL sollte nur mit einem speziellen User-Agent aufgerufen werden (“Mozilla/5.3 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/2232 Firefox/3.0.0.R“), sonst könnte es zukünftig sein, dass man anhand des User-Agents als “Normaler Browser-Benutzer” identifiziert wird und eine IP-Sperre bekommt. Zusätzlich gibt es eine IP-Sperre, wenn man zu oft den Server kontaktiert … ganz schön nervig wenn man dauernd reconnects durchführen muss! . Die IP-Sperre kennzeichnet sich damit aus, dass man falsche Daten erhält (ganz schön pfiffig!).

Nungut, zurück zu dem Link. In diesem Fall sieht man “destType=rsdc”. An dem erkannt man, dass ich den RSD reversed habe. Aber ich hab auch jDownloader decompiled und dokumentiert (nur mangels Java Kenntnisse die zum nachbauen nötig waren, es dabei belassen. Ein Freund, der genügend Java Kenntnisse besitzt, macht sich gerade daran!). jDownloader selbst benutzt (kann sein dass diese Daten veraltet sind, es sind ein paar Monate her, seit ich jDownloader decompiled hatte):

http://service.jdownloader.org/dlcrypt/service.php?jd=1&srcType=plain&data=[data]

Wieso hat jede Implementation des DLC einen anderen Aufruf? Ganz einfach: damit der JD-Server ein bestimmtes Programm Sperren kann, sobald es gebrochen wird. Wenn also der Algo der in RSD verwendet wird, öffentlich gemacht wird, sperrt der Server einfach alle RSD Benutzer! Wie oben erwähnt, das ganze wird zum Katz-und-Maus-Spiel. Wenn ich also meinen Decrypter hier zur Verfügung stelle, und das JD-Team davon Wind bekommt, können alle RSD-Nutzer keine DLCs mehr öffnen. Wenn ich aber nun die Methoden aller DLC-nutzenden Programme raushätte? Dann müssten die Entwickler immer wiede neue Algorithmen für alle DLC-nutzenden Programme entwickeln, die Keys wechseln usw. Bis wann kann das ganze so weitergehen? (vergleicht es ruhig mit Premiere!).

Nun, was ist dieses “[data]“? Das sind die letzten 88 Bytes (ich hoffe, dies hat keine politische Bedeutung ) der DLC Datei (öffnet eine DLC Datei mit einem Editor eurer Wahl; ihr seht einen Base64 kodierten String, die letzten 88 Zeichen davon meine ich). Diesen sendet man also dem Server. Er antwortet mit soetwas:

<rc>noch_ein_base64_string</rc>

Mit diesem string (nachdem wir das mit “rc” entfernt haben) können wir einen Key generieren (nennen wir ihn mal “Response-Key”).

Diesen Base64-Key dekodiert man. Nun führt man eine AES-Entschlüsselung durch, und zwar im ECB Modus (Size: 128), mit dem konstante Key “15938425379F64DD“. <- Das ist z.B. so ein Key, das ich weiter oben erwähnt habe … ein Schlüssel, der fest im Programm integriert ist.

Das ist aber nun noch nicht alles, wir haben immernoch nicht unseren neuen Key berechnet. Wir müssen nun das Resultat der Entschlüsselung mit dem konstanten Wert “24dbc598bcb9bc39” Byteweise XORen. Nun haben wir unseren neuen Key berechnet (das ist unser Response-Key). Dieser sieht aus wie ein md5-Wert, nur ist es halb so lang!

Nun kommt ein etwas komplizierterer Teil. Wir müssen nun in 16-Byte Schritten handeln. Erstmal müssen wir aber den inhalt der DLC Datei auslesen. Davon müssen wir noch die letzten 88 Bytes ausschneiden (die haben wir ja oben bereits verwendet). Den restlichen base64 string dekodieren wir nun. Es kommt nur binärer Bullshit dabei raus. Aber keine Sorge, das wird noch! *edit* Das nachfolgende beschreibt im Prinzip nur den CBC Modus. Ich habe mangels Kenntnisse es nicht als solche entlarvt, und einfach nachgebaut was ich gesehen habe. Zusätzlich bot mir meine Ruby-Library diesen Modus nicht an, AFAIK */edit* An das dekordierte hängen wir den New-Key vorne dran. So, das ganze müssen wir noch XORen. Und zwar wird das dekordierte (diesmal aber wieder ohne den New-Key vorne dran) entschlüsselt. Im ECB Modus, Size 128, und als Key wird wieder der New-Key verwendet. Dies muss man aber jeweils blockweise in 16-Byte Schritten tun! Also erstmal die 16 bytes des dekordierten, mit den 16-bytes des entschlüsselten XORen, und dann zu den nächsten 16 Bytes usw.

Am Ende hat man einen ganz neuen Base64-String. Von hier an ist es nicht mehr weit. Nur noch einmal dekodieren, und schon haben wir das XML-Format, dass der DLC Datei zugrunde liegt. Sowas in etwa:

<dlc>
<header>
<generator>
<app>TGlua3NhdmUoY3J5c3RhbCk=</app>
<version>MC41</version>
<url>aHR0cDovL3d3dy5saW5rc2F2ZS5pbg==</url>
</generator>
<tribute>
<name>bi5BLg==</name>
</tribute>
<dlcxmlversion>MjBfMDJfMjAwOA==</dlcxmlversion>
</header>
<content>
<package name=”MjgyNjYxNzcxNDkxYzIyYTk3ZTkzNQ==” comment=”RExDIGNyZWF0ZWQgYnkgTGlua1NhdmUuaW4=”>
<file>
<url>aHR0cDovL3JhcGlkc2hhcmUuY29tL2ZpbGVzLzE1MzU0Nzk3Ny9SU0RfMC41ODkucmFy</url>
<filename>UlNEXzAuNTg5LnJhcg==</filename>
<size>NTk1MzUzNg==</size>
</file>
</package>
</content>
</dlc>

Fast fertig! Die ganzen Base64-Strings die da verwendet werden, können einfach dekodiert werden, ohne entschlüsselung diesmal Und wo liegt nun der Link? Genau: <file><url>HIER</url></file>!

Und die URL muss wieder (jaja, langsam nervt es) base64-dekodiert werden!

Das war das ganze Geheimnis!

In der Tat muss ich sagen, dass ich weder dem jDownloader Team schaden, noch Petzen helfen möchte. Ich glaube daran, dass alle Informationen frei zugänglich sein müssen. Tatsächlich aber, hätte ich eine Sicherheitslücke dem JDownloader-Team gemeldet, und gewartet bis diese den Bug behoben haben, sodass ich dann nacher (wenn die Gefahr vorbei ist) diesen Blogeintrag veröffentlichen kann. Aber das ganze Container System ist ein Bug. Ich hätte die Leute also auffordern müssen, DLC komplett zu vergessen, was sicherlich nicht realisierbar ist. Ich hoffe wirklich, dass sich keiner angegriffen fühlt. Ich liebe den JDownloader und benutze es auch intensiv (hab sogar mal einen kleinen Patch geschrieben und zu verfügung gestellt). Aber dass die Beschreibung sagt “Komplett Open-Source (GPL Lizenz)”, aber dies nicht zutrifft (die Container Source-Codes sind nicht offen) macht einen schon ein wenig stutzig. Das Blöde aber ist, dass die GPL wohl nicht wirklich verstanden wurde. Denn in der GPL geht es um Freiheit (was der jDownloader wohl nicht vollständig gewährt), außerdem heißt es dort auch: “Die Arbeitsweise eines Programms darf studiert und den eigenen Bedürfnissen angepasst werden.“. Wenn also JD wirklich komplett unter der GPL ist, dann darf ich das DLC Format also doch studieren

DLC ist genausowenig sicher, wie die ganzen, mit Werbung überladenen, link-crypt Seiten. Wenn ihr immernoch Sicherheit wollt, gebt die Links nur per PN raus. Ich weiß, dass ist eine menge Arbeit, aber anders geht es nicht! Ihr müsst euch damit abfinden, dass es keine ausreichende Sicherheit vor Petzen gibt. Akzeptiert es.

Das wars wieder mal von mir, ich hoffe der Artikel hat euch gefallen. Ihr könnt gerne Kommentare abgeben, mich dissen und zu tiefst beleidigen.

Und hier habt ihr meinen Decrypter Ruby-Script:

DOWNLOAD

Verwendet es solange ihr könnt, denn ich bin mir ziemlich sicher, dass der Server bald den Decrypter blockt und somit die ganzen Tuxload und PyLoad User aussperrt Wenn ich wieder Zeit und die passende Motivation finde, werde ich den Decrypter erneuern (evtl. mal die Methode vom jDownloader selbst verwenden).

Das JD-Team hat nun die RSD-Nutzer serverseitig gesperrt, der Decrypter ist also mit den jetzigen Keys nicht funktionstüchtig. Wenn ihr unbedingt einen funktionierenden Decrypter braucht, könnt ihr mich anschreiben. Falls ihr einen guten Grund liefert, bin ich bereit den neuen Decrypter mit euch zu teilen, unter der Bedingung, dass ihr es nicht weiterverteilt! Kontaktinformationen findet ihr in meinem Aboutme.

//update 17.01.2010:

Es ist nun etwas mehr als ein Jahr vergangen, und die Lage hat sich beruhigt. Mittlerweile haben mich schon mehrere Leute kontaktiert, die meinen Decrypter auf andere Sprachen portiert haben. Unter anderem dlc2txt von TheFox in Perl.

Falls du auch mein Script portiert hast, sende mir eine Email! Ich würde es mir gerne ansehen und (mit deiner Erlaubnis) hier verlinken.

Nebenbei erwähnt: ich habe nichts mit containerex, oder den anderen Decryptern zu tun. Ich liefere nur die Informationen. Ich weiß weder, ob diese Projekte auf meine Dokumentation aufbauen noch ob sie das hier überhaupt kennen.

Phrack #65 ist endlich raus!

Aus Tagen wurden Wochen, aus Wochen wurden Monate, und schließlich wurde ein Jahr daraus!
Nach nun dieser langen Zeit ist die nächste Phrack Ausgabe online.
Die neuen Artikel klingen auch nicht schlecht Die Introduction ruft nur so nach “Los! Lies mich! Lies mich!”

[...]
What about a PHRACK issue ?

PHRACK comes from the underground, the underground worked on it, submitting
papers, sending feedback, commenting, spending long night chatting,
reading, BREATHING. Does the underground still breath ?

Things change, panta rei. As hackers, we have fun. We want fun. Hacking is
fun. You know it because you did it, because you spent nights and nights on
this fucking fun, going to sleep at 6 a.m. and waking up three hours later
to present your face at school or work, with your brain still back home on
your encrypted work. Are you still having fun ?
[...]

Frohes lesen!

Neues Tutorial: API-Crypting

Ich hab heute ein neues Tutorial geschrieben (das Thema wollte ich ohne hin schonmal durcharbeiten). Es handelt sich um das Verschleiern von WinAPI Aufrufen, sodass viele Heuristische Scan-Methoden von Antivirus Programmen beim Suchen nach gewissen Mustern fehlschlagen.
Bin gerade fertig geworden, und bitte, gebt mir Kritik und Verbesserungsvorschläge, es ist sehr wahrscheinlich dass irgendein mehr oder weniger peinlicher Fehler im Tutorial ist

Das Tutorial wird im ersten EZine von Netplayazz auftauchen (Jaaa, Netplayazz ist wieder online )
Viel spaß beim lesen

API-Crypting Tutorial vom 03.03.2008

RSDF – Reverse Engineering

Es war wieder mal einer dieser langweiligen Tage. Ich hatte nichts zu tun so suchte ich mir ein paar Filme aus der Gulli:Börse.
Als wäre ich nicht schon genug genervt, sprangen mir hier und da nur CCF und RSDF Dateien vors Gesicht. Ich hatte es satt mir immer Threads auszusuchen wo die Links im Klartext da lagen (um dann mit etwas Glück zu hoffen, dass die Links nicht schon verpetzt sind).
Auf der Suche nach CCF oder RSDF für Linux stieß ich nur auf Hilfeschreie von armen Linux Nutzern. Ihnen musste jemand helfen!
Kurze Zeit später fand ich heraus, dass der hervorragende jDownloader das RSDF Format unterstützte. Also ging ich (schon wieder, nach meinem letzten Problem) zurück in den IRC Channel des jDownloader Teams (irc.freenode.org #jDownloader).
Nach einer kleinen Probe ob ich nichts böses mit dem RSDF Format hätte (Bin ich ne Petze? ) kamen auch nette Antworten von thomas_sch welches mich auf den Thread im Gulli Board aufmerksam machte. Genauer genommen, die Beiträge von Kugelfisch23.
Er fand durch Reverse Engineering den Key zum entschlüsseln für das RSDF Format, und zugleich die Verschlüsselungsmethode.
Ich war glücklich über die Scripte dort, doch dieser eine Drang in mir der schon seit Tagen nach Hardcore Assembler und Reverse Engineering schreit hielt mich nicht davon ab selbst zu reversen!
Ich suchte mir erstmal ein paar Downloader (wusste bis dato nicht mal von welchen Downloadern diese Formate unterstützt werden) und fand dann MSD und RSD. Ich nahm mir RSD vor (ich glaub, MSD hat nicht mal einen RSDF Support). Nach einer kleinen Spritztour durch den PE Explorer hatte ich eine von UPX befreite RSD.exe
Nach meinen Misslungenen Versuchen die rsdf.dll aus dem YouCryptJunior Ordner aufzurufen, schmiss ich doch Olly mal an.
Och, sah ganz interessant aus. Bisschen nach Strings umgeschaut (hätte gedacht es wäre DeDe nötig gewesen, aber so einfach wie das Programm aufgebaut war, ging es leicht) und ich fand etwas viel versprechendes “Erstelle rsdf …”. Na das klang doch super!
Schnell hingejump, bisschen gebreaked und umgeschaut.
Die ganzen CALLs habe ich studiert und dokumentiert/kommentiert. Am Ende wusste ich wohl mehr darüber bescheid wie RSD arbeitet als der Programmierer selbst (welcher Anscheinend die DCPcrypt Komponente für Delphi genutzt hat um SHA und AES einzusetzen, nebenbei noch Base64 wahrscheinlich mit einer anderen Komponente)
Ich kam soweit dass ich die Links entschlüsselt anblicken konnte (habs dann auch so gepatched dass es mir per MessageBox die Links einzeln anzeigen konnte), aber viel weiter kam ich (heute) noch nicht. Es sind nun ca. 8 Stunden vergangen. Ich kann ASM Code nicht mehr anblicken!

Morgen werde ich wohl das ganze Geheimnis um RSDF SELBER gelüftet haben (nachdem ich das verdammte Problem gelöst habe -.-)

Kommt mir bitte nicht mit “Du hilfst den Petzen” Comments, musste schon genug mit ansehen wie der arme Kugelfisch im Gulli:Thread fertig gemacht wurde, obwohl er für garnichts schuldig, und in allem was er sagte im Recht war.

//edit
So, ich gebe auf
Es wird von mir doch höhere AES Kenntnisse vorrausgesetzt. Da ich aber so gut wie 0 Ahnung davon habe, komm ich auch nicht weiter
Aber die Informationen die ich wollte, hab ich sowieso alles. War schon in der Endphase
Hier der Aufbau der RSDF Datei:
1.) Datei wird in 2-Byte Schritten von Hex zu Ascii umgewandelt
2.) Es ergibt sich ein base64 String. Dieser wird decoded.
3.) Es ergibt sich ein AES Ciphertext. Dieser wird decoded und man hat die Links
Der Key für AES müsste das folgende sein:
8C35192D964DC3182C6F84F3252239EBFFFFFFFFFFFFFFFF
kA wieso ich einen anderen Key als Kugelfisch habe :S Vermutlich hab ich genau da einen Fehler gemacht. Hab dann nach Stunden voller Schweiß mich doch dazu verleiten lassen in das fertige Python Script zu schauen.
Als ich die Zeile mit “IV” und den ganzen “FF”s sah, wurde mir klar dass ich keine Ahnung von AES hatte. Wie sollte ich dann herausfinden wie das ganze funktioniert? Ich weiß ja nicht mal was dieses IV ist
Naja, ich gebe dann halt auf, 4 Tage sind genug für ein Dateiformat

Eddy, der Phreaker?

Ja ich weiß, irgendwann werden die “Eddy, der …” Einträge langweilig, aber ich fühl mich halt bei allen Scenes so, dazwischen ^^
Naja, diesmal hab ich mich für Phreaking entschieden, und kam auf interessante Tutorials/Seiten die ich euch nicht vorenthalten möchte! Da wäre erstmal eine neue Phreaker Seite (mit Forum):
http://telekommunistz.de
http://www.phuck-board.tk/ (komisch, auf funpic gehostet aber noch nicht gekicked ^^)
Und ein paar “Neuzeit Phreaking”-Tutorials:
Deutsches Phreaking Handbuch von Kaleton (Xirror Mirror)
Phreaking im 21ten Jahrhundert von 7SAC7 (Xirror Mirror)