D.L.C. - Download Link Container

[Obi-Wahn]

Hi!

Jdownloader hat damit angefangen, RSD unterstützt es AFAIK auch, und andere werden bei der derzeitigen Abuse-Welle auch folgen.
Ja, die Rede ist von DLC. Dieses Crypt-Container Format wurde von den Machern vom JDownloader entwickelt, und soll was die Sicherheit angeht, RSDF und CCF sang- und klanglos in den schatten stellen.

Ein Grund für mich, mich mal etwas mit dem Container zu beschäftigen.

Im Web hab ich mal etwas gegooglet, und mal ein Paar infos zusammengetragen.

DLC ist nicht bloss RSDF mit einem anderen Key. Der File-Key eines DLC-Containers kann nur über einen
Webservice (unter Zuhilfenahme des Loader-Keys, mit dem der Webservice den Output verschlüsselt)
entschlüsselt werden - und genau da bietet sich die Möglichkeit an, kompromittierte Loader-Keys
auszuschliessen. Somit bringt es nicht mehr wirklich etwas, einen Loader-Key aus RSD/jD/MSD/...
zu holen, da dieser, sobald etwas veröffentlicht würde, schnell gesperrt wäre. Solange der
Processing-Key, mit dem der File-Key eines jeden DLC-Containers verschlüsselt ist, und der nur auf
dem Server liegt, der den Webservice zur Verfügung stellt, nicht geleakt wird (und das ist - von
Sicherheitslöchern auf dem Webservice-Server einmal abgesehen - unmöglich), wird kein öffentlicher
DLC-Decrypter länger als ein paar Stunden überleben.

While not being a big friend of containers, and therefore not wanting to promote DLC,
I still have to tell you this is not as simple as it sounds. You are right, in theory,
`they` could log data, but everything the server gets to know is, after my own analysis,
the encrypted DLC-file-key. As this is nothing but a randomly generated 128-bit-value,
which is not even guaranteed to be unique, this `information` is not valuable.
Even if `they` would log all data `they` get, including your IP-Address, the time of
access, the file-key, and the destination format (which reveals the loader you’re using),
no illegal activity could be proven using the logfiles.

Doch schon vorher hab ich mal meinen guten alten Netzwerksniffer angeworfen.
Denn durch das bereitstellen von einem Converter-Service und dem meiden der Abspeichermöglichkeit nach ccf bzw. rsdf wurde ich hellhörig.

Die Snifflogs haben folgendes Ausgegeben:

POST /dlcrypt/service.php HTTP/1.1
Referer: http://jdservice.ath.cx
Accept-Language: de, en-gb;q=0.9, en;q=0.8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Content-Length: 40
Host: jdservice.ath.cx
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-type: application/x-www-form-urlencoded

jd=1&srcType=plain&data=7752a9b6b516dabf
HTTP/1.1 200 OK
Connection: close
Date: Sat, 19 Apr 2008 13:21:14 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PHP/5.2.3
Content-type: text/html

<rc>Q2pDWS9NMmQzYkFtVzNtN1o2OGZOd2lNTTFxaFBMRG81M0hUQWJPenQrZFRSNUFzaXlkTVhDMEl5L3pDWTFVaw==</rc>

POST /dlcrypt/service.php HTTP/1.1
Referer: http://jdservice.ath.cx
Accept-Language: de, en-gb;q=0.9, en;q=0.8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Content-Length: 124
Host: jdservice.ath.cx
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-type: application/x-www-form-urlencoded

jd=1&destType=jdtc&srcType=dlc&data=Q2pDWS9NMmQzYkFtVzNtN1o2OGZOd2lNTTFxaFBMRG81M0hUQWJPenQrZFRSNUFzaXlkTVhDMEl5L3pDWTFVaw==
HTTP/1.1 200 OK
Connection: close
Date: Mon, 21 Apr 2008 07:35:48 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PHP/5.2.3
Content-type: text/html

<rc>KTHZU3ZbPu60l9oY1tIrS5vYenyFYewdtgt/Xm2lPW0=</rc>

Dies lässt mich zu folgender Annahme kommen:

JDownloader verschlüsselt die Links, wahrscheinlich mit einem Hard-Gecodetem Key
Übermittelt den Crypt-String an jdownloader.ath.cx
Bekommt einen mit einem Crypt-Key verschlüsselten String retour

Die Abfragen sind alles post-geschichten die sich einfach mit WGET realisieren lassen.
Ich habe ziemlich viel im Base64-Crypt-Routinen im Dekompilierten Java-Code gesehen. Daher könnte die Anfangs-Verschlüsselung Base64 sein (???)

Schwierig ist (wenn meine Annahmen bisher korrekt sind), dass jedes Mal, wenn der Key Publik wird, der Serverseitige Cryptkey geändert wird. Und dass würde eine Immensen Wartungs und Aktualisierungsaufwand bedeuten.


Nun, gesetz dem Fall, meine Schlussfolgerungen sind richtig:
Wie ist das Realisierbar?
Ist das Realisierbar?
Wollen wir das Realisieren?

Code: Select all

If Allanswers = Ja
   Msgbox, 64, Frage, Wer hilft mir?
ExitApp

Greets
Obi-Wahn

[IsNull]

Also (wenn ich mich nicht täusche) ist foglendes gegeben:

Ein Java-OpenSOurce-Tool, welches diese Container erstellen und auch anhand von solchen downloaden kann. -> D.h. wir dekompilieren den JsDownloader und müssen verstehen wie das ganze abläuft. dann sollte eine portation nach AHK nicht all zu schwierig werden.

Ohne den Source angeschaut zu haben, würde ich über das Format der DLC folgende Aussagen machen:

1. Für so wenig Informationen ist die Dateigrösse ziemlich gross. Da könnte es noch Überraschungen geben.

2. Dieses File schein folgendermassen verschlüsselt:

Code: Select all

base64(aes256bit(UrsprungsDLC))

Das macht auch Sinn; eine AES verschlüsselung kann problemlos nicht darstellbare Zeichen enthalten - was eine Übermittlung beeinträchtigt. Durch die base64 codierung kann dies umgangen werden.

Ich werde mir den Source mal zu Gemüte führen.

[Obi-Wahn]

Lang, lang ists her, aber jetzt hab ich wieder ein bisschen zeit, mich mit dem thema zu beschäftigen.
Zumal das Thema bei mir wieder recht aktuell geworden ist.

Der Hintergrund: Ich lade öfter mal was bei rs.com, und da irgendwas nicht ganz einwandfrei zu seinen scheint bei meinem pc oder meinem ISP, hab ich gelegentlich CRC-Fehler bei den geladenen parts.

Daher hab ich mir eine GUI zusammen geschraubt, die -Plain AHK versteht sich- per httpQuery die übergebenen RS.com-Links online überprüft (da kommt ein MD5-Hash raus), und dann geb ich den ordner an, wo gespeichert wurde, und das script vergleicht mir dann die MD5-Hashes (welche es von den lokalen Dateien natürlich auch nimmt).

Das Problem was ich habe ist nun, dass ich meistens mit DLCs arbeiten muss. Ich hab zwar bereits einen decrypter gefunden, der mir die Links decrypted, aber es währe schöner, effizienter und v.a. mit weniger werbung versehen, wenn das script übergebene DLC's selbst dekodieren könnte.


Daher hab ich mich mal wieder bei Google umgesehen, und habe DIESE ANLEITUNG gefunden.

Die ersten Schritte hab ich schon umgesetzt, aber nun steht noch den codingtechnische hochaufwand von AES-Entschlüsselung im ECB-Mode u.a. bevor, und da hab ich halt keinen schimmer von.

Also wenn jemand befähigtes, der Zeit und Lust hat, und diese auch investieren will, währe ich ausgesprochen dankbar...
Greets
Obi-Wahn