CCF Generator von Dexter

**krazyivan** · 26. 06. 2007, 23:51

naja eigntlich ist es ja sobald die links irgendwie drangehängt werden nicht mehr unbedingt downloader-unabhängig, oder?
man kanns nur versuchen so zu machen das es in möglichst allen eingebaut werden kann.

**Ridcully** · 26. 06. 2007, 23:56

darüber war man sich ja mehr oder weniger schon im vorfeld einig.

wobei ich mir über solche kleinigkeiten wie die downloadschlange jetzt echt noch keinen kopf machen würde.

ist ja eh schon ein manko, das es ne sequentielle folge wird, aber in punkto petzen ist das halt ein notwendiger schritt..

ich persönlich hab sowieso den 16.mbit vorteil auf meiner seite .. ne dvd zu saugen ist für mich wie video on demand ..

**angelasferkel** · 27. 06. 2007, 00:06

sequentiell wäre ja nicht schlimm - das interleaving macht den spaß´kapuitt. mir war das nicht aufgefallen weil ich immer nur dasselbe file ziehe, aber ich kenn leute, die haben immer eine queue von ein paar hundert parts. wenn die warten müssen (fast) bis zum letzten part des letzten projekts, damit sie das erste projekt fertig haben, die wären nicht froh.
man bräuchte eine option: neue links oben einfügen. dann müsste man die manuell eingefügten imme noch händisch ans ende schieben, aber damit ließe sich wohl leben.

**Ridcully** · 27. 06. 2007, 00:09

mir würde da eher ne automatische download priorität einfallen , aber willst dir da jetzt wirklich schon gedanken drum machen ??

am ende brauchst du sonst einen komplette neuen downlaoder .. aber gewisse östreicher brauchen ja auch was zum arbeiten .. forcceload nimmt gestalt an .. loool

**samy23** · 27. 06. 2007, 08:25

hi
wird es eigentlich eine aktuelle ccfdecomp.exe zu cryptload 0.8se geben?

**schneewiesel** · 27. 06. 2007, 09:14

Nein, mit großer wahrscheinlichkeit nicht.

**angelasferkel** · 27. 06. 2007, 09:48

ich fände es am besten, ccf komplett fallen zu lassen, so lange das derart proprietär ist.

edit: beim drüberschlafen bekam ich einen alptraum - die downloaddauer strebt gegen unendlich, solange neue links eingefügt werden.
ich hab mal ne mail an dimonius geschrieben, ob er eine option einbauen kann "neue links am kopf der liste einfügen". programmiertechnisch wäre das wahrscheinlich kein problem. optional könnte man auch das tool, das einkommende files auf enthaltene partzeiger überwacht, so gestalten, dass es den link an den kopf der downloadliste schreibt, aber dann wäre es nicht dl-tool unabhängig. ich denke, man sollte es so allgemein wie möglich halten.

**seed** · 27. 06. 2007, 14:48

wie wäre es wenn die links nicht direkt auf rapidshare zeigen würden, sondern auf html-dateien, die auf dem eigenen server liegen, und zwar mit folgendem inhalt:

nächster.part3.rar.zufälligeSequenz.§$%&.html :

PHP-Code:


<META HTTP-EQUIV="Refresh"

CONTENT="0; URL=http://rapidshare.com/1111111/nächster.part3.rar">

dadurch muss man wenn eine datei aus der mitte der reihe gelöscht wurde, nur diese auch wieder hochladen und den redict link des vorherigen parts auf den neu hochgeladenen part ändern...

so muss man zumindest nicht alle vorherigen parts neu hochladen, und die petze muss trotzdem die parts zuerst runterladen bevor sie diese petzen kann

man müsste natürlich den eigenen server entsprechend absichern, aber ich glaube kaum, dass die petzen versuchen werden nen server zu knacken um die links für urlaubsfotos rauszukriegen

**Ridcully** · 27. 06. 2007, 16:39

jetzt mal scherz beiseite ..

ich alter spanner wollte schon immer die urlaubsfotos und bilder von andern sehen ..
hab schon etliche gb an daten runtergeladen und was war .. kein einziger urlaubsfilm dabei .. nur so aktuelle spiele und irgendwelche neuen kinofilme und son schrott ..
mal sehen ob ich irgendwann mal endlich wirklich mal ein urlaubsvideo finde

**saltlake** · 27. 06. 2007, 17:07

Zitat von seed

wie wäre es wenn die links nicht direkt auf rapidshare zeigen würden, sondern auf html-dateien, die auf dem eigenen server liegen, und zwar mit folgendem inhalt:

dadurch muss man wenn eine datei aus der mitte der reihe gelöscht wurde, nur diese auch wieder hochladen und den redict link des vorherigen parts auf den neu hochgeladenen part ändern...

Und wenn der Server dann down ist, dann kann niemand mehr downloaden. Und wie bereits beschrieben wuerde eine Petze wohl saemtliche Links loeschen, die sie in die Finger bekommt. Somit muesst man sowieso von vorn hochladen.

greetz

**seed** · 27. 06. 2007, 17:25

stimmt hast recht...

dann sind aber alle methoden hier so ziemlich sinnlos, denn sie verhindern das verpetzen gar nicht, sondern verzögern das nur...

noch ne idee: es ist gar nicht notwendig ans ende der parts den link anzuhängen... man kann einen containerfile ertellen, bei dem nur der erste link unverschlüsselt ist, der nächste link ist jedoch verschlüsselt, und zwar mit der checksumme des vorherigen parts... so kann man sicherstellen das der runtergeladene part fehlerfrei ist und auch dass die petze die links nicht bekommt solange sie nicht alles runtergeladen hat...

// EDIT: Eine Implementierung kommt bald...

**saltlake** · 27. 06. 2007, 17:30

Klingt auch ganz nett. Man muesste dann als Schluessel zB den CRC der gepackten Datei nehmen. Den CRC der gesamtdatei kann man nicht nehmen, da in dieser der Link zur hochzuladenden Datei enthalten ist, welche ja noch nicht oben ist, weil der Schluessel fehlt.

Dafuer braeuchte man aber auch einen extra Downloader, oder man muss immer ein Tool zum berechnen der CRC anbieten. (md5, sha1 oder was auch immer geht natuerlich auch)

greetz

**schneewiesel** · 27. 06. 2007, 19:09

Tools zum md5 und crc32 berechnen hatte ich vor ein paar wochen mal geproggt.
Sollte eig. kein Prog sein das irgendwo zu integrieren, dll form wäre auch möglich.

**angelasferkel** · 27. 06. 2007, 19:17

so richtig den sinn seh ich darin nicht - man gewinnt nichts, man braucht nur ein tool mehr bzw. verliert noch mehr downloadunabhängigkeit. rar mledet eh crc fehler, wenn das file kaputt ist.

edit:

dann sind aber alle methoden hier so ziemlich sinnlos, denn sie verhindern das verpetzen gar nicht, sondern verzögern das nur...

und genau deshalb sind sie nicht sinnlos, sondern zumindest theoretisch effektiver als alle bisherigen ansätze - die nicht einmal bzw. nur unterhalb der oberen schwelle, ab der es auch den downloader ausbremst, verzögern.
wäre ich petze, würde ich problemlos jeden tag alle im board geposteten klartextlinks verpetzen können.
wäre ich eine hinreichend frustrierte petze, würde ich ein ccf mit 40 parts in ~ 5-10 minuten komplett verpetzen können (vorausgesetzt, ich hab kein decrypt tool, dann dauerts natürlich nicht so lang).
wenn ich für den nächsten link ersten einen i.d.r. 100 mb part ziehen muss, hilft mir kein tool und kein trick der welt und die benötigte zeit steigt immens.
ich hab oben schonmal geschrieben, dass sich das erst ab einer kritischen masse positiv auswirkt - dann reicht die zeit der petzen schlicht nicht mehr, um die masse der files zu gefährden.
absolute sicherheit gegen petzen gibt das verfahren natürlich nicht, dazu war es auch nie gedacht, und so ein verfahren wird es auch nie geben. was ich laden kann, kann ich verpetzen. entscheiden ist die frage, wie schnell ich etwas laden kann.

**saltlake** · 27. 06. 2007, 19:29

Stimmt schon. Wie gehabt bin ich immer noch fuer das Format, wie es mein Unix Uploader erstellt

Meiner Meinung nach ist das intuitiv und leicht automatisierbar. Alles andere ist Schnickschnack. Wenn man gewaehrleisten moechte, dass man die Parts komplett herunterladen muss, dann kann man einfach ein solid state Archiv erstellen. Dann muss man naemlich das gesamte Archiv erst entpacken bevor man die nextpart.txt bekommt. Die Vorteile der CRC Ueberpruefung und des kompletten Downloads sind auch hier vorhanden, es gibt jedoch keine Abzuege beim Benutzerkomfort.

Nachteil an der CRC Sache ist, dass man auf jeden Fall das Archiv erst komplett entpacken muss, bevor man weiterlaedt. Wenn man kein solid state Archiv hat, dann kann man direkt nachdem man die Datei heruntergeladen hat nur die nextpart.txt entpacken, den naechsten Download starten, und danach in aller Ruhe das gesamte Archiv entpacken.

greetz

**QOTSA** · 27. 06. 2007, 20:06

Ich finde die Idee mit der nextpart.txt zwar auch sehr gut, glaube aber nicht wirklich, dass es von den Uploadern angenommen wird. Was ist, wenn man zB bei 50 Parts aufgrund eines CRC-Fehlers einen Part neuladen muss. Wie kommt man dann an den Link der jeweiligen Datei?

Mir würde ein Container-File wie ccf, wenn es als offener Standard für alle Download-Manager etabliert würde, besser gefallen. Es wird ja immer wieder behauptet, dass es so einfach wäre mit Paketsniffern wie Wireshark an die echten Links zu kommen. Aber ist es das wirklich? Ich habe es selbst noch nie probiert, aber werden sich die Petzen echt die Mühe mache, das zu tun? Ein Containerfile mit guter Verschlüsselung würde meiner Meinung nach das "Petzenproblem" erheblich eindämmen.

**schneewiesel** · 27. 06. 2007, 20:09

Zitat von QOTSA

Es wird ja immer wieder behauptet, dass es so einfach wäre mit Paketsniffern wie Wireshark an die echten Links zu kommen. Aber ist es das wirklich? Ich habe es selbst noch nie probiert, aber werden sich die Petzen echt die Mühe mache, das zu tun?

Ja, das ist wirklich so einfach.