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.
If you enjoyed this article please consider staying updated via RSS. Links to your own social media pages could be added here.
This entry was posted on Saturday, November 15th, 2008 at 22:58 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.
November 16th, 2008 at 11:39
Toll Eddy, das meiste was du hier geschrieben hast ist bekannt und wir haben nie etwas anderes behauptet, effektiv hast du nur bewirkt das jetzt der rsd gesperrt ist, ein Loader der kaum noch weiter entwickelt wird, es wird also dauern bis der rsd wieder dlc kann. Du kannst dich gerne an der Entwicklung von dlc2 beteiligen wir haben auch schon einige Ideen wie man dlc2 sicherer machen kann, du weißt ja wie du uns erreichen kannst.
November 16th, 2008 at 16:52
Hallo DwD,
ja ich weiß, dass es euch bekannt war. Deswegen habe ich ja auch geschrieben, dass euch von Anfang an klar war, dass es unsicher ist und dass ihr das Format nur entwickelt habt um der Nachfrage eines neuen Formates gerecht zu werden
Es musste ja nicht unbedingt der RSD sein, nur das war halt das Programm, was ich auf dem Rechner hatte, um direkt mit dem reversen anfangen zu können. An dem jDownloader bin ich jetzt auch noch dran, nur denke ich, dass ich schon genug Leuten “geschadet” habe, sodass dieser wohl einige Zeit nur privat meinem Tuxload Beihilfe leisten wird
Aber zu dlc2 kann ich nichts weiter sagen, als dass ich nicht gerne an etwas arbeite, dass sowieso letztenendes keinen Sinn ergibt :O Aber ich werde es sicher mal dokumentieren wenn es rauskommt … der Spaß darin liegt ja, ein “Geheimnis” zu entlüften, und den hätte ich nicht, wenn ich mitentwickeln würde.
Ich hoffe, ihr seid mir nicht allzu böse wegen dem Ganzen :O
Naja, ich geh jetzt mein GRUB reparieren
November 16th, 2008 at 22:44
hey ich starte das script mit ruby dlc-decrypt.rb datei.dlc und das kommt dabei raus:
dlc-decrypt.rb:17:in `require’: no such file to load — ruby-aes (LoadError)
from dlc-decrypt.rb:17
kannste mir ma erklären wie das gehn soll? bitte via mail an unr3al011 AT gmail DOT com
November 16th, 2008 at 22:56
Hallo unbekannter!
Wie du am ende des Posts (und im Kommentar von DwD) lesen kannst, das Script funktioniert nicht mehr, da es serverseitig blockiert wird.
Aber wenn du trotzdem eine Antwort brauchst: du musst ruby-aes installieren, das findest du auf: http://rubyforge.org/projects/ruby-aes
November 16th, 2008 at 23:13
Ich habe ruby-aes “installiert” aber jetzt kommt:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/ruby-aes.rb:40:in `require’: no such file to load — ruby-aes/aes_alg (LoadError)
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/ruby-aes.rb:40
from /Users/XXX/Downloads/dlc-decrypt.rb:17:in `require’
from /Users/XXX/Downloads/dlc-decrypt.rb:17
Habe MacOS X 10.5.5 drauf, kannst du mir vielleicht helfen?
November 16th, 2008 at 23:26
Hallo,
bei mir unter Linux hatte alles funktioniert (auf einem anderen Rechner aber wieder nicht), unter Windows jedoch musste ich das Packet “ruby-aes-normal-1.0.gem” installieren, da die 1.1er version nicht funktionierte. Ich kenne mich leider mit MacOS nicht aus, und weiß auch garnicht wie es mit Ruby dort aussieht, aber der folgende Befehl sollte alles ordnungsgemäß installieren:
gem install ruby-aes-normal-1.0.gem
Da wir hier rubygems benutzen, musst du in das Ruby-Script noch eine Zeile hinzufügen, und zwar:
require ‘rubygems’
mach es am besten direkt über das erste require im Script.
Wie aber zich mal erwähnt, das Script funktioniert nicht mehr, also auch wenn du es zum laufen bringst, wirst du keine Links entschlüsseln können. Ihr müsst euch gedulden bis ich den rest auch noch dokumentiert habe, damit der decrypter wieder funktioniert
November 16th, 2008 at 23:44
Eddy
Ich bitte dich soviel Respekt vor unserer Arbeit zu zeigen es zu lassen. Es wird sowieos nur ein Katz-Mausspiel.
Im Endeffekt schadest du damit viel mehr Usern wie du hilfst. Gleichzeitig machst du mir das Leben schwer. Weil ich meine Zeit mit dem alten DLC anstatt dem neuen DLC2 verbringen muss. DLC2 kannst du gerne kommentieren wenn es released wird.
Es wird sowieso komplett quelloffen sein.
Versteh das bitte als Appell an deine Vernunft.
Grüße, Coalado
November 16th, 2008 at 23:56
Hallo coalado,
sorry dass ich dich damit gestresst habe, das hatte ich mit Sicherheit nicht vor. Aber wie gedenkst du die “Sicherheit” von DLC2 zu gewähren, wenn es opensource ist? Wird es etwa kein Crypter mehr, sondern nur eine Art “Packet” mit Links ?
Meine nächste Analyse über den jDownloader werde ich dann wohl aus Respekt nur unter ein paar Freunden verteilen und nicht “öffentlich” demonstrieren. Es reicht ja, wenn ich die Informationen aus diesem Blog-Post einfach weiter existieren lasse
Ich denke, das ganze hier hat für genug “Aufklärung” gesorgt.
November 17th, 2008 at 17:45
So, es lag an der 1.1′er Version, die 1.0′er funktioniert endlich!
Jetzt kommt aber ein anderer Error:
/Users/XXXXX/Downloads/dlc-decrypt.rb:30: undefined method `length’ for nil:NilClass (NoMethodError)
PS: Mir ist es schon klar, dass es nicht funktioniert, aber wenn ich etwas anfange, möchte ich es auch zu ende bringen!
)
@Admin: hast du ICQ? Möchte dich ein bisschen über DLC löchern (Wie du es geschafft hast
November 17th, 2008 at 20:31
hi,
erstmal glückwunsch das du es geschafft hast ^^ hab aber noch ein paar fragen zu dem dlc format
sind die konstanten keys (die du gepostet hast z.b. 15938425379F64DD) bei allen downloadern gleich? oder gibt es z.b. beim jdownloader andere methode zum entschlüsseln.. weil ich bekomme bei dem jd eine andere server response als beim msd…
mfg
ps.: der JD benutzt folgende URL:
http://service.jdownloader.org/dlcrypt/service.php?srcType=dlc&jd=11&destType=jdtc2&data=
November 17th, 2008 at 21:25
Jungs gebt es auf….
Hat sich ja gezeigt wie lange sein “geknacktes” dlc funktioniert hat. Wenn ihr es veröffentlich wird es sofort gesperrt. Falls nicht, spätestens beim nächsten Update des loaders.
Jede Dlc hat einen anderen key. Jeder loader auch. Und die Loaderkeys werden relativ fix ausgetauscht.
Eddy war ganz sicher nicht der erste wegen dem der ein oder andere Loaderkey getauscht werden musste.
Coa
November 17th, 2008 at 21:38
@ein anderer:
(hab vergessen einen parameter-check einzubauen)
Meine Kontakt-Daten stehen in meinem “About me” auf diesem Blog.
//edit:
Sorry deine Frage hab ich vergessen zu beantworten
Liegt wohl daran, dass du die Datei ohne Parameter aufgerufen hast:
dlc-decrypt.rb die-dlc-datei.dlc
so müsste es funktionieren
@coalado:
ich glaub die Leute sind nicht so “doof” wie ich, und machen es public, die werden sicher non-pub bleiben :-O
@2 posts über mir:
Nee die sind nicht bei jedem Downloader gleich, jedes Programm bekommt eine andere Funktionsweise zugeschrieben (obwohl die bei MSD und RSD gleich zu sein scheinen, evtl auch bei jedem anderen Programm [außer jd selbst] das DLC verwendet). Bei MSD scheinen nur die Keys anders zu sein
November 17th, 2008 at 23:46
Jetzt geb ich auch mal meinen Senf dazu, ich schau mir gerade den Java-Code an und kann wirklich nur sagen das die zuständige Klasse in 2 Versionen einige Unterschiede aufweißt und die Keys kann man auch nicht so leicht auslesen, wird vermutlich immer eine andere Variante genutzt um an den Key zu kommen…
Naja ich halte hiermit auch meinen Mund und bin auch schon auf DLC2 gespannt wie das mit OpenSource funktionieren soll
@coalado: Eddy war wenigstens so fair, auch anderen ein wenig mehr Infos zu diesem Format zugeben. Das man schnell User aussperren kann hat man ja gesehn, aber nach dem 5ten Key wechsel denke ich habt ihr auch iwann keine Lust mehr und soviele Variationen zum bekommen des Keys werdet ihr ja wohl kaum haben…
November 18th, 2008 at 20:11
meinen respekt das du so etwas schaffst… finde es aber trotzdem nicht gut das du es öffentlich gemacht hast…
mfg cookie
November 20th, 2008 at 19:12
Die ganzen Kontainer sind immer Bullshit. Irgendwann muss auf dem Clientrechner der Rapidshare-Link ankommen. Wo/Wie er entschlüsselt wird ist doch völlig egal. Man kann auch einfach die jdownloader-Routine aufrufen. Ich versteh nicht warum man da auch noch eine Version 2 von entwickeln will.
Mal abgesehen davon, daß verschlüsselte Kontainer an sich dämlich sind. Was soll das überhaupt bringen?
November 20th, 2008 at 19:14
PS: @Eddy danke! Erweiter mal das Skript so, daß es einfach im den aktuellen Jdownloaderkey verwendet …
November 20th, 2008 at 21:47
@coalado:
Ich verstehe nicht, warum ihr euch so aufregt. Erstens scheint ihr nicht verstanden zu haben, was GPL eigentlich bedeutet und zweitens frage ich mich, wie der Doc, was den die Verschlüsselung der Container soll. An die Links, die im Container stecken, komme ich immer auf irgendeine Art und Weise. RDS zu sperren, finde ich absolut lächerlich, denn jdownloader macht selbst etwas vergleichbares (captchas).
November 23rd, 2008 at 21:15
@DrSnuggles:
Mit dem was du nicht verstehst könnte man wohl mehrere Bücher füllen.
@ibinsfei:
Ich finde nicht dass ich mich aufrege.
GPL:
Mag die falsche LIzenz sein. Wegen eines kleinen closedsource Schippsels. LIzenz werden wir bald entsprechend ändern.
Unser Grundgedanke war nie penibel genau Lizenzbestimmungen zu erfüllen. Wir haben uns darauf konzentriert es möglichst vielen leuten zu ermöglichen beizutragen, und eventl. andere zu inspirieren.
RSD:
War aus Sicherheitsgründen leider nötig. Wird mit dem nächsten RSD Update wieder gehen. Würde hier der DJ Key stehen. würden wir auch JD bis zum Update sperren. Ihr schadet mit solchen Aktionen, euch selbst, den Downloadern am meisten.
DLC2:
Wird open source sein, und als Grundprinzip nicht das verstecken von Links haben. Es wird sichergestellt, dass jemand nict emhr Links decrypted als er tatsächlich laden kann.
Überhaupt:
Versucht mal daran zu denken, dass es nicht nur euch gibt, sondern auch andere Leute, mit anderen Interessen. Und als Uploader hat man normalerweise großes Interesse daran, dass die Links möglichst lange zur Verfügung stehen.
November 27th, 2008 at 00:37
@coalado
>Es wird sichergestellt, dass jemand nict Mehr Links decrypted als er tatsächlich laden kann.
Das ist trivial. Der erste Link im Container ist unverschlüsselt.
Der n-te Link ist AES-verschlüsselt mit der md5sum der (n-1)ten Datei.
Schon kann man nurnoch soviele Links entschlüsseln wie man auch downloaden kann.
Aber bitte was soll das bringen?
November 28th, 2008 at 02:10
cryptload wurde in der ersten version auch von einem 13jährigen geknackt super arbeit eddy du kommst noch sehr weit die ganzen container sind für müll müllcontainer da kommt sicher bald was besseres stand neulich am gulliport
November 30th, 2008 at 01:17
mhmm ich verstehe den sinn von dlc nicht?
man bekommt ein javaprogramm, einen schlüssel quasi in die hand gedrückt und die zu entschlüsselnde datei.
ist das jetzt nicht ein bisschen blauäugig?
versteht mich bitte nicht falsch – aber bis vor 15minuten wusste ich nicht mal was dlc dateien sind.
seit 10minuten grübel ich jetzt über den versteckten witz des formates nach – und komm einfach nicht dahinter.
gibt schon lustige leute
December 1st, 2008 at 13:57
Netter Artikel. Fehlt noch ein Artikel über CCF 0.7 – 2.0 um dann das Thema abzuschliessen für alle Zeiten und die alten Erinnerungen in Ewigkeit zu bewahren.
December 2nd, 2008 at 15:49
Ich wäre froh, ihr würdet diesen Containerdreck endlich einstampfen. Als USD User ist man doch aktuell nur der Depp. Selbst CCF oder RSDF “dekodiere” ich erst einmal um die Verfügbarkeit zu überprüfen. Nicht ist nerviger als “verschlüsselte” Links im Downloader zu haben, wo dann auf einmal ein paar Parts nicht mehr verfügbar sind.
Der DRM Vergleich des Blogers hier war mehr als treffend. Ich hoffe ihr Affen geht den Bach runter. Ihr kämpft aktuell mit den Mitteln, die ihr einst verflucht habt. Da fehlen einem echt die Worte …
December 2nd, 2008 at 17:16
@DrSnuggels und @coalado:
Wenn das so funktionieren sollte wie von Snuggles beschrieben, ist es doch eigentlich unmöglich vorher zu prüfen, ob überhaupt noch alle Links online sind. Dann lädt man die ersten 20 Parts und dann fehlen ein oder zwei und schon ist der Spaß flöten.
Natürlich könnte man dann wieder eine Serverkomponente einsetzen, die eben genau dies wieder prüft, aber das würde dann auch wieder am Prinzip von der GPL vorbeisetzen oder nicht?
Ich bitte um Aufklärung.
December 3rd, 2008 at 00:01
Respekt für dafür das Schema offen zu legen, war bestimmt einiges Arbeit
@issen
Ideologisch gesehn erscheint es vielleicht entgegen der GPL, aber technisch gesehn ist der Server eine komplett andere Software. Du darfst mit Firefox ja auch auf microsoft.com surfen ohne das Microsoft ihren Server unter der Lizenz vom Firefox veröffentlichen müssen.
@coalado
Wo findet denn der Entwurf von dlc2 statt? Kann man das irgendwo öffentlich einsehen? Sollte ja kein Problem sein wenn es nicht mehr auf obscurity setzt.
—-
Ich finde das mit den Containern auch unsinn, weil spätestens beim Download die links sowieso im Klartext über die Leitung gehen egal wie sehr ihr euch da noch bemüht.
Mit OpenSource und Java gibs sogar bequemere Möglichkeiten als den sniffer:
* Einfach euren Code/Routinen verwenden, is wurscht ob die obfuscated sind oder ned, aufrufen kann man se trozdem aus eigenem Java code. Euer Server wird das dann als JDownloader erkennen, für den reconnect wegen der IP-Sperren eurerseits liefert ihr ja auch die entsprechende funktionalität mit
* ein “System.out.println(this.toString());” in die Konstruktoren von “java.net.URL” einfügen[1], schon landen alle urls die JDownloader öffnet auf der Kommandozeile.(Das man das auch in eine *.txt loggen kann sollte jedem klar sein)
[1] entweder die rt.jar patchen oder zur laufzeit per instrumentierung einfügen
BTW: Was will JD eigentlich bei http://null.sun.com
und wieso wird ständig http://twitter.com/statuses/user_timeline/jdownloader.xml?count=1&since=Mon%2C%2001%20Dec%202008%2021:48:36%20GMT aufgerufen?
December 6th, 2008 at 18:35
CCF 2.0 gab es nie. Die ersten 3 CCF-Versionen wurden meist direkt nach der CL-Version benannt, mit der sie eingeführt wurden (CCF 0.7, CCF 0.8, CCF 1.0) – diese verwendeten Rijndael-256-CBC mit fixen Keys. Danach kam – mit CL 1.1.3 – CCF 3.0 (das Format heisst so, weil `CCF3.0` als magische Bytefolge diente, um solche Dateien zu identifizieren). Hier wurde ein eigener Cipher verwendet, der jedoch fundamentale Schwächen aufwies. Wohl als Reaktion auf Lukas’ Artikel kam dann – mit CL 1.1.5 – ein neues Containerformat, das ich CCF 5.0 nenne (analog CCF 3.0).
December 16th, 2008 at 02:11
>Das ist trivial. Der erste Link im Container ist unverschlüsselt.
>Der n-te Link ist AES-verschlüsselt mit der md5sum der (n-1)ten Datei.
>Schon kann man nurnoch soviele Links entschlüsseln wie man auch downloaden kann.
>Aber bitte was soll das bringen?
Also ich finde diese Idee der rekursiven Verschlüsselung verdammt genial!
Und was das bringen soll? Das nicht einfach jemand auf einen Schlag eine Website abgrasen, Dateien im “Wert” von 1,5 Terabyte “anzuladen” und diese dann auf einen Schlag abusen kann. So muss er zumindest auch genau das herunterladen was er “bestellt” hat.
Mehr geht auch nicht, wenn man möchte das überhaupt noch jemand die Dateien laden kann (außer weitere künstliche Zugangsbeschränkungen / Downloadlimits von Seiten des jDownloader-Servers – man hat ja bereits mit “Download-Tickets” experimentiert, sodass man nicht mehr als ein paar Container pro Stunde pro IP laden konnte).
Ich bin auf jeden Fall gespannt was am Ende dabei heraus kommt!
December 18th, 2008 at 13:42
Über Sinn und Unsinn der Container kann man streitet.Ich persönlich finde aber die Intention des Autoren dieses Beitrages eher fragwürdig. Fassen wir mal zusammen: Es war den Machern von DLC bekannt, dass das Containerformat unsicher ist. Ein Nachweis war eher unnötige, jeder der sich damit beschäftigt hat wußte es. Wer zieht effektiv Nutzen aus dieser “Dokumentation”? Es mag an meiner mangelnder Vorstellungskraft liegen, aber ich kann mir kein Szenario vorstellen wo die Entschlüsslung von Links zu etwas positivem eingesetz werden kann. Die Verlierer von dieser “Dokumentation” liegen ja klar auf der Hand…
Also warum entschließt man sich etwas zu erschaffen und dann zu veröffentlichen das nachweislich mehr Menschen schadet als nutzt und gleichzeitig keinen nennenswerten Aufklärungscharakter besitz? Ein Schelm, wer Böses denkt…
January 5th, 2009 at 00:27
@Hans Gruber
Na na na! Mehr Menschen schadet als nützt? Das sehe ich nicht so. Schließlich sprechen wir hier von etwas, was eher zu der Grauzone gehört. Wenn es für viele ach so einfach und trivial sein soll, für mich nicht. Für mich war das sehr interessant zu lesen!
Abgesehen davon finde ich es gut, wenn die Entwickler dazu angetrieben werden, die Programme zu verbessern
January 11th, 2009 at 12:45
Hi,
ich frag mich auch was das ganze mit den verschlüsselten Links in einem Container soll, wenn ich doch später bei RS und Co. dem Link im Klartext schicken muß. Da wird so viel Hirnschmalz im die Entwicklung eines Verschlüsselungssystem und die nachträgliche Sicherung der Links gesteckt (kein Sniffer etc), und drei Meter weiter wird er unverschlüsselt durch die große weite Welt geschickt (der nächste Router oder Proxy erhält ihn sowieso). Das ist genauso, als ob ich meine Geheimnummer auf meine EC Karte schreibe. Wenn ich den Hintergrund von dem System richtig verstanden habe, dient es nicht dazu, nicht den Link sicher zu machen (der ist doch austauschbar), sondern, das die Daten bei den Hosten so lange wie möglich online bleiben. Oder nicht?
Wenn ich einer großen Masse Daten zur Verfügung stellen will, verschlüssel ich sie doch nicht, sondern lege eine Sicherheitskopie an. Falls irgend ein DAU sie versehendlich löscht. Warum macht man das hier nicht auch?
Es könnte z.B. so laufen:
Man schreibt in den Container einfach eine URL bzw. eine ID, wo ich die Hoster URL bekomme. Der Server, der die Hoster URL heraus gibt hat zu jeder Datei eine, ich nenne sie mal “Master URL” und zwei “Downloade URL´s” (wie eine Spiegelsatz von der Masterdatei). Der Server gibt (normaler weise) immer die erste “Download URL” heraus. Wenn der Client an den Server zurück gibt, das der Link Off ist, bekommt der Client die zweite “Download URL” und der Server weiß, das er dafür sorgen muss, eine neue zweite “Download URL” zu erzeugen. So braucht der Server nicht immer zu schauen, ob die Dateien noch ON sind, diese Aufgabe übernehmen die Clients und er kann wichtigere Aufgaben übernehmen. Die Leute können dann auch petzen, wenn sie wollen. Es wird ja eh nur der Spiegel gelöscht, nicht der Master.
Was haltet Ihr von dieser Methode?
January 15th, 2009 at 17:59
danke für die verlinkung von pyLoad!
werde versuchen dein skript einzubauen
February 1st, 2009 at 00:26
habe keine Ahnung vom Coden/Reversen…
aber ich dachte immer man kann Java Programme decomplierem, da dlc doch auch java basiert ist der quellcode doch offen oder?
Zwar nicht mit absicht der Entwickler aber man aht Einsicht in den Code.
February 1st, 2009 at 00:33
EDIT:
achja zu den jd-devs, ihr heult rum weil eddy mit seiner dlc Dokumentation euch schadet?
Überlegt mal wem ihr mit DLC schadet und wem ihr helft.
Helfen tut ihr irgendwelchen faulen Leechern.
Schaden tut ihr den Hoster die auf Werbeeinnahmen und Premiumkunden angewiesen sind.
February 8th, 2009 at 15:58
Dazu: http://www.boerse.bz/talk/szene-talk/139123-dlc-geknackt-2.html#post1201989
February 21st, 2009 at 17:58
noch nen kleiner “Hinweis” schaut euch mal die hsqldb Datenbank von jD genauer an, in der die Konfiguration gespeichert wird. Der Key ist “GUI” der Wert is nen Hashtable, in der Hashtable gibts nen Feld namens “package”… Den rest kann man ganz einfach per decompiling der jd.plugins.a.D Class rauskriegen.
Mir wird nämlich gerad langweilig und hätt gern mal wieder was neues zu reversen
Tipp an jd-team: schaut euch mal proguard oder yguard an, das war ja viel zu einfach *rofl*
February 22nd, 2009 at 13:10
@ 27. Manzelmann:
> Also ich finde diese Idee der rekursiven Verschlüsselung verdammt genial!
Auf welcher Seite stehst Du? Fehlt die erste Datei oder ist sie beschädigt/gehackt, können die Links der folgenden nicht mehr ermittelt werden. Ein Rechteinhaber muss nur noch eine Datei, die erste, sperren lassen und nichts geht mehr.
@ 19. DrSnuggles
> Der erste Link im Container ist unverschlüsselt.
> Aber bitte was soll das bringen?
Rechteinhaber können Dateien bei RS sperren lassen. Der Uploader hat die Möglichkeit, die Sperrung aufheben zu lassen, sofern er bestätigt, dass keine fremden Rechte verletzt wurden. Das macht man sinnvollerweise nur, wenn man auch alle Rechte besitzt, sonst hat man eine Klage am Hals.
=> Dieses Verfahren bringt also dem Rechteinhaber den Vorteil, dass er nur noch einen Link sperren lassen muss, da ohne diesen niemand an die anderen kommt. Und da er unverschlüsselt ist, muss er dafür nicht einmal etwas laden.
Besitzt man die Rechte an der ersten Datei (das ist dann der Fall, wenn man Inhalt und Datei selbst erstellt hat oder Freeware-Dateien benutzt), geht das nicht mehr. Dann muss der Rechteinhaber erstmal diese Datei laden, um an den Link zu kommen, für den er die Rechte besitzt, macht ihm also Arbeit. Die zweite Datei kann er dann sperren lassen und niemand kommt mehr an die restlichen. Aber auch alle anderen müssen diese Datei zuerst laden und bei entsprechender Größe für die eigentliche Datei anschließend warten (als Free-User).
=> Dieses Verfahren bringt dem Rechteinhaber also etwas Arbeit, allen anderen Datenmüll, Wartezeit und ändert nichts am Prinzip, dass mit der Sperrung der zweiten Datei das weitere Laden unmöglich wird. Und eines noch: Die Server verbrauchen noch mehr Strom.
Ich weiß, dass das eine rhetorische Frage war. Jetzt ist sie halt trotzdem beantwortet.
Sicherheit gibt es nur mit geheimen, nicht digital übertragenen Schlüsseln (man denke nur an die rar-Dateien von Suchmaschinen, die man, ohne PW und Blog zu kennen, lädt).
Wer über Blogs veröffentlichen will, muss akzeptieren, dass die Links aufgespürt und gesperrt werden. Das ist wie mit Geheimagenten.
Je mehr Arbeit die Rechteinhaber damit haben, desto weniger wird gesperrt.
So einfach ist die Sache. Das JDownloader-Team leistet dabei Phänomenales.
Wer meint, eddy14 hätte den Rechteinhabern Neues erzählt, ist naiv. Die Firmen, die von ihnen beauftragt werden, wussten das bereits vor dem Post. Jetzt können aber vielleicht mehr nachdenken, welche Möglichkeiten es noch gibt. Und dafür braucht man kluge Köpfe, auch solche, die nicht in Java und Linux fit sind. Vielleicht kommt ja jemand auf eine völlig neue Idee, nachdem er die Probleme hier gehört hat.
March 26th, 2009 at 18:47
Ich habe den JD schonmal vor einem Jahr oder so angesehen. Ich habe es damals innerhalb von 4 Stunden geschafft, dem Ding seine Links zu entlocken (wurden bei jedem Öffnen einer DLC-Datei in eine Textdatei exportiert). Damals schien es so, als würde das Programm beim DLC-Decrypt einige Files aus dem JDownloader-Ordner hashen und den Hash zur Verschlüsselung benutzen – die Interna der Verschlüsselung waren mir damals wumpe – ich wollte nur endlich wieder Dateien von meinem Linux-Server aus herunterladen können. Ich habe die Sicherheitsklassen dekompiliert und das Resultat wieder kompilierbar gemacht, anschließend habe ich nur eine Funktion geändert, so dass JD nicht mehr für sein eigenes Verzeichnis Checksummen angelegt hat, sondern für ein externes, wählbares Verzeichnis. In dieses Verzeichnis habe ich eine normale, ungepatchte JD-Version gelegt, die ich immer mit Updates versorgt habe. Somit konnte JD richtige Hashes erzeugen, aber trotzdem verändert sein und die dummen Links ausspucken, ohne mich zu nerven.
Das ganze System von Link Protection ist wirklich mal broken by design. Wenn ich als durchschnittlicher Informatikstudent, damals noch im Grundstudium, so etwas in 4h schaffe, wie sieht es dann mit darauf spezialisierten Unternehmen aus? Klar stört es sie, aber es ist kein großer Arbeitsaufwand. Hat man es einmal geknackt, hat man es immer geknackt. Wenn man sich nun ausrechnet, wie viele User einer Seite mit nicht ganz legalen Inhalten verloren gehen, wenn diese merken, dass sie auf anderen Seiten keine buggy Downloadmanager benutzen müssen, sondern einfach so runterladen können, wie sie es für richtig halten, sollte man vielleicht überlegen, auf diesen Quatsch – einschließlich der lästigen RAR-Passwörter (“Ich will, dass andere Leute meinen Namen eintippen, weil ich so toll bin”) zu verzichten. Diese dummen Linkprotectionsachen sind tatsächlich ein deutsches Phänomen. Vielleicht ist man hier ein wenig paranoider, vielleicht liegt es auch daran, dass man sich hier gern gegenseitig sabotiert (“Abuse-Crews”), um mit der eigenen Seite mehr Kohle zu machen. Auf amerikanischen Seiten (Zerosec, rlslog,plube,…) wird so ein Blödsinn nicht betrieben und ich habe es selten erlebt, dass überhaupt Links gelöscht wurden. Fest steht, dass es unheimlich nervt. Und zwar die Benutzer mehr als die Rechteinhaber. Wenn ein großer Film kommt, für den entsprechende Energien aufgewendet werden, um Raubkopien einzudämmen, dann werden auch “geschützte” Links gelöscht.
Schon ohne Reverse engineering des JD, sondern nur mit einem installierten Webserver und verbogenem Rapidshare-DNS-Eintrag auf diesen Webserver (oder alternativ ein bestimmter Paketsniffer) kann ich ein DLC innerhalb von wenigen Sekunden entschlüsseln – was soll also der Quatsch? Ich habe es nie verstanden. Ich bin ein Freund davon, Dinge einfach funktionieren zu lassen. Und wenn Files gelöscht werden, so werden sie gelöscht – so ist das eben. Damit müssen die Benutzer leben, mit und ohne DLC. Ich würde lieber ein paar mehr gelöschte Files sehen (denn die gehören halt dazu), als noch einmal JD oder ähnliche schlimme Programme benutzen zu müssen. Und Passwörter. Die bringen nun mal gar nichts. Trotzdem sind in Deutschland 90% aller Files damit “geschützt”. Dafür hat man dann bei großen Downloadmengen Probleme, diese wieder zu finden. Oft funktionieren sie nicht. Viele User sind verwirrt. Auch dies gibt es auf amerikanischen Seiten seltener.
April 3rd, 2009 at 18:38
mein gott ich habe noch nie so viele klugscheißer auf einmal schreiben sehen. der jd funktioniert einfach und ich möchte ihn nicht mehr missen. ob die container jemand auslesen kann oder nicht geht mir am voll arsch vorbei. warum setzt sich denn mal keiner von den ganzen klugscheißern,eddy14 mal ausgeschlossen, die hier groß rum tönen hin und schreibt ein ebenbürtiges programm und noch eine gute verschlüsselung für die contauner files??? die leute machen das in ihrer freizeit und das sollte man mal honorieren. ist ja wie im kindergarten… ich habs gestern geknackt… na und ich habs aber vorgestern geknackt … und ich erst jaaaa ioh habs schon geknackt da gabs das programm noch gar nicht.. junge junge anstatt dumm rum zu labern mal taten sprechen lassen und selbst was auf die beine stellen. ich gebe meinen senf sonst eigentlich nicht zu dingen von denen ich keine ahnung habe aber das mußte ich mal loswerden sonst wäre ich geplatzt…
April 10th, 2009 at 12:12
dlc2txt 1.0.0…
Es gibt kein Problem, das man nicht mit Perl loesen koennte. dlc2txt ist ein Perl Script, mit dem man Dateien, die die Endung .dlc haben, entschluesseln kann.
DLC ist ein Containerformat, das von JDownloader verwendet wird. JDownloader ist ein Java-Pr…
June 26th, 2009 at 13:33
Naja, soo schlecht ist die Idee mit der Rekursiven Verschlüsselung nun doch nicht ganz. hawk hat zwar Recht mit “ein Rechteinhaber muss nur noch eine Datei, die erste, sperren lassen und nichts geht mehr”, allerdings muss auf der anderen Seite auch nur eine Datei wieder hochgeladen werden, damit es wieder läuft. Die “unerlaubte Weitergabe von DLC-Containern” (höhöhö) wäre damit auch eingegrenzt. Aber damit man nicht so viel wieder hochladen muss, wär es eigentlich effektiver, die letzte Datei als Erste laden zu lassen (die ist normalerweise die kleinste).
Ansonsten muss ich aber Unbehagen zustimmen. Der ganze Passwort- und Crypting-Scheiß ist echt zum Kotzen. Ich hab neulich mal ein Album hochgeladen (extra nur gezippt – also kein proprietäres Format – ohne Passwort und auf schön vielen Mirrors) und dann kommt da irgendjemand von hardcoremetal.biz, verpasst dem ganzen ein beschissenes Passwort und packt das auch in nen DLC (Download nur über RS wohlgemerkt)! *schnüff*
July 10th, 2009 at 11:25
[...] und fand eine alte version des SFT-Loaders (”SFT Loader 2006″). Nach meinem letzten Beitrag über DLC dachte ich mir, es wäre doch praktisch meine Kenntnisse im Gebiet der Analyse von unbekannten [...]
January 10th, 2010 at 19:13
No security by obscurity!!
March 1st, 2010 at 15:44
Was heult ihr alle rum?
Bei mir geht der jdownloader-scheiss wunderbar… mich bockts solang net bis es nemmer geht.
un wenn dann halt einer meint, er muss wochenlang in seinem keller den scheiss aufzudecken, um sich selbst was zu beweisen und seinem internetschwanz paar cm an länge zu geben, soll ers halt machen
bis dann,
April 4th, 2010 at 09:32
[...] Put … Das end es Javaprogramm are online. Edit Spiel Team index against income. Browserspiels …Blog of eddy14 Blog Archive DLC geknackt!Blog of eddy14 … Name (required) Mail (will not be published) (required) Website. Comment © [...]
September 15th, 2010 at 17:14
Nice work
Funktioniert der Mechanismus immer noch? Konnte ruby-aes auf meinem System nicht aufsetzen und das von dir verlinkte Perl-Script liefert keine Links zurück.
Bin daher gerade am Überlegen, was kleines in C zu schreiben ^^
September 15th, 2010 at 21:17
Hey lynix,
soweit ich weiß funktioniert es noch tadellos (kanns hier gerade nicht testen).
Siehe im Beitrag oben:
“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.”
Schreib mir eine mail, und du kriegst den decrypter.
February 25th, 2011 at 23:28
[...] 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 [...]