Erläuterung emule-Verbose-log - Loggi

Transcription

Eine umfangreiche Abhandlung über den Abmahnwahn,
die mit dem ewigen Mythos gründlich aufräumt,
hier würde alles mit rechten Dingen zugehen.
(Beschreibung eMule verbose-log) powered by Loggi-Leaks
Die Log-Dateien des eMule (eine detaillierte Erläuterung)
Seite 2 von 51
Vorwort
Ein Internet-Nutzer schaut an einem Freitag-Nachmittag in seinen Briefkasten, und findet einen Brief von einer
Anwaltskanzlei vor, in dem sinngemäß folgendes zu entnehmen ist:
Abmahnung wegen unerlaubter Verwertung geschützter Werke in sogenannten Tauschbörsen...
... und sich durch Unterzeichnung der beigefügten strafbewehrten Unterlassungserklärung unter Fristsetzung
bis zum (darauffolgender Montag) zu verpflichten ...
Jeder der eine solchen Abmahnbrief zum ersten mal öffnet, dürfte erst einmal in eine Art Schockzustand verfallen.
Wir wollen in der hier vorliegenden Abhandlung ausnahmsweise einmal nicht mit einer Empfehlung beginnen, was
nach dem Erhalt eines solchen Briefes aufgrund der gebotenen kurzen Reaktionsfrist als Erstes zu tun wäre.
Die hier vorliegende umfangreiche und komplexe Abhandlung sieht sich eher als Empfehlung nach dem ersten
Schockzustand, und orientiert sich in erster Linie auch an dem Kreis der P2P-Abgemahnten, die bereits über
grundlegende erste Erfahrungen im Umgang mit dem Internet sowie auch Filesharing-Programmen verfügen.
In dieser Abhandlung werden wir an Hand einer P2P-Client eMule-Version, an Hand zahlreicher Screenshots aus
Abmahn-Dokumenten, aus den praktischen Erfahrungen diverser P2P-Testvorgänge, und an Hand aufwändiger
technischer Recherchen dem aufmerksamen Leser einmal näher bringen, was im Abmahnwahn tatsächlich abläuft.
Wir versuchen hier einmal grundlegend aufzuklären, warum es schon beim Ermittlungsdatensatz einer Abmahnung
in nahezu allen Fällen weder beweisgesichert, noch mit rechten Dingen zugeht. Warum eine spezielle
Aufzeichnungssoftware sich plötzlich als herkömmliches Tauschbörsenprogramm herausstellt. Aus welchen Gründen
die zusammengeflickte Ermittlungsliste einer Loggerbude nur noch mit einem Honigtopf in Einklang zu bringen ist,
und warum eine Aufzeichnungsliste mit über 5200 IP-Adressen nur noch mit Zauberei zu erklären wäre. Und wir
werden dem Leser auch darlegen, dass die ursprünglich vorgesehene Verfolgung von Urheberrechtsverletzungen
in P2P-Netzen mittlerweile zu einem umsatzorientierten Abmahnsystem für Porno-Verbreiter mutiert ist.
Der Leser dieser Abhandlung sollte sich nicht nur auf einige technische Herausforderungen einstellen, sondern auch
auf zahlreiche Abenteuerlichkeiten, die im Abmahnwahnsinn offensichtlich ohne jegliche Skrupel abgezogen werden.
Inhaltsverzeichnis
Seite
Kapitel
3
1.) Einleitung
4
2.) Vorbereitungen / Uhrzeit
5
3.) Aktivierung der eMule Log-Dateien
6
4.) die Standard Log-Datei einer eMule-Mod-Version (eMule.log)
7
5.) die erweiterte Log-Datei einer eMule-Mod-Version (eMule Verbose.log)
8
6.) die Verbose-Log Datei (allgemeine Einträge)
8
7.) die Verbose-Log Datei (allgemeine Einträge / eMule Start und Ende)
9
8.) der Grundsatz einer Abmahnung
10
9.) die Verbose-Log Datei (Download / Quellen-Abfragen)
12
10.) die Verbose-Log Datei (eigene Download-Einträge)
13
11.) die Verbose-Log Datei (eigene Upload-Einträge)
15
12.) die Verbose-Log Datei (Hinweise auf Warteschlangen-Logs)
16
13.) die Verbose-Log Datei (IP-Filter Einträge)
17
14.) der fehlende Userhash (GUID) in der Abmahnung
18
15.) die Verbose-Log Datei (Userhash der Gegenstellen)
20
16.) Upload-Identifikation (verbreitet die Loggerbude den Dateihash ?)
29
17.) der Anscheinsbeweis zum Dateihash (wie ist es abgelaufen ?)
31
18.) der Anscheinsbeweis (die Loggerbude verteilt den Dateihash)
32
19.) die Anti-Leecher-Funktion (eMule-Client gegen Loggerbude)
33
20.) die Anti-Leecher-Funktion (Technik und Verbose-Log-Einträge)
37
21.) die fragwürdigen Loggerlisten (Eindeutige Hinweise auf den Upload)
39
22.) Warum verteilt eine Loggerbude den Dateihash (die technische Analyse)
45
23.) Verteilung über Fake-Namen auf dem Honigtopf (Analyse Porno-Werke)
51
24.) Zusammenfassung und Fazit
51
25.) Schlussbemerkung
Vorwort und Inhalt
>> Seite 3
Einleitung >>
Seite 3 von 51
1.) Einleitung
Um die Log-Dateien (hier vor allem die sog. Verbose.log) des eMule wird in diversen Abmahnwahn-Foren in letzter
Zeit ziemlich viel diskutiert und spekuliert. Leider vermitteln die bisherigen Diskussionen noch immer den Eindruck,
dass die meisten abgemahnten P2P-Nutzer (hier: ed2k/eMule/eDonkey/eKad) nicht die geringste Vorstellung davon
haben, welche Möglichkeiten diese Log-Dateien auch in Bezug auf die Überprüfung der eigenen Abmahnung haben.
Die folgende Abhandlung soll nun dazu beitragen, etwas Licht hinter das Geheimnis "Verbose-Log" zu bringen. Der
eine oder andere Abgemahnte wird beim Vergleich mit dem Inhalt seiner Log-Dateien vielleicht sogar noch
feststellen, dass er schon beim Ermittlungsdatensatz der Abmahnung schlichtweg angelogen wurde.
Es ist mittlerweile kein Geheimnis mehr, dass die Masse der sog. Loggerbuden bei der angeblich beweissicheren
Aufzeichnung von Urheberrechtsverletzungen über P2P-Netzwerke weder eine spezielle Log-Software einsetzen,
noch irgendwelche beweissicheren Aufzeichnungen bisher vorlegen konnten. Hier muss sogar unterstellt werden,
dass die in den Abmahnungen behauptete Spezialsoftware gar nicht existiert, sondern lediglich aus einer ganz
gewöhnlichen P2P-Clientversion, und einem Datenbankprogramm zum Einlesen und Auswerten der Log-Dateien
besteht. Unter Anwendung dieser Programm-Kombination, für die es übrigens weder irgendwelche Gutachten, noch
irgendwelche Zertifikate zur Beweissicherheit geben kann, werden dann die berüchtigten Loggerlisten konstruiert.
Diese sind dann Grundlage für die Provider-Auskunft, und nachfolgend auch Grundlage für die Abmahnungen.
Einige Abmahner scheinen sich noch nicht einmal sonderlich daran zu stören, dass mit dem Einsatz eines ganz
“gewöhnlichen Filesharing-Clients” bei der Loggerbude, das abzumahnende Werk via Upload auch noch selbst
und kostenlos an unzählige Nutzer verteilt wird. Interessanterweise soll der Abgemahnte für die dann eigentlich
exakt gleiche Handlung zum Schadenersatz gegenüber dem Rechteinhaber herangezogen werden.
Beginnen wir mit einem höchst interessanten Detail in einem Abmahnvorgang.
Bild 1 - Auszüge aus einem Abmahnvorgang der Kanzlei Waldorf/Frommer
Eine wirklich interessante
Kombination in einem
Abmahnvorgang.
So richtig einig darüber,
mit "was" denn nun
eigentlich tatsächlich
aufgezeichnet wird,
scheint man sich auch
zwischen der Loggerbude
und dem Abmahner
nicht zu sein.
Im folgenden Verlauf werden wir jetzt einmal eine eMule-Mod-Version zu einem Ermittlungssystem umfunktionieren,
um ein klein wenig mehr Licht z.B. auch in diese o.g. "interessante Kombination im Abmahnvorgang" zu bringen.
In der folgenden Beschreibung soll also zumindest im Ansatz versucht werden, welche technischen Möglichkeiten
die Log-Dateien des eMule-Clients bieten, und was darin so alles recherchiert werden kann.
Damit lassen sich nämlich nicht nur die “technischen Angaben” in der Abmahnung überprüfen, sondern im
besonderen Falle auch feststellen, ob die vom Abmahner beauftragte Loggerbude das abgemahnte Werk bzw.
den Dateihash (sofern er überhaupt angegeben wurde) sogar noch selber verteilt hat.
Bevor wir über diese Dateien herfallen, sofern diese evtl. schon vorhanden sind, gilt es allerdings noch Einiges
bei der Uhrzeit des Clients zu beachten. Dazu weiter im nächsten Kapitel.
>> Seite 4
Einleitung
Uhrzeit >>
Seite 4 von 51
2.) Vorbereitungen / Uhrzeit
Dieser Punkt richtet sich vor allem an jene eMule-Nutzer, bei denen die beiden Log-Dateien bereits vorhanden sind.
Der Grund ist nämlich folgender. Die internen Uhren im Client gehen meist alles Andere als richtig. Im Gegenzug
behaupten die Abmahner bzw. deren Loggerbuden permanent in ellenlangen Textbaustein-Belehrungen, dass ihre
Super-HighTech Aufzeichnungs-Server grundsätzlich mit einer Atomuhr synchronisiert werden. Das mag zwar vom
technischen Grundsatz her korrekt sein, trotzdem ist diese Art der Darstellung in den Abmahnungen einfach nur
textfüllender Schwachsinn, der den Abgemahnten beeindrucken oder gar einschüchtern soll. Jeder Windows-Client
seit der Einführung von Windows2000 besitzt eine solche Möglichkeit der Uhrzeit-Synchronisation.
Sollten wir also bereits im Vorfeld feststellen, dass unsere Uhrzeit im Client ungenau läuft, und zudem noch die
genannten Log-Dateien des eMule auf dem Client bereits vorhanden sind, dann sollten wir uns unbedingt vor dem
Stellen der korrekten Uhrzeit die festgestellte Zeit- bzw. Datums-Abweichung notieren. Wollen wir nämlich die Inhalte
der Log-Datei mit den Datum/Zeitangaben aus der Abmahnung vergleichen, dann müssen wir diese evtl. Abweichung
berücksichtigen. Zum Zeitpunkt als uns die Loggerbude im Netz geloggt hatte, könnte nämlich unsere Uhr im Client
bereits falsch gegangen sein. Diese "falschen" Zeiten finden sich dann natürlich auch in unserer Log-Datei wieder.
Diese Abweichung müssen wir also beim Zeit-Vergleich zwischen vorhandener Log-Datei und der Abmahnung ggf.
berücksichtigen.
Damit zukünftig auch unserer eMule-Client in der Log-Datei immer die exakte Zeit aufzeichnet, stellen wir also erst
einmal sicher, dass die Uhr in unserem Client mit einer Atomuhr synchronisiert wird. Dazu bedarf es keiner
Super-HighTech-Ausrüstung (wie von manchen Loggerbuden regelrecht zelebriert), sondern einfach nur ein paar
Mausklicks in unserem Windows-Client. Das dazu natürlich eine Verbindung ins Internet benötigt wird, die wir ja
auf Grund des eMule-Betriebes ohnehin schon haben, dürfte wohl jedem Nutzer einleuchten.
Also starten wir den internen Zeitgeber-Dienst im Windows. Dieser kommuniziert in regelmäßigen Abständen mit
dem Zeitserver von Microsoft. Dieser wiederum synchronisiert sich mit einer Atomuhr. Die Selbe übrigens, über
die wir in unserer Abmahnung immer mit ellenlangen Textbausteinen aufgeklärt werden.
Als gehen wir im Windows in die Systemsteuerung und öffnen das Menü "Verwaltung" mit Doppelklick.
In Windows-Vista bzw. Windows-7 sind die Bezeichnungen übrigens weitestgehend gleich geblieben.
Danach öffnen wir im Menü "Verwaltung" den Menüpunkt "Dienste".
Bilder 2 bis 4 - Windows-Funktionen und Menüs
Wenn wir jetzt in den Diensten ganz nach unten scrollen, finden wir den sog. "Windows-Zeitgeber".
Wir können diesen Dienst jetzt manuell starten, dann sollten wir diese Aktion aber auch regelmäßig im Abstand von
etwa zwei Wochen wiederholen. Wem das zuviel Mühe bereitet, der kann diesen Dienst auch auf den
automatischen Start umstellen. Dazu muss nur der Dienst mit Doppelklick geöffnet werden, und im Auswahlreiter
"Starttyp:" auf automatisch umgestellt werden.
Bei aktiver Internetverbindung stellt dieser Dienst dann im Hintergrund die Uhr im Client immer auf die exakte
Uhrzeit ein.
Dieser Zeitgeber-Dienst stellt übrigens weder eine Sicherheitslücke dar, noch überträgt der Dienst irgendwelche
Nutzerdaten an Microsoft. Wer darin dennoch ein gewisses Risiko für seine Client-Sicherheit erkennen mag, der
kann den Dienst auch jederzeit manuell starten, und nach der Synchronisation wieder stoppen. Allerdings sollte
man das dann auch regelmäßig tun, damit die interne Uhr im Client nicht wieder vor- oder nachgeht.
>> Seite 5
Uhrzeit
Optionen >>
Seite 5 von 51
3.) Aktivierung der eMule Log-Dateien
Bevor wir jetzt zu den technischen Details der Log-Dateien kommen, ist es zunächst einmal erforderlich, dass die
Log-Funktion im eMule überhaupt aktiviert wurde. Standardmäßig ist diese nach der Erstinstallation leider
ausgeschaltet bzw. deaktiviert. Vom eMule-Nutzer häufig selbst verursacht, weil der entsprechende Hinweis bereits
bei der Erstinstallation einfach übersprungen wurde, oder die entsprechenden Hilfedateien zur Programm-Nutzung
erst gar nicht gelesen wurden.
Bild 5 - die Log-Funktion im Setup/Optionen des eMule
Dieser Hinweis richtet sich vor allem an solche Nutzer,
die grundsätzlich keine FAQ’s lesen, und häufig dazu
neigen das Programm-Setup kaputt zu klicken.
Diese Option aktiviert eine vereinfachte Log-Datei mit
dem Namen “eMule.log”.
Das Aktivieren dieser Option bewirkt das Anlegen
einer zweiten zusätzlichen Log-Datei mit dem
Namen “eMule_Verbose.log”.
Diese einzelnen Optionen bestimmen, welche
Aktivitäten in der “verbose-log” aufgezeichnet werden.
Diese sollten alle aktiviert werden.
Der sog. “Log-Level” sollte auf dem Wert “5” bleiben.
Je nachdem ob eine eMule-Standard Version oder
eMule-Mod-Version eingesetzt wird, kann die
Anzahl der einzelnen Optionen etwas geringer ausfallen.
Nachdem wir die o.g. Optionen aktiviert haben, muss der eMule neu gestartet werden.
Im Installations-Pfad des eMule finden wir jetzt im Unterordner "logs" die beiden neuen Dateien "eMule.log" und
"eMule_Verbose.log". Diese lassen sich übrigens mit einem gewöhnlichen Texteditor öffnen.
Bild 6 - Log-Dateien unterhalb der Größe 1024 kByte
>> Seite 6
Optionen
Standard-Log >>
Seite 6 von 51
Bild 7 - Log-Dateien größer als 1024 kByte vorhanden
Im Bild-7 sehen wir jetzt eine Besonderheit des eMule. Wenn die beiden Log-Dateien die Größe von 1024 kByte
überschreiten, dann werden diese nicht einfach überschrieben oder gelöscht. Statt dessen wird die aktuell offene
Log-Datei mit einem augenblicklichen Datum und Zeitstempel versehen und "gesichert". Im Anschluss daran legt
der eMule sofort eine neue "leere" Log-Datei für den gleichen Typ an, und beschreibt ab sofort nur noch diese.
Das bedeutet, die Log-Dateien ohne Zeitstempel-Zusatz sind immer die aktuell aktiven Dateien, wo momentan
alle Log-Ausgaben gespeichert werden.
Durch diese Besonderheit müssen die Log-Dateien eigentlich nie gelöscht werden. Dann lässt sich selbst nach über
zwei Jahren noch nachvollziehen, ob der Ermittlungsdatensatz in der Abmahnung überhaupt stimmen kann.
Wie bekannt brauchen einige Abmahner vom Logzeitpunkt bis zum Zustellen der Abmahnung teilweise über ein Jahr.
Nach unserer Ansicht liegt das nicht an verspätet ausgelieferten oder verschluderten Provider-Nutzdaten, sondern
ist eine pure dreiste Absicht. Dem Abgemahnten soll jede Möglichkeit genommen werden, nach einem so langen
Zeitraum die technischen Angaben in der Abmahnung überhaupt auf Richtigkeit überprüfen zu können.
4.) die Standard Log-Datei einer eMule-Mod-Version (eMule.log)
In diesem Kapitel sollen einige Standard-Log-Einträge einer eMule-Mod-Xtreme Version erläutert werden.
Die Betonung auf "eMule-Mod" erfolgt deshalb, weil in den Mod-Versionen eine strikte Trennung vorgenommen wird,
in welcher der beiden Log-Dateien genau "was" aufgezeichnet wird. Bei den eMule-Standard-Versionen ist das leider
nicht immer der Fall. Hier werden häufig Log-Einträge, die bei der Mod-Version nur in der Verbose-Log zu finden sind,
in die Standard-Log-Datei geschrieben, und damit mit weniger wichtigen Logs praktisch zusammen gemischt.
Das macht eine genaue Analyse nicht gerade einfacher. Grundsätzlich zeichnen aber beide Versionen die gleichen
Log-Aktivitäten mit gleichen Details auf. Nur eben halt in unterschiedliche Log-Dateien.
Bild 8 - Auszug aus der Standard-Log-Datei
Die Standard-Log-Datei ist eher unspektakulär. Die einzelnen Zeilen sind bereits selbstklärend. Interessant sind
lediglich noch die exakte Bezeichnung der verwendeten eMule-Version, sowie die beiden vorletzten Zeilen.
Die Zeile "Verbindung hergestellt..." zeigt den aktuell verbundenen ed2k-Server an.
Wichtig noch die Zeile "received an IP:". Hier wird die aktuell zugewiesene dynamische IP-Adresse angezeigt,
die unserer Internet-Verbindung vom Provider zugewiesen wurde. Diese ist übrigens sogar noch ein zweites Mal
in der "eMule_Verbose.log" aufgezeichnet. Dieser Eintrag ist schon insofern besonders hilfreich, dass viele
Abgemahnte aus ihrem sog. DSL-Router-Log die zugewiesene IP-Adresse häufig schon nach einem Monat nicht
mehr nachvollziehen können.
In den nachfolgenden ScreenShots zu den Log-Dateien werden wir zur besseren Übersicht am Anfang immer das
Datum wegschneiden, sowie auch mit Absätzen und Zeilenumbrüchen arbeiten. In den Original-Log-Dateien sind
die Zeilen häufig über 100 Zeichen lang, was eine Darstellung hier sehr erschweren würde.
Grundsätzlich folgen alle Log-Zeilen (wie im Bild-8) immer dem gleichen Muster aus "Datum Zeit: Logtext".
>> Seite 7
Standard-Log
Ordnerfreigabe >>
Seite 7 von 51
Bild 9 - Auszug aus der Standard-Log-Datei (Dateifreigaben)
In der Standard-Log-Datei sind zudem noch die Anfragen zu freigegebenen Verzeichnissen zu sehen. Sofern eine
solche Anfrage überhaupt erfolgte. Das gilt übrigens auch für solche Anfragen, die unser eMule-Client z.B. von einer
Loggerbude erhalten würde, und je nach eMule-Setup-Einstellungen zulässt oder abweist.
Interessanterweise können wir eine solche Zurückweisung unseres Clients nicht zeigen, weil wir bisher auch in
unzähligen Feldtests noch nie eine solche Anfrage von einer Gegenstelle erhalten haben. Das überrascht uns schon
insofern, dass in zahlreichen Abmahnungen permanent behauptet wird, die Loggerbude würde diese Abfrage
grundsätzlich durchführen. Wir halten das für eine schlichte Lüge, diese Abfrage wird gar nicht erst durchgeführt.
Der Hauptgrund dürfte wohl darin liegen, dass in einer "gewöhnlichen" eMule-Version dieser Abfragevorgang i.d.R.
nicht automatisiert werden kann, und sich somit auch nicht vollautomatisch in einer Datenbank speichern lässt.
Es gibt zwar die Möglichkeit einer programmtechnischen Umsetzung, diese erfordert aber einen sehr hohen Aufwand.
Die einzige Alternative dazu ist ein Umprogrammieren der eMule-Version. Man "modelt" also den eMule oder ein
vergleichbares P2P-Programm zu einer Log-Software um.
Nach unserer Ansicht gibt es bisher aber gerade mal zwei Loggerbuden (MediaProtector und Logistep), denen man
überhaupt das komplette Umprogrammieren eine P2P-Software zutrauen würde. Der Rest glänzt immer nur mit
irgendwelchen Behauptungen, fehlenden Gutachten, nicht existierenden Gutachtern, und kann auch bezüglich einer
ansatzweise beweissicheren Log-Software auf direkte Anfrage nie etwas Konkretes vorlegen.
5.) die erweiterte Log-Datei einer eMule-Mod-Version (eMule Verbose.log)
Wer als wenig erfahrener eMule-Nutzer die Datei “eMule_Verbose.log” das erste mal mit einem Texteditor öffnet,
wird sicherlich von der Unmenge an kryptischen Einträgen regelrecht erschlagen. Wir werden uns daher in den
folgenden Kapiteln nur mit solchen Log-Einträgen beschäftigen, die einen direkten Bezug auf die technischen
Angaben einer Abmahnung haben könnten. Zudem werden vorrangig relevante Log-Einträge in separaten Kapiteln
“Allgemein”, “Download”, “Upload”, “Userhash/GUID” und "Anti-Leecher" näher betrachtet. Das dürfte auch für
weniger erfahrene Abgemahnte die Recherchen in der eigenen Log-Datei sowie auch der Abmahnung erleichtern.
Bild 10 - Muster-Screenshot einer geöffneten Verbose-Log-Datei
Aus Gründen der besseren Übersichtlichkeit werden in den nächsten Screenshots alle weniger wichtigen Einträge
(also Solche die nicht direkt Bestandteil dieser Abhandlung sind) auch zwischen den Zeilen herrausgelöscht.
Bei überlangen Einträgen wird der “hintere” Teil der Zeile über einen Zeilenumbruch in Tabellenform unter den
ersten Teil der Zeile geschrieben.
>> Seite 8
Ordnerfreigabe
Verbose allgem. >>
Seite 8 von 51
6.) die Verbose-Log Datei (allgemeine Einträge)
Bild 11 - Auszug aus der Verbose-Log-Datei (allgemeine Einträge)
neuer Userhash
eingebundene
Netzwerkkarten
eMule-Client läuft hinter
einem Router im
Heim-Netzwerk
Die dynamisch vergebene IP-Adresse vom Provider
Die hier im Bild-11 gezeigten Einträge erscheinen immer nach einem Neustart des eMule. Besonderes Augenmerk
gilt vor allem dem Eintrag in der zweiten Zeile “Created new RSA keypair”. Hier hat der eMule nämlich beim Start
einen neuen Userhash (auch häufig als “GUID” bezeichnet) erzeugt. Welche Bedeutung das eigentlich hat, wird
in einem weiter hinten folgenden Kapitel "Userhash/GUID" genauer erläutert.
Die Einträge in der Mitte “NAFC: Adapter...” zeigen an, welche aktiven Netzwerk-Karten/Adapter im
eMule-Client erkannt wurden, sofern es mehrere gibt. Diese Einträge sind vor allem dann aufschlussreich, wenn der
verwendete eMule-Client (z.B. bei einem Notebook) über eine WLAN-Karte verfügt. Fehlt der entsprechende Eintrag
für den WLAN-Adapter, dann war dieser zum Zeitpunkt des eMule-Betriebes auch nicht aktiviert. Dieser Punkt ist
immer dann wichtig, wenn man als Abgemahnter mit der Problematik “Nachweis eines gesicherten WLAN’s”
konfrontiert wird. Fehlt der Adapter in der Log-Datei, dann kann es darüber auch kein Filesharing gegeben haben.
In der vorletzten Zeile “NAFC: emule is bound...” kann man an der nachfolgenden IP-Adresse erkennen, ob der
eMule-Client über einen zwischengeschalteten Router mit dem Internet verbunden wurde. Ist diese IP-Adresse
mit der IP in der letzten Zeile identisch, war der Client direkt mit dem Internet (z.B. via DSL-Modem) verbunden.
In der letzten Zeile “NAFC: your public IP...” wird die vom Provider dynamisch vergebene IP-Adresse angezeigt,
die unserem Internet-Anschluss zu diesem Zeitpunkt zugeordnet war. Wie bereits auf Seite-6 im Bild-8 erwähnt,
lässt sich also in der "eMule_Verbose.log" die vom Provider zugewiesene IP-Adresse ein zweites Mal verifizieren.
7.) die Verbose-Log Datei (allgemeine Einträge / eMule Start und Ende)
Bild 12 - Auszug aus der Verbose-Log-Datei (eMule beenden und neu starten)
Netzwerk-Stop
eMule-Ports
Die Einträge hier im Bild-12 zeigen den Übergang von einem Beenden und Neustarten (erkennbar am Datum) in
der Verbose-Log-Datei. Wichtig ist der Zeitstempel-Eintrag “CemuleApp::ExitInstance”. Ab diesem Zeitpunkt wird
nämlich die eMule-Anwendung vom Netzwerk-Protokoll des Clients quasi abgetrennt. Das bedeutet im Detail:
Wenn wir den eMule beenden ist unser Windows-Client immer noch mit der uns zugewiesenen öffentlichen
IP-Adresse im Internet erkennbar. Sendet jetzt eine Loggerbude einfach nur einen sog. Ping an unsere IP-Adresse,
dann sind wir immer noch erreichbar bzw. Online. Sendet jedoch der Logger-Client ein eMule-Datenpaket an unsere
IP-Adresse, dann gibt es auf unserem Client keine aktive Netzwerk-Anwendung mehr, die diese Datenpakete (z.B.
auf den bekannten eMule-Ports 4661, 4662, 4672, usw.) bestätigen würde. Die Datenpakte werden verworfen
und landen im Nirwana. Die Logger-Client erhält dann auch keine entsprechende eMule-Rückantwort mehr.
Diesen Punkt mit dem “Netzwerk-Stop” sollten wir uns also sehr genau einprägen.
Verbose allgem.
>> Seite 9
Abmahnung >>
Seite 9 von 51
8.) der Grundsatz einer Abmahnung
Zunächst einmal müssen wir uns erneut den Grundsatz der Abmahnung betrachten. Wir hätten das abgemahnte
Werk ohne Erlaubnis anderen Nutzern zum Download zur Verfügung gestellt, was zudem mit einem Datentransfer
von unserem Internetanschluss beweissicher festgestellt wurde. In der Abmahnung sieht das dann wie folgt aus.
Bild 13 - Auszug aus einer Waldorf-Abmahnung
Bild 14/15 - Auszug aus einer Waldorf-Abmahnung (technische Angaben)
Zunächst einmal im Bild-14, “Unsere Mandantschaft hat festgestellt,...”. Interessant, die Mandantschaft behauptet
es nicht bloß, Sie hat es schon festgestellt. Damit dürfte dann auch klar sein, die Mandantschaft kann auch ein
ordentliches und nachvollziehbares Beweisstück vorlegen, z.B. in Form eine Probe-Downloads von unserem Client.
Freundlicherweise hat uns der Abmahner vorab schon mal eine Übersicht vom Probe-Download in Form eines
Ermittlungsdatensatzes zur Verfügung gestellt. Wir sollen also an dieser Stelle keine Zweifel mehr hegen, dass
dieser Probe-Download bei der Mandantschaft auch wirklich vorliegt. Was übrigens auch im Bild-13 noch einmal
ausdrücklich (Zudem wurde der Datentransfer über Ihren...) genannt wird.
Bevor wir an dieser Stelle solchen Behauptungen uneingeschränkten Glauben schenken, sollten wir jetzt vielleicht
doch erst mal einen Blick in unsere eMule_Verbose.log Datei werfen.
In der Verbose-Log-Datei werden (wenn alle Optionen aktiviert sind) u.a. auch sämtliche Datentransfers
aufgezeichnet. Das gilt für Quellenanfragen, sowie sämtliche Up/Downloads, ob ein Up/Download überhaupt
erfolgreich ausgeführt wurde, und sogar welche Datenmenge dabei an welchen Nutzer übertragen wurde.
Und das bedeutet natürlich auch, der gerichtsfest getestete Datentransfer aus Bild-13 muss sich in Form von
Log-Einträgen auch in unserer Verbose-Log-Datei befinden. Als Unterstützung hat uns der Abmahner
freundlicherweise auch den exakten Zeitstempel benannt, wo der Log-Eintrag in unserer Log-Datei zu finden wäre.
Und das schauen wir uns jetzt genauer an.
>> Seite 10
Abmahnung
Warteschlange >>
Seite 10 von 51
In den nachfolgenden Screenshots ist natürlich nicht das abgemahnte Werk aus dem Ermittlungsdatensatz
von Seite-9 Bild-15 zu sehen. Es wird jedoch an Hand von zahlreichen Beispielen aus diversen eMule-Tests
gezeigt, welche Log-Einträge für welche Vorgänge (z.B. Up/Download) vorhanden sein müssten.
9.) die Verbose-Log Datei (Download / Quellen-Abfragen)
Zunächst einmal muss folgender Grundsatz klar sein. Wenn wir mit unserem eMule "das Werk" (oder Teile davon)
anderen Nutzern zum Download angeboten haben sollen (so steht es ja eindeutig in der Abmahnung drin), dann
müssen wir natürlich erst einmal das Werk selbst (oder Teile davon) heruntergeladen haben. Die sog. Tauschbörsen
funktionieren ja nur nach einem Geben-Nehmen-Prinzip (steht übrigens so in einem Gutachten drin). Daraus folgt
natürlich auch, was wir nicht heruntergeladen haben, können wir anderen Nutzern auch nicht anbieten. Logisch.
Also schauen wir jetzt, was in der Verbose-Log-Datei passiert, wenn wir ein Werk/Dateihash downloaden wollen.
Bild 16 - eMule-Client (Fenster Dateisuche)
Zunächst einmal müssen wir von dem zu downloadenden Werk den exakten sog. ed2k-DownloadLink kennen,
(der könnte z.B. von einem Filesharing-Portal oder einer sog. esel-Seite stammen) oder wir müssen das Werk
manuell suchen, den “richtigen” Dateihash auswählen, und das Werk zum Download anfordern bzw. starten.
Im Bild-16 sehen wir zum Dateinamen u.a. auch den Dateihash, sowie die Menge der verfügbaren und vollständigen
Gegenstellen von den wir das Werk herunter laden könnten. Zudem sehen wir bei der Suche über den Dateinamen
in der Liste auch bereits das ganze Elend an sog. Fake-Namen. Hier also “den richtigen” Dateihash zu erwischen,
ist mitunter recht schwierig.
Ein wichtiger Punkt an dieser Stelle: Solche Suchaktionen können von keinem Logger-Client aufgezeichnet werden,
und erscheinen auch nicht in unserer Verbose-Log-Datei. Erst wenn wir den Dateinamen zum Download starten, ist
in unserer Log-Datei ein Zeitstempel-Eintrag zu finden, den auch ein Logger-Client aufgezeichnet haben könnte.
Bild 17 - Auszug aus der Verbose-Log-Datei (Download / Server-Anfragen)
[1]
[2]
Ab dem Moment wo wir den Download starten, fragt der eMule zuerst beim verbundenen ed2k-Server nach den
verfügbaren Quellen an, und vermerkt diese Aktion in der Log-Datei. Siehe Punkt [1]. Interessant hier vor allem, in
der Log-Datei erscheint nicht der Dateihash, sondern nur der Name der Datei.
Die entsprechende Rückantwort vom ed2k-Server ist im Punkt [2] zu sehen. Zudem wird jetzt hier die Anzahl der
möglichen Quellen geliefert, von denen wir das Werk herunter laden könnten.
An dieser Stelle werden wir bereits mit dem ersten Problem konfrontiert, wenn wir selbst (quasi als Loggerbude) die
Verbose-Log zu Ermittlungszwecken verwenden wollten. Die Anzahl der verfügbaren Quellen die vom ed2k-Server
geliefert werden, ist praktisch nie auf dem aktuellen Stand und damit eigentlich immer falsch bzw. nicht korrekt.
Das besondere Problem daran ist jedoch, der eMule erhält im Hintergrund (das können wir nicht sehen und auch
nicht in der Log-Datei aufzeichnen lassen) mit dieser Rückantwort vom ed2k-Server zu den 64 Quellen bereits alle
Angaben wie Client-Name, IP-Adresse/Port, Userhash, usw. Und damit baut unser eMule bereits eine detaillierte
Warteschlangen-Anzeige auf. Und sogar noch während dieses Bild-Aufbaus beginnt unser eMule bereits erste
“feindlich” gesinnte IP-Adressen auszufiltern (z.B. gebannte Clients oder eine aktive IP-Filter-Liste), wirft diese im
Hintergrund aus der Warteschlangen-Liste bevor sie überhaupt angezeigt werden, und beginnt sogar schon eine
gezielte Quellenabfrage zu jeder einzelnen IP-Adresse.
Wir bekommen also vorab nur eine “unfertige” Warteschlangen-Anzeige zu sehen, die nur auf Quellen-Daten vom
ed2k-Server basiert, von unserem eMule bereits vorgefiltert wurde, und die sich in Sekundenschnelle erneut wieder
verändern wird. Das sollten wir uns zum Thema "Warteschlangen-Screenshot" unbedingt merken.
>> Seite 11
Warteschlange
Quellenabfrage >>
Seite 11 von 51
Bild 18 - eMule-Client (Warteschlangen-Anzeige)
Im Bild-18 zeigen wir eine Besonderheit. Die farbig markierten Daten werden wir später in keiner Log-Datei finden.
Und hierzu ergibt sich nachfolgend noch ein neues Problem für uns. Ab dem Moment wo unser eMule den Server
kontaktiert (siehe Seite-10 Bild-17), wird auch unser eMule-Client samt unserer IP-Adresse auf dem ed2k-Server
in der sog. Quellen-Indexliste aufgeführt. Genau diese Quellen-Liste haben auch wir zuvor vom Server abgefragt.
Und das bedeutet jetzt für uns: Eine Loggerbude die mit einem “herkömmlichen Filesharing-Client” eine vermeintlich
beweissichere Aufzeichnung durchführt (so laut Abmahnung auf Seite-3 Bild-1) erhält vom Server mit dieser ersten
Warteschlangen-Liste auch unseren Client bzw. IP-Adresse in ihrer Anzeige. Und das obwohl wir zu diesem Zeitpunkt
von dem Werk/Dateihash weder etwas heruntergeladen, noch zur Verfügung gestellt haben.
Diese wichtige Detail sollten wir uns sehr gut einprägen. Es zeigt bereits sehr deutlich, wie von nahezu allen
Abmahnern die Begriffe “Warteschlangen-Anzeige”, “TimeStamp” und “zur Verfügung stellen” in einer Abmahnung
falsch interpretiert und regelrecht auf den Kopf gestellt werden.
Bild 19 - Auszug aus der Verbose-Log-Datei (Quellenabfragen)
[1]
[2]
[3]
[4]
[5]
[6]
Während die Warteschlangen-Liste noch aufbaut, werden bereits im Hintergrund die vom Server gelieferten
IP-Adressen der Quellen von unserem eMule jetzt mit einer erneuten Quellenanfrage "direkt angerufen". Diese Aktion
(siehe Punkt [4]) erfolgt für jede IP-Adresse getrennt. Die braune Markierung "9067602@212.63.206.35" setzt sich
übrigens aus der vom Server zugewiesenen Client-ID und der IP-Adresse des ed2k-Servers zusammen.
Und wir treffen auf ein neues Problem bezüglich der ersten Warteschlangen-Anzeige im Bild-18.
Unter Punkt [3] ist ein Quellenabfrage-Eintrag erkennbar, der sich vom Punkt [4] deutlich unterscheidet. Die braune
Markierung zur Angabe des ed2k-Servers fehlt nämlich. Diese Quellenabfrage stammt vom sog. Kademlia-Teil
(auch kurz einfach "Kad" genannt) des eMule. Dieser läuft im Hintergrund zusätzlich noch mit, basiert auf der sog.
serverlosen P2P-Technik, und ist demzufolge auch nicht auf die Quellenlisten des ed2k-Servers angewiesen.
Und da beginnt das eigentliche nächste Problem in einer Warteschlangen-Liste am Bildschirm erneut.
Die Quellenabfragen des "Kad" verändern die Warteschlangen-Liste permanent wieder. Damit wird ein Screenshot
der Quellenliste direkt vom Bildschirm praktisch völlig sinnlos. In der Verbose-Log hingegen sehen wir dann an den
Punkten [5] und [6] die entsprechenden Rückantworten von den IP-Adressen, die auf unsere direkte Quellenabfrage
auch tatsächlich geantwortet haben.
>> Seite 12
Quellenabfrage
Download >>
Seite 12 von 51
10.) die Verbose-Log Datei (eigene Download-Einträge)
In diesem Abschnitt vervollständigen wir den eigentlichen Download-Vergang in der Verbose-Log-Datei. Und zwar
die Einträge, die belegen dass ein Download überhaupt gestartet wurde, und ggf. auch tatsächlich stattgefunden hat.
Und da gibt es einige mächtig interessante Unterschiede.
Bild 20 - Auszug aus der Verbose-Log-Datei (Download-Session / Start und Ende)
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Im Punkt [7] und [8] sehen wir, wann ein Download von dem Werk überhaupt gestartet wurde. Zwischen den beiden
Einträgen ist auch hier wieder eine deutliche Unterscheidung erkennbar. Unser eMule hat sich nämlich aus der
Quellenabfrage gemerkt, ob die IP-Adresse der Quelle ursprünglich vom einem ed2k-Server, oder vom Kad geliefert
wurde. Das die ersten Quellenabfrage-Sessions via Kad, im Gegensatz zum ed2k-Server mit einem "anderen"
Netzwerk-Protokoll und Port erfolgen (Kad = UDP-4672), soll in dieser Abhandlung nicht näher erläutert werden.
Auf unsere Download-Einträge hat das erst mal keinen Einfluss.
Im Punkt [9] sehen wir dann, wann die Download-Session mit der Gegenstelle (IP-Adresse) endete. Vor allem aber
mit welchem Grund diese geendet hat, wie lange die Session gedauert hat "Length:...", und welche Datenmenge
tatsächlich übertragen wurde "Transferred: ...". Der Eintrag "Payload: ..." ist übrigens nur für das sog. Kreditsystem
nützlich, und kann deutlich größer als die Transfer-Datenmenge sein. Soll hier nicht weiter erläutert werden.
Und natürlich noch der Eintrag "Timeout.". Dieser nennt nämlich hier den Grund, die Gegenstelle hat sich seit der
letzten Übertragung mehr als 100 Sekunden einfach nicht mehr gemeldet. Der eMule betrachtet diese DownloadSession zu der Gegenstelle dann wegen Verbindungsproblemen als gescheitert. Es gibt jedoch noch deutlich mehr
Gründe für das Beenden einer Download-Session. Hier sollen nur noch zwei davon gezeigt werden.
Bild 21 - Auszug aus der Verbose-Log-Datei (Download-Session-Ende)
Dieser Eintrag soll nicht weiter erläutert werden. Er steht für das sog. normale Beenden einer Download-Session,
die durch den eMule selbst gesteuert, und von vielen Faktoren (z.B. Kreditsystem) beeinflusst wird.
Bild 22 - Auszug aus der Verbose-Log-Datei (Download-Session-Ende)
Auf solche Einträge sollten wir besonders achten. Wenn bei einem von der Gegenstelle gesteuerten Abbruch der
Download-Session die Transferdaten-Menge "Transferred:..." bei nur 20 kByte oder darunter liegt, dann erfolgte
dieser Abbruch meist nicht zufällig. Er könnte z.B. auch von einem sog. Honigtopf-Client (erläutern wir später noch)
ganz gezielt erzwungen worden sein.
>> Seite 13
Download
Upload >>
Seite 13 von 51
Bei der Überschrift des folgenden Kapitels werden sich einige Abgemahnte zu Recht fragen, wieso sollen wir unsere
eigenen Upload-Einträge recherchieren, und damit die Behauptung in der Abmahnung “illegaler Upload des Werkes”
dem Abmahner auch noch auf dem Silbertablett bestätigen. Eine durchaus berechtigte Frage. Allerdings, der
Fokus dieser Abhandlung besteht nicht darin dem Abmahner neue Beweise zu liefern, sondern eher darin den
“technischen” Inhalt der Abmahnung selbst in Frage zu stellen. Es geht also in erster Linie darum, stimmt denn das
überhaupt was in der Abmahnung behauptet wird, “es wurde beweissicher festgestellt, dass sie das Werk
im Zeitraum von-bis illegalerweise anderen Nutzern zur Verfügung gestellt haben”. Und in zweiter Linie geht es um
die Frage, wieso wir überhaupt für den illegalen Upload einen Schadenersatz in derartiger Höhe leisten sollen,
wenn die Loggerbude das Werk zuvor (unter anderem auch an uns) selbst verteilt haben könnte. In einem solchen
Fall hätte eine Loggerbude bereits dahingehend mitgewirkt, dass dem Rechteinhaber des Werkes “der Schaden”
überhaupt in dieser Höhe entstanden ist.
Verkürzt dargestellt, “wenn der Rechteinhaber selbst, oder über einen beauftragten Dritten das abzumahnende
Werk über Tauschbörsen selber verteilt hat, ist die in der Abmahnung begründete Forderung nach der Höhe des
Schadenersatzes wohl keinem Gericht mehr zu vermitteln”. Dabei ist noch nicht einmal die Frage gestellt, ob in
diesem Fall das sog. “gewerbliche Ausmaß” in der Abmahnung überhaupt noch greifen würde.
11.) die Verbose-Log Datei (eigene Upload-Einträge)
Bevor wir uns jetzt den Upload-Einträgen widmen (sofern es solche bei uns überhaupt gibt), sollten wir noch einmal
einen Blick auf die Seite-9 Bild-13 und 15 werfen. Dort ist ja eindeutig dargelegt, dass mit einem Testdatentransfer
(der sog. Probe-Download) eindeutig festgestellt wurde, wir hätten das Werk im Zeitraum von-bis angeboten. Das
bedeutet natürlich auch, in unserer Verbose-Log muss es also einen Upload-Eintrag geben, der mit dem Zeitstempel
des genannten Ermittlungsdatensatzes (Seite-9 Bild-15) übereinstimmt.
Voraussetzung dieser Recherche ist natürlich, dass neben dem Logger-Client auch in unserem P2P-Client die Uhr
sekundengenau gestellt ist.
An dieser Stelle möchten wir noch einmal das Kapitel-2 (Uhrzeit des Clients) in Erinnerung rufen, und warum es
so wichtig ist, dass vor den Recherchen die Uhr des Clients sekundengenau gestellt sein sollte.
Bild 23 - Auszug aus der Verbose-Log-Datei (Upload-Einträge)
[1]
[2]
[3]
Bevor eine Upload-Session beginnt, prüft unser eMule im Hintergrund erst einmal ab, ob die in Frage kommende
Gegenstelle die von uns bereitgestellten Teile des Werkes überhaupt noch benötigt. Dazu wird erst einmal eine
sog. Quellenabfrage wie im Punkt [1] direkt in die Gegenstelle geschickt. Der Unterschied zur Quellenabfrage im
Kapitel Download (Seite-11 Bild-19), wo der eMule anfragt “welche Teile hast du vom Werk”, besteht jetzt nur darin,
dass unser eMule beim Upload anfragt, “welche Teile benötigst du vom Werk”. Falls die Gegenstelle tatsächlich
noch Teile von dem Werk benötigt, wird sie im Punkt [2] jetzt auf unsere Upload-Liste gesetzt, und auf dem Status
verbunden “Connected/...” gehalten. Ganz wichtig, damit hat der eigentliche Upload noch nicht begonnen !!
In einem aktiven eMule sieht das dann so aus wie im nachfolgenden Bild-24.
Bild 24 - Screenshot eMule (Warteschlange der Gegenstellen)
Connected/...
Erst mit der Bestätigung von der Gegenstelle wie im Punkt [3], dass diese zum Datenempfang bereit ist, setzt unser
eigentlicher Upload an die entsprechende IP-Adresse ein. Erkennbar wird das auch am Eintrag “Uploading/...”.
Im Bild-25 ist bei einem aktiven eMule dann der Eintrag “Übertrage” (leider hier nur verkürzt) sichtbar.
Bild 25 - Screenshot eMule (Übertragung zur Gegenstelle / Upload)
Übertrage
Und jetzt sollten wir einmal nachschauen, ob der im Punkt [3] gezeigte Zeitstempel in unserer Verbose-Log-Datei
mit dem Start-Zeitstempel aus unserem Ermittlungsdatensatz (wie auf Seite-9 Bild-15) übereinstimmt.
Auch wenn beide Uhren (unser Client und der Logger-Client) sekundengenau gestellt sind, kann es hier aufgrund
von Laufzeitverzögerungen (also bis die Kommandos in beiden Clients abgearbeitet sind) immer zu einem geringen
Unterschied (zwischen unserer Verbose-Log und dem Ermittlungsdatensatz) bei den Zeitstempeln
von 1-2 Sekunden kommen. Mehr sollte es allerdings nicht sein.
>> Seite 14
Upload
Upload >>
Seite 14 von 51
Im nächsten Bild-26 vervollständigen wir den Upload-Vorgang in der Verbose-Log-Datei, und zwar das Upload-Ende.
Auch hier gibt es wieder, wie schon bei den Download-Vorgängen, alle möglichen Varianten wie der Upload zur
Gegenstelle (z.B. aufgrund eines Verbindungsabbruchs) beendet wurde. Wir erläutern hier nur zwei Varianten.
[1]
[2]
[3]
[4]
Im Punkt [4] sehen wir jetzt den Eintrag, wann die Upload-Session zu einer bestimmten IP-Adresse geendet hat.
Die Besonderheit hierbei, es gibt keinen separaten Log dass der Upload beendet wurde. Statt dessen wird die
Gegenstelle gleich aus unserer Upload-Liste entfernt. Hier handelt es sich übrigens um eine “normale” Beendigung
der Upload-Session, die z.B. auch vom eMule-Kreditsystem ausgelöst worden sein kann.
Der Eintrag “Transferred: ...” ist insofern besonders hilfreich, wenn wir den ursprünglichen Upload-Start zu dieser
IP-Adresse in der Verbose-Log zurückverfolgen müssen. Da die Log-Datei ja noch mit Hunderten anderer Einträge
vollgestopft ist, lässt sich so der passende Zeitstempel leichter finden, indem man einfach die Transferzeit vom
Upload-Ende ausgehend zurückberechnet.
Der Eintrag “SessionUp: ...” gibt die Menge der Nutzdaten !! zum Werk an, die wir an die Gegenstelle gesendet
haben. Wichtig ist hierbei auch der Eintrag “Bytes Req blocks: 2”. Er gibt an, dass wir die Nutzdaten zu zwei
kompletten sog. Chunks (ed2k-Datenblöcke mit ca. 9.28 MByte Größe) fehlerfrei zur Gegenstelle übertragen haben.
Bild 27 - Auszug aus der Verbose-Log-Datei (Upload beendet)
Im Bild-27 sehen wir, ähnlich wie das schon bei einer Download-Session (Seite-12 Bild-22) der Fall war, dass die
Beendigung unseres Uploads von der Gegenstelle ausgelöst wurde. Auch dieser Eintrag kann durchaus in
Zusammenhang mit einer Loggersoftware stehen. Vor allem dann, wenn wir unmittelbar vor diesem Zeitstempel
einen zur IP-Adresse passenden “OpCode-Eintrag” in der Log-Datei finden. Dieser OpCode soll jetzt hier allerdings
nicht näher erläutert werden, das würde den Rahmen dieser Abhandlung sprengen.
Der Eintrag “SessionUp: ...” zeigt zwar an, dass eine gewisse Nutzdatenmenge an die Gegenstelle übertragen
wurde, diese aber laut Eintrag "Byte Req blocks: 0" nicht ausgereicht hat, bei der Gegenstelle einen kompletten
fehlenden Chunk fertigzustellen.
Und jetzt sollten wir erneut nachschauen, ob der im Punkt [4] gezeigte Zeitstempel in unserer Verbose-Log-Datei
mit dem Ende-Zeitstempel aus unserem Ermittlungsdatensatz (wie auf Seite-9 Bild-15) übereinstimmt.
Es ist auch durchaus denkbar, dass die Loggerbude im Ermittlungsdatensatz einen Ende-Zeitstempel angegeben
hat, der hier gar nicht zu einer durchgängigen Übertragung (Upload) passt. Im Prinzip ist das jedoch überhaupt kein
Problem. Wir müssen eigentlich nur zu den beiden Zeitstempeln aus dem Ermittlungsdatensatz in unserer Log-Datei
die beiden entsprechenden Upload-Start/Ende Einträge finden, die auch inhaltlich (IP-Adresse, Client-Version, DateiName) übereinstimmen müssen. Sofern ein Dateiname in der Abmahnung überhaupt angegeben wurde.
Die weitere Vorgehensweise, wenn diese Einträge tatsächlich exakt übereinstimmen sollten, beschreiben wir im
Kapitel "Identifikation" noch detailliert.
Finden wir hier gar keine passenden Upload-Einträge, dann stimmt etwas an dem Ermittlungsdatensatz nicht.
Eine weitere Variante wäre natürlich noch, der Abmahner hat uns mit dem Inhalt der Abmahnung schlichtweg
belogen, und überhaupt keinen "gerichtsfesten" Testdatentransfer (Probe-Download) durchgeführt
Dazu weiter auf der nächsten Seite.
>> Seite 15
Upload
Warteschlangen-Log >>
Seite 15 von 51
12.) die Verbose-Log Datei (Hinweise auf Warteschlangen-Logs)
Für den auf der vorhergehenden Seite-12 genannten Fall, dass wir in unserer Verbose-Log keine passenden
Upload-Einträge finden können, sollten wir uns jetzt darauf konzentrieren, dass die Loggerbude tatsächlich gar
keinen Probe-Download beweisgesichert hat, und es sich beim Ermittlungsdatensatz einfach nur um einen simplen
Warteschlangen-Screenshot handelt. In welcher Form dass die Loggerbude umgesetzt hat, ob z.B. eine Log-Datei
einfach von einem eMule-Client (so wie unsere Verbose-Log) eingelesen wurde, oder ob "dort" jemand einfach
die Warteschlangen-Anzeige vom Bildschirm abgetippt hat, kann uns an dieser Stelle völlig egal sein.
Aus der Warteschlangen-Anzeige beim Logger-Client lässt sich nämlich von einer angezeigten Gegenstelle weder
ein Upload, noch ein Download des Werkes beweissicher ableiten. Die Warteschlange zeigt lediglich an, dass unter
einer bestimmten IP-Adresse das Werk/Dateihash (oder Teile davon) vorhanden ist. Mehr nicht.
Interessanterweise hat aber auch diese Warteschlangen-Anzeige eine gewisse Rückwirkung auf den Logger-Client.
Um nämlich diese Anzeige mit einer "herkömmlichen" eMule/eMule-Mod Version überhaupt aufbauen zu können,
muss das Werk/Dateihash erst einmal zum Download eingestellt werden. Im Anschluss daran erfolgt eine
automatische Quellenabfrage, die sich übrigens auch gezielt für einzelne Gegenstellen (IP-Adressen) manuell
"provozieren", und bei entsprechenden technischen Kenntnissen sogar manipulieren lässt.
Welche Form die Loggerbude hier auch durchführt, diese Aktionen bleiben auch den Gegenstellen nicht verborgen.
Bedeutet im Klartext, die Quellenabfragen der Loggerbude sind auch in unserer Verbose-Log zu sehen.
Bild 28 - Auszug aus der Verbose-Log-Datei (Quellenabfragen)
Zum besseren Verständnis sollten wir jetzt noch mal unsere Download-Einträge von Seite-11 Bild-19 betrachten.
Das Bild-28 zeigt eine Quellenabfrage, die unser Client zu einer Gegenstelle sendet, um festzustellen ob dort Teile
von dem Werk vorhanden sind, die wir noch nicht haben. Das Bild-29 zeigt bei Punkt [1] jetzt das genaue Gegenstück
dazu. Eine Quellenabfrage, welche die Gegenstelle jetzt zu uns sendet. Der kleine Unterschied ist an dem
"Kommando" hinter dem Zeitstempel zu erkennen. Beim Kommando (Bild-29) "SXRecv:" steht das "Recv" für den
Begriff (Receive = Empfang). Wir können also in unserer Verbose-Log auch die eingehenden Abfragen feststellen.
An dieser Stelle muss allerdings auch klar sein, dass "unsere" gesendeten Quellenabfragen genauso bei der
Loggerbude gesehen und aufgezeichnet werden können. Auch dass sollten wir stets im Hinterkopf behalten.
Bild 29 - Auszug aus der Verbose-Log-Datei (empfangene Quellenabfragen)
[1]
[2]
[3]
[4]
Im Bild-29 sind zudem zur Übersicht einige Quellenabfragen aufgelistet, die unser eMule-Client am häufigsten von
den Gegenstellen empfängt.
Im Punkt [1] ist eine Quellenabfrage zu sehen, die auf einer Kad-Verbindung basiert.
Im Punkt [2] hingegen ist die Gegenstelle mit einem ed2k-Server verbunden, erkennbar an der braun markierten
Serverkennung.
Im Punkt [3] ist mit der ankommenden Quellenabfrage auch der Eintrag “NoNeededParts” (keine benötigten Teile)
sichtbar. Das bedeutet, bei der Gegenstelle liegen keine Teile (Chunks bzw. Parts) von dem Werk vor, die wir noch
benötigen würden. Unser eMule wird also im Moment bei dieser Gegenstelle keinen Download mehr versuchen.
Im Punkt [4] sind zwei besonders seltene Einträge zu sehen, die es in dieser Kombination aus P2P-technischer
Sicht beim eMule gar nicht geben dürfte. Die Gegenstelle hat von uns einen Teil des Werkes/Dateihash zum
Download (wir sollen also Uploaden) angefordert, den wir selbst noch gar nicht herunter geladen haben. Was wir
selbst nicht haben, können wir anderen Nutzern natürlich auch nicht zum Download anbieten. Der eMule fragt ja
regelmäßig (ca. aller 20 Minuten) sämtliche Gegenstellen nach vorhanden Teilen von dem Werk ab, damit eben
genau solche o.g. Fehler nicht passieren.
Mehrere eMule-Tests in der Vergangenheit haben allerdings gezeigt, dass solche Einträge fast immer von sog.
bösartigen Clients ausgehen, wo die gesendeten Quellenabfragen ganz gezielt manipuliert werden.
Das sind meistens die sog. Leecher-Mods, und interessanterweise auch einige Versionen von P2P-Clients, die
ganz gezielt zu einer Loggersoftware “umprogrammiert” wurden.
Interessanterweise trifft das übrigens auch auf den im Punkt [4] angezeigten P2P-Client "Shareaza" zu.
>> Seite 16
Warteschlangen-Log
IP-Filter >>
Seite 16 von 51
Die von der Loggerbude Logistep selbst gebastelte Loggersoftware "File Sharing Monitor" (zumindest der sog.
P2P-Teil) basiert z.B. auf einem modifizierten Shareaza-Client.
Allerdings trifft das auf die hier angezeigte (Seite-15 Bild-29) IP-Adresse ganz sicher nicht zu. Zumindest nicht auf
eine Loggerbude in Deutschland, denn die IP-Adresse "93.87.35.58" führt zu einem Serverplatz in Serbien.
Dieses eben genannte Beispiel zeigt auf, dass ggf. bei solchen fragwürdigen Einträgen in der Verbose-Log auch
die IP-Adresse der Gegenstelle überprüft werden sollte, bzw. wo diese IP-Adresse hinführt.
Es ist also durchaus sinnvoll den Ermittlungsdatensatz (Seite-9 Bild-15) dahingehend mit unserer Verbose-Log-Datei
zu vergleichen, ob die angeblich beweisgesicherten Zeitstempel lediglich einen sog. Warteschlangen-Screenshot
repräsentieren. Das würde in Folge natürlich auch bedeuten, der in der Abmahnung (Seite-9 Bild-13) behauptete
gerichtsfeste Datentransfer hat nie statt gefunden. Der angeblich gerichtsfeste Beweis existiert also gar nicht.
Wenn für den o.g. Fall "reiner Warteschlangen-Log" ein eindeutiger Nachweis erbracht werden kann (exakt
übereinstimmende und zusammenpassende Zeitstempel mit dem Ermittlungsdatensatz), dann wird sich an dieser
Stelle ein betroffener Abgemahnter ganz sicher fragen, "wie nun weiter, was ist jetzt zu tun ?".
Die sicher interessante Frage, ob man "damit" jetzt gegen den Abmahner vorgehen sollte, können wir auch nicht
beantworten. Das käme schon fast einer Rechtsberatung gleich. Auf jeden Fall sollte man sich solche Recherchen
sehr gut sichern, und für einen durchaus möglichen Fall einer Filesharing-Klage gut zurecht legen.
Es macht auf jeden Fall auch Sinn, solche o.g. Recherchen mit technisch erfahrenen Abgemahnten in diversen
Anti-Abmahnforen auszutauschen. Das hilft auf jeden Fall, solche wie o.g. dreisten Abmahnlügen aufzudecken
und öffentlich anzuprangern.
13.) die Verbose-Log Datei (IP-Filter Einträge)
In diesem Kapitel werden wir nur kurz die Einträge in der Verbose-Log erwähnen, die mit dem Einsatz des sog.
IP-Filters im eMule entstehen. Das solche Einträge mit einem Zeitstempel aus dem Ermittlungsdatensatz überein
stimmen, halten eher für unwahrscheinlich. Denn der IP-Filter sorgt dafür, dass eine Gegenstelle die über ihre
IP-Adresse hier vom Filter als "böse" identifiziert wurde, gleich auf der sog. Bann-Liste landet. Unser eMule blockiert
dann jegliche Kommunikation mit dieser IP-Adresse, und antwortet auch nicht mehr auf irgendwelche Anfragen.
Die Beispiele im Bild-30 zeigen allerdings auch, dass schon die puren Schnüffel-Versuche einer Loggerbude dem
IP-Filter im eMule nicht verborgen bleiben. Wichtig ist natürlich dabei, dass die entsprechende IP-Filterliste (Bild-31)
immer auf dem aktuellen Stand gehalten wird. Abschließend muss natürlich noch klar sein, auch mit dem IP-Filter
lässt sich nicht alles filtern, und auch nicht jede Loggerbude bei ihrer dubiosen Aktivität erwischen.
Bild 30 - Auszug aus der Verbose-Log-Datei (Einträge IP-Filter)
[1]
[2]
Im Punkt [1] sehen wir eine blockierte Quellenabfrage zum Werk/Dateihash, die uns via Kad-Verbindung erreichte.
Da die IP-Adresse unserer Filterliste bereits bekannt ist, akzeptiert unser eMule diese Anfrage gar nicht erst.
Im Punkt [2] wird die laut Filterliste bekannte IP-Adresse gleich mit aus der Liste der sog. “Kad-Kontakte” geworfen,
die wir zuvor via Kad-Verbindung von einer Gegenstelle erhalten haben. Übrigens, wer sich schon einmal mit dem
Thema “Hadopi” in Frankreich beschäftigt hat, dem dürfte der Name der P2P-Schnüffel-Firma sicher bekannt sein.
Bild 31 - Auszug aus dem eMule IP-Filter (ipfilter.dat)
[1]
[2]
Im Punkt [1] sehen wir eine alt bekannte Loggerbude. Die hatten es tatsächlich fertiggebracht, für ihre Log-Vorgänge
unter der IP-Adresse einen ed2k-Server zu betreiben. Dreister geht’s wirklich nicht mehr.
Im Punkt [2] ist noch ein alter Bekannter aus der Loggerbuden-Szene zu sehen. Auch der hätte mit Loggereien von
dieser IP-Adresse aus, bei unserem eMule hier keine Chance auf ein erfolgreiches Abgreifen von P2P-Daten.
>> Seite 17
IP-Filter
Userhash fehlt>>
Seite 17 von 51
14.) der fehlende Userhash (GUID) in der Abmahnung
In diesem Kapitel soll auf die Problematik "fehlender Userhash" in der Abmahnung eingegangen werden. Dazu
schauen wir erst einmal in ein mittlerweile bekannt gewordenes Gutachten zur Loggersoftware “FileWatch”.
Weitere Details zu diesem Gutachten sind übrigens auch auf der Web-Seite der Loggerbude zu finden. Brisante
Problemfragen bezüglich des Gutachtens werden im Web-Auftritt der Loggerbude natürlich nicht erwähnt.
Hier die entsprechende Web-Seite: http://stop-p2p-piracy.com/site/filewatch-merkmale
Bild 31 - Auszug aus dem FileWatch-Gutachten (Userhash)
Dem sog. Userhash des P2P-Clients, der übrigens nicht mit dem Dateihash des Werkes verwechselt werden sollte,
wird also eine sehr hohe Bedeutung beigemessen. Mal unabhängig der Tatsache, dass die Behauptung im Bild-31
“... über Monate hinweg...” im praktischen eMule-Betrieb völliger Unsinn ist, basiert diese Aussage dennoch auf
einer “gewissen Eindeutigkeit” des Userhashes. Zumindest wenn hier als Bezugszeitraum nur ein Logger-Tag mit
24 Stunden betrachtet wird. Der Userhash im eMule kann zwar in Sekundenschnelle geändert und sogar gefälscht
werden, allerdings werden das in der Praxis sicher die wenigsten eMule-Nutzer innerhalb eines Tages während einer
laufenden Up/Download-Session machen. Es gibt aber durchaus eine Menge Nutzer, die mit jedem Neustart ihres
P2P-Clients, oder mit jeder neu zugeordneten dynamischen IP-Adresse des Internet-Anschlusses, auch den
Userhash neu generieren lassen. Davon machen vor allem sog. Leecher-Mods intensiven Gebrauch.
Bild 32 - eMule-Client (Userhash-Anzeige und Speicherort/Datei)
Im Bild-32 links sehen wir den aktuellen Userhash im Anzeigefenster eines eMule-Clients. Gespeichert ist dieser
übrigens in der Datei “preferences.dat” im Config-Ordner des eMule. Für die Anzeige benötigen wir allerdings einen
Editor/Viewer (Bild-32 rechts) der hexadezimale Werte anzeigen kann.
Obwohl jedoch eben dieser Userhash sogar von einem Gutachten als eindeutig eingestuft wird, und die
Glaubwürdigkeit solcher Gutachten von den Abmahnern sowie auch diversen Gerichten regelrecht zelebriert werden,
fehlt in den sog. Ermittlungsdatensätzen ausgerechnet dieser Userhash in nahezu allen Abmahnungen.
Die interessante Frage ist natürlich, “warum ?”.
Bild 33 - Auszug aus einer Abmahnung von Schulenberg & Schenk
Der hier angegebene Hash
ist der Dateihash zum Werk,
und nicht der Userhash
In dieser Abmahnung (Bild-33) wird schon mal vorsichtshalber nur der Begriff “Hash-Code” verwendet. Das es sich
hierbei nicht um den Userhash handelt, soll sich der Abgemahnte vermutlich auch noch selbst zusammen reimen.
Ganz zu schweigen von der Tatsache, dass die aufgeführte Loggerbude auch noch in der Schweiz residiert, und
es dort ein grundlegendes Gerichtsurteil gegeben hatte, was solche Logger-Aktionen untersagt hatte.
>> Seite 18
Userhash fehlt
Userhash/verbose-log >>
Seite 18 von 51
Der Ermittlungsdatensatz aus der Abmahnung in Bild-34 ist als besonderes Husarenstück einzustufen. Auch hier
fehlt der Userhash. Allerdings stammt dieser Ermittlungsdatensatz ausgerechnet von der Loggerbude, zu deren
Log-Software (FileWatch) im Gutachten (Seite-17 Bild-31) noch die Beweissicherheit des Userhashes besonders
hervorgehoben wurde, und seltsamerweise in einer Abmahnung dann einfach weggelassen wird.
Bild 34 - Auszüge (Seite 1 und 2) aus einer NZGB-Abmahnung
Interessanterweise liegen von der im Bild-34 genannten Loggerbude auch Ermittlungsdatensätze aus einem Antrag
zur Provider-Auskunft (aus Akteneinsicht beim LG Köln) vor, in denen der aufgezeichnete Userhash wiederum
enthalten ist. Das wirft gewisse Fragen auf, wieso dieser in der Abmahnung dann nicht angegeben wird.
Zum gegenwärtigen Stand bei den Filesharing-Abmahnungen (hier speziell eMule/eDonkey) sieht es so aus, dass
der vermeintlich einmalige Userhash (siehe Seite-17 Bild-31) generell nicht angegeben wird. Die Ursache dürfte
wohl darin liegen, dass man sich vor weiteren technischen Recherchen zur vermeintlichen beweissicheren
Spezialsoftware (Logger-Software) fürchtet. Denn ausgerechnet ein generell fehlender Userhash gibt Aufschluss
darüber, ob die Loggerbude überhaupt mit einer speziellen Aufzeichnungssoftware arbeitet, oder eben doch nur
mit einem "regulären Tauschbörsenprogramm" wie auf Seite-3 Bild-1 erwähnt. Unter "generell fehlend" verstehen
wir, wenn der Userhash in der Abmahnung, sowie auch in der Unterlagen aus der Akteneinsicht fehlt.
15.) die Verbose-Log Datei (Userhash der Gegenstellen)
Wer die bisherigen Screenshots zur eMule-Verbose-Log aufmerksam betrachtet hat, der wird feststellen das hier
nirgendwo ein Userhash zu sehen war. Das hat auch seinen Grund. In den eMule-Versionen (auch Mod-Versionen)
ist im "gewöhnlichen" P2P-Datenaustausch die Aufzeichnung des Userhashes in der Log-Datei gar nicht vorgesehen.
Selbstverständlich verarbeitet der eMule im Hintergrund den Userhash einer Gegenstelle, und kann ihn sogar auch
detailliert anzeigen. Allerdings, mit Ausnahme einer bestimmten Konstellation von Verbindungsüberprüfungen, wird
der Userhash i.d.R. nicht in einer beiden Log-Dateien gespeichert. Er wird nur in einer Warteschlange anzeigt.
Bild 35/36 - Auszug aus dem eMule (Anzeige der verbundenen Gegenstelle)
Userhash (GUID)
der Gegenstelle
Wie im Bild-35/36 gezeigt, können wir uns zwar den Userhash der Gegenstellen anzeigen lassen, eine direkte
Möglichkeit diesen in eine Log-Datei "umzulenken" gibt es jedoch nicht.
Um das dennoch umzusetzen bzw. zu erreichen, müsste man schon die eMule-Version gezielt umprogrammieren,
oder eben wie schon oben genannt, mit einer ganz gezielten Verbindungsprüfung provozieren. Allerdings lässt sich
dieser Vorgang nicht so einfach automatisieren, wie es für eine automatisch arbeitende Loggersoftware nun mal
notwendig wäre.
>> Seite 19
Userhash/verbose-log
Userhash/verbose-log>>
Seite 19 von 51
Bild 37 - Auszug aus der Verbose-Log-Datei (Verbindungsprüfungen)
Wie im Bild-37 gezeigt, haben wir es hier mit einer "herkömmlichen" eMule-Mod-Version dennoch geschafft,
den Userhash einer Gegenstelle in die Verbose-Log umzuleiten. Damit wäre es natürlich schon mal grundsätzlich
möglich, auch diese herkömmliche eMule-Version als Loggersoftware zu missbrauchen. Allerdings hat dieser
Versuch auch noch gleich zwei Haken.
Der Erste wäre:
Die im Bild-37 gezeigte Funktion führt der eMule im Hintergrund manchmal auch automatisch aus, aber gezielt für
eine ganz bestimmte Gegenstelle (IP-Adresse) lässt sich das eben nicht so einfach steuern. Dazu sind schon einige
Änderungen oder Manipulationen zusätzlich in bestimmten eMule-Dateien erforderlich, was zudem noch
automatisiert werden müsste. Nur so würde der Einsatz als automatische Loggersoftware zumindest im Ansatz
funktionieren. Da diese Abhandlung sicherlich auch einige Amateur-Loggerbuden lesen könnten, beschreiben wir
hier logischerweise keine technischen Details, wie das o.g. denn nun genau funktioniert.
Der zweite Haken wäre:
Der vom eMule generierte (angeblich einmalige) Userhash (siehe Seite-17 Bild-31) hat mit 32 Stellen Länge leider
exakt die selbe Größe, wie auch der ebenfalls vom eMule verwendete 32-stellige ed2k-Dateihash. Zudem lässt sich
der Userhash auch noch in Sekundenschnelle manipulieren. Versucht man also jetzt die Verbose-Log mit einer
Loggersoftware zu analysieren, um daraus Ermittlungsdatensätze zu generieren, dann könnte das auch beim
vermeintlich einmaligen und beweissicheren Userhash zu einem echten Verwechslungs-Problem werden.
Das nachfolgende Bild zeigt eine solches Problem, worauf wir in einem der zahlreichen eMule-Tests eher
zufällig gestoßen sind.
Bild 38 - Auszug aus der Verbose-Log-Datei (Verbindungsprüfung)
Die hier im Bild-38 gezeigte IP-Adresse (die übrigens aus dem Netz der Deutschen Telekom stammt) ist bei einem
ausgiebigem eMule-Test mehrfach von der sog. Anti-Leecher-Funktion identifiziert worden. Eine Überprüfung des
in der Verbose-Log aufgezeichneten Userhases der Gegenstelle brachte ein recht interessantes Problem hervor.
Bild 39 - ed2k-Hash Überprüfung (ed2k.shortypower.org)
>> Web-Link <<
Die im Bild-38 gezeigte Gegenstelle (IP-Adresse) hatte ganz offensichtlich nicht nur ihren Userhash manipuliert,
sondern als gefälschten Userhash auch noch witzigerweise genau den ed2k-Dateihash (siehe Bild-39) verwendet,
der ausgerechnet auch noch der aktuell zu downloadenden Datei (siehe Bild-39) zugeordnet war.
Wir sind übrigens nicht der Meinung, dass hier die Übereinstimmung zwischen Userhash (Bild-38) und Dateihash
(Bild-39) rein zufällig entstanden ist. Hier war definitiv ein bemerkenswert einfallsreicher Witzbold am Werk.
Fazit zum Userhash:
Eine beweissichere Wiedererkennung des Userhashes über Monate hinweg (wie auf Seite-17 Bild-31) ist schon mal
gleich vorab als technischer Unsinn einzustufen. Allerdings, wie ebenfalls auf Seite-17 unter Bild-31 angemerkt, ist
der Userhash eines eMule über einen Aufzeichnungszeitraum von 24 Stunden (bzw. so lange sich die IP-Adresse
des P2P-Clients nicht ändert) durchaus als Einmalig zu betrachten. Eine gewisse Beweissicherheit ist auch insofern
gegeben, dass z.B. doppelte oder gestohlene Userhashes von der Anti-Leecher-Funktion des eMule i.d.R. recht
schnell erkannt werden. Und die gezielte Manipulation im Bild-38 ist zudem sicherlich kein Masseneffekt.
Es sollte also für eine spezielle Aufzeichnungssoftware kein Problem sein, den Userhash wie auf Seite-18 Bild-35/36
von der Gegenstelle direkt auszulesen, und mit dem durchgeführten Probe-Download auch den Userhash als
zusätzliche Beweissicherung im Ermittlungsdatensatz mit aufzunehmen. Allerdings zeigen auch die bisherigen
Beispiele, dass sich eine "herkömmliche" eMule-Version mit der Analyse der Verbose-Log-Datei, als beweissichere
Aufzeichnungssoftware für den Userhash definitiv nicht eignet. Interessanterweise scheinen jedoch sämtliche
Loggerbuden, wo der Userhash im Ermittlungsdatensatz fehlt, tatsächlich mit einem einfach nur als Spezialsoftware
behaupteten “herkömmlichen" Tauschbörsen-Programm zu arbeiten.
>> Seite 20
Userhash/verbose-log
Identifikation/Abmahnung >>
Seite 20 von 51
16.) Upload-Identifikation (verbreitet die Loggerbude den Dateihash ?)
In den folgenden Kapiteln werden wir diverse Analysemöglichkeiten erläutern, ob die Loggerbude das abgemahnte
Werk tatsächlich selbst verteilt, oder sich an der Verteilung beteiligt hat. Neben der Identifikation zwischen dem
Ermittlungsdatensatz und unserer Verbose-Log-Datei gehen wir zudem noch auf weitere Recherchemöglichkeiten
ein, die sich z.B. aus einer Akteneinsicht (IP-Liste) und einer Eidesstattlichen Versicherung der Loggerbude ergeben
können. Das Ergebnis dieser Recherchen könnte durchaus so lauten, "Unter Beachtung technischer Gegebenheiten
kann der Dateihash nur noch von der Loggerbude, oder einem beauftragten Dritten in Umlauf gebracht worden sein".
An dieser Stelle wird auch gleich ein wichtiger Hinweis gegeben. Wir werden hier keine rechtlichen Empfehlungen
oder Handlungsanweisungen abgeben, die sich aus einem solchen o.g. erbrachten Nachweis ergeben würden.
Es ginge also um die Analyse folgender möglicher Ablaufkette:
- Die Loggerbude (oder beauftragter Dritter) verteilt das abzumahnende Werk via Upload selbst.
- Wir laden das Werk (oder Teile davon) u.a. auch von deren P2P-Client herunter.
- Die Loggerbude lädt jetzt das Werk (oder Teile) im Rahmen des sog. Probe-Downloads von unserem P2P-Client.
- Wir Recherchieren das abgemahnte Werk.
- Eine Akteneinsicht präsentiert eine höchst fragwürdige Ermittlungsliste (IP-Adressen-Liste).
- Eine vorliegende Eidesstattliche Versicherung nennt den Dateihash und das Verifizierungsdatum.
Im folgenden Teil der Abhandlung werden wir an Hand von Beispielen zeigen, wie ein solcher Nachweis erbracht
werden kann, der durchaus auch den Rahmen eines sog. Anscheinsbeweises überschreiten könnte.
Die folgende Abhandlung zeigt zudem auch auf, mit welch perfiden Vorgehensweisen vor allem Betroffene von
Porno-Abmahnungen konfrontiert werden. Und das ist leider weder erfunden, noch irgendwo herbei geleitet,
sondern die traurige eiskalte Realität im Filesharing-Abmahnwahnsinn.
Stellen wir uns also einfach vor, wir hätten vor einigen Monaten mit dem eMule eine Filmdatei heruntergeladen.
Der eMule befindet sich noch immer auf unserem Rechner, sämtliche Sicherheitsfunktionen und Log-Optionen waren
auch “damals” zum Download-Zeitpunkt aktiviert. Wir hatten in einem Forum gelesen, dass diese Optionen alle
eingeschaltet werden sollten.
Jetzt wurden wir mit einer Filesharing-Abmahnung konfrontiert. Und ausgerechnet auch noch ein Porno-Werk, was
wir schon vom Titel/Namen her garantiert nicht freiwillig, und auch noch per eMule herunterladen würden.
Bild 40 - Muster eines Ermittlungsdatensatzes aus einer Abmahnung
Nachfolgend rekonstruieren wir die komplette Geschichte aus einer Porno-Abmahnung, wohin die folgenden
Recherchen geführt hatten, und welche verblüffenden Erkenntnisse wir daraus gewonnen haben. Ob der im Bild-40
gezeigte Ermittlungsdatensatz frei erfunden (und daher ungeschwärzt) oder absolut real ist, werden wir an dieser
Stelle nicht erwähnen. Ebenso die erste Vorgehensweise nach einer solchen Abmahnung erwähnen wir hier nicht.
Nachdem sich der erste Schock gelegt hat, erinnern wir uns wieder daran, dass wir vor einigen Monaten versucht
hatten, einen Kinderfilm/Trickfilm via eMule herunter zu laden. Unsere Tochter wollte an einem Samstag mit einigen
Freundinnen ihren Kindergeburtstag nachfeiern. Dazu wollten sie sich auch gemeinsam einen tollenTrickfilm
anschauen. Irgend etwas mit “Barbie und Elfen”, oder so ähnlich. Wir erinnern uns außerdem noch, dass Mama
gedrängelt hatte, lade doch den Film mal mit deinem Computer, dann brauchen wir nicht erst in die Videothek
rennen. Außerdem hast du ja am Mittwoch frei, Papa mach mal. Bis Samstag sollte das kein Problem sein, bei
meinen Lieblingsfilmen aus Bollywood hat das ja bisher auch immer geklappt.
Aber irgendwie funktionierte damals mit dem Herunterladen im eMule etwas nicht. Verdammt, das ist ja schon
mehrere Monate her. Wir können uns nur noch daran erinnern, dass wir den Trickfilm dann doch als DVD in
unserer Videothek ausgeliehen hatten, und zwar am Wochenende. Ein kurzer Blick in den Kalender zeigt zudem
auch, unser arbeitsfreier Tag war an einem Mittwoch den 05.08.2009. An diesem Tag hatten wir zum ersten mal
versucht den Trickfilm für unsere Tochter via eMule zu laden, irgendwann um die Mittagszeit.
Und jetzt lesen wir nochmal unsere Abmahnung, und da steht doch tatsächlich der 5.8.2009. Und das war genau der
arbeitsfreie Mittwoch, wo wir versucht hatten den Trickfilm zu laden. Aber in der Abmahnung steht ein Porno-Film
(oh man, wenn das die Frau zu lesen bekommt). Also den haben wir ganz sicher nicht geladen, aber irgendwie
konnten wir auch den Film nicht laden. Und in den Eigenschaften von dem Dateihash stand auch irgend etwas von
einer Fake-Meldung drin. Mist, wir haben keinen Screenshot davon gemacht. Zumindest waren wir erst mal der
Empfehlung eines guten Freundes gefolgt, wie wir auf eine solche Abmahnung sofort reagieren sollten. Also werden
wir am Wochenende den Laptop schnappen, und mal unseren Freund den Technik-Freak besuchen.
>> Seite 21
Identifikation/Abmahnung
Identifikation/Dateihash >>
Seite 21 von 51
Zum Glück hatten wir den eMule auf unserem Laptop noch nicht gelöscht. Wir sitzen also am Wochenende bei
unserem technikerfahrenen Freund und fangen an zu recherchieren. Zuerst mal im Internet nach dem Trickfilm.
Bild 41 - Der begehrte Trickfilm, als DVD-Rip auf einer P2P-Portal-Seite
BitTorrent-Link !!
Wir werden recht schnell fündig, und stellen aber fest, dass das ein BitTorrent-Link ist. Für unseren verwendeten
eMule völlig nutzlos. Wir erinnern uns jedoch daran, dass wir damals auch nur BT-Links oder DirectDownloads
gefunden hatten. Auf sämtlichen bekannten Esel-Seiten hatten wir definitiv keinen ed2k-Link gefunden. Also hatten
wir den eMule angeworfen, und den Trickfilm über die direkte Suchfunktion sogar gleich gefunden. Immerhin war ja
der o.g. BT-Link auch schon vom März-2009, da sollte im August doch locker auch schon ein eMule-Link zu finden
sein. Wir erinnern uns zudem noch, dass in der Suchliste irgendwie zwei rote Ausrufezeichen bei unserem
Dateinamen “Barbie.present.Elfinchen.German.2009.DVDRiP.XviD-WDE.avi” davor standen, die wir allerdings nicht
für voll genommen haben. Ein schwerer Fehler, wie sich noch herausstellen sollte.
Unser technikerfahrener Freund zeigt uns an einem Musterbeispiel, wie eine solche Fake-Warnung aussieht.
Der genaue Hinweis lässt sich bereits in der Suchfunktion anzeigen, ohne den Download starten zu müssen.
So ähnlich hatte das damals bei unserem Trickfilm auch ausgesehen. Nur hatten wir das leider ignoriert.
Bild 42 - eMule-Suchfunktion (Fake-Warnung)
Bild 43 - eMule-Suchfunktion (Dateieigenschaften)
bei zwei roten Ausrufezeichen
vor dem Dateinamen...
...sollten immer die Dateieigenschaften, sowie auch der
Dateihash überprüft werden (siehe Bild-44).
Wir hatten also einen Download zu einem Dateinamen gestartet, hinter dessen Dateihash sich ein sog. Fake-Name
verborgen hatte. Der Dateihash enthält also ein völlig anderes Filmwerk als der Dateiname angezeigt hatte.
Zunächst überprüfen wir erst einmal den Dateihash, der in der Abmahnung (Seite-20 Bild-40) angegeben war.
Bild 44 - ed2k-Hash ermitteln (ed2k.shortypower.org)
>> Web-Link <<
Hinter dem angegebenen Dateihash in der Abmahnung verbarg sich tatsächlich ein Porno-Werk. Abgesehen von
der ziemlich geringen Quellenverfügbarkeit (da haben wir schon ganz andere Zahlenwerte gesehen), wissen wir
immer noch nicht, was dieser Porno-Film den nun mit unserem Trickfilm gemeinsam hatte. Auch die Suche (Bild-44)
ergab keinen einzigen Hinweis darauf. Also zurück in die Gegenwart, nämlich dieser Abhandlung hier.
>> Seite 22
Identifikation/Dateihash
Identifikation/P2P-Portal >>
Seite 22 von 51
Im nächsten Schritt untersuchen wir also unser komplettes eMule-Verzeichnis auf dem Laptop. Wir finden u.a. auch
die beiden Log-Dateien. Wir öffnen diese mit einem Texteditor, und finden darin auch den Dateinamen von unserem
Download-Versuch “Barbie.present.Elfinchen.German.2009.DVDRiP.XviD-WDE.avi” wieder. Was wir allerdings darin
nicht finden, ist der Dateihash aus der Abmahnung (Seite-20 Bild-40) bzw. der ed2k-Hash-Suche (Seite-21 Bild-44).
Bild 45 - die Log-Dateien im eMule
An dieser Stelle treffen wir bereits auf ein erstes Problem. Der eMule speichert in den beiden o.g. Log-Dateien i.d.R.
für alle Up/Download-Aktionen nur den Dateinamen, und keinen Dateihash dazu. Hinzu kommt noch, dass nur dieser
Dateiname in der Log-Datei abgespeichert wird, den wir zum Download eingestellt hatten. Also der Fake-Name.
Bild 46 - eMule-Optionen (Dateien)
Diese beiden Optionen sind
nach einer Erstinstallation
standardmäßig ausgeschaltet.
Das Bild-46 zeigt, wo unser Problem liegt. Unser eMule hat nirgendwo den kompletten ed2k-Link gespeichert,
den wir zum Download eingestellt hatten. Und da wir diesen Download (er stellte sich ja als Fake-Leiche heraus)
auch noch wieder gelöscht hatten, ist natürlich auch die sog. temporäre Part-Datei gelöscht, aus der wir den Hash
hätten noch ermitteln können.
Sind diese beiden o.g. Optionen nämlich aktiviert, dann speichert der eMule auch den kompletten ed2k-Link in einer
Log-Datei ab. Bei manchen eMule-Versionen auch in einer separaten Datei (downloads.log).
Diese beiden Optionen sollten also immer eingeschaltet sein.
Sollten wir an dieser Stelle dennoch eine eindeutige Verbindung zwischen unserem Trickfilm-Fake-Namen und
dem Dateihash von dem Porno-Werk herstellen können, sollten wir trotzdem jetzt erst einmal das Porno-Werk auf
diversen Esel-Seiten nach einem verfügbaren ed2k-Link absuchen.
Irgendwo muss ja auch die Loggerbude den Dateihash hergenommen haben, um ihn gezielt loggen bzw.
aufzeichnen zu können. Herbeizaubern lässt sich “Der” nämlich nicht, höchstens selbst erstellen (First-Releaser).
Bevor wir jetzt mit der intensiven Suche über das Internet herfallen, sollten wir zunächst beachten, dass zwischen
dem Erhalt unserer Abmahnung und dem Log-Zeitpunkt meist etliche Monate vergangen sind. Somit dürfte auch
unser abgemahntes Werk mit dem "richtigen" Dateihash mittlerweile auf mehreren Esel-Seiten zu finden sein.
Bei den evtl. zahlreichen Suchergebnissen müssen wir also dahingehend selektieren, dass wir dem Log-Datum
am nächsten kommen. Hier zählt also der älteste veröffentlichte ed2k-Link mit dem passenden Dateihash dazu.
Das diese Suche mitunter recht zeitaufwändig sein kann, darüber sollten wir uns im Klaren sein.
Bild 47/48 - das älteste eMule-Suchergebnis auf einer P2P-Portal-Seite
Eigenschaften des Download-Links
Dieses Datum ist
besonders wichtig !
Dateityp | Byte-Größe | Datei-Hash
>> Seite 23
Identifikation/P2P-Portal
Identifikation/Gutachten >>
Seite 23 von 51
Auf Seite-22 Bild-47/48 ist es uns nun endlich gelungen, den vom Datum her ältesten ed2k-Link zu finden, der vom
Namen des Filmwerkes sowie auch vom Dateihash überhaupt zu unserer Abmahnung passen könnte.
Einen älteren ed2k-Link haben wir nirgendwo gefunden. Und dieser recherchierte ed2k-Link wurde aber erst am
08.08.2009 veröffentlicht. Und das ist bereits besonders interessant, denn laut unserer Abmahnung wurden wir
bereits am 05.08.2009 mit diesem Dateihash geloggt. Also schon drei Tage bevor dieser ja bekanntlich einmalige
Dateihash (so wird es permanent von den Abmahnern behauptet) von einem First-Releaser veröffentlicht wurde.
An dieser Stelle müssen wir uns über folgendes im Klaren sein. In durchweg allen bekannten Vorfällen zu
Filesharing-Abmahnungen, und auch Klage-Vorfällen, wird permanent behauptet, dass vor dem Beginn einer
beweissicheren Aufzeichnung (Log-Vorgang) der Dateihash heruntergeladen, und mit dem Original-Filmwerk
verifiziert wird. Das wird häufig sogar noch mit einer Eidesstattlichen Versicherung bestätigt.
Und genau hier drängt sich zu unserem Ermittlungsdatensatz in der Abmahnung die brisante Frage auf, woher
hatte die Loggerbude in diesem Fall den Dateihash ? Von einer Esel-Seite konnte der nicht stammen, die haben
wir alle abgesucht. Aus einer direkten Suche im ed2k-Netz ? Sicherlich kaum. Niemand kannte den Dateihash bis
dahin, der erst zum 08.08.2009 von einem First-Releaser bekannt gegeben wurde. Zudem will ja die Loggerbude
diesen Dateihash auch noch vor dem 05.08.2009 zwecks Verifizierung herunter geladen haben. Fragt sich nur
"von wem" überhaupt herunter geladen. Wenn keiner den Hash kannte, gab es bis zu diesem Zeitpunkt auch
kaum Uploader-Quellen im ed2k-Netz, wo man das 700 MByte Große Filmwerk überhaut hätte laden können.
Spätestens jetzt haben wir ein Problem. Hier sorgt nur noch eine Akteneinsicht für die nötige Aufklärung.
Irgend etwas passt hier mit dem geloggten Dateihash des Filmwerkes und dem Veröffentlichungsdatum nicht.
Zudem werden wir jetzt noch unsere eMule-Log-Dateien unter die Lupe nehmen, ob es da nicht irgendwelche
Anhaltspunkte gibt, die zu dem Ermittlungsdatensatz aus unserer Abmahnung passen.
An dieser Stelle kommen wir zu einer interessanten Frage in diesem Kapitel. Hat die Loggerbude das Porno-Werk
selbst veröffentlicht ? Die hintergründige Frage "wer hat die dazu überhaupt legitimiert ?" stellt sich hier gar nicht
mehr. Hier geht es um ein Porno-Werk. Zudem ist es ja durchaus noch denkbar, dass ein Dritter mit dem Upload
beauftragt wurde, und die Loggerbude hier nur Teil eines dreisten Abmahngeschäftes ist. Welche Variante hier auch
immer in Frage kommt, es ist ein ziemlich heftiger Vorwurf. Weiterhin könnten wir diesen Vorwurf ohnehin nicht
hundertprozentig belegen, wir wissen ja letztendlich nicht, wer sich hinter einer festgestellten Uploader-IP-Adresse
verbirgt.
Aber wir können einen ersten Anscheinsbeweis erbringen, wenn der Ermittlungsdatensatz zu eindeutigen Einträgen
in unserer Verbose-Log-Datei passt. Und wir können sogar noch, sofern die Angaben aus der Akteneinsicht auch
noch dazu passen, einen unerschütterlichen Nachweis (wie es immer so schön im Abmahnerjargon formuliert wird)
darüber erbringen. "Aufgrund technisch eindeutiger Gegebenheiten kann dieser Dateihash nur von der Loggerbude,
oder einem ihr wissentlich bekannten dritten Uploader veröffentlicht worden sein"
Beginnen wir also mit der detaillierten Recherche.
Nachfolgend werden die Erläuterungen vorwiegend in Kurzform erfolgen, damit es nicht zu kompliziert wird.
Zudem werden wir hier auch keine umfassende Beschreibung zu den Code-Einträgen in der Verbose-Log-Datei
liefern. Einige davon wurden bereits in der vorhergehenden Kapiteln gezeigt. Wer hier detaillierte Informationen
zum eMule-Quellcode haben möchte, der sei auf die Web-Site der eMule-Entwickler-Gemeinde verwiesen. Hier ist
jede einzelne Funktion nicht nur beschrieben, sondern sogar mit diversen "Problem-Hinweisen" kommentiert.
http://www.koders.com/cpp/fid41F6909636B359CECF5C7E7F1C7055B9B9594B95.aspx?s=rsa
Eine kleine Anmerkung noch:
Der eben genannte Web-Link ist bewusst ausgewählt. Denn ausgerechnet hier findet sich ein Hinweis bei den
Code-Zeilen 981 und 1160, wonach ein Download mit verkürzten Datenblöcken von etwa 10 kByte nicht fehlerfrei
funktioniert. In einer weiteren Modul-Beschreibung (Link hier nicht genannt, das sollen die Loggerbuden mal schön
selbst herausfinden) befindet sich ein Hinweis, dass dieses Problem vorrangig mit der sog. Anti-Leecher-Funktion
in Zusammenhang steht. Und ausgerechnet in einem "beweissicheren ?" Gutachten zur Loggersoftware "FileWatch"
wurde behauptet bzw. festgestellt, dass dieser verkürzte 10 kByte Download fehlerfrei funktionierte. Wohl kaum.
Bild 49 - Auszug aus dem FileWatch-Gutachten (Testdownload)
Abgesehen von der Tatsache, dass der Gutachter sicher kaum schlauer ist als die eMule-Enwickler-Gemeinde,
muss dieser Testdownload von der Gegenstelle überhaupt erst einmal gelingen und durchgeführt werden.
Ein Nachweis dazu aus der realen eMule-Praxis, und nicht aus einer Laborumgebung in der auch noch massiv
geschummelt wurde, fehlt übrigens bis heute. Den Kommentar dazu verkneifen wir uns jetzt hier.
>> Seite 24
Identifikation/Gutachten
Identifikation/Upload >>
Seite 24 von 51
Bild 50 - Auszug aus der Verbose-Log-Datei (öffentliche IP)
Zunächst einmal müssen wir in der Verbose-Log das passende Datum vom Ermittlungsdatensatz (Seite-20 Bild-40)
finden. Danach die öffentliche IP-Adresse, die zum Zeitpunkt des eMule-Betriebes unserem Internetanschluss
zugeordnet war. Auch die Uhrzeit ist wichtig. Denn erst zu diesem Zeitstempel wird unser eMule auf irgendwelche
Datenpakete von anderen P2P-Clients überhaupt erst einmal reagieren. Das der Zeitstempel aus unserem
Ermittlungsdatensatz nicht vor diesem Zeitstempel (max. -2 sek) liegen kann, sollte auch einleuchtend sein.
Hier wird natürlich vorausgesetzt, dass die Uhren in beiden P2P-Clients (also auch von der Loggerbude)
sekundengenau gingen. Hier kann es bei den Zeitstempeln aufgrund von Signallaufzeiten (Latenzzeiten) in beiden
Clients trotzdem noch zu Unterschieden von 1-2 Sekunden kommen. Mehr sollten es jedoch nicht sein.
Im nächsten Schritt suchen wir in der Verbose-Log nach dem Zeitstempel aus dem Ermittlungsdatensatz. Uns wird
ja ein Upload vorgeworfen, den die Loggerbude mit einem Probe-Download beweisgesichert hat. Also muss es in
unserer Log-Datei auch einen Upload-Eintrag geben. Sollten wir an dieser Stelle (Zeitstempel plus/minus
2 Sekunden) lediglich eine Quellenabfrage finden, dann wäre es schon mal denkbar, dass die Loggerbude gar
keinen Probe-Download, sondern lediglich einen sog. Warteschlangen-Screenshot gemacht hat.
[1]
[2]
Im Punkt [1] sind wir fündig geworden. Ein Upload-Eintrag “...to upload list:...” von uns an eine Gegenstelle, wo der
Zeitstempel auch noch exakt zum Ermittlungsdatensatz aus der Abmahnung passt. Allerdings sollten wir auch die
weiteren Angaben (braune Markierung) beachten. Noch einmal zur Erinnerung, dieser Eintrag belegt eine
Verbindung die über einen ed2k-Server zustande gekommen ist. Siehe auch Seite-15 Bild-29. Die IP-Adresse der
Gegenstelle steht hier in der Klammer, der Begriff ‘plugin’ dahinter ist der P2P-Client-Name, und die Angabe
(Shareaza v2.4 ...) ist die Clientversion der Gegenstelle. Diese wird übrigens von unserem eMule an Hand
bestimmter Abfragen im Hintergrund ermittelt. Eine Änderung des Client-Namens kann den eMule nicht austricksen.
Die Angaben (braune Markierung) sind insofern wichtig, wenn wir in der Verbose-Log auch den Zeitstempel finden
wollen, wann der Upload wieder beendet wurde. Hier müssen dann natürlich die IP-Daten und Client-Daten mit dem
ersten Zeitstempel übereinstimmen. Das Upload-Ende ist dann im Punkt [2] zu sehen. Hier sehen wir dann auch
am Eintrag “SessionUp: 1.70 MB” die Upload-Datenmenge die wir gesendet haben, und ob ggf. überhaupt ein
Upload stattgefunden hat. Ganz unten sehen wir am Eintrag “File: ...” den Dateinamen, der in unserem eMule dem
Dateihash zugeordnet wurde. Wir können also auch hier nicht erkennen, dass es sich um einen Fake handelt.
Allerdings wird exakt dieser Dateiname auch so an die Gegenstelle gesendet, und müsste natürlich dann auch
genauso in einem Ermittlungsdatensatz stehen. Wenn das nämlich nicht der Fall ist, dann ist an dem Log-Vorgang
bei der Loggerbude bereits irgend etwas faul. Das sollten wir uns einprägen.
Zudem wäre es auch denkbar, dass im Ermittlungsdatensatz der Zeitstempel unter Punkt [2] genannt wird. Wir
wissen ja nicht genau, “wie” nun die Loggerbude genau “was” hier überhaupt geloggt hatte. Dann müssen wir die
o.g. Suche natürlich rückwärts durchführen. Also zum “Removing client from upload...” bei Punkt [2] dann den dazu
passenden Upload-Start bei Punkt [1] finden. Bei Punkt [2] Eintrag “Transferred: 5:22 Mins” steht die Zeitdauer, wo
dann rückwärts gerechnet der Startpunkt zu finden sein müsste.
Interessant ist übrigens im Punkt [2] auch die Art der Upload-Beendigung. Der Eintrag “Remote client cancelled”
bedeutet nämlich, dass der Abbruch von der Gegenstelle ausgelöst wurde. Hierzu sollte auch noch einmal der
Hinweis zum sog. “OpCode” aus Seite-14 Bild-27 beachtet werden.
Wenn wir jetzt in einem Klageverfahren unseren Vortrag an dieser Stelle beginnen würden, dann würden sich der
Abmahner und die Loggerbude wie die Aasgeier nur auf diesen einen Punkt “Upload” stürzen. Die restlichen
Nachweise, dass die Loggerbude das Werk selbst verteilt hat, interessiert dann leider nicht mal mehr einen Richter.
Das ist leider (noch immer) die traurige Realität an deutschen Amtsgerichten bei sog. Filesharing-Klagen.
Mit diesem Hinweis soll noch einmal der grundsätzliche Kontext dieser Abhandlung klargestellt werden.
Hat die Loggerbude das abgemahnte Werk selbst verteilt ? Mit welchen technischen Mitteln können wir das
nachweisen und evtl. sogar eindeutig belegen. Darauf sollten wir hier beim Lesen immer achten.
>> Seite 25
Identifikation/Upload
Identifikation/Download >>
Seite 25 von 51
Jetzt sollten wir in unserer Verbose-Log einen passenden Download-Eintrag (es kann mehrere Downloads von
der gleichen Gegenstelle/IP-Adresse geben) zu unserem Upload finden. Wenn mir Teile des Werkes geuploaded
haben, dann müssen wir logischerweise diese Teile von dem Werk erst mal selbst herunter geladen haben. Die
Frage lautet allerdings jetzt, von welcher Gegenstelle (IP-Adresse) haben wir zuvor geladen. Und hier liegt das
besondere Augenmerk jetzt bei den Upload-Einträgen auf Seite-24 Bild-51 bei den braun markierten Client-Daten.
Wenn diese Einträge übereinstimmen, haben wir vor dem Upload von selbiger Gegenstelle zuvor herunter geladen.
Bild 52 - Auszug aus der Verbose-Log-Datei (identische Download-Einträge)
[1]
[2]
[3]
Im Bild-52 im Punkt [1] sehen eine Quellenabfrage, die von unserem eMule gesendet “SXSend:”, und von der
Gegenstelle beantwortet wurde “...source response...”. Die Gegenstelle hatte also vor unserem Download Teile von
dem Werk vorrätig. Und es ist ausgerechnet auch noch die selbe Gegenstelle, wie von unserem Upload-Eintrag.
Im Punkt [2] sehen wir den Beginn der Download-Session, die Gegenstelle uploaded also das Werk. Im Punkt [3]
sehen wir das Ende der Download-Session. Interessant auch der Grund des Download-Ende “Timeout. ...”, die
Gegenstelle hatte vor mehr als 100 Sekunden plötzlich einfach nicht mehr geantwortet. Zudem sollten wir alle
festgestellten Zeitstempel im Auge behalten, und zwar für die späteren Daten aus der Akteneinsicht.
Die weiteren Einträge oder Varianten zum Download-Ende wurden bereits auf Seite-12 ab Bild-21 erläutert.
An dieser Stelle stellt sich jetzt erneut die Frage, “haben wir das Werk von einer Loggerbude herunter geladen” ?
Um einen solchen ersten Anscheinsbeweis belegen zu können, müssten wir natürlich jetzt die Down/Upload-Logs
exakt auf typische Inhalte analysieren. Also z.B. die Transfer-Mengen, gibt es nur diese IP-Adresse noch mehrfach
in der Verbose-Log, die Art und Weise der Up/Download-Abbrüche, ... usw. Das wollen wir jetzt hier nicht erläutern.
Damit sollte man sich als Abgemahnter dann ohnehin an einen vertrauten erfahrenen Techniker wenden.
Im weiteren Verlauf sollten wir uns also jetzt auf einen detaillierten Vergleich mit den Angaben aus der Akteneinsicht
konzentrieren. Also vorrangig die geloggten IP-Datensätze, und sofern dann vorliegend, natürlich auch die
Eidesstattliche Versicherung. In den IP-Datensätzen sollte ja unsere Client-IP-Adresse (Seite-24 Bild-50), und
natürlich auch unser gesendeter Werkname (Seite-24 Bild-51 Punkt [2]) zu sehen sein. In der Eidesst.Versicherung
sollte der geloggte Dateiname zu finden sein, der ed2K-Dateihash, und das Datum wann dieser herunter geladen
und verifiziert wurde. Die interessante Frage ist natürlich, wenn die Unterlagen aus der Akteneinsicht dann vorliegen,
passt dass denn überhaupt alles mit unserer Verbose-Log zusammen. Und wenn “JA”, in welcher Form.
Bevor wir jetzt unsere Recherche bis zum Eintreffen der Akteneinsicht beiseite legen, sollten wir allerdings noch die
u.a. auch im Punkt [3] gezeigte IP-Adresse der Gegenstelle mit einer sog. Whois-Abfrage recherchieren, und diese
Daten z.B. in Form von Screenshots sichern. Das kann auf jeden Fall, nur zur Sicherheit, nicht schaden.
Bild 53 - Whois (IP-Adr. aus Verbose-Log) >> Web-Link <<
Der nebenstehende Screenshot (Bild-53) ist schon insofern
interessant, dass es sich hierbei gar nicht um eine sog.
dynamisch vergebene IP-Adresse eines P2P-Nutzers handelt,
sondern um den statischen IP-Bereich eines Kundenservers.
Ob es sich hierbei um eine Loggerbude handelt, oder ob von
diesem Kundenserver illegales Filesharing betrieben wurde,
das werden wir auch mit den Daten aus der Akteneinsicht
nur sehr schwer feststellen können.
Interessanterweise gibt es jedoch aktuell in 2011 den hier
gezeigten Kundenserver nicht mehr. Wir kennen zwar den
tatsächlichen Grund dafür nicht, aber trotzdem sollten wir
solche höchst merkwürdigen IP-Adressen, die zudem noch
in der Verbose-Log aufgefallen sind, natürlich gut aufheben.
Manchmal bringt eben doch der “Teufel Zufall” zu einem
späteren Zeitpunkt unerwartete Erkenntnisse ans Tageslicht.
Diesen Punkt werden wir jetzt aber nicht in sämtlichen
Details erläutern, denn der nebenstehende Screenshot ist
absolut real, und steht im Zusammenhang mit einem
außerordentlich dubiosen Log-Vorgang.
>> Seite 26
Identifikation/Download
Identifikation/Log-Liste >>
Seite 26 von 51
In diesem Teil des Kapitels wenden wir uns jetzt der sog. IP-Liste einer Loggerbude zu. Erstaunlicherweise liegt hier
auch eine Eidesstattliche Versicherung vor, welche zu einer bemerkenswerten Erkenntnis führen wird. Diese
erläutern wir zum Abschluss dieses Kapitels. Zur besseren Übersichtlichkeit werden unter die Loggerlistenauszüge
die jeweils dazu passenden Bildauszüge der vorherigen Seiten darunter gestellt.
Bild 54 - Auszug Akteneinsicht/Loggerliste (Datensatznummer 1-5 der Liste)
[1]
[2]
[4]
[5]
Ermittlungsdatensatz
(Seite-20 Bild-40)
Datum und IP-Adresse
(Seite-24 Bild-50)
Zeitstempel Upload-Eintrag
(Seite-24 Bild-51)
Im Punkt [1] der Loggerliste finden wir den einzigen Datensatz (der übrigens der erste Datensatz auf der Liste ist),
der zu unserem Ermittlungsdatensatz, und auch zu unseren Verbose-Log-Einträgen passt. Und trotzdem gibt's hier
schon mal ein Log-Problem. Den der Dateiname passt nicht zu unserem Upload-Dateinamen. Wie schon in der
Abhandlung erwähnt, verarbeitet der eMule den Dateihash ausschließlich im Hintergrund. Für den Austausch der
sog. Metadaten zwischen den Clients (z.B. bei einer Quellenabfrage o.ä.) sendet und empfängt der eMule auch
grundsätzlich den Dateinamen mit, der auf dem jeweiligen eMule-Client zum Download angefordert wurde. Also
müsste sich im Log-Datensatz unter Punkt [1] eigentlich unser Dateiname "Barbie.present.Elfinchen..." wiederfinden.
Hier ist also etwas faul am Log-Datensatz. Was zudem noch auffällt, dass unser Trickfilm-Dateiname unter Punkt [5]
zu finden ist. Aber dieser Datensatz passt schon nicht zu unserer IP-Adresse. Ebenfalls nicht zu übersehen, der
enorme Datum-Sprung zwischen Punkt [1] und Punkt [2], die weiteren Fake-Namen, und dass zwischen Punkt [4]
und Punkt [5] gleich mal eine Log-Lücke von fast 12 Stunden klafft. Auf der Suche nach einem evtl. Zeitstempel aus
unserem Download (siehe Seite-25 Bild-52) können wir nur noch die chaotische Loggerliste komplett durchsuchen.
[272]
[273]
[274]
[275]
[276]
[277]
[278]
[283]
[284]
Das Chaos bei Datum/Zeitstempeln sowie Fake-Namen zieht sich übrigens durch die gesamte Liste.
Identifikation/Log-Liste
>> Seite 27
Identifikation/Log-Liste >>
Seite 27 von 51
An diesem Punkt können wir immer noch nicht mit Sicherheit feststellen, ob unser Download (siehe Seite-25 Bild-52)
denn nun von einem P2P-Client der Loggerbude erfolgte, oder eben nicht. Wenn das tatsächlich der Fall wäre, dann
dürften wir von der Gegenstelle (Loggerbude ??), von der wir das Werk herunter geladen haben, eigentlich keine
IP-Adresse und auch keinen passenden Zeitstempel in der Loggerliste finden. Die IP-Adresse der Gegenstelle aus
unserem Download-Eintrag war ja, wie wir bereits auf Seite-25 Bild-53 festgestellt haben, keine veränderliche
dynamische IP-Adresse. Und die Loggerbude wird sicherlich kaum die IP-Adresse des eigenen Upload-Clients
auf der Loggerliste stehen lassen, und diese dann auch noch zum Beauskunftungs-Gericht schicken.
Wir müssen also die gesamte Loggerliste nach einem passenden Zeitstempel zu unserem Download-Eintrag
durchsuchen, was bei den hier gezeigten Zeitstempel-Hopsern eine ziemlich nervige Angelegenheit werden könnte.
[98]
[99]
[100]
[102]
[103]
Zeitstempel Download-Eintrag
(Seite-25 Bild-52)
Wir werden tatsächlich bei Punkt [103] in der Loggerliste fündig. Wir finden ein passendes Datum, unser Dateiname
stimmt überein, und der Zeitstempel passt exakt zu einer Quellenabfrage vor unserem Download-Eintrag.
Der Zeitstempel kann aber auch ebenso zu dem folgenden Zeitstempel “Download session started” passen. Denn
wie bereits auf Seite-13 unter Bild-25 erläutert, kann es hier zu Verschiebungen von 1-2 Sekunden kommen. Wieso
das Datum vom 05.08.2009 aber so weit hinten in der Loggerliste steht, dass sollte uns bei den schon vorher
festgestellten wilden Zeitstempel-Hopsern in dieser Liste nun wirklich nicht mehr wundern.
Was bei Punkt [103] allerdings nicht zu unserem Download-Eintrag passt, ist die IP-Adresse auf der Loggerliste.
Wir suchen also weiter die Liste ab, und stoßen zu unserem Erstaunen auf eine bekannte IP-Adresse aus unserer
Verbose-Log. Und zwar auf die IP-Adresse, von der wir das Werk zuvor herunter geladen hatten (Seite-25 Bild-52).
Bild 57 - Auszug Akteneinsicht/Loggerliste (Datensatznummer 270 der Liste)
Wir haben also die IP-Adresse aus unserem Download-Eintrag auch noch auf der Loggerliste (Bild-57) gefunden. Es
ist wohl nicht davon auszugehen, dass die Loggerbude hier versehentlich ihren eigenen Upload-Client aufgezeichnet
hat. Natürlich wäre hier auch die Möglichkeit denkbar, dass es sich bei der IP-Adresse (Bild-57) um einen Dritten
handelt, der mit dem Upload des Dateihashes beauftragt wurde. Diese IP-Adresse landet zwar damit auch bei der
sog. Klarnamen-Beauskunftung, aber man muss der bekannten beauftragten Person ja keine Abmahnung schicken.
An dieser Stelle sind wir also jetzt in eine Sackgasse geraten. Die Zeitstempel zu unseren Up/Download-Einträgen
passen zwar zum Ermittlungsdatensatz, sind sogar auf der Loggerliste eindeutig zu finden, passen aber irgendwie
nicht vollständig zusammen bzw. stimmen nicht hundertprozentig überein. Wir können also nicht mehr mit Sicherheit
sagen, ob wir den Dateihash nun tatsächlich von der Loggerbude herunter geladen haben. Deren Upload also.
Anderseits steht jedoch noch die Tatsache, dass ein Upload von unserem eMule an die IP-Adresse aus Bild-57
erfolgt ist, dieser Zeitstempel exakt in der Loggerliste mit unserer IP-Adresse drin steht, und auch noch mit dem
Ermittlungsdatensatz unserer Abmahnung übereinstimmt. Die Gegenstelle zu der wir geuploaded haben, scheint
also irgendwie doch mit der Loggerbude in Verbindung zu stehen. Unser Problem ist jetzt, wir könnten das nie
eindeutig und nachvollziehbar beweisen. Wir würden jetzt hier definitiv in das Reich der Spekulationen abdriften.
In einem möglichen Klagefall vor Gericht würde uns das kein Richter so abnehmen bzw. glauben.
An diesem Punkt wird jetzt klar, dass es eben doch nicht so einfach ist, nur an Hand von Log-Dateien, Zeitstempeln
und Loggerlisten den Upload der Loggerbude nachzuweisen. Es sprechen zwar alle Fakten eindeutig dafür, aber
letztendlich fehlt uns der entscheidende Nachweis. Wir können die IP-Adresse, von der wir den Dateihash herunter
geladen, und sogar wieder nachweislich geuploaded haben, nicht mit der Loggerbude in Verbindung bringen. Aber
wir haben es wenigstens versucht, und haben eine Menge über die chaotischen Loggerlisten gelernt. Aufgeben
sollten wir aber trotzdem nicht, es gilt nämlich noch weitere Nachweismöglichkeiten zu untersuchen.
>> Seite 28
Identifikation/Log-Liste
Identifikation/EidesStatt >>
Seite 28 von 51
Zuerst einmal schauen wir uns die Eidesstattliche Versicherung (im Weiteren nur noch "Eides-Vers." genannt) der
Loggerbude an, wann der Dateihash mit dem Originalwerk verifiziert wurde, und in welcher Form das erfolgte.
Vor allem die Datumsangaben sind hier entscheidend.
Bild 58 - Auszug Akteneinsicht (Eidesstattliche Versicherung)
Das Bild-58 (die Eides-Vers.) müssen wir sicherlich nicht ausgiebig kommentieren. Es dürfte wohl klar sein, wenn
man das hinter dem Dateihash verborgene Filmwerk am 10.06.2009 mit dem Originalwerk verglichen hat, dann
musste man den Hash natürlich schon vor diesem Datum gekannt haben. Immerhin muss man ja das komplette
Werk bzw. den Dateihash noch herunterladen, um es überhaupt mit dem Originalwerk vergleichen zu können.
Bevor wir jetzt eine neue Nachweis-Strategie aufbauen, sollten wir vorher noch die komplette Loggerliste auf
markante Probleme analysieren. Welcher Datum/Zeitstempel ist der erste Log-Datensatz auf der Liste, welche
Datensätze liegen noch bis zu unserem Log-Zeitpunkt dazwischen, gibt es unerklärliche Lücken im zeitlichen Ablauf.
Hier sollten wir auch die immer wiederkehrende Behauptung im Blick behalten, “der Aufzeichnungsvorgang erfolgte
gerichtsfest und absolut fehlerfrei”. Die Bilder auf Seite-26 und 27 zeigen aber schon, dass dem offensichtlich nicht
so ist. Bei Einträgen aus der Loggerliste sollte zudem auch die laufende Datensatznummer (also an welcher
Stelle/Seite stand der Eintrag) mit notiert werden. Das erleichtert die spätere Suche in einer endlos langen und
fehlerhaften Loggerliste. Da wir diese Analyse bisher noch nicht gemacht haben, holen wir das jetzt nach und
notieren die wichtigsten Stichpunkte in einer Auflistung. Die vorherigen Recherchen nehmen wir hier ebenfalls mit
auf. Hier sollten wir vor allem Angaben, welche uns in der Ablaufkette nicht logisch erscheinen, auch gleich farblich
markieren. Eine solche tabellarische Auflistung (Ablaufkette) könnte also wie folgt aussehen:
Bild 59 - Musterbeispiel Ablaufkette
1
2
3
4
5
6
10.06.2009
05.08.2009 - 14:25:12
05.08.2009 - 14:25:12
05.08.2009 - 16:01:16
05.08.2009 - 16:01:16
05.08.2009 - 16:01:16
07.08.2009 - 05:31:41
07.08.2009 - 20:26:51
08.08.2009
Eides-Vers. / ed2K-Dateihash verifiziert / > passt nicht zum Esel-Seite Datum
Logliste Nr.103 / erster Zeitstempel / > Beginn des Logvorgangs
Verbose-Log / Quellenabfrage vor Download / > DL ist eine Sekunde später
Logliste Nr.1 / zweiter Zeitstempel / kein weiterer Log am 05.08.2009 in Liste gefunden
Ermittlungs-DS laut Abmahnung / > Dateiname passt nicht zum Upload-Namen
Verbose-Log / Upload-Eintrag / > kein Download mehr, Hash scheint Datei-Leiche zu sein
Logliste Nr.2 / dritter Zeitstempel / > Log-Lücke von 37 Stunden !!
Logliste Nr.5 / > Log-Lücke von 15 Stunden !!
ed2K-Dateihash auf Esel-Seite veröffentlicht / > kein älteres Datum im Netz zu finden
Wenn wir uns jetzt über diese Auflistung intensiv Gedanken machen, kommen wir schon hier zu einem sehr
interessanten Ergebnis. Das Log-Datum vom 05.08.2009 aus unserem Ermittlungsdatensatz gibt es nur zwei mal
auf der kompletten Loggerliste. Danach fehlt schon mal ein kompletter Tag. Auch am 07.08.2009 gibt es nur sehr
wenige Log-Datensätze, und an diesem Tag gibt es schon wieder eine große Lücke im Log-Vorgang.
Das bedeutet schon mal, dass es vom 05.08. bis zum 07.08. zu diesem Dateihash nur sehr wenige Quellen im Netz
gegeben hat. An sich auch logisch, denn der Dateihash wurde ja erst 08.08.2009 offiziell bekannt gemacht.
Und diesen Dateihash will die Loggerbude schon zwei Monate vor dem Log-Zeitpunkt im Netz herunter geladen,
und auch noch verifiziert haben. Also das widerspricht jeglicher Logik, und ist technisch nicht machbar.
>> Seite 29
Identifikation/EidesStatt
Anscheinsbeweis >>
Seite 29 von 51
Jetzt stehen wir natürlich vor der interessanten Frage, wie soll das überhaupt mit der Verifizierung, schon zwei
Monate bevor der Dateihash im Netz bekannt wurde, bei der Loggerbude funktioniert haben.
Zunächst wissen wir aus der Eides-Vers. (Seite-28 Bild-58), dass die Loggerbude das Filmwerk in Originalform auf
DVD vorliegen hat. Allerdings lässt sich das leider nicht so einfach in eine P2P-taugliche Filmdatei “verwandeln”, bei
der dann nicht nur die Dateigröße, sondern auch der Dateihash exakt übereinstimmen müsste.
Eine kurze Erklärung zu dem Problem "P2P-taugliche Filmdatei":
Diese “Verwandlung” wird übrigens im P2P-Bereich als sog. Rip-Vorgang bezeichnet. Dazu wird von der OriginalDVD, außer der Filmdatei selbst, sämtlicher zusätzlicher Ballast weggeschnitten. Nur die Filmdatei wird dann mit
einem speziellen sog. Video-Codec auf ein Höchstmaß zusammengepresst, um die Dateigröße P2P-tauglich zu
machen. Es entsteht also eine Video-Datei, die deutlich kleiner als auf der Original-DVD ist. Wiederholt man diesen
Rip-Vorgang jetzt mehrere Male hintereinander mit exakt dem selben Original-Film, dann wird man feststellen das
die Dateigröße jedes mal geringfügig abweicht. Das liegt daran, dass der o.g. Video-Codec beim Rip-Vorgang
dynamisch arbeitet, und die Kompressionsrate des Videos nicht exakt vorherbestimmt werden kann. Dadurch wird
der Inhalt der Video-Datei bei jedem Rip-Durchgang immer geringfügig “anders” aussehen, was wir allerdings dann
im Video nicht sehen können. Stellt man diese neuen Video-Dateien jetzt nacheinander in den Upload-Ordner eines
eMule, dann erzeugt dieser automatisch einen ed2k-Dateihash, der mit jeder Rip-Version einen anderen Hashwert
anzeigt. Obwohl sich jedesmal um das gleiche Video handelt, weichen sie dennoch geringfügig voneinander ab.
Und genau hier liegt das Problem der Loggerbude bei der Verifizierung des Dateihashes. Würde die Loggerbude
über einen sog. Rip-Vorgang vom Original-Film den ed2K-Dateihash am 10.06.2009 (siehe Seite-28 Bild-58) zum
Verifizieren selbst erzeugen (was durchaus machbar ist), dann würde dieser Hash-Wert nicht mit dem ed2k-Hash
übereinstimmen, den später (siehe Seite-22 Bild-47/48) ein sog. First-Releaser auf einer Esel-Seite veröffentlicht.
Und dieses Detail sollten wir uns sehr genau einprägen.
Zunächst steht jetzt für uns immer noch folgende Frage. Hat die Loggerbude zwecks Verifizierung tatsächlich über
einen Rip-Vorgang vom Original-Werk den ed2k-Dateihash selbst erzeugt, und diesen dann auch noch als sog.
First-Releaser im ed2k-Netz verbreitet ? Also wir können uns das eigentlich in dieser Form nicht vorstellen, und
unsere Antwort lautet erst mal “Nein”. Erstens wird sich die Loggerbude kaum die Mühe machen, über einen
aufwändigen stundenlangen Rip-Vorgang die P2P-taugliche Video-Datei selbst zu erzeugen. Zweitens dürfte die
Loggerbude sicher nicht mit diesem Dateihash als First-Releaser in einer P2P-Portal-Seite aufgetreten sein.
Es muss also noch eine andere Variante geben, die im Endergebnis auch zu unseren bisherigen Recherchen passt.
Denn die wichtigsten Fakten sehen nun einmal wie folgt aus:
1.) Die Loggerbude hat den Dateihash zwei Monate vor dem First-Releaser-Datum bereits verifiziert.
2.) Auf der Loggerliste befinden sich zahlreiche IP-Datensätze zu diesem Dateihash, die bereits 3 Tage vor
dem First-Releaser-Datum aufgezeichnet wurden.
Die entscheidende Frage lautet also, “wie ist die Loggerbude überhaupt an den exakten Dateihash gelangt” ?
Und dieser Frage gehen wir im folgenden Kapitel nach.
17.) der Anscheinsbeweis zum Dateihash (wie ist es abgelaufen ?)
In diesem Kapitel werden wir eine Indizienkette zu dem Log-Vorgang zusammenstellen, die auch unter Beachtung
aller technischen Voraussetzungen, nur noch als einzige in Frage kommt. Nach unserer Ansicht jedenfalls.
Zunächst müssen wir wieder das Internet stressen, ob das abgemahnte Filmwerk vor dem sog. eMule-Release
(siehe Seite-22 Bild-47) bereits eine “Vorgeschichte” in anderen P2P-Netzen hatte. Es gibt ja noch das sog.
BitTorrent (BT), und natürlich auch die unzähligen Direkt-Download-Portale (DDL). Bei der Suche sollten wir natürlich
auch das Datum 10.06.2009 aus der Eides-Vers. im Auge behalten. Das Werk muss also schon einige Zeit vor
diesem Datum im Netz veröffentlicht worden sein.
Also schauen wir nach.
Bild 60 - Suche des Filmwerkes (alle Portale außer eMule)
Bei der intensiven Suche mussten wir feststellen, dass es vom Datum her keine passenden BitTorrent-Links gibt.
Wohl aber mehrere sog. DirektDownload-Links (DDL). Und der Älteste davon, wo auch gleich noch der Dateiname
aus der Eides-Vers. exakt passt, ist im Bild-60 dargestellt.
>> Seite 30
Anscheinsbeweis
Nachweis Dateihash >>
Seite 30 von 51
Bild 61 - gefundenes Filmwerk (DirektDownload)
[1]
[2]
[3]
[4]
Schauen wir uns die Dateieigenschaften des Download-Links genauer an. Der Dateiname [1] stimmt exakt überein.
Der sog. Rip-Vorgang wurde bereits von einem First-Releaser [2] durchgeführt. Der hierbei verwendete Video-Codec
(Xvid/AVI) stimmt ebenfalls überein [3]. Und die Video-Datei wurde auf eine P2P-taugliche Größe komprimiert [4].
Schauen wir noch einmal in die Loggerliste (Seite-26 Bild-54), dann ist dort die Dateigröße mit 696.7 MByte
angegeben. Das entspricht genau der maximalen Größe von 700 MByte für eine selbst gebrannte CD.
Es handelt sich also bei dem o.g. Direkt-Download ganz offensichtlich um die selbe Video-Datei, die auch für die
Verifizierung laut der Eides-Vers. (Seite-28 Bild-58), sowie auch im Log-Vorgang verwendet wurde. Die Frage die
hier jetzt zu klären wäre, wie die Loggerbude auf den selben Dateihash wie der First-Releaser des ed2k-Links
(Seite-22 Bild-47/48) gekommen ist. Dazu erläutern wir jetzt eine plausible Möglichkeit.
1.) Die Loggerbude hat im Frühjahr-2009 die Video-Datei von einem Direkt-Download-Portal komplett herunter
geladen. In der Eides-Vers. ist interessanterweise nur das Datum der Verifizierung (10.06.2009) genannt. Wann
genau das Werk herunter geladen wurde, und vor allem "von wo", wird in der Eides-Vers. nicht genannt.
2.) Die herunter geladene Video-Datei wurde nach der Sichtung und Verifizierung in den Upload/Shared-Ordner
eines P2P-Clients verschoben. Das kann genauso gut eine Log-Software sein, die mit dem ed2k-Protokoll
(eMule & Co) zurecht kommt. Bei diesem Vorgang wird automatisch ein einmaliger ed2k-Dateihash generiert,
der übrigens vom Inhalt der Video-Datei berechnet wird. Würden wir jetzt diese Video-Datei ebenfalls aus einem
DDL-Portal herunter laden und unverändert in den Upload-Ordner unseres eMule verschieben, dann berechnet
unser eMule exakt den selben Dateihash wie auch bei der Loggerbude. Es spielt also keine Rolle von wo die
Video-Datei zuvor herunter geladen wurde, es muss sich nur um die selbe Video-Datei mit exakt dem gleichen
Inhalt handeln. Dann wird der berechnete ed2k-Hash immer gleich sein. Das sollten wir uns merken.
3.) Am 08.08.2009 hatte ein First-Releaser diese Video-Datei mit dem selben ed2k-Hash veröffentlicht, den die
Loggerbude in der Eides-Vers. bereits zum 10.06.2009 kannte. Dafür gibt es eine ganz einfache Erklärung.
Der First-Releaser von der Esel-Seite hatte die gleiche Video-Datei von einem DDL-Portal herunter geladen,
und in einen Upload-Ordner eines eMule geschoben. Er hat den sog. Rip-Vorgang von der Original-DVD also
gar nicht selbst durchgeführt. So wie das eben im Punkt 2.) beschrieben wurde. Damit wird natürlich auch klar,
dass hier der selbe ed2k-Dateihash erzeugt wurde.
Damit wäre zumindest jetzt erst einmal geklärt, wie die Loggerbude den ed2k-Dateihash bereits zum 10.06.2009
gekannt hatte, der auf einer Esel-Seite erst zwei Monate später veröffentlicht wurde.
Diese Variante belegt allerdings auch, dass die mit dem Original-Video zu verifizierende Video-Datei (bzw. der
dahinter liegende ed2k-Dateihash) laut Eides-Vers. definitiv nicht via ed2k-Netz herunter geladen wurde.
Es bleibt also jetzt noch die erneute Frage nach dem Upload der Loggerbude. Dazu müssen wir erneut unsere
Verbose-Log-Datei untersuchen. Dieses Mal allerdings nach Quellenabfragen auch vom und zum ed2k-Server.
Hier wird nämlich auch die Menge der verfügbaren Quellen zu dem Dateihash zurückgeliefert. Diese Anzeige ist
zwar nie ganz aktuell (wie schon auf Seite-10 Bild-17 beschrieben), gibt aber dennoch einen ungefähren Überblick
wie viele Quellen überhaupt vorhanden sind, wo das Werk/Dateihash herunter geladen werden könnte.
Und dazu müssen wir dann noch die Loggerliste unter die Lupe nehmen, wie viele Log-Datensätze es überhaupt
an den dazu passenden Tagen gibt. Hier müssen wir uns in Erinnerung rufen (Seite-15 Bild-28), dass die
Loggerbude auch nur die selben Quellen/Gegenstellen im ed2k-Netz sehen kann, wie wir mit unserem eMule auch.
Das bedeutet z.B. natürlich auch, wenn am betreffenden Log-Tag im Netz nur 15 verschiedene Quellen zu finden
waren, dann kann es an diesem Log-Tag keine 100 IP-Datensätze in der Loggerliste geben.
Zudem müssen wir noch etwas berücksichtigen. Der Dateihash wurde erst am 08.08.2009 auf einer Esel-Seite
bekannt. Niemand kannte diesen also bis dahin. Und bis zum 08.08.2009 wird sicherlich auch kaum eine ganze
Horde saugwütiger eMule-Nutzer seit dem 05.08.2009 am Bildschirm auf die Veröffentlichung gewartet haben. Die
eMule-Praxis sah bisher eher so aus, dass es nach der Veröffentlichung auf einer Esel-Seite noch etwa 1-2 Tage
dauert, bis die Anzahl der verfügbaren Quellen zu dem Dateihash deutlich ansteigt. Wir sind auf diesen Dateihash
vor der dem 08.08.2009 ja auch nur zufällig gestoßen, weil wir einen völlig anderen Dateinamen (Fake-Name) zum
Download eingestellt hatten. Also, wer hatte diesen Dateihash schon vor dem 08.08.2009 verbreitet ?
>> Seite 31
Nachweis Dateihash
Nachweis/Upload >>
Seite 31 von 51
18.) der Anscheinsbeweis (die Loggerbude verteilt den Dateihash)
Wir hatten ja an den beiden folgenden Tagen nach dem 05.08.2009 weiter versucht, unseren Trickfilm irgendwie
doch noch herunter zuladen. Aber auch das klappte nicht. Die Datei wollte einfach nicht mehr weiter laden, so dass
wir dann am 07.08.2009 nach dem letzten Versuch entnervt aufgegeben haben. Dennoch müsste es in unserer
Verbose-Log zumindest noch Hinweise auf Quellenabfragen geben. In der analysierten Loggerliste konnten wir zwar
sehen das der 06.08.2009 fehlt, aber am 07.08.2009 gab es einige Datensätze in der Liste (Seite-26 Bild-54).
Und interessanterweise stehen da auch nur Fake-Namen drin.
Wir untersuchen also im folgenden Verlauf weiter unsere Verbose-Log-Datei auf Einträge, die nach dem 05.08.2009
liegen. Und treffen dabei auf höchst seltsame Einträge. Es gibt zwar Quellenabfragen, aber Down- bzw. Uploads
können wir in der Verbose-Log nicht mehr finden.
Bild 62 - Auszug aus der Verbose-Log-Datei (seltsame Einträge am 05.08.2009)
Nach unserem letzten Download der Datei (siehe Seite-25 Bild-52) waren laut Quellenabfrage vom ed2k-Server
plötzlich keine verfügbaren Quellen mehr vorhanden. Danach setzte unser einziger Upload ein, den wir in der
Verbose-Log (Seite-24 Bild-51) gefunden hatten. Welcher zudem noch von der Gegenstelle aus gestoppt wurde.
Also hier steuert doch jemand ganz gezielt, wo der Dateihash lagert bzw. angeboten wird.
Am Abend des 06.08.2009 wollten wir eigentlich versuchen, den Trickfilm weiter herunter zuladen. Es war bei einem
kurzen Versuch geblieben, den wir nach rund 3 Stunden wieder aufgegeben hatten. Wir finden keine Down/UploadEinträge in der Verbose-Log an diesem Tag. Die Quellenabfrage vom ed2k-Server verrät uns auch warum, nur zwei
verfügbare Quellen. Interessant, die schon bekannte IP-Adresse, zu der wir am Vortag geuploaded hatten, tauchte
an diesem Abend ein einziges Mal wieder auf. Noch interessanter natürlich, dass es an diesem Tag in der
Loggerliste keinerlei Datensätze gibt.
Am Abend des 07.08.2009 dann unser letzter Download-Versuch zu dem Trickfilm. Und wieder nur sehr wenige
Quellen vorhanden. Wir hatten dann auch hier nach ca. 4 Stunden entnervt aufgegeben, und den eMule danach
nicht wieder in Gang gesetzt. Hatte keinen Sinn mehr, die Video-Datei war eine Download-Leiche. Einträge zu
Down/Uploads konnten wir auch an diesem Tag nicht finden, dafür aber wieder unsere bekannte IP-Adresse.
Beim Blick in der Loggerliste ist uns dann aber doch ein interessantes Detail aufgefallen. Die Datensätze an diesem
Tag enthalten ausschließlich Fake-Namen.
Also hier geht uns dann doch ein gewisses Licht auf.
Offenbar gab es am 07.08.2009 wieder einige eMule-Nutzer, die nach einem bestimmten Filmwerk offensichtlich
manuell gesucht hatten, und ebenfalls über einen Fake-Namen an den Dateihash mit dem Porno-Werk geraten
sind. Allerdings muss es ja irgendeine Uploader-Quelle gegeben haben, die diese Video-Datei mit dem Hash auf
ihrem P2P-Client zu liegen hatte, und permanent mit einem anderen Dateinamen umbenannt hatte. Auch beim
eMule funktioniert so etwas problemlos, wenn man die Video-Datei im Upload/Shared-Ordner stehen hat.
Die einzige Quelle die da für uns jetzt in Frage käme, wäre nun mal die Loggerbude. Diese hatte die Video-Datei
mit dem "richtigen" Dateihash bereits vor der Veröffentlichung auf der Esel-Seite am 08.08.2009. Die werden doch
nicht etwa die Video-Datei schon am 05.08.2009 selber verteilt haben. Danach versuchte man dann den Dateihash
wieder von den Downloadern herunter zu laden, und zeichnete das als sog. Probe-Download auf. Und dort wo das
nicht gelang, hatte man dann ja immer noch die IP-Adresse, wo der Downloader die Datei zuvor vom Log-Client
herunter geladen hatte. Das wurde dann ebenfalls als Probe-Download hingestellt. Ziemlich perfide das Ganze.
An dieser Stelle verlassen wir die rekonstruierte Geschichte zu einer Porno-Abmahnung von Seite-20 Bild-40.
Im weiteren Verlauf der Abhandlung kommen wir noch auf das Problem zurück, warum die Aufzeichnung einer so
großen Loggerliste innerhalb kurzer Zeit ohne den Upload technisch gar nicht umsetzbar wäre.
>> Seite 32
Nachweis/Upload
Anti-Leecher/Log-Software >>
Seite 32 von 51
19.) die Anti-Leecher-Funktion (eMule-Client gegen Loggerbude)
Bevor wir zu dieser Funktion "Anti-Leecher" (die es i.Ü. nur im eMule in solch ausgeprägter Form gibt) technische
Details und deren Wirkung erläutern, schauen wir zuerst einmal wieder in Richtung Loggerbude bzw. Abmahnung.
Hier gibt es ja in den verschiedenen Abmahnungen, und sogar auch nachweislich in einem Gutachten, bezüglich
der angeblich durchgeführten "beweisgesicherten und gerichtfesten Aufzeichnung zum Log-Vorgang" die dollsten
Ausführungen. Hier ist in der Tat von "kompletter Unsinn" über "rotzfrech dreiste Lüge" bis "Oberlehrer-Manie"
wirklich alles vertreten. Im Folgenden listen wir mal einige Stichpunkte auf, welche Kommentare wir bisher in
diversen Schriften, Kommentaren, Web-Auftritten, usw. zum Thema "Log-Vorgang" so alles vorgefunden haben.
* Nachdem mutmaßliche Dateien aufgespürt und heruntergeladen wurden, wird über einen manuellen Vergleich...
* Die Angebotsdaten wurden mittels eines regulären Tauschbörsenprogramms gewonnen.
* Im Rahmen dieser Recherche wurden folgende Daten dokumentiert und beweiserheblich gesichert.
* Darüber hinaus wurde das von Ihnen angebotene Filmmaterial geladen, gesichtet und zum Beweis gesichert.
* Zudem wurde der Datentransfer über ihren Internetanschluss getestet und gerichtsfest gesichert.
* Mittels einer Spezialsoftware wurden nachfolgende Informationen erfasst.
* Die Daten wurden mittels einer speziell entwickelten Antipiracy-Technologie ... festgestellt und dokumentiert.
* Unsere Software wurde von einem unabhängigen Softwaregutachter untersucht und auf Korrektheit überprüft.
* Das Landgericht Köln hat die verwendete Software als einen fehlerfreien Beweissicherungsmechanismus anerkannt.
In dem u.g. Gutachten geht man gleich noch einen Schritt weiter, indem der Gutachter behauptet, die eingesetzte
Spezialsoftware "FileWatch" arbeitet grundsätzlich im sog. Leecher-Modus (also Null-Upload), und dass das von
keinem ed2k-Server und keinem normalen ed2k-Client (damit meint er wohl sicher den eMule) bemerkt und
unterschieden werden könnte. Also bevor der Gutachter weiter solchen Unsinn behauptet, empfehlen wir Ihm einen
Blick auf diese Web-Site. http://www.koders.com/cpp/fid8DBFF68874A12CF319BA9AC043029C20D4307D3D.aspx?s=rsa
Hier kann er zumindest schon mal entnehmen, was ein eMule-Client bezüglich Leecher-Modus so alles erkennt, und
was seine begutachtete Spezialsoftware ganz sicher nicht umgehen kann.
Bild 65/66/67 - Auszüge aus dem FileWatch-Gutachten
66
65
67
Wenn wir die o.g. Kommentare und Screenshots zusammenfassen, dann soll die Allgemeinheit (dazu gehören auch
Gerichte) an den Spezialkenntnissen und den unglaublichen Fähigkeiten der Loggerbuden keine Zweifel haben.
Eine Loggerbude arbeitet durchweg mit einer speziell entwickelten Antipiracy-Software, die grundsätzlich
gutachterlich bestätigte fehlerfreie und gerichtsfeste Beweise liefert, niemals einen Upload von der zu
überwachenden Datei zulässt, und dabei von keiner überwachten Gegenstelle bemerkt oder identifiziert wird.
Man arbeitet also grundsätzlich mit der absoluten Superlösung für Profis, der Eierlegenden Wollmilchsau.
Soso, eine Super-Profilösung, entwickelt mit einer geheimen speziellen Antipiracy-Technologie, exklusiv für
Abmahn-Profis. Geschrieben in der Programmiersprache C++ (irgendwie haben wir das schon auf der o.g. eMule
Entwickler-WebSite gesehen), in Kombination mit der OpenSource-Datenbank "PostgreSQL".
Also für uns sieht "Geheim", "spezielle Technologie" und "Profilösung" aber grundlegend anders aus.
Wir wollen uns an dieser Stelle nicht weiter über den oben aufgeführten technischen Unsinn aufregen, sondern
uns der realen Praxis in einem ed2k-Netzwerk zuwenden. Und die sieht nun mal wie folgt aus.
Egal welche Super-Software hier eine Loggerbude einsetzt, wenn diese über die P2P-Clients am anderen Ende
der Leitung bestimmte Dinge aufzeichnen will, dann müssen beide P2P-Clients erst mal fehlerfrei miteinander
kommunizieren können. Und beim eMule ist die Grundlage dafür nun mal das sog. ed2k-Protokoll. Damit lassen
sich bestimmte Kommandos untereinander austauschen, und "andere" Kommandos wiederum nicht. Weil solche
im ed2k-Protokoll nie vorgesehen waren, nicht erwünscht sind, und demzufolge auch nicht implementiert wurden.
Wenn die Supersoftware einer Loggerbude an den zu überwachenden eMule-Client am anderen Ende das neu
erfundene Kommando "Zeige mir auf, an welchen anderen eMule-Nutzer du gerade einen Upload machst" sendet,
dann wird die Supersoftware darauf keine Antwort erhalten. Der eMule-Client auf der anderen Seite versteht diesen
Befehl gar nicht. Weil es diesen Befehl in seinem eMule-Client im aktuell verwendeten Standard-ed2k-Protokoll
nämlich gar nicht gibt. Der eMule-Client verwirft dieses ankommende Datenpaket (Kommando/Befehl) einfach, weil
er es nicht versteht, und damit nichts anfangen kann.
>> Seite 33
Anti-Leecher/Log-Software
Anti-Leecher/Technik >>
Seite 33 von 51
Interessanterweise wurde genau diese Problematik bereits in einem Gutachten im Jahre-2006 festgestellt.
Bild 68 - Auszug aus dem Fraunhofer-Gutachten 11.08.2006 (3.1 Einsicht in Dateiliste...)
Bild 69 - Auszug aus dem Fraunhofer-Gutachten 11.08.2006 (3.3 ... eDonkey-Server)
Die beiden Screenshots (Bilder 68+69) aus einem Gutachten vom 11.08.2006 zeigen schon mehr als deutlich, dass
die Behauptungen der Loggerbuden (siehe Seite-32) schlichtweg an den Haaren herbeigezogen sind. Es gibt sie
einfach nicht, die Super-Logsoftware die im ed2k-Netz auch noch unentdeckt funktionieren würde.
20.) die Anti-Leecher-Funktion (Technik und Verbose-Log-Einträge)
In diesem Kapitel werden wir auf die vereinfachte Anti-Leecher-Funktion in einer eMule-Standard-Version, sowie
auch auf die sog. "Dynamic Leecher Protection" (DLP) einer eMule-Mod-Version eingehen. Interessanterweise
werden nämlich auch diese Aktionen (wenn die Anti-Leecher-Funktion im eMule aktiv wurde) in der Verbose-Log
aufgezeichnet. Das bedeutet natürlich auch, wenn die Loggerbude tatsächlich mit einem Null-Upload-Client ständig
versuchen würde unseren eMule zu kontaktieren, und unsere Anti-Leecher-Funktion das erkennt (und das schafft sie
fast immer), dann ist der Logger-Client auch in unserer Verbose-Log zu sehen. Zunächst einmal gehen wir kurz auf
die Unterschiede ein, zwischen einer eMule-Standard-Version und den weit verbreiteten eMule-Mod-Versionen.
Bild 70 - eMule-Standard-Version (Menü:Optionen)
Bild 71 - eMule-Standard-Version (Menü:Sicherheit)
Im Bild-70+71 sehen wir die standardmäßig aktivierten
Optionen einer eMule-Standard-Version, die u.a. auch auf
die integrierte Anti-Leecher-Funktion einwirken. Hiermit
wird ein gewisser Grundschutz gewährleistet. Damit werden
z.B. sog. aggressive Clients ausgesperrt, oder Clients deren Kommunikation sich nicht an das ed2k-Protokoll hält.
So sorgt die Kombination aus "Credit System" und "sichere Identifikation" u.a. dafür, dass manipulierte eMule-ClientVersionen (z.B. eine Loggersoftware) erkannt werden, und dass Leecher-Clients in unserer Upload-Warteschlange
permanent nach hinten verdrängt werden. Damit gelingt z.B. einem Logger-Client mit Null-Upload (also im LeecherModus) nur in seltenen Fällen ein Probe-Download. Ohne angesammelte Credit-Punkte aus dem eigenen
Upload geht nun mal beim eMule so gut wie gar nichts. Das gesamte System basiert nun mal darauf.
>> Seite 34
Anti-Leecher/Technik
Anti-Leecher/Technik Mod >>
Seite 34 von 51
Folgend erläutern wir noch die Anti-Leecher-Funktion in den eMule-Mod-Versionen, die hier übrigens als sog. DLP
(Dynamic Leecher Protection) bezeichnet wird. Der Begriff "dynamisch" ist daraus abgeleitet, dass die DLP hier
sämtliche Client-Kommunikation von einer Gegenstelle nach bestimmten Verhaltensmustern analysiert. Wenn wir
also mit einem Logger-Client (z.B. basierend auf einer Shareaza oder xMule-Version) einer Gegenstelle vorgaukeln
wollen, hier meldet sich ein "sauberer" eMule-049c-Client der kein Leecher ist, dann erkannt die DLP diesen Nepp
an bestimmten typischen Verhaltensmustern eines Leecher-Clients. So z.B. die fehlenden Punkte im Creditsystem,
manipulierte Rückantworten auf unsere direkten Quellenabfrage, usw.
An dieser Stelle soll noch einmal erwähnt werden, dass die sog. DLP-Funktion den ohnehin schon vorhandenen
Leecher-Grundschutz noch mit zusätzlichen Funktionen erweitert. Und da geht es richtig ans Eingemachte.
Bild 72 - eMule-Mod-Version (Anti-Leecher / DLP)
Bild 73 - eMule-Mod Web-Seite (Auflistung)
aktuelle Version
ist die DLP v44
>> Web-Link <<
Liste enthält über 250
Leecher-Clients
Im Bild-72 sehen wir das Einstellungen-Menü "Anti-Leecher" in einer eMule-Mod-Version. Wenn alle diese Optionen
aktiviert sind, haben Clients die im Leecher-Modus arbeiten (also auch ein Logger-Client) praktisch keine Chance.
Hier wird einer simplen Vorgehensweise gefolgt. Wer sich nicht an die ed2k-Protokoll-Regeln hält, und wer nichts
ans Netz abgibt (Upload), der fliegt gnadenlos raus. Selbstverständlich gelingt es auch mit einem Leecher-Client
von einem anderen eMule-Client öfters etwas herunter zuladen, allerdings gelingt das eher nur bei relativ kleinen
Dateien (z.B. Audio-Dateien). Bei großen Dateien jedoch, mit mehreren sog. Chunks/Parts (1 Chunk = 9.28 MByte),
wird man als Leecher recht schnell enttarnt und gebannt, oder in der Upload-Warteschlange nach hinten abgedrängt.
Im Bild-73 sehen wir eine Auflistung von erkannten Leecher-Client-Versionen auf der eMule-Mod-Webseite. Die hier
aufgelisteten Clients werden von der DLP-Funktion bereits schon am sog. Mod-String jeder Client-Version erkannt.
Das bedeutet, dieser Leecher-Client erhält von unserem eMule noch nicht einmal eine Antwort auf seine erste
Quellenabfrage an uns, sondern fliegt schon vorher gleich auf die Bannliste.
Diese Anmerkung ist besonders wichtig, weil einige Loggerbuden behaupten, sie könnten auch mit jedem LeecherClient als Loggersoftware durchweg einen Warteschlangen-Log anfertigen. Das ist schlichtweg Unsinn. Wenn der
Logger-Client Glück hat, dann schnappt er vielleicht gerade mal noch die IP-Adresse der Gegenstelle auf, bevor er
von dieser auf die Bannliste verdonnert wird. Dann geht für den Logger-Client hier gar nichts mehr.
Die DLP-Funktion war schon bei ihrer ersten eMule-Einführung vor mehreren Jahren das Schreckgespenst
sämtlicher eMule-Leecher. Ab dem Jahre-2006 sind in die DLP-Funktion immer mehr Erfahrungswerte und Hinweise
von eMule-Mod-Nutzern in die Perfektionierung dieser Funktion eingeflossen. Einer der Hauptgründe dafür war
nicht nur die zunehmende Verbreitung der verhassten eMule-Leecher-Mods, sondern auch die zunehmend
bekannten Logger-Aktivitäten der Firma Logistep in der Schweiz.
Bild 74 - Auszug aus dem Programm-Code (AntiLeecher/DLP)
Im Bild-74 sehen wir Stücke des Programm-Codes der DLP-Funktion des eMule. So ist an den abschließenden
Kommentar-Einträgen gut zu erkennen, in welchem Monat/Jahr die Leecher-Erkennung
bereits umgesetzt wurde.
>> Seite 35
Anti-Leecher/Technik Mod
Anti-Leecher/Verbose-Log >>
Seite 35 von 51
Bild 75 - Auszug aus dem Programm-Code (AntiLeecher/DLP)
Im Bild-75 ist ein Teil von manipulierten Shareaza-Client-Versionen zu sehen. Wie schon auf Seite-16 oben erwähnt,
basiert ja eine bekannte Logger-Software auf einem modifizierten Shareaza-Client. Und bevor das eine Loggerbude
bestreiten sollte, gleich noch die passenden Screenshots dazu. Diese stammen aus einem Abmahnvorgang der
englischen Abmahner-Kanzlei "Davenport Lyons". Auch dorthin war der Loggerbuden-Nepp bereits expandiert.
Bild 76/77/78/79 - Auszüge aus einer Beschreibung (File Sharing Monitor / Logistep)
76
77
78
79
Die Bilder-76,77 und 79 wollen wir hier nicht näher erläutern. Auch ohne englisch Kenntnisse ist der Inhalt eindeutig
erkennbar, und um "was" es eigentlich geht. Das Bild-78 erläutern wir allerdings noch kurz. Man ermittelt also erst
nach dem Log-Vorgang, zu welcher sog. Provider-IP-Range die geloggte IP-Adresse gehört. Bei einer Loggerliste
mit über tausend IP-Adressen kann das aber gründlich in die Hose gehen. Wir haben diese Whois-Prüfung der
geloggten IP's auf einer Liste mit über 5000 Adressen auch mal erst hinterher gemacht. Logisch, denn diese Liste
war ja schon ein paar Monate alt. Mit dem Ergebnis, dass über 200 IP-Adressen nicht mehr eindeutig zugeordnet
werden konnten, weil die betreffenden relativ kleinen IP-Ranges ganz offensichtlich an sog. Reseller zeitlich befristet
weiter vermietet wurden. Das Problem ist, dass es hierbei häufig dann zu sog. Überschneidungen kommt, wenn die
IP-Ranges an den nächsten Reseller weiter vermietet werden, und dieser jetzt die selben vorher genutzten
dynamischen IP's erneut wieder an Nutzer vergibt. Diese nachträgliche Prüfung ist also immer problematisch.
Allerdings fragen wir uns, ob eine Whois-Prüfung bei einigen Loggerbuden überhaupt noch gemacht wird.
>> Seite 36
Anti-Leecher/Verbose-Log
Anti-Leecher/Verbose-Log >>
Seite 36 von 51
Abschließend können wir also zum Thema "Niemand erkennt den Logger-Client" nur noch sagen, dass hätte die
Loggerbude vielleicht gern so. Die Praxis im ed2k-Netz (speziell eMule) sieht nun mal aber völlig anders aus.
Im folgenden Abschnitt kommen wir wieder zu unserer Verbose-Log-Datei zurück. Dort sind u.a. auch sämtliche
Einträge zu sehen, wo und bei welcher Gegenstelle die Anti-Leecher-Funktion zugeschlagen hatte. Auch diese
Einträge sind bei unseren Recherchen sehr hilfreich, wenn wir hier auf Zeitstempel treffen, die exakt mit unserem
Ermittlungsdatensatz übereinstimmen. Der Zeitstempel-Vergleich wurde bereits auf Seite-27 Bild-56 erläutert. Wir
können also auch an den Anti-Leecher-Einträgen erkennen, ob hier ein möglicher Logger-Client schon bei der ersten
Quellenabfrage an unseren eMule auf der Bannliste gelandet ist. In diesem Fall gelingt dem Logger-Client kein
Probe-Download mehr von uns, und wir könnten dort (wenn der Logger-Client uploaded) auch nichts herunter laden.
Bild 80 - Auszug aus der Verbose-Log-Datei (gebannte Clients)
[1]
[2]
[3]
Im Bild-80 erläutern wir einige der Bannlist-Einträge in der Verbose-Log.
Die Einträge Im Punkt [1] bedeuten, eine manipulierte eMule-Version wurde erkannt, ein Verbindungsversuch
wurde abgelehnt, ein weiterer Verbindungsversuch wurde verweigert. Wichtig aber hierbei, durch einen vorherigen
Warteschlangen-Eintrag kennt die Gegenstelle auch unsere IP-Adresse. Das könnte u.a. auch von diversen
Loggerbuden ausgenutzt werden, die definitiv nur Warteschlangen-Screenshots als Probe-Download verkaufen.
Im Punkt [2] stand eine Gegenstelle (IP-Adresse) mit einem Userhash (z.B. abxx0) noch in unserer sog.
Client-Liste. Einige Zeit später tauchte die selbe IP-Adresse mit einem anderen Userhash (z.B. cdyy1) bei uns auf.
Die Reaktion unseres eMule, zwei verschiedene Userhashes mit der selben IP-Adresse innerhalb kurzer Zeit wird
als sog. Userhash-Klau betrachtet, und als aggressives Verhalten eingestuft. Der Client wird verbannt.
Das kann uns übrigens auch passieren, wenn wir mit dem eMule Online sind, anschließend einen neuen Userhash
generieren (siehe Seite-17 unter Bild-31), und mit dem erneuten Start des eMule immer noch die selbe öffentliche
IP-Adresse haben. Dann werden wir ebenso gebannt.
Der Punkt [3] ist ganz besonders interessant. Denn hier liegt ein Problem vor, was wir auf der Seite-32 unten
erläutert hatten. Diese Gegenstelle versucht via Kad unserem eMule Anfragen oder Kommandos aufzuzwingen, die
wir in Folge einer eMule-Setup-Einstellung nicht beantworten wollen (z.B. zeige Inhalt deines Shared-Ordners), oder
es sich hierbei um einen Befehl handelt den unser eMule einfach nicht versteht. Da uns die Gegenstelle damit aber
massiv bombardiert, zieht die DLP-Funktion hier die Notbremse. Komplette IP-Adresse gebannt. Diese Adresse
hat für den Rest unserer eMule-Online-Session nicht mal mehr die Chance für eine Quellenabfrage bei uns.
Zusammenfassend wäre in diesem Kapitel schon mal festzustellen, dass es die "Eierlegende Wollmilchsau" einer
Log-Software zumindest im ed2k-Netz definitiv nicht gibt. Vor allem in den eMule-Mod-Versionen ist die Technik der
Leecher-Erkennung schon seit Jahren derart ausgereift, dass ein Logger-Client im Leecher-Modus von einem eMule
nur in seltenen Fällen ein Probe-Download gelingt. Auf keinen Fall in solchen Mengen, wie auf den Loggerlisten
dargestellt und behauptet wird.
Damit beenden wir jetzt die umfangreichen Thematik “Verbose-Log-Einträge” komplett, und wenden uns dem
nächsten Kapitel “Eindeutige Hinweise auf den Upload der Loggerbuden” zu.
>> Seite 37
Anti-Leecher/Verbose-Log
fragliche Loggerlisten >>
Seite 37 von 51
21.) die fragwürdigen Loggerlisten (Eindeutige Hinweise auf den Upload)
Wenn wir an dieser Stelle die bisherige Abhandlung komplett zusammen ziehen, dann dürfte es eigentlich gar keine
abgemahnten bzw. geloggten eMule-Nutzer geben. Schon gar nicht Nutzer von eMule-Mod-Versionen. Diese sind
schon seit langem derart ausgereift, dass jede Gegenstelle, die sich nicht an die ed2k-Protokoll-Regeln hält, oder
die sich nicht am Upload beteiligt, gnadenlos ausgesperrt oder verbannt wird. Das trifft natürlich auch auf den Client
der Loggerbude zu, der ja irgendwie mit dem eMule einer Gegenstelle kommunizieren muss, oder gar einen sog.
Probe-Download erhaschen will.
Die Realität sieht aber nun mal aber so aus, dass es abgemahnte eMule-Nutzer gibt, und zwar gleich in Massen.
Einige Loggerlisten vermitteln sogar den Eindruck, dass das sog. Tauschbörsen-Netz komplett nur aus geloggten
eMule-Clients bestand. Was eigentlich schon aufgrund der umfangreichen Anti-Leecher-Funktionen gar nicht sein
kann. Andere Loggerlisten vermitteln wiederum das unübersehbare Bild, hier hat eine Aushilfskraft einfach mal
eben ein paar IP-Adressen aus einer Warteschlange abgetippt, und “Netz: eDonkey” dahinter geschrieben.
Hier ergeben sich also immer mehr Fragen über Fragen, denen eine immer dichter folgende Feststellung folgt:
Die einzige Möglichkeit, eine IP-Liste in solchen Ausmaßen zu generieren, war bei dem aktuellen Bekanntheitsbzw. Verbreitungsgrad des geloggten ed2k-Hashes nur noch in der Form möglich, dass die Loggerbude sich aktiv
am Upload beteiligt hat.
Und bevor wir uns dieser Feststellung detailliert zuwenden, gehen wir zur besseren Übersicht erst einmal ein ganz
kleines Stück zurück, um die “Vorgeschichte” etwas genauer zu verstehen.
Die in der Vergangenheit zahlreich durchgeführten eMule-Tests, Analyse diverser Loggerlisten, sowie umfassende
Recherchen zu den geloggten Werken/Dateihashes, warfen in letzter Zeit immer häufiger folgende Frage auf.
“Verteilt die Loggerbude das abzumahnende Werk über einen sog. Honigtopf selbst, oder beteiligt sich zumindest
während des Log-Vorganges am Upload ?”
Vor allem in Bezug auf die Verbreitung von sog. Porno-Werken ist das eine recht brisante Frage.
Zunächst einmal ein Überblick, was bisher geschehen war.
Die ersten Analysen erfolgten immer unter Voraussetzung folgender Ablaufkette (Kurzform):
- der Rechteinhaber des Werkes stellt fest, dass sein Werk illegal im P2P-Netz verbreitet wird
- die Loggerbude ermittelt das jeweilige P2P-Netz (ed2k oder BitTorrent), stellt den/die Dateihash/es fest,
lädt diese anschließend herunter, und verfiziert diese zweifelsfrei mit dem Originalwerk
- ein Log-Vorgang wird mit dem Ziel gestartet, welche IP-Adressen verbreiten das Werk illegal (Upload-Nachweis)
Dabei waren wir von folgenden Grundsätzen ausgegangen:
- zum Zeitpunkt der Hash-Verifizierung wurde der Dateihash bereits im zugehörigen P2P-Netz massiv verbreitet
- die Loggerbude arbeitet mit einem speziell modifizierten Leecher-Client, führt damit grundsätzlich keinen Upload
aus, und verteilt das Werk auch nicht selbst oder lässt verteilen (Stichwort: Problem Porno-Werke)
- es wird grundsätzlich ein Probe-Download durchgeführt, um die tatsächlichen illegalen Uploader festzustellen
Gestützt wurde diese Voraussetzung zudem noch auf ein recht glaubwürdiges und detailliertes Gutachten, wo die
o.g. Ablaufkette in Verbindung mit einer getesteten Log-Software auch "genau so" gutachterlich bestätigt wurde.
Leider mussten wir allerdings schon in ersten umfangreichen eMule-Tests feststellen, dass der Probe-Download bei
der überwiegenden Masse der Uploader gar nicht gelingt. Die Ursache waren vor allem in der verwendeten Technik
der eMule-Clients zu finden. Diese benutzten durchweg das bekannte Kreditsystem (nur Uploader belohnen), und
verfügten zudem noch über eine äußerst wirksame Leecher-Erkennung. Zudem mussten wir bei der Überprüfung
des o.g. Gutachtens auch noch feststellen, dass eben diese eMule-Techniken in dem Gutachten gar nicht erst
berücksichtigt (vermutlich bewusst deaktiviert worden), und die daraus für den Logger-Client entstehenden
Probleme (kein Probe-Download gelingt) schlichtweg vertuscht wurden. Zudem wurde nachfolgend auch noch eine
Loggerliste analysiert, die ausgerechnet mit der begutachteten Log-Software erstellt wurde.
Danach mussten wir bei o.g. Ablaufkette bereits folgende Korrekturen vornehmen:
- zum Zeitpunkt der Hash-Verifizierung war dieser Dateihash noch in keinem P2P-Portal veröffentlicht worden,
und demzufolge nur relativ gering oder gar nicht verbreitet
- statt zahlreicher Probe-Downloads hatte die Loggerbude aufgrund ihrer Leecher-Problematik nahezu durchweg
nur sog. Warteschlangen-Screenshots aufgezeichnet, und weder Upload noch Download belegt
Nach jüngst durchgeführten intensiveren Analysen einiger Loggerlisten mussten wir allerdings weiterhin feststellen,
dass auch der sog. “nur Warteschlangen-Screenshot” nicht mehr mit Inhalt und Menge einiger Loggerlisten in
Einklang zu bringen war. Das betraf neben dem Startzeitpunkt des Log-Vorganges hauptsächlich die in welchem
Zeitraum geloggte Menge an IP-Adressen. Vor allem die während des Log-Zeitraumes im Netz verfügbaren
“deutschen” Quellen, die den Dateihash überhaupt hätten verteilen können, war nicht einmal annähernd mit der
Menge an aufgezeichneten IP-Adressen in Übereinstimmung zu bringen. Es gab also schon gar nicht so viele
deutsche Quellen, die man für einen Warteschlangen-Screenshot hätte sehen und aufzeichnen können.
Hier schien also eindeutig noch ein Teil in dem Puzzle “Log-Vorgang” zu fehlen, dass wir bisher noch nicht
berücksichtigt hatten, und auch gar nicht so recht glauben wollten. Und das ist der Upload der Loggerbuden.
Auf der nächsten Seite werden wir eine solch fragwürdige Loggerliste kurz erläutern, und vor allem warum
diese eigentlich “so fragwürdig” ist. Es handelt sich übrigens um die umfangreichste Loggerliste, die wir bisher
zu analysieren hatten. Ein wahres Listen-Monster mit über 5000 IP-Adressen.
>> Seite 38
fragliche Loggerlisten
Ipoque-Loggerliste >>
Seite 38 von 51
Zuerst einmal vorab. Diese “Monster-Liste” besteht gleich aus zwei Listen, und hat einen solchen Umfang, dass wir
aus Platzgründen hier nur einen winzigen Schnipsel davon in Kurzform erläutern können. Diesen beiden Listen A+B
der Loggerbude werden wir demnächst noch eine separate Abhandlung spendieren. Das war uns insofern schon
eine extra Analyse wert, was hier tatsächlich "vom Stapel gelassen" wurde.
In dieser "Monster-Liste" wurden übrigens gleich 10 Dateihashes (5x ed2k, 5x BitTorrent) gleichzeitig geloggt, jedoch
alle zu dem gleichen Filmwerk. Und genau das brachte schon vorab einige interessante Details hervor, die uns in fast
annähernder Form bereits auf Seite-22 Bild-47 suspekt vorgekommen waren. Es gab eigentlich noch gar nicht genug
verfügbare Quellen im P2P-Netz (ed2k + BT), denn die Hashes wurden bis auf eine Ausnahme erst unmittelbar vor
dem gestarteten Log-Vorgang (am 23.10.2009) in diversen P2P-Portalen veröffentlicht.
So gab es nur einen einzigen BitTorrent-Hash der bereits am 19.10.2009 veröffentlicht wurde. Von den restlichen
9 Dateihashes wurden 4 BitTorrent und 2 ed2k-Hashes am 22.10.2009 fast zeitgleich veröffentlicht. Und die drei
übrigen ed2k-Hashes waren im Netz gar nicht erst zu finden. Auf keiner einzigen P2P-Portal-Seite.
Die am 22.10.2009 veröffentlichten Dateihashes glichen alle den folgenden Screenshots:
Bild 81 - Auszug BitTorrent (onlytorrents.com)
Bild 82 - Auszug ed2k (titanmule.to)
22.10.2009
4x BitTorrent und 2x ed2k-Hash wurden
einen Tag vor dem Log-Vorgang
erst veröffentlicht.
Die Bilder 81+82 müssen sicher nicht näher erläutert werden. Setzen wir allerdings jetzt noch die bereits erwähnte
Loggerliste darunter, dann dürfte das nicht nur uns in helles Erstaunen versetzen. Wie hat das wohl funktioniert ??
durchgängig geloggt von Freitag-Nachmittag bis Montag-Früh
innerhalb von 59 Stunden
5220 IP-Adressen
Bild 83 - Auszug Loggerliste der Firma Ipoque Leipzig (Ermittlungsdatensätze Liste-A)
Die hier im Bild-83 gezeigte Loggerliste ist übrigens nur der Teil-A. Die zweite Liste-B (hier nicht gezeigt) enthält u.a. noch den Dateihash
sowie den geloggten Dateinamen, und ist ebenso endlos lang. Und beide wurden zum Antrag der Klarnamen-Beauskunftung beim
zuständigen Gericht abgeladen. Diese Menge veranschaulicht bereits, dass den Loggerbuden im Abmahnwahnsinn selbst exorbitanter
Aufwand nicht zu gering ist. Hier scheint man sogar extra Nachtschichten vom Sonntag zum Montag einzulegen, um den Logger-Client
nach Mitternacht zu stoppen. Wer bezahlt hier eigentlich den Nachtzuschlag des Mitarbeiters. Doch hoffentlich nicht jeder Abgemahnte ?
Wir wollen an dieser Stelle die o.g. Loggerliste nicht mehr mit all ihren Details und diversen Hintergründen erläutern.
Das werden wir demnächst mit einer separaten Abhandlung nachholen.
Fakt ist jedenfalls, schon aus technischer Hinsicht (Bekanntwerden der Dateihashes im Netz, Verbreitungsgrad vor
dem Log-Vorgang, verfügbare Quellen von deutschen Nutzern, IP-Adressen von nur einem einzigen Provider, usw.)
ist eine solche aufgezeichnete Menge an IP-Adressen, nur mit Probe-Downloads und reinen WarteschlangenScreenshots, definitiv nicht mehr zu machen. Das grenzt schon fast an Zauberei.
Die einzig erklärbare technische Antwort die wir darauf noch haben, lautet wie folgt:
Die Loggerbude hat sich aktiv an der Verteilung (Upload) der Dateihashes via sog. Honigtopf beteiligt. Es wurden
die Downloader vom eigenen Honigtopf-Client aufgezeichnet, und zeitgleich noch die sog. Probe-Downloads.
Und dort wo beides nicht gelungen ist, wurden noch sämtliche verfügbaren Quellen per Warteschlangen-Screenshot
in die selbe IP-Liste mit reingepackt. Eine andere Erklärung haben wir nicht mehr, für 5220 IP's in 59 Stunden.
Und im folgenden Kapitel gehen wir der Frage "Warum ?" nach, sowie auch den Hintergründen dazu.
>> Seite 39
Ipoque-Loggerliste
Upload/Begründung >>
Seite 39 von 51
22.) Warum verteilt eine Loggerbude den Dateihash (die technische Analyse)
In diesem Kapitel gehen wir der Frage nach, "Warum verteilt die Loggerbude das abzumahnende Werk selbst?".
Eigentlich müsste die Frage ja lauten, aus welchen Gründen die Loggerbude das überhaupt tun sollte. Wer sich in
diversen Abmahnwahn-Foren bereits umfassend zum Thema "IP-Loggerei" informiert hat, und diese Abhandlung
gelesen hat, der dürfte hier sicherlich für den o.g. Upload-Grund zur folgenden einfachen Erkenntnis gelangen.
Weil es um's Geld geht, oder genauer gesagt, um eine maximale Ausbeute an abmahnfähigen IP-Adressen.
Die Loggerei mit dem angeblich beweisgesicherten Probe-Download funktioniert entweder nicht richtig, oder
die Menge der damit gewonnenen IP-Datensätze (überführte/erwischte Uploader) wäre einfach so gering, dass
schon der Logger-Aufwand wirtschaftlich nicht mehr tragbar wäre. Und mit einem Warteschlangen-Screenshot
lässt sich weder Upload noch Download beweisen. Also wendet man alle Mittel und Möglichkeiten an, um die
Ausbeute an IP-Adressen maximal zu erhöhen. Dabei schreckt man eben auch nicht davor zurück, das Werk
selbst zu verteilen. Damit gelangt man nicht nur an die IP-Adressen sämtlicher Downloader, sondern kann
sogar noch den Probe-Download von bereits aufgezeichneten IP’s ganz gezielt provozieren und verifizieren.
Grundsätzlich wären wir hier natürlich zu der gleichen Ansicht gelangt. Allerdings würde man es sich hier mit der
Antwort doch etwas zu einfach machen. Die eigentliche Frage nach dem “Warum ?” ist hier im Grunde genommen
nämlich nicht beantwortet. Es muss einen Hintergrund bzw. eine Ursache dafür geben, warum die Loggerbuden zu
dem rechtlich höchst fragwürdigen Mittel “eigener Upload oder Honigtopf” gegriffen haben. Und dieser Hintergrund
ist tatsächlich zuerst im technischen Bereich zu finden. Auch der aktuelle Entwicklungsstand des bis dato am
weitesten verbreiteten P2P-Clients “eMule” hatte daran einen Anteil. Und das werden wir jetzt zumindest an einigen
Abschnitten etwas näher beleuchten. Es ist natürlich schon aus Aufwandsgründen nicht möglich, hier die komplette
Ablaufkette umfassend darzulegen. Aus diesem Grund kommentieren wir nur in stark gekürzter Form, und an Hand
einiger Screenshots bestimmte Abschnitte der Ablaufkette, welche nach unserer Ansicht eindeutig zur Umsetzung
"Loggerbuden-Upload/Honigtopf" geführt haben. Wichtig ist noch, dass wir uns bei der Ablaufkette hier nur auf den
Bereich "eMule & Co" konzentrieren. "BitTorrent" war zwar vom gleichen Problem betroffen, allerdings sah hier die
technische Ablaufkette doch grundlegend anders aus.
Begonnen hatte das Problem "Upload/Honigtopf" ursprünglich auf einem ganz anderen Level. Der amerikanische
IT-Dienstleister "MediaCentry" hatte damit begonnen, die P2P-Netze mit gefälschten Müll-Dateien zu überfluten.
Man hatte hier also einfach Dateien mit irgendwelchen Datenmüll erzeugt, in etwa auf die gleiche Größe einer
urheberrechtlich geschützten Datei gebracht, mit dem entsprechenden Dateinamen versehen, und anschließend
über sog. Honigtopf-Clients in den P2P-Netzen verteilt. Damit sollte den Filesharern urheberrechtlich geschützer
Werke bereits der Download grundlegend vergällt werden. Da das natürlich auch mit einem kostenintensiven
technischen Aufwand verbunden war, entstand bereits hier ein neues Geschäftsmodell "Datenmüll in P2P-Netzen
verteilen", mit dem man als Dienstleistung auch noch Geld verdienen konnte. Klar das dieses Modell auch nach
Deutschland überschwappte. So entstanden auch hier diese höchst dubiosen Dienstleister.
Bild 84 - Website "P4M GmbH” (neue Website: "das-schwarze-schaf.com")
Web-Seite erstellen
Problem neu aufwärmen
Fachkompetenz zelebrieren
Unsinn erzählen
Hier im Bild-84 ist nur ein Web-Auftritt von einem dieser Müllverteil-Dienstleister zu sehen. Alle diese
Werbe-Auftritte hatten eines gemeinsam, sie präsentierten durchweg den selben Unsinn.
Upload/Begründung
>> Seite 40
Upload/Patentantrag >>
Seite 40 von 51
Was bisher keiner dieser P2P-Müllverteilungs-Dienstleister präsentieren konnte, war eine funktionierende Lösung
zum Verteilen der sog. Fake-Dateien, die in der Praxis der P2P-Netze auch funktionieren würde. Was man zudem
noch nicht einmal einkalkuliert hatte, waren die möglichen Reaktionen der P2P-Nutzer. Besonders die eMule-Nutzer
sowie auch die eMule-Entwickler-Gemeinde reagierten besonders allergisch auf diese Fake-Verteil-Aktionen. Das
führte im eMule zur massiven Aufrüstung der Schutz- und Prüffunktionen. Neben der Verbesserung der AntiLeecher-Funktion lag das besondere Augenmerk auf dem sog. Media-PlugIn zur Erkennung von Audio/VideoDateien, dem IP-Filter, sowie der Integration eines wirksamen Fake-Melde-Systems über einen Datenbankserver.
Bild 85 - eine eMule-Version (Fake-Melde-Funktion)
Bild 86 - eine eMule-Version (IP-Filter-Funktion)
Wer in den Programm-Code der Anti-Leecher-Funktion hineinschaut (siehe Seite-34 Bild-74), der wird feststellen,
dass die Datum-Kommentare fast durchweg vom Jahre 2006 stammen. Die eMule-Nutzer hatten gegen diese
Fake-Verbreitung technisch aufgerüstet. Zudem hatten die Müllverteilungs-Dienstleister mit einem ganz anderem
Problem zu kämpfen. Es war schier unmöglich von einer größeren Audio/Video-Datei den ed2k-Hash zu fälschen,
ohne dass das von den eMule-Nutzern bemerkt worden wäre. Ein einfaches Umbenennen einer Fake-Datei reichte
dafür nun mal eben nicht aus. An diesem Punkt war das Modell der Fake-Verteilung im ed2k-Netz bereits wieder
gestorben, bevor es überhaupt irgendwelche gravierenden Wirkungen gezeigt hatte. Im Prinzip hatte diese
Müllverteilungsaktion das genaue Gegenteil bewirkt. Der eMule wurde technisch aufgerüstet, und resistent
gemacht gegen solche Fake-Versuche.
Diese Problematik war auch einer gewissen Firma Logistep nicht entgangen, die sich daraufhin etwas ganz
Besonderes hatte einfallen lassen. Bei der Verteilung der Fake-Dateien werden die IP-Adressen der Downloader
mit aufgezeichnet. Diese neue Modell wurde dahingehend perfektioniert, dass man sogar einen Patentantrag
daraus gemacht hatte.
Bild 87 - Auszüge Patentantrag (publikationen.dpma.de/DPMApublikationen/pdf_any_all.do;...)
Alternativ-Link http://view.txtbear.com/73074/untitled-txtbear-document/
Die Idee des Logger-Systems "Honigtopf". Ein P2P-Client
im Leecher-Modus zum Loggen, ein Zweiter zum Verteilen.
Upload/Patentantrag
>> Seite 41
Upload/Logistep-Logger >>
Seite 41 von 51
Auch wenn dieser Patentantrag (Seite-40 Bild-87) eher einem blöden Witz ähnelte, bekamen eMule-Nutzer einige
Zeit später deutlich zu spüren, dass man es mit dem vorgestellten Funktionsprinzip “Fangrechner” todernst meinte.
Diese Fangrechner-Masche (ein ed2k-Index-Server macht im Grundprinzip auch nichts Anderes) wurde tatsächlich
auf das ed2k-Netz losgelassen. Nicht etwa um es zu testen, sondern um damit Geld zu verdienen.
Bild 88 - Auszug einer Website (Hinweise auf Logistep)
Web-Link: "krawall.de/web/Earth_2160/news/id,17098/show,comments"
Hier wurde bereits erkennbar, dass es
eine Staffelung gibt, wer welche Höhe
an Schadenersatz zu leisten habe.
Im Prinzip war also schon hier an Hand
der Logger-Daten eine Kalkulation der
Kosten möglich.
Das Geschäftsmodell “Massen-Logging”
war geboren, verkauft als Dienstleistung.
Etwa ein Jahr später waren diverse Web-Foren vollgepflastert mit Berichten über diese Abmahnmaschinerie.
Besonders interessant sind die Details, die unten in den Screenshots zu sehen sind, die repräsentativ für unzählige
anderen Foren-Berichte sind, und in denen immer wieder die gleichen Bemerkungen vorgefunden hatten.
Bild 89 - Auszug eines Web-Forums (Hinweise auf Logistep)
Web-Link: www.planet3dnow.de/vbulletin/archive/index.php/t-280241.html
Die Loggerbude Logistep hatte nicht nur illegale Uploader zu dem Werk (Computer-Spiel) ermittelt, sondern
auch Downloader. Von dem Werk was sie auch noch selbst verteilt hatten. So ganz nebenbei wurden auch noch
die eMule-Nutzer mit aufgezeichnet, die sog. Crack-Versionen und No-CD-Patches nicht nur verteilt, sondern
auch nur herunter geladen hatten. Ob die Loggerbude sogar noch die Crack-Versionen selber verteilt hat, ist
heute kaum mehr nachzuweisen. Der Gedanke liegt auf jeden Fall sehr nahe.
Schauen wir uns noch einmal auf Seite-39 das Bild-40 an, und anschließend den Patentantrag auf Seite-40.
Dann wird offensichtlich was Logistep hier angeblich neu entwickelt hatte. Die hier genannte Möglichkeit, sog.
Fakes zum Herunterladen anzubieten, wurde einfach durch die Variante ersetzt, das Original-Werk zum Herunterladen anzubieten. Und da sich wie bekannt, bei den eMule-Clients der sog. Probe-Download (als Beleg des
illegalen Uploads) nur sehr schwer realisieren lässt, wurde bereits damals einfach die Masche durchgezogen,
die wir schon auf Seite-38 ganz unten behauptet hatten.
Im Prinzip war das was Logistep hier präsentiert hatte, die Geburtsstunde der Honigtopf-Masche.
Blöd nur, dass ausgerechnet in diesem Zeitraum (siehe Bild-89) ein Gutachten des Fraunhofer Institut IPSI
auftauchte, welches die Beweislage beim Thema "beweissichere Loggerei im ed2k-Netz" auch noch in sämtliche
Bestandteile zerlegte. Übrigens, weder die Loggerbude noch der verbandelte Abmahner haben sich
jemals zu diesem Gutachten geäußert. Das ist schon irgendwie sehr nachdenklich.
>> Seite 42
Upload/Logistep-Logger
Upload/Honigtopf >>
Seite 42 von 51
Im Jahr 2006 tauchte ein Gutachten auf, wo u.a. die Nachweis-Möglichkeiten bezüglich Loggerei im ed2k-Netz
gründlich beleuchtet wurden. Oder besser gesagt, es wurde beleuchtet was sich im ed2k-Netz nur sehr schwer, oder
gar nicht nachweisen lässt. Wir erläutern an dieser Stelle nur noch einen Punkt aus dem Gutachten.
Das komplette Gutachten sollte sich jeder einmal selbst durchlesen. Es ist relativ kurz und verständlich gehalten.
Web-Link: www.ipsi.fraunhofer.de/ipsi/press/press_releases/2006/fraunhofer_gutachten_bagatellklausel_final.pdf
Bild 90 - Auszug Fraunhofer-Gutachten (Deckblatt eingekürzt)
Bild 91 - Auszug aus dem Fraunhofer-Gutachten 11.08.2006 (3.4 ... eDonkey-Clients)
Diesen Punkt im Gutachten finden wir besonders interessant. Hier wird nicht nur der sogenannte Honigtopf definiert,
sondern auch gleich noch dessen rechtliche Auswirkung. Wir brauchen hier sicher nicht mehr erläutern, welche
Auswirkung diese gutachterliche Aussage auf den witzigen Patentantrag (Seite-40 Bild-87) von Logistep hatte.
Die entscheidende Frage wäre natürlich, wann ist die auf dem Honigtopf angebotene Datei als nicht urheberrechtlich
geschützte nutzlose Fake-Datei einzustufen, und wann als urherrechtlich geschützte Original-Datei. Zumindest
in dem Patentantrag auf Seite-40 Bild-87 Punkt [0015] wurde diese Unterscheidung schon mal vorsichtshalber gleich
weggelassen. Das hält die Möglichkeit für nachträgliche Anpassungen dieser Definition offen. Zum Beispiel in dem
man der angebotenen Original-Datei auf dem Honigtopf einfach einen sog. Fake-Namen verpasst. Die Datei also
einfach in z.B. "SuperGame-2160-NoCD-Patch-Version" umbenennt. Eine Vorgehensweise von der man, zumindest
nach den zahlreichen Berichten (siehe u.a. Seite-41 Bild-89) zu urteilen, offensichtlich regen Gebrauch gemacht hat.
Was die Loggerbude dabei wohl (absichtlich) übersehen hatte, dass im ed2k-Protokoll die eindeutige Zuordnung
einer bereitgestellten Datei nicht über den Dateinamen erfolgt, sondern über den berechneten ed2k-Dateihash.
Bild 92 - Auszug aus dem FileWatch-Gutachten
Auch wenn das FileWatch-Gutachten zahlreiche technische Definitionen schlichtweg falsch darstellt, gibt es an
diesem Punkt nichts zu bemängeln. Absolut korrekt dargestellt.
Damit wäre dann auch die Frage eindeutig geklärt, wann bei einem Honigtopf-Einsatz auch der Download einer
bereitgestellten Datei nicht mehr illegal wäre (siehe im Bild-91 letzte Zeile). Eine Erkenntnis übrigens, mit der selbst
juristisch perfekt ausgebildete Abmahner immer noch so einige Probleme haben.
>> Seite 43
Upload/Honigtopf
Upload/Verträge >>
Seite 43 von 51
An dieser Stelle wird zum Thema "angebotene Datei im Honigtopf" jetzt zwangsläufig die Frage nach dem
Rechteinhaber in den Vordergrund rücken. Dazu noch einmal ein Auszug aus dem Fraunhofer-Gutachten von
Seite-42 Bild-91 die letzte Zeile.
Bild 93 - Auszug aus dem Fraunhofer-Gutachten 11.08.2006 (3.4 ... eDonkey-Clients)
Hier stellt sich natürlich die Frage, in welcher Form der Rechteinhaber überhaupt dieser "Bereitstellung zum
Download" zugestimmt hatte. Zum einen ist die Loggerbude (i.d.R.) nicht der Rechteinhaber an dem angebotenen
Werk. Zum anderen dürfte ein Rechteinhaber bei der Beauftragung der Loggerbude wohl kaum den Vertragstext
"Erlaubnis zur Bereitstellung auf einem Honeypot, o.ä." verwenden. Allerdings, irgendeinen Vertrag muss es
mit der Loggerbude ja geben, damit diese nicht selbst als illegaler Filetauscher in's Schussfeld gerät.
Und genau solche Art Verträge gibt es tatsächlich, mit teilweise bemerkenswert versteckten Formulierungen,
aus denen man problemlos einen regelrechten Persilschein für den Upload ableiten kann. Das dort natürlich nichts
von einem Honigtopf geschrieben steht, dürfte wohl jedermann einleuchten. Schauen wir uns also mal einige solcher
Verträge genauer an. Damit die Bilder nicht zu groß werden, wurden nur die relevanten Abschnitte ausgeschnitten
und hier gezeigt.
Bild 94 - Auszug aus einem abgeschlossenen Vertrag (DigiProtect)
[1]
[2]
Bild 95 - Auszug aus einem noch nicht abgeschlossenen Vertragsmuster (Resisto IT)
[3]
Im Bild-94 Punkt [1] ist übliche bekannte Spruch für die Legitimation des Log-Vorgangs zu sehen. Diese findet sich
praktisch in jedem Vertrag wieder. Interessanter wird es hier schon im Punkt [2]. Die Loggerbude räumt sich hier
gleich mal das Recht ein, dass Werk auch kostenlos an Endbenutzer anzubieten. Das damit der Honigtopf gemeint
ist, dürfte hier wohl auch der letzte P2P-Nutzer erkennen. Was in dem Vertrag unter "kostenpflichtig" zu verstehen
wäre, können wir allerdings auch nicht beantworten. In den von uns getesteten eMule-Versionen hatten wir bisher
noch kein aufklappendes Fenster mit "Zahlungsbetrag und Kreditkartennummer" feststellen können.
Im Bild-95 sind die ersten beiden Punkte identisch. Man könnte glatt meinen, hier hat Einer vom Anderen den
Vertragstext einfach abgeschrieben. Gleich einen Schritt weiter geht man hier allerdings unter Punkt [3]. Das Recht
des kostenlosen Anbietens kann auf einen Dritten übertragen werden. Im Klartext, der Upload-Honigtopf wird an
eine dritte Person übertragen, die nicht mit der Loggerbude in Verbindung zu bringen ist.
>> Seite 44
Upload/Verträge
Upload/Verträge >>
Seite 44 von 51
Bild 96 - Auszug aus einer Bestätigung zu einem Vertrag
Im Bild-96 gibt es eine Besonderheit. Hier handelt es sich nicht um den Vertrag, sondern bereits um eine
Bestätigung des Vertrages mit der Loggerbude. Und hier hat man definitiv den Vogel abgeschossen.
Die Loggerbude entscheidet nach freiem Ermessen, was mit dem Werk im Netz veranstaltet wird. Bei dieser
Gelegenheit lässt sich dann auch gleich nach Gutdünken frei entscheiden, beim wem das Anbieten des Werkes
als rechtswidrig festgelegt wird, und bei wem mal eben nicht. Das es sich dabei nur um den Honigtopf-Uploader
handeln kann, dürfte wohl auch klar sein.
An dieser Stelle haben wir damit verstanden, was in den höchst interessanten Loggerbudenverträgen unter der
"Auswertung in dezentralen Computernetzwerken" zu verstehen ist. Nämlich die Auswertung, wer das Werk vom
Honigtopf herunter geladen hat. Und damit verstehen wir jetzt endlich auch den letzten fraglichen Punkt in einer
völlig sinnentleerten Pressemitteilung, welche im Jahre 2009 auf die öffentliche Presse abgekippt wurde.
Bild 97 - Auszug aus einer Pressemitteilung (DigiProtect)
Zumindest haben wir jetzt verstanden, wie man sich dem auf Seite-43 Bild-94 gezeigten Vertrag mit effizienten
Verfahren der Bewältigung stellt. In der Tat ist ein Honigtopf ein sehr effizientes Verfahren, um Downloader
festzustellen. Was wir allerdings noch nicht verstanden haben, was an dem Download hier dann illegal sein soll.
Irgendwie will diese Aussage nicht so ganz zu dem Fraunhofer-Gutachten (siehe Seite-42 Bild-91) passen. Und
ein entsprechendes Warnfenster im eMule, "Sie dürfen dieses kostenlose Angebot von uns nicht annehmen. Es
ist für Sie illegal.", haben wir bisher auch nicht entdecken können. Das könnte natürlich auch daran liegen, dass
wir zumindest den in der Abmahnung behaupteten Dateihash gar nicht heruntergeladen hatten. Aber das ist
sicher wieder eine ganz andere Baustelle.
Eigentlich könnten wir an dieser Stelle das Thema beenden, wenn es da bezüglich dieser Honigtöpfe nicht doch
noch eine letzte Frage geben würde. Wie wird denn das nun mit dem Honigtopf gemacht, wenn sich hinter dem
angebotenen Dateihash ein Porno-Werk verbirgt ? Da es ja im eMule auch keine Abfrage für die Altersverifikation
gibt, würde hier der § 184 StGB ganz böse zuschlagen. Auch von der möglichen Ausrede der Loggerbude, der
Rechteinhaber hätte das "für den Endbenutzer kostenfreie Anbieten" ja so vertraglich selbst beauftragt, dürften
weder ein Gericht, noch die Jugendschützer besonders erbaut sein. Also werfen wir noch einmal einen Blick in's
ed2k-Netzwerk und die dort verbreiteten Dateihashes mit Porno-Werken dahinter.
>> Seite 45
Upload/Verträge
Honeypot/Fake-Identifikation >>
Seite 45 von 51
23.) Verteilung über Fake-Namen auf dem Honigtopf (Analyse Porno-Werke)
Zunächst müssen wir noch einmal einen Blick zurück auf die Seite-39 Bild-84 werfen. Dort wird ja sinngemäß
behauptet, man könne von jeder Original-Datei eine nicht zu unterscheidende Fake-Datei erzeugen, und somit im
Prinzip auch den ed2k-Hash fälschen. Also ganz gezielt eine sog. Hash-Kollision erzeugen. Das würde bedeuten,
im ed2k-Netz gäbe es dann zwei Dateien, mit gleichem Dateinamen und gleichem Dateihash, jedoch verschiedener
Inhalt. Der Downloader bzw. der eMule könnten dann nicht mehr unterscheiden, ob man denn nun die Original-Datei
oder den Fake herunter lädt. Grundsätzlich ist beim 32-stelligen ed2k-Hash (ein sog. MD4-Hash) eine solche
Hashkollision natürlich möglich. Allerdings ist die Chance auf eine Solche zu treffen, oder diese gezielt zu erzeugen,
eher vergleichbar mit einem Lotto-Hauptgewinn. Hier ist natürlich schon zu erwarten, dass die Loggerbuden gerade
beim Thema "Honigtopf und Porno-Werke" genau den selben Unsinn wie auf Seite-39 Bild-84 behaupten würden.
Wir verteilen nicht das Original-Werk, schon gar nicht eine Porno-Datei, sondern nur spezielle Fake-Dateien.
Solchen technischen Blödsinn kennen wir bereits zur Genüge, alles ist grundsätzlich "Spezial" bei den Loggerbuden.
Und trotzdem sind solche seltenen Hashkollisionen durchaus möglich. Ob sie zufällig entstanden sind, oder gezielt
erzeugt wurden, lässt sich schon im ed2k-Netz mit relativ einfachen Mitteln erkennen. Zudem verfügen nicht nur die
eMule-Clients über diverse Plugins zur erweiterten Hashprüfung, sondern auch die ed2k-Server. Und trotzdem
kann es solche Hashkollisionen durchaus geben, wie die nachfolgenden zwei Beispiele zeigen. Es sind i.Ü. die
einzigen Hashkollisionen, die wir von den weit über tausend abgemahnten Werken entdecken konnten.
>> Web-Link <<
Im Bild-98 sehen wir eine Hashkollision die zufällig entstanden ist. Zu einer relativ kleinen Audio-Datei einen Fake
zu erzeugen, der vom Dateihash zu einer 1.36 GByte Video-Datei passt, wäre derartig plump, dass es jeder
Downloader sofort bemerken würde. Zudem hat die Fake-Datei hier keine vollständig verfügbaren Quellen, kann
also unmöglich von einem Honigtopf stammen. Dieser Hash-Fake entstand also rein zufällig.
>> Web-Link <<
Im Bild-99 sehen wir eine Fake-Datei die eindeutig gezielt "hergestellt" wurde. Der Dateihash, die Dateigröße, sowie
auch der Dateiname stimmen mit dem Porno-Werk überein. Allerdings hat bereits das sog. Media-Plugin auf einem
ed2k-Server den Fake aufgedeckt, der Video-Codec stimmt nicht überein. Zahlreiche eMule-Mod-Versionen können
hier sogar eine Warnmeldung (Warnung bei unzuverlässigen Dateien) ausgeben, wenn Datenpakete von einer
solchen Datei empfangen werden. Weiterhin ist diese Fake-Datei bereits bei mehreren Quellen vollständig
vorhanden. Da ist mit Sicherheit auch der Honigtopf dabei. Und trotzdem zeigt auch dieses Muster hier, die Fakes
sind relativ leicht erkennbar. Die Behauptung von Seite-39 Bild-84 ist also schlichtweg nur dummes Gerede.
Damit dürfte an dieser Stelle klar sein, dass der Einsatz von Fake-Dateien auf einem Honigtopf praktisch gar nicht
umsetzbar ist. Zumindest nicht bei sehr großen Video-Dateien, die sich vom Downloader leicht identifizieren lassen.
Die Fragen lauten also:
Wie macht man das denn nun mit den Porno-Videos auf dem Honigtopf ?
Benennt man diese jetzt einfach nur um, aufgrund der o.g. Problematik der sonst sofortigen Fake-Erkennung im
ed2k-Netz bzw. bei den Downloadern ?
Diesen Fragen sind wir bereits ab dem Jahre 2009 mit zahlreichen aktiven Tests im ed2k-Netz nachgegangen, mit
teilweise bemerkenswerten sowie auch erstaunlichen Ergebnissen.
Weiter dazu auf der nächsten Seite.
>> Seite 46
Honeypot/Fake-Identifikation
Honeypot/Hash-Prüfung >>
Seite 46 von 51
Ausgangspunkt der Recherchen im ed2k-Netz zu den berüchtigten Porno-Werken war eher eine rein zufällige
Entdeckung. Bei der Überprüfung eines Dateihashes aus dem sog. Ermittlungsdatensatz einer Abmahnung sind wir
auf höchst seltsame Dateinamen gestoßen, unter denen der Dateihash im ed2k-Netz verbreitet wurde.
>> Web-Link <<
Im Bild-100 handelte es sich nicht um eine Fake-Datei, sondern schlichtweg nur um einen sog. Fake-Namen der
Original-Datei, die von einem Uploader im Shared-Ordner des P2P-Clients offensichtlich einfach nur umbenannt
wurde. Das es bereits fünf vollständige Quellen gab, hatte sich dieser Fake-Name also auch schon verbreitet.
Die Frage war allerdings, wer kam auf Idee, die Datei im Upload/Shared-Ordner mit einem ganz offensichtlichen
Datumstempel "25.10.2009", einer laufenden Nummer "87", und auch noch einer Dateiendung "vlog" zu versehen.
Das könnte man glatt als Datei für das "Verify Logging" betrachten. Also der übliche Durchschnitts-Filesharer wäre
sicherlich kaum auf die blöde Idee gekommen, die Datei im Upload-Ordner so zu benennen. Auch die laufende
Nummer "87" war offensichtlich kein Zufall. Wird fanden zu diesem Zeitpunkt bereits über 70 dieser höchst
seltsamen vlog-Dateinamen an nur einem Tag im ed2k-Netz.
Auch die folgende Suchen nach den Porno-Werken auf diversen P2P-Portal-Seiten waren eher zufällig angelegt.
Was wir allerdings hier dann feststellen mussten, war simpel ausgedrückt der absolute Hammer.
Bild 101 - Auszug aus einer P2P-Portal-Seite
Das sog. First-Releaser-Datum auf den Esel-Seiten stimmte nahezu durchweg exakt mit dem o.g. vlog-Datum
überein, oder es lag nur einige wenige Tage davor. Auch der Dateihash hinter dem Download-Link stimmte überein.
Zu diesem Zeitpunkt war damit für uns eindeutig klar, diese vlog-Dateinamen werden nicht von irgendwelchen
Witzbolden verbreitet, hier steckte eindeutig ein System dahinter. Und das stammte ganz sicher nicht vom sonst
bekannten Durchschnitts-Filesharer. Und die Einzigen die für den Sinn einer solchen Aktion überhaupt in Frage
kämen, waren nun mal die Porno-Abmahner bzw. die mit der Überwachung beauftragten Loggerbuden.
Bild 102 - Überprüfung in der Abmahndatenbank (abmahndatenbank.de)
>> Web-Link <<
Und wie denn auch zu erwarten war, wurde das Porno-Werk auch in der Abmahndatenbank gefunden. Der erste
bekannte Log-Zeitpunkt von einem Ermittlungsdatensatz aus einer Abmahnung fällt auch noch genau auf den
selben Monat wie das o.g. First-Releaser-Datum (Bild-101). In der Tat ein recht bemerkenswerter Zufall.
>> Web-Link <<
Weiterhin sind wir auch noch auf solche vlog-Dateinamen gestoßen, die mit einen ganz offensichtlich noch älteren
Datumstempel "12.08.08" versehen waren. Laut Abmahndatenbank wurde dieses Porno-Werk jedoch bereits im
Jahre 2007 abgemahnt. Hier drängte sich bereits der erste Verdacht auf, dass diese Dateien ganz gezielt über einen
Honigtopf im Jahre 2008 noch einmal "angeschoben" wurden. Mit dem Ziel zusätzliche Downloader anzulocken, mit
deren abgefischten IP-Adressen man zusätzliche Abmahnungen zur Umsatzmaximierung generieren konnte.
Gemäß der laufenden Nummer war man also im Jahre 2008 schon bei Porno-Datei Nummer "53".
>> Seite 47
Honeypot/Hash-Prüfung
Honeypot/ed2k-Scans >>
Seite 47 von 51
Im weiteren Verlauf der Recherchen sollte festgestellt werden, bis zu welchem Datumbereich diese vlog-Dateinamen
überhaupt zurückreichen. Sofern diese Dateien überhaupt noch im ed2k-Netz zu finden waren.
>> Web-Link <<
So waren wir denn auch nicht mehr überrascht, dass die laufende Nummer "11" bereits am Anfang des Jahres 2008
lag. Hier zeigt sich schon in etwa, wann mit diesem Spuk bereits begonnen wurde. Interessant zudem noch, dass
wir dieses Porno-Werk nicht in der Abmahndatenbank gefunden hatten. Was uns bei dieser Quellenverfügbarkeit
auch gar nicht verwundert hatte. Hier war man wohl mit dem Honigtopf und abfischen von IP-Adressen ganz
offensichtlich leer ausgegangen. Also hier mal eben keine Abmahnungen über's DE-Land abgekippt.
Im Frühjahr 2010 stand nach umfangreichen Recherchen nachweislich fest, dass diese dubiosen vlog-Dateinamen
ausschließlich nur bei solchen Dateien zum Einsatz gekommen waren, hinter deren ed2k-Hash sich ein Video mit
einem Porno-Werk verbarg. Weiterhin wurden die Recherchen dann mit aktiven Scans direkt im ed2k-Netz erweitert.
Bild 105 - ed2k-Netzscans / Stand 09.07.2010 (Server-Quellenindexe)
Zudem mussten wir eine weitere interessante Entdeckung machen. Bei diesen vlog-Dateinamen handelte es sich
um Porno-Werke, die laut der bekannten Abmahndatenbank durchweg nur einem einzigen Abmahner bzw. dessen
beauftragter Loggerbude zuzuordnen waren. Und es waren auch Werke dabei, über die noch keine Abmahnungen
bekannt worden waren.
Unmittelbar nach dem o.g. Zeitpunkt (Bild-106) war eine detaillierte Auswertung zu diesen dubiosen vlog-Dateien in
einem bekannten Anti-Abmahnwahn-Forum veröffentlicht worden. Was wir nicht erwartet hatten, war die erstaunliche
Reaktion bzw. Veränderung, die sich im ed2k-Netz bei diesen vlog-Dateien nach dieser Veröffentlichung einstellte.
>> Seite 48
Honeypot/ed2k-Scans
Honeypot/vlog-Bericht >>
Seite 48 von 51
Bild 107 - Auszug aus einem Anit-Abmahnwahn-Forum (Beschreibung vlog-Dateien)
In dieser Veröffentlichung in einem Anti-Abmahnwahn-Forum wurden unzählige dieser dubiosen vlog-Dateien mit
den dahinter liegenden Dateihashes, den Dateinamen des Porno-Werkes, sowie entsprechende Angaben zu den
bereits erfolgten Abmahnungen veröffentlicht. Die Reaktion auf diese Veröffentlichung wurde danach im ed2k-Netz
schlagartig sichtbar.
Innerhalb eines Monats brach die Anzahl dieser im Netz verbreiteten vlog-Dateinamen nicht nur schlagartig
zusammen, sondern die verbliebenen vlog-Dateien wurden häufig auch noch umbenannt. Wir mussten uns zudem
noch zu zahlreichen ed2k-Servern einzeln verbinden, um die vlog-Dateinamen überhaupt noch zu finden.
Interessanterweise funktionierte hier die Suche nach den vlog-Dateien über die “Globale Serversuche” auf einigen
ed2k-Servern plötzlich nicht mehr. Das war in der Tat schon äußerst merkwürdig, und veranlasste uns auch zu
einigen grundsätzlichen Überlegungen.
Hier war als eindeutig klar, irgendwer hatte auf die Veröffentlichung (siehe Bild-107) sehr schnell reagiert. Die Frage
war nur noch “Wer ?”. Zunächst einmal die Frage, wer hatte die o.g. Veröffentlichung eigentlich gelesen. Das war
ein Anti-Abmahnwahn-Forum, wo sich vorrangig P2P-Nutzer belesen, die bereits eine P2P-Abmahnung erhalten
hatten. Das diese Nutzer nach ihrer Abmahnung sich weiter ungezügelt am Filetausch beteiligten, konnte nach dem
ersten Abmahnungs-Schock bei der Mehrheit der Nutzer sicher erst einmal ausgeschlossen werden. Diese kamen
für die schlagartige Reduzierung der vlog-Dateinamen also erst einmal nicht in Frage. Damit blieb eigentlich nur noch
eine Nutzergruppe übrig, und zwar die Betreiber der Honigtöpfe, die diese dubiosen vlog-Dateinamen wohl ganz
offensichtlich mit einem bestimmten Ziel im Netz verbreitet hatten.
Zudem mussten wir auch nach einer Kad-Suche feststellen, dass die Quellenverfügbarkeit zum Dateihash selbst
(also dem dahinter liegenden Porno-Werk) kaum gesunken war. Es waren tatsächlich zu dem jeweiligen Dateihash
nur diese dubiosen vlog-Fake-Namen verschwunden. Zumindest dachten wir das anfänglich. Denn tatsächlich
wurden diese einfach in immer kürzeren Zeitabschnitten erneut umbenannt. Mit einem neuen Typ von Fake-Namen.
Und dieser wollte schon von der besonderen Art und Weise der Umbenennung überhaupt nicht mehr zum
Durchschnitts-Filesharer passen.
Hier blieben definitiv nur noch die Betreiber der Honigtöpfe übrig.
>> Seite 49
Honeypot/vlog-Bericht
Honeypot/neue FakeNamen >>
Seite 49 von 51
An Stelle der vlog-Dateinamen erschienen im ed2k-Netz nach der Veröffentlichung (Seite-48 Bild-107) neue
Fake-Namen, welche eigentlich schon gar nicht mehr als Dateinamen zu erkennen waren. Im Prinzip waren das nur
noch sinnlose Ansammlungen von Buchstaben mit einer Dateiendung “.avi”. Wir mussten zudem sämtliche dieser
Dateinamen-Recherchen in einer Datenbank erfassen, um hier überhaupt noch “den Überblick” zu behalten. Diese
Fake-Namen zu den Porno-Werken wurden teilweise im zwei Wochenabstand verändert. Ganz sicher nicht von den
sog. Durchschnitts-Filesharern.
Bild 110 - Auszug aus einer ed2k-Netzrecherche (Datenbank Porno-Werke)
Bild 111 - Auszug aus einer P2P-Portal-Seite (p2pworld.to)
Beim Vergleich von Bild-110 und Bild-111 sehen wir erneut, dass der vlog-Dateiname wieder exakt zum Datum der
Veröffentlichung auf einer Esel-Seite passt. Auch das der sog. Log-Vorgang (laut einem Ermittlungsdatensatz einer
Abmahnung) gleich im darauf folgenden Monat “08” erfolgte, verwunderte uns hier überhaupt nicht mehr. Neu waren
allerdings die völlig kryptischen Dateinamen, unter den denen das Porno-Werk jetzt verbreitet wurde, und die sich
in kurzen Abständen geändert hatten.
Die oben gezeigten Veränderungen bei den Dateinamen zeigten bereits ganz offensichtlich, dass diverse Betreiber
der Honigtöpfe die Veröffentlichung (siehe Seite-48 Bild-107) nicht nur gelesen hatten, sondern auch umgehend
darauf reagiert hatten. Da fühlte sich jemand bei seiner höchst dubiosen Upload-Tätigkeit wohl glatt erwischt.
Insofern wäre natürlich der nächste logische Schritt gewesen, diese Honigtopf-Strategie zu ändern, und die
dubiosen vlog-Dateinamen im ed2k-Netz verschwinden zu lassen bzw. durch andere Dateinamen zu ersetzen.
Also wurde besonderes Augenmerk auf solche in P2P-Portalen veröffentlichten Dateihashes gelegt, deren dahinter
liegende Porno-Werke derzeit noch nicht abgemahnt wurden.
Bild 112 - Auszug aus einer ed2k-Netzrecherche (Datenbank Porno-Werke)
Das Bild-112 zeigt, dass die von uns bereits vorab vermutete Änderung bei der Honigtopf-Strategie schneller eintrat
als erwartet. Bisher bestehende vlog-Dateinamen verschwanden schrittweise aus dem ed2k-Netz, während
hingegen neu veröffentlichte Dateihashes zu Porno-Werken ohne diese vlog-Dateinamen auftauchten. Statt dessen
wurde die neue Strategie mit den kryptischen Dateinamen, bei Porno-Werken die bis dahin noch nicht abgemahnt
wurden, durchweg umgesetzt.
>> Seite 50
Honeypot/neue FakeNamen
Honeypot/neue FakeNamen >>
Seite 50 von 51
An diesem Punkt dürften wohl kaum noch Zweifel darüber bestehen, dass auch diverse abgemahnte Porno-Werke
völlig schmerzfrei über einen Honigtopf zum Download angeboten werden. Auch die Strategie der Verschleierung
über kryptische vermurkste Dateinamen taugt hier als eindeutiger Beleg dafür.
Der normaler Durchschnitts-Nutzer, sowie auch ein Downloader und Liebhaber dieser Porno-Werke, würden
sicherlich kaum auf die Idee kommen solche Dateinamen zu verwenden. Bei mehreren Downloads gleichzeitig
würde der eben genannte Liebhaber nämlich völlig den Überblick verlieren, welche gerade downloadende
Datei “dfjhwrngn.avi” gehörte denn nun verdammt noch mal zu welchem Video. Das ein Download-Interessierter
nicht nach solchen kryptischen Namen suchen würde, muss sicher auch nicht näher erläutert werden.
Der First-Releaser von der Esel-Seite hätte sicher auch kein Interesse daran, solch kryptische Dateinamen in
Umlauf zu bringen. Dieser versteht sich als Dienstleister, mit dem Ruhm der Erste zu sein der dieses neu beschaffte
Filmwerk P2P-tauglich anbieten konnte. Das würde mit einem kryptischen Dateinamen wohl kaum funktionieren.
Kein Downloader würde das ernst nehmen bzw. an einem ganz offensichtlichen Fake Interesse zeigen.
Damit bleiben auch bei den Porno-Werken nur noch die Betreiber eines Honigtopfes übrig.
Auf die letztendlich noch zu stellende Frage, “Müssten die Loggerbuden als Betreiber eines Honigtopfes, oder
über einen direkt beauftragten Uploader, nicht fürchten damit erwischt zu werden ?”, haben wir zumindest zwei
recht einfache Anmerkungen.
Wer sollte die Loggerbude (oder einen beauftragten Uploader) beim Anbieten denn erwischen.
Wer sollte denn das überhaupt prüfen, ob das geloggte Werk beim Log-Vorgang gleichzeitig angeboten wurde.
Der eigentliche Hintergrund für diese einfachen Anmerkungen ist an einer völlig anderen Stelle zu finden. Und
dieser beginnt schon beim Kopfeintrag in der Loggerliste für das Beauskunftungsgericht, wo der betreffende
Provider für die aufgelisteten IP-Adressen bezeichnet wird.
Was bedeutet das eigentlich ?
Hier müssen wir uns zuerst über folgende Dinge im Klaren sein. Die DTAG ist nicht der einzige Provider am Markt,
und nicht jeder geloggte Filesharer hat seinen Anschluss dort. Das bedeutet, die Loggerbude wird auf ihrer ersten
Aufzeichnungsliste die IP-Adressen von mehreren Providern bzw. Netzbetreibern vorfinden. Und da die zuständigen
Beauskunftungsgerichte für den jeweiligen Provider nicht alle am selben Standort gelegen sind, muss also die
Loggerbude mehrere IP-Listen für den jeweils vorab ermittelten Provider filtern und erstellen. Und genau dort liegt
der eigentliche Hintergrund, die IP-Listen werden bereits vorab gefiltert.
Somit dürfte dann auch klar sein, dass die Loggerbude bereits bei dieser Vorab-Filterung problemlos auch diverse
IP-Adressen aussortieren kann, die von einem mit dem Upload beauftragten Honigtopf stammen. Selbst wenn eine
solche IP-Adresse doch mal versehentlich auf der Liste zur Klarnamen-Beauskunftung laden würde, wäre das auch
kein Problem. Das zuständige Beschlussgericht prüft hier sowieso grundsätzlich nichts. Und auch der betreffende
Provider hat selbst mit hunderten fehlerhaften IP-Adressen auf einer Liste (also solche die sich gar nicht erst
ermitteln lassen) offenbar keine Probleme. Man stellt einfach keine Fragen darüber, ein Gericht hat's ja schließlich
so angeordnet.
An dieser Stelle sind wir damit (leider) bei der Erkenntnis angelangt, dass trotz der auf Seite-44 ganz unten
genannten Kollision mit dem § 184 StGB der beauftrage Uploader eines Porno-Werkes nicht mit irgendwelchen
Problemen rechnen muss. Dabei spielt es überhaupt keine Rolle mehr, ob der Honigtopf bei einer Loggerbude,
oder bei einem beauftragten Dritten betrieben wird. Die kompromittierende IP-Adresse aus dem Upload des Werkes
lässt sich problemlos vertuschen oder aus einer Liste filtern.
Und solange noch nicht einmal bei Porno-Abmahnungen in diversen Gerichtsverfahren nachgefragt wird, wie denn
der Loggerbude hier eigentlich überhaupt ein Probe-Download gelungen sein soll, solange wird man mit den
Honigtöpfen bei Porno-Werken auch fleißig weitermachen.
An diesem letzten Musterbeispiel (Bild-113), was leider stellvertretend für unzählige gleichgelagerte Filmwerke steht,
sollten wir noch die Frage stellen, wie es der Loggerbude im April 2010 gelungen war, für die Abmahnungen im
Juli 2010 hier überhaupt abmahnfähige IP-Adressen zu generieren.
>> Web-Link <<
Nach bisherigen praktischen Erfahrungen im ed2k-Netz bleibt dafür nur noch eine einzig mögliche Erklärung übrig.
Die Loggerbude hatte versucht das Filmwerk über einen Honigtopf selbst zu verbreiten. Da dass irgendwie nicht
so recht gelingen wollte, hat man wenigstens die IP-Adressen einiger weniger Downloader abgefischt, und in den
folgenden Abmahnungen einfach als Upload verkauft. Die interessante Frage nach dem vermeintlich gerichtsfesten
und beweisgesicherten Probe-Download, sollten wir bei diesen Abmahnungen besser gleich komplett vergessen.
Damit beenden wir an dieser Stelle die sehr umfangreiche Abhandlung. Auf der folgenden Seite geben wir noch
einmal eine Zusammenfassung, und ziehen ein abschließendes Fazit.
>> Seite 51
Honeypot/neue FakeNamen
Zusammenfassung/Fazit >>
Seite 51 von 51
24.) Zusammenfassung und Fazit
Wie bereits gleich zu Beginn der Abhandlung festgestellt wurde, sind die meisten Behauptungen in einer Abmahnung
zum Thema Tauschbörsen und Filesharing nicht nur höchst fragwürdig, sondern teilweise auch ganz offensichtlich
gelogen. Es gibt die behauptete Spezialsoftware oft gar nicht, es wird statt dessen mit einem herkömmlichen
P2P-Client bei der Loggerbude gearbeitet, bei der Nachfrage zum behaupteten Gutachten verfallen Loggerbude und
Abmahner in tiefste Ratlosigkeit, und auf eine Anforderung zur Vorlage des gerichtsfest durchgeführten und
archivierten Testdatentransfers, wird an Stelle der Nachweisdaten nur noch eine Eidesstattliche Versicherung als
letzter Rettungsanker schnell aus dem Ärmel geschüttelt.
Im weiteren Verlauf der Abhandlung wurden an Hand eines eMule-P2P-Clients die bereits vorhandenen zahlreichen
Log-Möglichkeiten erläutert, was sich damit eigentlich alles genau feststellen lässt, wie der Ermittlungsdatensatz der
Abmahnung auf Richtigkeit überprüft werden kann, und ob der uns laut Abmahnung unterstellte illegale Upload als
Rechtsgrundlage für die Klarnamen-Beauskunftung häufig einfach nur erfunden wurde.
Im hinteren Teil der Abhandlung wurden die zahlreichen Schutzfunktionen eines eMule-Clients detailliert erläutert,
mit welchen Problemen eine Loggersoftware dadurch konfrontiert wird, warum der angeblich beweisgesicherte
Probe-Download nur bei einem äußerst geringen Prozentsatz der eMule-Nutzer funktionieren würde, wie sich die
tatsächlichen Aktivitäten eines möglichen Logger-Clients in den Log-Dateien feststellen lassen, und der eindeutige
Beleg dafür, dass die endlos langen IP-Aufzeichnungslisten fast durchweg nur Warteschlangen-Screenshots sind.
Im letzten Teil der Abhandlung wurde der Frage nach den sog. Honigtöpfen nachgegangen, auf welcher Grundlage
diese überhaupt erst entstanden sind, dass sich deren Einsatz bereits aus diversen Überwachungsverträgen
zwischen Rechteinhaber und Loggerbude ableiten lässt, eine Loggerliste mit mehreren tausend IP-Adressen gar
keine Zweifel mehr an einem Honigtopf zulässt, und dass bei der Verteilung von Porno-Werken eine ganz besonders
perfide Honigtopf-Strategie zum Einsatz kommt.
Und damit kommen wir zum abschließenden Fazit:
Wir haben im ed2k-Netzwerk (eMule & Co) keinerlei Zweifel mehr daran, dass aufgrund unzähliger
technischer Probleme bei der beweissicheren Durchführung des Testdatentransfers von einem eMuleNutzer, die generierten IP-Listenaufzeichnungen durchweg gar keinen illegalen Upload belegen. Um diese
Probleme nicht in einem finanziellen Desaster enden zu lassen, setzt man eher auf die Generierung von
Tausenden Adressen langen “Wir haben da zufällig was gesehen” IP-Listen, und schreckt dabei
offensichtlich auch nicht vor dem Einsatz von Honigtöpfen zurück. Und dass bereits vor längerer Zeit ein
IT-Dienstleister diese Honigtopf-Strategie sogar noch mit einem Patentantrag veredeln wollte, lässt bei uns
auch keinerlei Zweifel mehr aufkommen, dass diese Honigtöpfe bereits seit Beginn der P2P-Abmahnungen
als Mittel zum Zweck eingesetzt wurden. Und leider sieht es auch so aus, dass die Vertreiber von billigsten
und schlecht verkäuflichen Porno-Werken, zum Zwecke der Umsatzoptimierung schon längst diese
Honigtopf-Masche mit einer besonders ausgeklügelten Fake-Namen-Strategie für sich entdeckt haben.
Diese Abhandlung soll dazu beitragen, dass vor allem Abgemahnte von Porno-Werken nicht nur den Inhalt
ihrer Abmahnung, sondern auch ihren irgendwann eingesetzten P2P-Client genauer unter die Lupe nehmen.
Es kann wohl nicht angehen, dass die ursprünglich vorgesehene Verfolgung von Urheberrechtsverletzungen
in P2P-Netzwerken, immer mehr zu einem gewinnbringenden Vertriebsmodell für ehemals unternehmerisch
erfolglose Trittbrettfahrer verkommt.
25.) Schlussbemerkung
Zum Abschluss wollen wir noch einige Worte an die sog. IT-Dienstleister richten, bei denen wir im Verlauf dieser
Abhandlung weder irgendwelche speziell entwickelte Aufzeichnungssoftware erkennen konnten, noch fehlerfreie
Beweissicherungsmechanismen sichten konnten, sondern schlichtweg nur noch ein umsatzorientiertes Abzockermodell vorfanden, welches mit zusammen geklempnerten und geschönten IP-Aufzeichnungslisten die hiesige
Rechtsprechung im Urheberrecht permanent hinters Licht führt.
Wir sind uns auch sehr wohl bewusst darüber, dass Ihnen diese Worte überhaupt nicht gefallen werden. Denn
diese kratzen an Ihrem Image als sog. professionelle IT-Dienstleister, und lassen Ihre vermeintlich speziell
entwickelten Antipiracy-Technologien nur noch als missglücktes ClosedSource-Softwareprojekt dastehen.
Dabei könnte es doch für Sie so einfach sein, dieses verlorene Profi-Image wieder gründlich aufzupolieren.
Legen Sie ihn doch ganz einfach und nachvollziehbar vor, diesen gerichtsfest gesicherten und archivierten
Testdatentransfer. Zeigen Sie uns doch einfach, wie Sie es mit einem Überwachungs-Client geschafft haben wollen,
innerhalb von 24 Stunden von 500 eMule-Nutzern im ed2k-Netz diesen illegalen Upload zu speichern, ohne dabei
selbst den zu überwachenden ed2k-Dateihash anzubieten. Bei dieser Gelegenheit sollten Sie uns auch gleich mal
aufzeigen wie Sie ihn verifiziert haben, diesen unbekannten ed2k-Dateihash, zwei Monate bevor er in diversen
P2P-Portalen gesichtet wurde. Also werte IT-Dienstleister im Bereich der Filesharing-Abmahnungen, ...
... wo ist denn nun dieser Testdatentransfer von den 500 illegalen eMule-Uploadern,
den Sie mit Ihrer Spezialsoftware gerichtsfest gesichert und archiviert haben.
Mit besten Grüßen
Loggi-Leaks
Juli 2011
Zusammenfassung/Fazit
<< Ende

Erläuterung emule-Verbose-log - Loggi

Transcription

Similar documents

Entwicklung einer generischen Instant Messenger Anwendung für

Kampfverband 13

PRN45HD

Newsletter-Recht - IHK Saarland

Blog Export: Blog von Fredy K?nzler, Winterthur, http://blog.kuenzler

KMUs fast unsichtbar im Netz - Heftarchiv

Die Folien

BEDIENUNGSANLEITUNG DATENLOGGER DCX - keller

Aktueller Stand der Erbschafts- und Schenkungssteuer

AnySTICK Die Dokumentation - AnySTICK - USB

LEO RECORD Ei - ACE