CCF Generator von Dexter

**Xeton** · 04. 07. 2007, 07:12

Zitat von seed

@Blad€: die neuen ccf sind super leicht zu entschlüsseln, wobei man dabei noch cl benötigt, denn es gibt ne wunderschöne schwachstelle in cl, die meiner meinung nach auch gar nicht so einfach behoben werden kann...

hmm, dann könnte man ja wieder ein Programm schreiben, oder?

**h264** · 04. 07. 2007, 11:25

die Idee von krazyivan mit zufällige string als Key ist auch sehr gut, da es schneller geht als hash von 100MB Datei zu berechnen. Und die Methode von seed hat den grossen vorteil das man nur das verpetzte teil reuppen muss. Ich überbearbeite das schema nach den Ideen von seed und krazyivan so:

Uppen:
1. DAT-files vorbereiten
part01.rar + [256 zufall bytes] -> part01.rar.dat
part02.rar + [256 zufall bytes] -> part02.rar.dat
...
2. upload dat-files mit beliebigen uploader
3. links container file erstellen:

Code:

[http://.../part02.rar.dat] + [letzte 32-bytes von part01.rar als key] --> verschlüsselte link für part02
[http://.../part03.rar.dat] + [letzte 32-bytes von part02.rar als key] --> verschlüsselte link für part03
...

Das links container file sieht dann so aus:

Code:

# comments, NFOs
part01.rar|100000000|none|http://.../part01.rar.dat
part02.rar|100000000|part01.rar|verschlüsselte link für part02
part03.rar|100000000|part02.rar|verschlüsselte link für part03
und so weiter nach dem schema
<filename>|<originalsize>|<keyholder-filename>|<encrypted-link>

Downloaden:

Code:

http://.../part01.rar.dat downloaden
letzte 256 bytes wegschneiden --> original part01.rar
[letzte 32-bytes von part01.rar als entschlüsselnkey] + verschlüsselte link für part02 --> http://.../part02.rar.dat
letzte 256 bytes wegschneiden --> original part02.rar usw.

Reupp: beispiel part50 ist verpetzt

Code:

1. part50.rar + [256 zufall bytes] -> neues part50.rar.dat (part50.rar bleibt unverändert!)
2. part50.rar.dat reuppen, bekommen wir neuen link http://.../part50.rar.dat
3. links container file re-generieren und wieder veröffentlichen
[letzte 32-bytes von part49.rar] + [http://.../part50.rar.dat] --> verschlüsselte link für part50 (neu)
Der downloader überspringt 49 teile die bereits auf Festplatte liegen und lädt von dieser stelle weiter.

- das padden ein zufallsblock hinter rar-teil ist einfacher als doppelt verpacken. Beim doppelten verpacken müssen wir sowieso irgendetwas, zufallsdaten, datum etc., dazu packen damit ein reupp klappt. Das padden/wegschneiden ist viel einfacher und resourceschonender als pack/unpack (nur einfach fseek(f,filesize(f)-256)); truncate(f); )
- warum nehme ich letzte bytes als key: 1. petze muss datei komplett laden, 2. dieses teil unterscheidet sich meistens von file zu file (im gegensatz zu header). Und 32 bytes also 256 bit sind genug. Der Petze lohnt es sich nicht via bruteforce zu knacken
- die cumulative verschlüsselung durch alle bisher geladene teile macht zwar etwas sicherer. Die petze hat aber schon diese teile, weil sonst wie ist sie zu diesem teil gekommen
- man kann beliebigen Upload Prog nehmen, aber es ist bequemer mit einem einfachen upload tool, der beim uppen dat-file on-the-fly erstellt (spart man zeit und platz)
- ich nehme rar und rapidshare als beispiel, ist ja das verbreiteste, muss aber nicht. Also hoster und file format unabhängig. Download progies müssen sowieso erweitern und nach einem standard halten

Ein Nachteil bei diesen kettenmethoden: man kann nicht vor dem download alle links checken. Es hilft eine webseite die die links on-the-fly prüft und gibt als Statusbild zurück. Es ist schön wenn dieses Statusbild direkt in G:B gezeigt wird. Die Links muss der Upper dem webserver mitteilen und werden dort sicher gespeichert.

EDIT. Das Statusbild belastet nur den server. Also reicht es ein Link zum checken der prüft und sagt welche Dateien verpetzt sind

EDIT2. Ich gebe zu dass es mit Dateigröße angabe sicherer ist

**schneewiesel** · 04. 07. 2007, 11:34

Zitat von Blad€

hmm, dann könnte man ja wieder ein Programm schreiben, oder?

Ich arbeite zzt. an einem, ccf zu rsdf konverter, damit ist es möglich die ccf Links mit dem RSD zu laden

**krazyivan** · 04. 07. 2007, 11:56

@h264:
bei deiner version ist es wieder so dass sich die keys nach einem reup nicht ändern, dh. eine petze die einmal alle keys hat kann sofort wieder petzen ohne sich die ganzen parts aufheben zu müssen.

so wie ich das meine ändern sich sämtliche keys bei jedem reup und nur wer die kompletten parts hat kann die gereupte version auch entschlüsseln, es genügt eben nicht nur die keys aufzuheben.

....Und die Methode von seed hat den grossen vorteil das man nur das verpetzte teil reuppen muss.....

wieso sollte das bei meiner version nicht gehen?

**h264** · 04. 07. 2007, 12:12

@krazyivan: natürlich geht es mit deiner version. Sie basiert doch auf seed-methode oder?
Zu dem petzen: die keys liegen ja in den vorherigen parts. Wenn die petze die parts einmal runtergeladen hat damit sie petzen kann, ist sie auch in der lage das neu reuppte part zu entschlüsseln. Das regenerierte container file muss man doch wieder veröffentlichen oder? Es sei denn wir packen alle neu und reuppen.
Das system hindert nämlich das erste petzen, weil der Aufwand alle teile zu petzen ist enorm im vgl zu CCF. Hat die petze das letzte teil petzen können, hilft es nur ein kompletter reupp

**Ridcully** · 04. 07. 2007, 18:56

macht barana den ccf-usd plugin?? wenn schneewiesel das für rsd macht?

**Natenjo** · 13. 07. 2007, 08:59

Zitat von schneewiesel

Ich arbeite zzt. an einem, ccf zu rsdf konverter, damit ist es möglich die ccf Links mit dem RSD zu laden

das ist das wasich suche....wie weit bist du den schon....oder wie lange wird es noch ca. dauern??

**schneewiesel** · 13. 07. 2007, 10:04

Den konverter gibt es bereits (thx an deXter), jedoch wird er nicht public, da man so auch schnell an die Original links kommt.
Wer eine ccf in eine rsdf gewandelt haben will, schickt mir einfach eine PM mit dem link zur ccf.

**Xeton** · 13. 07. 2007, 10:07

Moin schneewiesel,

kannst du das Programm vllt. nicht irgendwie modifizieren, sodass man den konverter in Verbindung mit RSD nutzen kann? Sowie das grad mit den .rsdf's geht, dann würde auch niemand an die Originallinks kommen...

**angelasferkel** · 13. 07. 2007, 10:26

ich denk mal, dass er die umwandlung automatisiert über cl macht und anschließend den container erzeugt -> dann würde natürlich jeder mit dem konverter die links im klartext bekommen.

**Natenjo** · 13. 07. 2007, 10:28

aaah ich hab grad entdeckt das der RSD auch ccf unterstützt

gugst du
http://getpic.info/?p=24055_ccf.jpg

**schneewiesel** · 13. 07. 2007, 10:33

@Natenjo:
Aber nur ccf´s bis CL0.7.

@Blad€:
wie angelasferkel schon schrieb, braucht man lieder immernoch CL zum auslesen der Links (*welche ironie*)

**angelasferkel** · 13. 07. 2007, 10:34

aber nur ccf versionen < 0.8 AFAIK

edit: bin zu langsam heute

deleted user · 17. 07. 2007, 08:20

Zitat von schneewiesel

Den konverter gibt es bereits (thx an deXter), jedoch wird er nicht public, da man so auch schnell an die Original links kommt.
Wer eine ccf in eine rsdf gewandelt haben will, schickt mir einfach eine PM mit dem link zur ccf.

Was Solls, an die originalen Links kommt, mann immer, nur eine Frage der Intelligenz und Zeit

TOM

**Yates** · 20. 07. 2007, 14:07

Ich hab das hier alles noch nicht so ganz begriffen, und bin auch auf dem Gebiet der Containerfiles ein ziehmlicher Laie, aber kann mir bitte jemand sagen, wie ich jetzt meine Links verschlüsseln kann, sodas ich sie vie CryptLoad wieder runterladen kann?

Das wäre mir wirklich eine sehr große Hilfe!

Vielen Dank schon mal!