• Skip Navigation

Blog von eddy14

Search for:

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

Bookz

Ja, Bookz, keine eBookz. Es ist schon Jahre her, seit ich mir mal ein Buch gekauft habe. Also vor ein paar Wochen einfach mal beschlossen, 2 Bücher zu bestellen:

Seitdem bin ich Tage und Nächte lang am Lesen. Die Kunst des Einbruchs von Kevin Mitnick ist nett zu lesen, jetzt nicht der Brüller (Die Kunst der Täuschung ist besser) aber trotzdem coole Geschichten, und man lernt auch so das eine oder andere (und man bekommt super viel Lust auf hacking! ).

In Illuminati von Dan Brown bin ich noch nicht weit, aber das Buch rockt! Jedenfalls der Anfang.

Demnächst bestelle ich mir Die Kunst der Täuschung, Vegane Ernährung von Gill Langley, Hacking: The Art of Exploitation von Jon Erickson und zuletzt Schiffbruch mit Tiger von Yann Martel.

*bücherwurmwird*

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

Liebe Tiere,

heute ist ein besonderer Tag für euch. Wir Muselmänner, die mit der einzig wahren Religion, zeigen euch unsere Zuneigung und Liebe. Heute ist wahrlich ein besonderer Tag. Es ist ein Feiertag. Was wir feiern? Nun, das wirst du, liebes Tier, früh genug erfahren.
Früh stehen wir Muselmenschen auf. Freuen uns auf das Treffen mit der Verwandtschaft. Küssen uns respektvoll und kriegen Geschenke und Geld. Überall sind glückliche Menschen, sie gratulieren sich Gegenseitig, auch wenn sie sich garnicht kennen. Es hat den Anschein, als wäre Friede auf Erden.
Bekannte laden dich ein, man erfreut sich dort an dem kostbaren Essen und freut sich über die immer wiederkehrenden Diskussionen. Man trifft Menschen die man seit dem letzten Feiertag nicht gesehen hat. Es gibt immer ziemlich viel zu erzählen. Die Leute sind alle schick angezogen. Es gibt Süßigkeiten für jedes Kind. Wahrlich, ein besonderer Tag.

Nun, liebes Tier, wie du vielleicht wahrgenommen hast, es war die Rede von Menschen. Du als Tier, erlebst diesen Tag vermutlich gänzlich anders. Du wirst geschlachtet. Zuerst wirst du von deiner Mutter getrennt (wenn das am letzten Feiertag nicht schon geschehen ist). Jetzt wirst du gejagt, danach an den Füßen gefesselt, und während du zappelst und um Gnade schreist, ruft ein Mann über dir den Namen Gottes (damit dein Fleisch auch wirklich religiös rein ist) und schneidet deine Kehle auf. Danach wird dein Blut abgespült (ja, wir Musel dürfen Blut nicht genießen) und du wirst ausgenommen. Danach essen wir dein Kadaver. Ja ich weiß, das klingt wirklich sehr erfreulich. Denn laut den Gelehrten in Moscheen ist es eine Ehre für dich, als Essen für mich zu enden. Ja, der liebe Gott liebt anscheinend nicht nur die Menschen, sogar die Tiere werden mit Stolz und Ehre belohnt.
Das Opferfest ist wirklich ein schöner Feiertag. Wir feiern die Taten Abrahams. Ich frage mich, ob ihr Tiere diesen Mann genauso liebt, wie wir Menschen.

Ja, liebes Tier, ich hoffe es erfreut dich genauso wie mich. Wenn du Angst hast, kann ich dich beruhigen: Viele Menschen und Pseudo-Wissenschaftler sind der Meinung, dass Tiere keine Schmerzen empfinden.

Hm…

Da fragt man sich doch wirklich wieso man die ganze Zeit versucht, den Veganismus mit der Religion zu erklären, wenn solch ein Tag einem alle Hoffnung nimmt.

Solange Menschen denken, dass Tiere nicht fühlen, müssen Tiere fühlen, dass Menschen nicht denken.

R.I.P.

DLC geknackt!

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 und einen Decrypter in PHP von Christian Lange.

Falls du auch einen Dekoder (basierend auf diesen Blogeintrag) geschrieben 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.

Vegan-Crypter (*.exe Crypter) Release

Nicht lange ist es her, dass ich wieder mit Delphi gearbeitet habe … ich hatte eine PE-Library erstellt um auf die interne Struktur einer PE-Datei (Portable Executable => exen, dlls etc.) zuzugreiffen.

Zum testen der Funktionstüchtigkeit der Library hab ich ein paar kleine Programme erstellt. Unter anderem einen Delphi-Port meines “One-Eye PE-Crypter“s, der nun “Vegan-Crypter” heißt und einen Export-Viewer, womit man die Exports einer EXE (oder eher DLL) Datei einsehen kann. Außerdem hab ich ein Tutorial darüber geschrieben, wie man (theoretisch) einen Crypter dieser Art programmieren könnte.

Vegan-Crypter:

Export-Viewer:

Es ist nicht viel, und noch lange nicht aus der Alpha raus, aber man kann es schon verwenden um mal ein Preview auf die kommenden Features zu haben. Also, was bietet meine Pe-Bibliothek?

Ihr könnt auf Eigenschaften der Datei zugreiffen (die Signaturen, Adressen, Sections usw.) und diese verändern. Ganz nach dem Delphi Prinzip braucht ihr nur “PeFormat.LoadFromFile(datei,exe)” aufrufen, und die Library ladet alles für euch. Einfach ein paar Änderungen an der Datei machen und wieder per SaveToFile abspeichern. So einfach ist das

Für mehr Infos, schaut einfach in den Export-Viewer (dieser ist einfach und zeigt die Grundfunktionalität der Library).

Dann gibt es noch etwas erwähnenswertes: Beide Programme sind OpenSource. Der Crypter und der Viewer sind unter der GPL wobei die Pe-Unit Public-Domain ist.

Also, dann mal viel Spaß mit diesem Release, und wartet erstmal das Endprodukt ab (samt die Dokumentation über die Library, mit vielen Beispielen) …

Download:

Vegan-Crypter
Eddys PE-File Export-Viewer

Have fun