Comments on: DLC geknackt!

By: KraSSor

KraSSor — Mon, 01 Mar 2010 14:44:00 +0000

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,

By: Security

Security — Sun, 10 Jan 2010 18:13:45 +0000

No security by obscurity!!

By: Blog of eddy14 » Blog Archive » Code makers and breakers

Blog of eddy14 » Blog Archive » Code makers and breakers — Fri, 10 Jul 2009 10:25:36 +0000

[...] 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 [...]

By: davd

davd — Fri, 26 Jun 2009 12:33:58 +0000

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*

By: fox21.at v.2.0

fox21.at v.2.0 — Fri, 10 Apr 2009 10:12:11 +0000

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…

By: Quakexxx

Quakexxx — Fri, 03 Apr 2009 16:38:40 +0000

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…

By: Unbehagen

Unbehagen — Thu, 26 Mar 2009 16:47:58 +0000

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.

By: hawk

hawk — Sun, 22 Feb 2009 11:10:51 +0000

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

By: wushu_c

wushu_c — Sat, 21 Feb 2009 15:58:31 +0000

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*

By: DLCDecrypt

DLCDecrypt — Sun, 08 Feb 2009 13:58:37 +0000

Dazu: http://www.boerse.bz/talk/szene-talk/139123-dlc-geknackt-2.html#post1201989