Designfehler von CCF 3.0…

…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

Von der Schliessung der gulli:börse, Spinnen, Urlaubern und Plagiaten…

Die gulli:börse, einst Umschlagplatz für Millionen Bytes an Warez, wird geschlossen – Phase 1, die Read-Only-Zeit, wurde am Freitag, dem 08.08.08, eingeläutet, Phase 2, die Komplettschliessung erfolgte am Monag, dem 11.08.08. Die drei Tage Übergangsfrist sollten den Benutzern die Möglichkeit geben, Backups anzulegen.

Nimm, was du kriegen kannst…

Die Folge war abzusehen – das Board hatte dieser Tage eine Spider-Plage zu beklagen. Viele wollten sich zumindest Teile der Börse sichern, was verständlicherweise einen `leicht` negativen Einfluss auf die Boardperformance hatte, um nicht zu sagen, das Board sei ständig überlastet gewesen. Nun, ein drei Tage überlastetes Board will man ja auch nicht. Also lässt man kurzerhand alle User, die einige Requests mehr tätigen, automatisiert für 3 Tage beurlauben. `Too many spider …` – ja, zu viele Spinnen, die zu viele Requests tätigen. Prominentes Beispiel eines solchen Urlaubers ist vmk. Auch mein Perl-Skript, das einige Backups machen wollte, war nicht wirklich gerne gesehen, auch ich gewann einen 3-Tage-Luxusurlaub.

gulli ($version++)

Mit der Schliessung der Börse geht unbestritten eine Ära des g:b’s zu Ende. Doch auch nach der Schliessung der Börse wird das gulli:board garantiert weiterleben, mit dem hübschen Nebeneffekt, dass die Serverlast – und damit auch die Frequenz der Überlastungsmeldungen – sinken dürfte. Insgesamt habe ich selbst die Börse selten verwendet, dennoch war sie da, praktisch, wenn man einmal etwas laden wollte. Aber so ist das Leben – altes vergeht, neues entsteht.

build gulli replica now!!!

…dieser Text entstammt keineswegs der Betreffzeile einer allseits erwünschten eMail. In der Phase der Börsenschliessung schossen Gulli-Plagiate in rauen Mengen aus dem Boden, den höchsten Bekanntheitsgrad geniesst ein Projekt, das erst `gulli:open`, dann `open gulli:börse` und schliesslich open:gully genannt wurde. Während dieses sowieso unter Erreichbarkeitsproblemen leidet, macht die Administration des g:b’s indes die Betreiber solcher Kopien auf Markenrechtsprobleme aufmerksam.
Doch auch open:gully selbst hatte Trittbrettfahrer – ein in hohem Masse kreatives Individuum hielt es für nötig, die Domain opengully.de zu registrieren und dort zu behaupten, open:gully sei `ins UseNet umgestiegen` (dieses Individuum sollte eher lernen, sicheren PHP-Code zu schreiben). Der nötige Ref-Link zu einem berüchtigten Usenet-Provider durfte natürlich nicht fehlen.

Update 1.0: open:gully ist tot. Der Administrator hat das Projekt aufgegeben, nachdem vermeintliche Realdaten `von jemandem, der nur helfen wollte` veröffentlicht wurden.
Update 2.0: open:gully entschwebt der Asche – oder soll das zumindest am 30. August tun. Eigenen Angaben zufolge wird ein anderer das Projekt weiterführen. Die zweite, bekannte Kopie gulli2.com soll seinen Angaben zufolge indes für DDoS-Angriffe verantwortlich sein.

RapidShare und die `armen` Leecher

RapidShare.com ist böse, Müll und überhaupt irgendwie schlecht – zumindest, wenn den `armen` Leechern mit dynamisch vergebenen IP-Adressen glauben darf.

Von glücklichen Stunden und Katzen…

Hintergrund dieser `Kritik` ist, dass RapidShare in den letzten Wochen das Hund- und Katzspiel mit Captchas leid geworden ist. Nach den verzerrten Katzencaptchas, die immerhin einige Wochen hielten, kam kurze Zeit ein tEABAG_3D-Derivat zum Einsatz, wessen Status einige Tage zwischen den Extrema `per OCR erkennbar` und `für Menschen nicht lesbar` schwankte. Nicht unerwähnt sollten die zu dieser Zeit aktiven `Happy Hours` bleiben – immerhin 16 Stunden am Tag kamen überhaupt keine Captchas zum Einsatz. RapidShares Plan war wohl, die extreme Bandbreitenauslastung während des Ansturms in den frühen Abendstunden durch Verlagerung der Free-User-Aktivitäten in Zeiten schwächerer Auslastung abzufangen. Dieses Unterfangen wurde aber durch automatisierte Erkennungsmethoden für die Captchas vereitelt – der verbotene Apfel musste zwingend gepflückt und gegessen werden, die täglich verbleibenden 8 Stunden mussten dringend auch zur automatisieren Generierung von Traffic ausgenutzt werden.

Aus dem Paradies vertrieben…

Dass RS.com dieses Spiel nicht ewig mitspielen wird, war abzusehen. Vor einigen Tagen wurde statt eines Captchawechsels eine neuartige Massnahme ergriffen – die Geschwindigkeit für Free-User wurde auf 500 Kilobit (ca. 63KiB) pro Sekunde gedrosselt, dafür entfallen die Captchas sowie die Wartezeit nach jedem Download. Unter den deutschen Leechern mit ihren dynamisch zugewiesenen IP-Adressen machte sich sehr schnell Unmut breit. Man brauche jetzt viel länger für die neuen Urlaubsfilm-BluRay-Discs, da man nicht mehr ununterbrochen mit 16 Megabit pro Sekunde laden könne. Dass man früher eigentlich mehr als zwei Stunden nach jedem 100MiB-Download hätte warten müssen, und dass die knappen 30 Minuten, die man als Free-User nun für 100MiB braucht, verglichen damit durchaus human sind, braucht keiner zu wissen. Schliesslich konnte man die Wartezeit durch ein Neuaufbauen der DSL-Verbindung und den damit verbundenen IP-Wechsel abkürzen.

…oder auch nicht?

Freilich hat nicht jeder eine dynamisch zugewiesene IP-Adresse. In vielen Ländern sind IP-Adress-Pools so gut wie unbekannt. Da zeigte das alte System sein wahres Gesicht – schön, wenn man für 5 Minuten die DSL-Leitung glühen lassen konnte, unschön, dass man danach einige hundert Minuten warten musste. Für all jene, die das alte System nicht ausgetrickst haben – etwa, weil es aufgrud einer fixen IP-Adresse nicht möglich war – stellt das neue System eine deutliche Verbesserung dar. Ausserdem bringen im neuen System auch Downloads von Premium-Usern Punkte, was den Uploadern sicherlich gefallen dürfte.

Auch die Premium-User…

…wurden in den letzten Wochen mit einigen Neuerungen beglückt. Neben einer – nach kurzer Zeit wieder zurückgenommenen – `Vereinfachung der Trafficabrechnung`, welche zur Folge hatte, das pro Tag `nur` 10 GiB Traffic erzeugt werden durften (statt 50GiB beliebig über 5 Tage verteilen zu können), wurden auch Massnahmen gegen Accountsharing ergriffen. Während auch hier eine grosse Menge höchst sinnvoller Beschwerden von Personen kamen, die vorher – den AGB zum Trotz – Accounts geteilt haben, gab es doch auch begründete Kritik – da der Premium-Account 15 Minuten nach jedem Download gesperrt bleibt, hat eine Zwangstrennung der Verbindung seitens des Providers eine Verzögerung von bis zu 15 Minuten zur Folge. RS.com versuchte, diesem Problem durch Lokerung der Sperre für das jeweilige /24-Subnetz Einhalt zu gebieten. Da einige ISPs jedoch verschiedene /24er-Netze in ihrem DHCP-Pool haben, ist das Problem dadurch nicht endgültig gelöst.

Früher…

…war bekanntlich alles besser. Was wollen die Power-Leecher? Diese Frage ist einfach zu beantworten, die Antwort wird jedoch verständlicherweise ein Wunschtraum bleiben. Was einige wollen, ist ein System, dessen Limits man austricksen kann. Keiner will wirklich wieder Captchas und Wartezeiten nach jedem Download. Das `gute` alte System ist nicht so beliebt, weil es wirklich grosszügiger war, sondern, weil es seine Wirkung – zumindest im Lande der dynamischen IP-Adressen – nicht entfalten konnte – und diese Tatsache ist RS.com verständlicherweise ein Dorn im Auge.

Im Endeffekt…

…ist dieser Post uninteressant. Die Leecher wollen soviel wie möglich in möglichst kurzer Zeit gratis herunterladen. Punkt. Alles andere ist uninteressant.

«All packtets are equal…

…but some packets are more equal than others.»

Die Netzneutralität ist ein wertvolles Konzept, das in der heutigen Zeit immer weiter eingeschränkt wird. `Netzneutralität` bedeutet, dass sowohl ISPs als auch Carrier jedes Datenpackt gleich zu behandeln haben – insbesondere darf keine Filterung oder Priorisierung anhand des Inhalts, des Protokolls oder des vermuteten Anwendungsbereichs vorgenommen werden. Während Internetzensur ebendieses Konzept von der einen Seite bedroht, steht an der anderen Front die Anti-P2P-Lobby sowie einige ISPs wie Comcast, die versuchen, Pakete, die vermuteterweise mit einem Peer-to-Peer-Netz ausgetauscht werden, zu verwerfen oder zumindest stark zu limitieren. Das ist jedoch nicht alles – Sandvine, die Entwickler des Filtersystems, das unter anderem von Comcast eingesetzt wird, hat vor kurzem ein neues Produkt vorgestellt, `FairShare` genannt. Während die Pressenotiz von Sandvine nicht viel über die Funktionsweise von `FairShare` verrät, spricht Sandvines Paper `The Value of Traffic Optimization in a World with Network Neutrality` eine deutlichere Sprache.

A policy is applied to heavy users during periods of congestion to allow light users a fair opportunity to use the available bandwidth. This policy usually consists of traffic shaping action and/or traffic prioritization to limit the abusive traffic during the congestion period.

Folglich soll die Bandbreite derjenigen, die ihre bezahlte Flatrate stark auslasten, zumindest während den Spitzenzeiten eingeschränkt werden. Ihre Pakete werden niedriger priorisiert, ihre Übertragungsgeschwindigkeit limitiert. Dies soll, laut Sandvine…

By encouraging heavy users to shift their usage to off-peak times, bandwidth can then be divided fairly among users throughout the day. The overall effect is an improved user experience.

…den armen Usern helfen. Die Wirklichkeit sieht aber so aus, dass sich der ISP in seiner Mischkalkulation vetan hat – schon in der Vergangenheit wurden Fälle bekannt, in denen ISPs Kunden, die viel Bandbreite verbraucht haben, gekündigt haben. Ebenfalls ist die Frage nicht beantwortet, wie die Bandbreiteneinschränkung genau erfolgen soll – wird das über BitTorrent heruntergeladene Debian-Image niedriger priorisiert als der Download des neusten Kinofilms über einen One-Click-Hoster, unter Benutzung des HTTP-Protokolls? Und wie sieht es mit den meist mehr oder weniger sinnlosen YouTube-Streams aus – oder mit Video-Streams von öffentlich-rechtlichen Fernsehsendern, z.B. über BBCs iPlayer, um einen Vorfall aufzugreifen, der sich im August letzten Jahres ereignet hat?

Der Handel mit Malware…

…an sich ist leider nichts neues. Relativ neu ist jedoch die Art, wie das Urheberrecht auf Malware durchgesetzt werden soll. Symantec hat sich den Lizenzvertrag des Malware-Pakets `Zeus` aus Russland genauer angesehen. Viel lesenswerter als die Bedingungen an sich…

Der Käufer:

1. Hat kein Recht, das Produkt zu Zwecken zu verteilen, die nicht mit dem Kauf des Produktes in Zusammenhang stehen.
2. Darf den Bot-Builder [Teil der Malware] weder disassemblieren noch dessen Binärcode analysieren.
3. Darf das Control-Panel [Teil der Malware] nicht zur Kontrolle anderer Botnetze oder zu anderen Zwecken benutzen.
4. Hat kein Recht, Teile des Produkts Anti-Virus-Unternehmen zukommen zu lassen.
5. Stimmt zu, den Verkäufer für jegliche Updates zu bezahlen, sofern es sich dabei nicht um Fehlerkorrekturen handelt.

…ist die Beschreibung, wie die Rechte durchgesetzt werden sollen:

Im Falle einer Verletzung des Lizenzvertrages verliert der Kunde sämtliche Ansprüche auf technischen Support. Ausserdem wird der Binärcode des erstellten Bots sofort an Anti-Virus-Unternehmen geschickt.

…womit sich natürlich die Frage stellt, ob die Mitarbeit der Anti-Virus-Unternehmen nun gewünscht sei. Zum Einen wird damit gedroht, die Malware im Falle von Lizenzverletzungen einem dieser Unternehmen zukommen zu lassen, andererseits wird dies ausdrücklich untersagt. Es mag ja schon schwer sein, seine Urheberrchte auf vollkommen legale Produkte durchzusetzen – wie mag es dann in der selbsternannten `Szene` aussehen, wo jeder versucht, sich selbst auf Kosten anderer zu bereichern? Je nach Standpunkt düster, denn die Drohung hat offenbar nicht verhindern können, dass `Zeus` einige Zeit nach dem Erscheinen in diversen `Szene`-Boards getauscht wird.

`Im Löschrausch`…

…ist wohl eine passende Bezeichnung für das gegenwärtige Verhalten von RapidShare.com. Nachdem die Tatsache, dass man fremde Unternehmen Dateien direkt löschen liess, schon Wirkung zeigte, wurde nun auch RapidShare-eigener Content – genauer gesagt: der RapidGames-Mirror von `Frets on Fire` – gelöscht.

`Diese Datei darf nicht verteilt werden.` – warum sie dann auf RapidGames verlinkt ist, ist genauso fraglich wie die Auffassung, dass ein GPL-lizenziertes Spiel nicht verteilt werden dürfe…

Von `ProMedia` und einem `Versehen`…

…spricht man, wenn ein etwas fülliger Chefermittler der ProMedia GmbH freie, Creative-Commons-lizenzierte Musik von RapidShare löscht. Ein knappes Duzend Tage ist’s her, als ich mir ein solches Szenario rein theoretisch konstruiert habe, als aufgrund einer Computer-Bild-Reportage weithin bekannt wurde, dass ProMedia-Mitarbeiter Dateien bei RS.com direkt löschen können. Nun ist der GAU tatsächlich eingetreten, das Album «Das Kreft» des Netlabels Zellophon, das CC-lizenziert ist und von den Urhebern selbst bei RS.com eingestellt wurde, «[...] wurde im auftrag der proMedia GmbH (luengen@antipiracy.de) gelöscht. Um die genaue Begründung zu erfahren bitten wir sie diese zu Kontaktieren.», wie RapidShare sagt. Eine Nachfrage bei der ProMedia GmbH brachte nebst einer `Entschuldigung` die Ursache zutage – der «[...] Link wurde auf dem Gulli-Board mit vielen anderen urheberrechtlich geschützten Dateien (NOFX-Alben) gefunden und ist aus versehen mitgelöscht worden.» – wir hoffen doch alle, dass sich solcherlei Vorfälle nicht wiederholen, ansonsten könnten gewisse Personen auf unangenehme Gedanken kommen, etwa, dass sich die Mainstream-Labels von den Netlabels ins Abseits gerängt fühlen…

RapidShare: ProMedia mit Löschrechten?

Eine ansonsten eher als minderwertig betrachtete Computerzeitschrift – ComputerBild – hat vor kurzem einen interessanten Video-Bericht über die Tätigkeit der allseits geliebten Musik-Piratererie-`Detektiven` ProMedia veröffentlicht. Interessant nicht vom eigentlichen Inhalt her (es ist der gefühlte zweiundvierzigste Bericht zu dieser Thematik) sondern, weil – wenn auch nur kurz – ein anscheinend internes Formular von RapidShare gezeigt wird, mit dessen Hilfe die ProMedia-Mitarbeiter gehostete Dateien direkt löschen können.

Sollte sich dies nicht in naher Zukunft als filmtechnische Fälschung herausstellen, wird die RapidShare AG wohl keine Freude haben, dass die ProMedia dies Formular dem ComputerBild-Filmteam und somit der Öffentlichkeit vorgeführt hat, zumal die Zuverlässigkeit von RapidShare im legalen Filehosting-Bereich durch die Tatsache, dass fremde Unternehmen ohne Kontrollen oder Nachfragen beliebige Dateien löschen können, nicht erhöht wird. Wenn der Abusedesk von RS.com auf `Anfrage` beliebige Dateien löscht, ist dies eine Sache. Löschrechte an Dritte zu vergeben, noch dazu an private Unternehmen, die unter anderem für den Missbrauch der Staatsanwaltschaften bekannt sind, ist ein anderes Paar Schuhe…

Auch 3dl.am…

…ist seit kurzem tot. Aktuell wird auf jede Anfrage mit einem Redirect auf ein UseNeXT-Affiliate geantwortet

kugelfisch@ozDeBIan $ telnet 3dl.am 80
Trying 85.17.16.20...
Connected to 3dl.am.
Escape character is '^]'.
GET / HTTP/1.1
Host:3dl.am

HTTP/1.1 302 Found
Date: Fri, 08 Feb 2008 19:59:31 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: PHP/4.3.9
Location: http://www.usenext.de/index.cfm?TD=399938
Content-Length: 0
Connection: close
Content-Type: text/html
Connection closed by foreign host.


…der Grund dafür ist nicht bekannt – auch nicht, ob, ähnlich wie bei der Gulli:Audiobörse, juristische Probleme die Ursache sind. Der frühere Betreiber Admix hat das Projekt nach eigenen Angaben schon vor geraumer Zeit verkauft, gestern sah es ganz danach aus, als ob 3dl.am Opfer eines Defacements geworden wäre – Unbekannte behaupten, im Besitz des PHP-Skripts hinter 3dl.am zu sein, und dies für 50€ verkaufen zu wollen. Auch wird gesagt, dass 3dl.am doch IP-Adressen loggen würde.

ich rate allen user ab 3dl.am jemals wieder zu benutzen, zumal sie DOCH IPs loggen. Wir haben die ganzen Datenbank gebackuped darin auch alle IPs!
das script wird fuer 50 euro festpreis verkauft

Im Topic des IRC-Channels zu 3dl.am (#3 auf irc.seilen.de) steht, dass 3dl.am unbeabsichtigt auf UseNeXT umleitet:

… 3dl.am Weiterleitung ist nur temporär, wir versuchen unser bestes …. Schuld sind Deniz von uploaded.to und sein bester Freund Murat.

Auch die Gerüchte, dass 3dl.am IPs loggen würde, werden dort dementiert:

21:29 <+kugelfisch> Was genau ist mit 3dl.am passiert? Stimmen die Geruechte, dass 3dl.am IPs loggt?
21:29 <+rdy> kugelfisch
21:29 <+rdy> nein.
21:29 <+rdy> 3 loggt nicht.

Update: Anscheinend wurde der DNS-Eintrag für 3dl.am manipuliert. Die Administration kümmert sich bereits um das Problem – währenddessen schafft ein Eintrag in der HOSTS-Datei Abhilfe:

21:51 <~admix> 85.17.170.88 3dl.am
21:51 <~admix> 85.17.170.88 www.3dl.am
21:51 <~admix> in die .hosts

Update 2.0: Die DNS-Einträge wurden wohl tatsächlich unberechtigt geändert. Bei ns1.hq-host.de, laut WHOIS-Informationen der primäre Nameserver von 3dl.am, löst die Domain schon wieder korrekt nach 85.17.170.88 auf.

ozean-osx:~ iFish$ nslookup 3dl.am ns1.hq-host.de
Server:         ns1.hq-host.de
Address:        193.254.185.254#53

Name:   3dl.am
Address: 85.17.170.88

Je nach Provider kann es noch einige Zeit dauern, bis die Einträge im lokalen DNS-Cache aktualisiert werden. Danach sollte alles wieder normal funktionieren.

Update 3.0: Hier gibt es einen interessante Bericht zum Verkauf von 3dl.am.

Update 4.0: Zur Zeit hat 3dl.am hin und wieder anscheinend nur vorübergehende Probleme. Das Malheur soll seinen Ursprung in einem defekten MySQL-Server haben, der mittlerweile zwar wieder repariert ist, die Datenbank hat wohl aber kleinere Schäden davongetragen…

Sie haben das Recht zu schweigen…

…nein, nicht der Angeklagte, sondern die RIAA hat am Wochenende von ihrem Schweigerecht in Form einer leeren Webseite Gebrauch gemacht. Schuld dafür ist eine SQL-Injektions-Lücke, und jemand, der dadurch wohl einige DROP- und/oder UPDATE-Kommandos eingeschleust hat. Mittlerweile ist ein Backup eingespielt, die Inhalte wieder da und die Lücke gefixt – eine XSS-Lücke blieb uns jedoch erhalten, während eine andere im selben Modul gefixt wurde.

Ich frage mich ernsthaft, wie man bei einer so einfach aufgebauten Webseite, bei der ein User nur an 3-4 Stellen überhaupt eigene Daten an den Server schickt, so viel falsch machen kann. Bei der News-Seite könnte man ganz einfach den intval() der Eingabe nehmen, und das Problem wäre gelöst. Jeden String mit mysql_real_escape_string() o.ä. zu behandeln, bevor man ihn in einem Query verwendet, sollte eine Selbstverständlichkeit sein. Ist aber nicht, weder für die RIAA, noch für diverse offizielle Seiten.

Die Löschung der Webseite ist aber nur ansatzweise lustig. Ich hätte aber eher einen subtilen Link auf thepiratebay.org ans Ende jeder Seite gesetzt (oder, auch gut, ein Script, das nach Ablauf einer bestimmten Frist document.location neu setzt und den User so vollautomatisch auf thepiratebay.org weiterleitet), statt die Seite komplett zu löschen…

Update: Wie ich eben festgestellt habe, hat sich die MPAA, das Film-Äquivalent der RIAA, bei der Absicherung ihrer Seiten auch nicht wirklich Mühe gegeben. Wer dieser Seite ein wenig Apostrophen im POST-Feld `rating` zu fressen gibt, sieht, was ich meine. Ich sage sicherheitshalber schon im Voraus `Ich war’s nicht!`…