…wurden vor einigen von Lukas und laxity untersucht und veröffentlicht (an dieser Stelle sei angemerkt, dass keine direkte Gefahr für diejenigen besteht, die den Container zum Schutz ihrer Links eingesetzt haben. Es gibt momentan keinen öffentlichen Decoder dafür, und die Autoren des Artikels haben keine Intention, einen solchen zu veröffentlichen).
Eine Ergänzung…
meinerseits: Der Cipher ändert die Daten nicht mehr, sobald des niederwertigste Byte des Schlüssels einmal 0×00 ist. In diesem Fall findet in jedem Schritt eine Bitrotation der Schlüssels um 0 statt und die Daten werden mit 0×00 XOR-Verknüpft. Beides hat offensichtlich keine Änderung des inneren Zustandes mehr zur Folge und die Ausgabe entspricht fortan der Eingabe.
Schwach sind nun die Schlüssel, die nach wenigen Durchläufen diesen Zustand erreichen. Die triviale Lösung ist natürlich ein Schlüssel, der zu Beginn schon in dieser Form vorliegt, mit einem low-Byte von 0×00 (was im Artikel genannt wurde). Ebenfalls ungut ist aber z.B. der Schlüssel `00 ?? ?? 08`. Die erste Bitrotation (Links, um 8 Bit) wird den Schlüssel in `?? ?? 08 00` überführen, womit der Endzustand wiederum erreicht wäre. Ähnlich beim Schlüssel `?? ?? 02 01` – hier wird das das letzte Bit bei der ersten Rotation (Rechts, um 1 Bit) ans andere Ende des Keys rotiert, das letzte 0-Bit des nächsten Bytes (02) rutscht nach. In Binärdarstellung – vor der ersten Rotation:
???????? ???????? 00000010 00000001
…und danach:
1???????? ???????? ?0000001 00000000
Tags: Idiotie ^^
Zum Public-Decrypter: Naja wenn man noch Beispiel-Code veröffentlicht, damit es auch der Letzte hinbekommt… Die Beteuerungen sind in etwa so glaubwürdig, wie Rapidshare offiziell absolut gegen den Upload von Warez auf ihren schönen Dienst ist.
…was aber nicht den Artikel betrifft, sondern den Cipher selbst, respektive die Tatsache, dass man das nicht Leuten überlassen hat, die etwas davon verstehen und einen bewährten und kryptografisch starken Cipher verwendet hat.
Man muss mindestens eine Programmiersprache beherrschen, um das `hinzubekommen`. Klar, man könnte das in einen Decoder umsetzen – doch mit einer 1:1-Kopie ist es nicht getan, man muss immerhin die die Datei blockweise einlesen und fehlenden Funktionen implementieren (zum Beispiel, um die Byte- bzw. Bitmatrix zu transponieren). Das ist zwar nicht wirklich schwierig, wenn man eine Programmiersprache beherrscht – aber nur dann. Ich sehe demnach die Gefahr nicht wirklich als gegeben an, solange kein Decoder veröffentlicht wird.
Dennoch – ich wusste schon länger über CCF3.0 Bescheid (was letztlich dazu geführt hat, dass das Format in jD implementiert wurde), hätte dazu aber nichts veröffentlicht – wenn auch aus anderen Gründen. Nun wird CCF4.0 unausweichlich sein, und die CL-Entwicker sind unkooperativ und wollen keinem anderen Einblick in ihre Container gewähren. Daraus folgt, dass jemand wieder Arbeit haben wird, um CL ein weiteres Mal zu analysieren. Nun ist der Artikel aber da, CCF4.0 kommt auf jeden Fall, also sehe ich keinen Grund, warum man ihn nicht verbreiten sollte – wie gesagt, die Gefahr für die eigentlich Container (wenn sie nicht gerade schwache Keys haben, wie im Artikel erwähnt) schätze ich als gering ein. Das wurde schon im G:B in einem Feedback-Thread diskutiert. Die Lektüre kann ich empfehlen.
Die Bemerkung mit dem Idiotie-Tag war natürlich auf die “Verschlüsselung” und nicht auf den Artikel bezogen!
Vor allem da sich die “Verschlüsselung” ja unter Umständen wieder selbst negiert. Das ist schon fast eine Kunst so etwas zu releasen…
Es war ja soo klar… Cryptload war mies und daran wird sich leider nichts ändern…
Von wegen dem Decrypten, ich verstehe davon leider bloss 60% aber wie immer: Respekt Kugelfisch!
Wo hast du das eigentlich gelernt?
Und dann noch eins:
Benutzt keine Container leute…
RSDF kann man fast lesen wie ein Buch, CCF kannste jetzt auch vergessen,
DLC wird oftmals nicht entschlüsselt (MSD) (und jDownloader finde ich scheisse)
Ich habe kein Bock, dass das jD Team meine IP+Welche Files ich lade bekommt!
Stellt euch vor, die bekämen von irgendwem massig Geld für die Auslieferung?
Ich bin ja eigentlich nicht ängstlich bei sowas, aber ein einziger Riesenserver wo die Files entschlüsselt werden? Decrypt Sicher ist es ja… ich mag das aber nicht …
mfg Novo
@Novo: kannst du handfeste beweise liefern das JDownloader loggt?
Die Frage ist viel weniger ob service.jdownloader.org loggt (das ist als User nicht nachzuprüfen und eine Diskussion darüber deshalb einigermassen sinnlos), sondern viel mehr, was theoretisch geloggt werden könnte. Nun, soweit ich weiss, wäre das der File-Key und die IP-Adresse (wer sich für den grundsätzlichen Aufbau der Recrypt-Requests interessiert möge den Sniffer seines Vertrauens anwerfen und Eddys DLC-Artikel lesen – auch wenn der Crypto-Part unnötig kompliziert ist, da er CBC from Scratch implementiert hat).
Der File-Key ist eine zufällige 128-Bit-Zahl (mit weit weniger Entropie… aber lassen wir das), die zufällig generiert wird und nicht global eindeutig sein muss. Natürlich könnte man sich rein theoretisch mit einem File-Key auf die Suche nach einem Container machen, der ebendiesen File-Key benutzt. Das entspräche aber IMHO etwa der Suche nach einem Urbild eines bestimmten MD5-Hashs.
Die IP-Adresse – ja, die könnte theoretisch geloggt werden. Das lässt sich bei einem serverbasierten Verfahren technisch nicht anders umsetzen – schliesslich willst du im Idealfall auch eine Antwort auf deinen Request.
Problematischer als die DLC-Services sind aus meiner Sicht die online CCF-nach-DLC-Services. Das mag den Zweck erfüllen, die Keys und Verfahren aus den eigentlichen Binarys zu verbannen – doch hier wird der Containerinhalt übermittelt und könnte geloggt werden. Ob man hier dem jD-Team vertrauen will, ist jedem selbst überlassen. Ich selbst täte es wohl.
Zu CCF:Das hier betrifft CCF3.0 (mit CL 1.1.3 eingeführt) – CCF0.7 bis 1.0 verwendeten Rijndael (256 Bit, CBC, by the way) mit fixen Keys. Mittlerweile wurde das Format (mit CL 1.1.5) abermals verändert.
PS: Ich bin nach wie vor kein Freund von Containern – und ja, um das vorwegzunehmen: Container implementieren DRM-Mechanismen. Ob das nun gut oder schlecht sei, soll jeder für sich entscheiden.
Hallo,
also zu der Logging-Sache kann ich nur meine Überlegungen dazu präsentieren (nicht unbedingt Fakten!):
Nach 6 maligem Aufruf des DLC Servers (wenn man es direkt hintereinander macht), wird man für einige Minuten gesperrt. Meine Überlegung sagt also: Wie identifiziert der jd-Server uns? Woher weiß es, wie oft und in welcher Zeitspanne wir den Server aufgerufen haben? Da gibt es nicht viele Möglichkeiten: über Cookie, einem anderen Wert (GET, POST) der übermittelt wird, oder über die IP. Die Cookie und GET/POST Geschichte fällt weg, da mein hauseigener Decrypter z.B. sowas nicht unterstützt und trotzdem geblockt werden kann.
Bleibt also nur: IP-Sperre. Und es ist unumgänglich diese IP-Adresse zu speichern (wie soll man sie sonst sperren?) UND den Zeitpunkt (damit der Server weiß, nach wieviel Minuten er uns wieder freigeben kann).
Für mich ist also (wenn kein fataler Fehler in meiner Denkweise liegt) klar, dass der Server loggen _muss_. Nur, inwiefern das umgesetzt wird (evtl $_SESSION in PHP oder in einer SQL-Datenbank), also auch, wie lange diese Daten wirklich gespeichert werden (evtl nur temporär), und auch, _welche_ Daten genau gespeichert werden, wissen nur die JD-Leute.
Mit dem geloggten File-Key jedenfalls, könnte man eigentlich sehr wohl herausfinden, welche rapidshare-links die einzelnen User/IPs angefordert haben. Aber das ist eine etwas andere Geschichte.
Und wie Kugelfisch bereits sagt, im Endeffekt liegt es an eurem Vertrauen.
Wie denn? Wie gesagt, man könnte bestimmt nach einem Container suchen, der denselben File-Key hat – dennoch ist dadurch nicht bewiesen dass es diese Datei war, die dekodiert wurde, da der File-Key nicht eindeutig ist. Wie gesagt, IMHO lässt sich das mit dem Suchen eines Urbildes unter einer Hash-Funktion vergleichen.
Ja, das ist selbstverständlich korrekt, die IP-Adresse wird zu diesem Zweck garantiert zumindest temporär gespeichert.
Klar wissen die , wer wann was geladen hat!
Wir übermitteln IP, Zeitpunkt und den Hashm woraus die RapidshareLinks decrypten und an den Loader zurücksenden.
ob sie das nur temporär benutzen oder richtig Mitloggen, wer weiss das schon.
Auf jeden Fall finde ich das Blöd, dass da ein Server dazwischenhängt, an den täglich Millionen von RapidshareLinks gesendet werden sozusagen!
Das, was du unter `Hash` verstesht, ist der (verschlüsselte) File-Key. Der hat mit dem Inhalt des Containers nicht viel gemein. Der Server entschlüsselt den File-Key mit seinem Key (`Processing-Key`, `Master-Key`,…), verschlüsselt ihn wiederum für den gewünschten Loader (mit dem entsprechenden Loader-Key) und sendet das Resultat an den Loader zurück. Der Loader entschlüsselt den erhalten File-Key nun mit seinem Loader-Key und mit dem File-Key dann den eigentlichen Content des Containers. So zumindest das, was ich selbst über DLCs weiss (und das scheint in sofern korrekt zu sein, als dass ein Decoder, der nach eben diesem Prinzip vorgeht, funktioniert).
Das witzigste ist immernoch, dass bei relink.us etc. alle 3 Container gleichzeitig (also auch RSDF) angeboten wird.
Naja und RSDF ist ja Cracked worden…
Alle Container anzubieten ist in der Tat (im Hinblick auf die Verschleierung (`Sicherheit`) der Links) sinnlos, spätestens seit jemand™ vor einem Jahr den RSDF-Key im G:B gepostet hat (bei relink.us kann man die zu erstellenden Container aber scheinbar wählen, es gibt keinen Zwang, RSDF-Container anzubieten).
Allgemein sind aber Container nur beschränkt sinnvoll. Man muss, sobald der Client einen Link hat, damit rechnen dass der User den Link ebenfalls sieht. Egal, ob man nun einen Link-Protektor oder einen Container verwendet.
na also! Du sagst es!
Der ganze Stress, Downloader inkompatibilität, Captcha, verschlüsseln/entschlüsseln etc.
Den ganzen Dreck müssen wir über uns ergehen lassen, und was bringts?
GARNIX!
Wenn jemand petzen will, kommt er so oder so an die Links, auch mit DLC!
Also Leute, LASST ES WEG, ES NERVT NUR!
Da muss ich dir zustimmen Novo, dieser ganze Verschlüsselungs dreck taugt nur minimal was, man hat so gesehen mehr Stress mit dem runterladen als jemand der die Sachen verpetzen will.
Wenn jemand was verpetzen will dann nur in großer menge, selbst mit einem kleinen Sniffer-Script kann man die eine oder andere Seite Komplett über Nacht verpetzen dazu muss man nicht einmal was drauf haben, beim echten Decoder hingegen schon.
Das Problem ist nur, dass die Uploader nicht mehr anders wollen was aber verständlich ist.
Naja, es gibt noch so viele andere Möglichkeiten Daten auszutauschen, wieso müssen es unbedingt immer die so “sicheren” 1KH sein.
Ich möchte keine Panik oder so verbreiten aber wer denkt das 1KH nicht loggen ist naiv.
Der einzige Hoster der interessant war ist Rapidshare.com den man aber nun knicken kann.
Wer paar Euros im Monat über hat kann sich eine Usenet Flatrate oder Torrent mit Seedbox holen, selbst mit DSL16k ist man bei Torrents gut bedient.
Usenet Accounts sind nicht das Problem.
Ich mag usenext einfach nicht, ich weiss nicht ob das stimmt, aber mir kommt das genauso vor wie Bearshare und Torrents…
Sunsicher!
Stimtm das?
Ganz wichtig: Das Usenet != (Firstload|UseNeXT|$teurer_binary_provider) – schliesslich sagt man auch nicht, das Internet sei die Telekom oder umgekehrt. UseNeXT ist nur ein Zugangsprovider, der dir einen Usenet-Zugang bereitstellt, genau, wie dir die Telekom deinen Internet-Anschluss stellt. Auch ist es eine häufige Fehlannahme, das Usenet sei eine Warez-Tauschbörse – das ist ebenso falsch, wie wenn man z.B. das G:B als Börse bezeichnet hätte. Klar, es gibt den alt.binaries-Teilbaum, es gab auch die Börsenforen im G:B, aber das Usenet ist in erster Linie eine Diskussionsplattform.
Ob du nun `sicher` bist, hängt ganz von deinem Usenet-Provider ab, resp. wie der mit den Daten seiner Kunden umgeht.
hab mich damit noch nie beschäftigt, wüsste garnet, wie ich da ran kkommen würde xD
kenn bloss SFT FTP RS
[...] 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 [...]
Hi,
leider scheint decrypter.ath.cx mittlerweile down zu sein und ich konnte auch keine Kopien finden – könnten Sie die Informationen evtl. nochmal posten?
Vielen Dank, ich verzweifel hier nämlich grade an diesem Security-through-Obscurity Mist.
Die verlinkte Dokumentation zur Analyse ist inzwischen unter http://superwayne.org/papers/ccf3/ zu finden. Beachte allerdings, dass das Container-Format inzwischen (mit CL 1.1.5) erneut verändert wurde.
D A N K E !
Das beendet eine lange Suche!
Jetzt muss ich das nur noch verstehen
http://superwayne.org/papers/ccf3/ gibts leider nicht mehr. Bitte neu hochladen.
Mirror der ehemaligen Seite: http://foooo.fo.ohost.de/ccf3mirror/
Hier noch ein Mirror: https://blog.posativ.org/files/2011/ccf/