Snitlev
26.07.10, 11:16
Abgleich der Systemzeit mit der offiziellen Zeit in Deutschland
Um für alle benötigten Zeitstempel eine möglichst genaue Uhrzeit zu erhalten, wird die Systemzeit von FileWatch alle 5 Minuten mit Hilfe des Network Time Protokolls (NTP) synchronisiert.
Das Network Time Protokoll ist ein Standardprotokoll zur Synchronisierung von Uhren in Computersystemen. Das Protokoll wurde speziell entwickelt, um eine zuverlässige Zeitabfrage über Netzwerke mit variabler Paketlaufzeit zu ermöglichen.
Als Quelle der offiziellen Zeit in Deutschland betreibt die Physikalisch-Technische Bundesanstalt (PTB) zwei sogenannte „Stratum-1“ Server. Diese Server erhalten ihre genaue Uhrzeit direkt von einer Atomuhr oder Funkuhr.
Die Media Protector GmbH betreibt zwei eigene „Stratum-2“ Server, die wie folgt eingesetzt werden: Die beiden Stratum-2 Server synchronisieren sich alle 16 Sekunden mit einem der beiden Stratum-1 Server der PTB. Sollte dieser eine Server einmal nicht erreichbar sein, so wird automatisch der zweite Stratum-1 Server der PTB zur Synchronisation der Zeit herangezogen.
Alle Systeme, auf denen FileWatch installiert ist, synchronisieren sich wiederum alle 5 Minuten mit einem der Stratum-2 Server der Media Protector GmbH. Sollte dieser eine Server bei der Media Protector GmbH einmal nicht erreichbar sein, so dient automatisch der zweite Stratum-2 Server der Media Protector GmbH zur Synchronisation der Zeit.
Sollte trotz der häufigen Synchronisation zwischen einem FileWatch-System und einem Stratum-2 Server eine Zeitdifferenz von mehr als 0,04 Sekunden entstehen, so werden sämtliche Datensätze der Protokollierung verworfen, die seit der letzten hinreichend genauen Synchronisation (mit einer Zeitdifferenz von weniger als 0,04 Sekunden) entstanden sind. Zeitlich ungenaue Datensätze werden somit nicht für eine spätere Auswertung herangezogen. Auf diese Art und Weise wird sichergestellt, dass sich die späteren Ermittlungen auf einen ausreichend genauen Zeitstempel im Hinblick auf die protokollierte IP-Adresse und weiteren Daten beziehen.
FileWatch enthält einige wichtige Funktionen, die es ermöglichen, Daten über Aktivitäten anderer Clients des Filesharing-Netzwerks zu erheben und in die eigene Datenbank wegzuschreiben. Insbesondere kann das Programm entscheidende Daten mitprotokollieren, wenn ein Client bestimmte Dateien aus dem Filesharing-Netzwerk herunterlädt oder bestimmte Dateien anderen Benutzern des Filesharing-Netzwerks zum Download anbietet.
FileWatch nutzt zur Protokollierung eines Clients grundsätzlich zwei Varianten:
1. Die erste Variante, entscheidende Daten mitzuprotokollieren, ergibt sich, nachdem sich ein Client nach erfolgreichem Handshake mit FileWatch verbunden hat bzw. Informationen über den mit FileWatch verbundenen Client aktualisiert worden sind. Hierbei werden Daten über den jeweiligen Client und über die betreffende Datei ausgetauscht, die sogenannten „Meta-Daten“.
2. Die zweite Variante ergibt sich, wenn ein Client an FileWatch Nutzdaten überträgt (Testdownload). FileWatch nutzt diesen Zeitpunkt aus, da sich zusätzlich zu den Meta-Daten auch noch konkrete Aussagen zu den übermittelten Nutzdaten (d.h. zu den übermittelten Dateiinhalten selbst) sammeln lassen.
Die wichtigsten Daten, die FileWatch mitschreibt, sind die folgenden:
* Sekundengenauer Zeitstempel, der angibt, wann die Protokollierung des beobachteten Clients genau erfolgte
* Filehash-Wert der beobachteten Datei
* Pseudonym, unter dem der Benutzer in der Tauschbörse auftrat
* Hash-Wert, der den Client im eD2K-Netzwerk eindeutig identifiziert
* Name der Tauschbörsensoftware des protokollierten Clients
* Version der Tauschbörsensoftware des protokollierten Clients
* Maximale Anzahl der Parts, die sich für die beobachtete Datei ergeben haben
* Gesamtgröße der beobachteten Datei (in Bytes)
* Anzahl der Parts, die der protokollierte Client tatsächlich zu der beobachteten Datei schon heruntergeladen hat
* IP-Adresse des protokollierten Internetanschlusses
* Internet Service Provider (ISP), der für den protokollierten Client zum fraglichen Zeitpunkt zuständig war
* Graphische Darstellung, welche Parts bereits von dem beobachteten Client komplett heruntergeladen worden sind und welche nicht
* Ein Zeichen, das angibt, ob FileWatch versucht hat, vom protokollierten Client Daten der beobachteten Datei herunterzuladen („d“ für „download“) oder ob der protokollierte Client versucht hat, Daten der beobachteten Datei von FileWatch herunterzuladen („u“ für „upload“).
FileWatch ist in der Lage, einen Client auch über Monate hinweg zu protokollieren, selbst wenn sich die Client-IP regelmäßig ändert.
Neben der Protokollierung von Aktivitäten anderer Clients im eD2K-Netzwerk ermöglicht FileWatch auch das Herunterladen von Dateien, die im Filesharing-Netzwerk angeboten werden.
Da die Media Protector GmbH bei ihren Recherche- und Protokollierungsaktivitäten im Netzwerk nicht selbst als Verteiler von urheberrechtlich geschütztem Material auftreten kann, ist durch eine programmtechnische Besonderheit der Upload von Dateien - im Gegensatz zu den regulären, weit verbreiteten Clients - vollständig unterbunden.
Wie bereits erwähnt, bietet jeder Benutzer, der Dateien aus dem eD2K-Netzwerk herunterlädt, diese Dateien normalerweise auch ohne weiteres Zutun anderen Benutzern im Netzwerk an. Typischerweise geschieht also das Anbieten und Herunterladen von Dateien (quasi) gleichzeitig.
Ein Benutzer hat zusätzlich noch die Möglichkeit, explizit Dateien für das eD2K-Netzwerk freizugeben. Hierzu existiert in den Optionen aller gängigen eD2K-Clients die Möglichkeit, spezielle Ordner oder Ordnerstrukturen freizugeben. Die aus diesen Freigaben resultierende Liste an Dateien wird als „Shared List“ bezeichnet.
Nachdem FileWatch einen erfolgreichen TCP-Verbindungs-Handshake mit einem (anderen) Client durchgeführt hat, wird dieser Client gefragt, ob er seine Shared List an FileWatch übermitteln möchte. Beantwortet der Client diese Anfrage positiv, so wird anschließend die Shared List an FileWatch übermittelt. FileWatch ist dann in der Lage, sämtliche Einträge der Shared List in der eigenen Datenbank abzuspeichern.
Wenn eine Datei innerhalb des eD2K-Netzwerks überwacht werden soll, so wird an FileWatch der Filehash-Wert der Datei übergeben. Der Filehash-Wert wurde zuvor von den Mitarbeitern der Media Protector GmbH für diese Datei berechnet (indem die eD2K-Standardalgorithmen verwendet werden).
Der erste Client, der FileWatch die zu überwachende Datei anbietet, übermittelt FileWatch unter anderem folgende Informationen:
* Liste mit allen Parthash-Werten der Datei
* Filehash-Wert der Datei
Nach der Übermittlung dieser Informationen berechnet FileWatch aus der Liste der Parthash-Werte der Datei den eindeutigen Filehash-Wert der Datei.
Anschließend führt FileWatch folgende Vergleiche durch:
1. Ist der aus den Parthash-Werten errechnete Filehash-Wert identisch mit dem Filehash-Wert der zu beobachtenden Datei?
2. Ist der von dem Client gesendete Filehash-Wert identisch mit dem Filehash-Wert der zu beobachtenden Datei?
Liefern beide Vergleiche ein positives Ergebnis, so wird die Liste mit den Parthash-Werten für eine spätere Verwendung abgespeichert. Liefert einer der beiden Vergleiche einen Fehler, so wird bei einem neuen Client versucht, die Liste mit den Parthash-Werten und den Filehash-Wert zu beziehen.
Wenn die Vergleiche zu einem positiven Ergebnis kamen, beginnt FileWatch, die Datei von dem beobachteten Client herunterzuladen. FileWatch verifiziert den korrekten Download von jedem einzelnen Part der Datei. Dies geschieht dadurch, dass nach dem vollständigen Aufsammeln aller zu einem Part gehörigen Bytes der Parthash-Wert errechnet und mit dem zuvor abgespeicherten Parthash-Wert aus der zuvor übermittelten Liste verglichen wird. Ist die Übereinstimmung der Parthash-Werte positiv, so schreibt FileWatch die relevanten Daten aller Clients, die an der Vervollständigung dieses Parts beteiligt waren, in eine Datenbank. Damit kann FileWatch sicher feststellen, dass von jedem der protokollierten Clients korrekte Daten zu einem bestimmten Part erhalten wurden und es sich nicht um einen sogenannte „Leecher-Client“ handeln kann (unter einem „Leecher-Client“ versteht man einen modifizierten Client, der nur Downloads, aber keine Uploads ermöglicht).
Kann keine Übereinstimmung bei den zu vergleichenden Parthash-Werten festgestellt werden, muss angenommen werden, dass ein Übertragungsfehler stattgefunden hat. In diesem Fall wird der gesamte Part verworfen und der Download-Vorgang wird neu begonnen. FileWatch verwirft ebenfalls sämtliche Daten aller Clients, die an der Vervollständigung dieses Parts beteiligt waren. Auf diese Weise wird auf jeden Fall verhindert, dass Clients zu Unrecht protokolliert werden.
Die Wahrscheinlichkeit, dass ein Parthash-Wert trotz falsch übertragener Daten tatsächlich mit dem Parthash-Wert aus der übermittelten Liste übereinstimmt, geht gegen null (1:2128 – fünf Mal einen 6-er im Lotto hintereinander wäre wahrscheinlicher).
Um einen unerschütterlichen Nachweis führen zu können, dass ein Client tatsächlich die Daten einer zu überwachenden Datei an FileWatch geschickt hat, werden nicht nur die Parthash-Werte verifiziert, sondern zusätzlich noch die ersten 10.240 Bytes an Daten abgespeichert, die der Client für einen Part geliefert hat. Es werden also pro Client und pro Part originäre 10.240 Bytes große Datenblöcke in der Datenbank der Media Protector GmbH gespeichert. Auf diese Weise lässt sich gut nachvollziehen, welche Clients zu welchem Part und damit auch zu einer Komplettierung der gesamten beobachteten Datei beigetragen haben.
Die Größe dieser 10 kB großen Datenblöcke ist übrigens für einen sicheren Nachweis völlig ausreichend, da die Wahrscheinlichkeit, dass zufällig Daten übermittelt wurden, die mit dem Datenblock der originären Datei bzw. Referenzdatei identisch sind, praktisch null ist (genau genommen ist die Wahrscheinlichkeit 1:281.920 – 1000x hintereinander einen 6-er im Lotto wäre deutlich wahrscheinlicher).
Zu jedem Datenblock wird zusätzlich festgehalten, wo er innerhalb der Datei beginnt und wo er endet. Somit ist es möglich, dass nach jedem erfolgreichen Testdownload die 10.240 Bytes automatisiert innerhalb der Referenzdatei (Datei, die von den Mitarbeitern der Media Protector GmbH bereits im Vorfeld positiv auf Übereinstimmung mit dem Originalwerk überprüft wurde und die auf den Archiv-Servern der Media Protector GmbH gespeichert ist) gesucht und auf Übereinstimmung geprüft werden.
Durch dieses Verfahren kann FileWatch nicht nur sicher feststellen, dass von einem protokollierten Client korrekte Daten zu einem bestimmten Part geschickt wurden, sondern auch noch, um welche Daten es sich hierbei handelte. Bei einer positiven Protokollierung des Clients kann ein Leecher-Client ausgeschlossen werden.
Durch die Abspeicherung dieser 10 kB großen Datenblöcke ist sichergestellt, dass der Testdownload von einem bestimmten Client zu einem späteren Zeitpunkt noch unverändert als Beweis vorgelegt werden kann.
Quelle: FileWatch - Wesentliche Merkmale - Stop-P2P-Piracy (http://stop-p2p-piracy.com/site/filewatch-merkmale)
So hiermit wollte ich Euch mal darstellen wie dieses Tool "FileWatch" im Dienste der Abmahnindustrie also Filesharing-Daten loggen tut, bzw. die Funktionsweise dieses Tools.
Dazu auch eine interessante Stellungsnahme von Dr. Rolf Freitag
Technischer Sachverständiger der Initiative Abmahnwahn-Dreipage
“FileWatch“ – was kann der Datenwächter wirklich?
Neben der Hauptarbeit der Initiative Abmahnwahn-Dreipage, der Bereitstellung von Wissen und Musterschreiben, möchten wir die Abgemahnten und Interessierten des Abmahnwesens informieren sowie wo es geht, aufklären. Zu diesem Zweck lassen wir in regelmäßigen Abständen von unserem technischen Sachverständigen, Herrn Dr. Rolf Freitag, eine Einschätzung abgeben, über vorliegende Gutachten der Log-Firmen.
Warum machen wir das? Nicht um die betreffenden Firmen der Lächerlichkeit preiszugeben, sondern nüchtern und einfach festzustellen, was ist mit den Gutachten, Top oder Flop sowie halten diese, was sie versprechen. Sicherlich gab es berechtigte Kritiken, dass man, so wie ich es handhabe, keine Beweise aneignen und verwenden darf. Aber diese Gutachten werden in öffentlichen Verhandlungen verwendet, es herrscht öffentliches Interesse und auf Anfragen regelmäßig eisiges Schweigen. Außerdem, ein Gutachten mit dem Qualitätssiegel unseres Sachverständigen, eine bessere Werbung für die entsprechende Log-Firma, gibt es ja nicht. Aber bis jetzt hat noch kein Gutachten den Freitagschen-Prüfstand unbeschadet verlassen. Natürlich möchten wir neben den Abgemahnten auch Juristen zu dieser Thematik sensibilisieren.
Der heutige Artikel wird in zwei Punkten aufgegliedert. Erstens wird der Sachverständige der Initiative Abmahnwahn-Dreipage, Herr Dr. Rolf Freitag, eine Einschätzung zum Gutachten über die Software: “FileWatch“ abgeben und zweitens wird versucht, einerseits von naturwissenschaftlichen und anderseits vom juristischen Standpunkt aus zu erläutern, welche Maßnahmen wären zwingend notwendig um die Beweiskette sicherer zu gestallten sowie Fehler auszuschließen. Hierzu werden die Herren Dr. Freitag und Dr. Wachs ihren Standpunkt darlegen.
Quelle: Abmahnwahn-Dreipage Aktuell (http://abmahnwahn-dreipage.de/aktuell.html)
Ich hoffe das man nun etwas mehr Hintergrundinfos über dieses Tool hat und auch die Vorgehensweise einzuschätzen vermag.
mfg
Um für alle benötigten Zeitstempel eine möglichst genaue Uhrzeit zu erhalten, wird die Systemzeit von FileWatch alle 5 Minuten mit Hilfe des Network Time Protokolls (NTP) synchronisiert.
Das Network Time Protokoll ist ein Standardprotokoll zur Synchronisierung von Uhren in Computersystemen. Das Protokoll wurde speziell entwickelt, um eine zuverlässige Zeitabfrage über Netzwerke mit variabler Paketlaufzeit zu ermöglichen.
Als Quelle der offiziellen Zeit in Deutschland betreibt die Physikalisch-Technische Bundesanstalt (PTB) zwei sogenannte „Stratum-1“ Server. Diese Server erhalten ihre genaue Uhrzeit direkt von einer Atomuhr oder Funkuhr.
Die Media Protector GmbH betreibt zwei eigene „Stratum-2“ Server, die wie folgt eingesetzt werden: Die beiden Stratum-2 Server synchronisieren sich alle 16 Sekunden mit einem der beiden Stratum-1 Server der PTB. Sollte dieser eine Server einmal nicht erreichbar sein, so wird automatisch der zweite Stratum-1 Server der PTB zur Synchronisation der Zeit herangezogen.
Alle Systeme, auf denen FileWatch installiert ist, synchronisieren sich wiederum alle 5 Minuten mit einem der Stratum-2 Server der Media Protector GmbH. Sollte dieser eine Server bei der Media Protector GmbH einmal nicht erreichbar sein, so dient automatisch der zweite Stratum-2 Server der Media Protector GmbH zur Synchronisation der Zeit.
Sollte trotz der häufigen Synchronisation zwischen einem FileWatch-System und einem Stratum-2 Server eine Zeitdifferenz von mehr als 0,04 Sekunden entstehen, so werden sämtliche Datensätze der Protokollierung verworfen, die seit der letzten hinreichend genauen Synchronisation (mit einer Zeitdifferenz von weniger als 0,04 Sekunden) entstanden sind. Zeitlich ungenaue Datensätze werden somit nicht für eine spätere Auswertung herangezogen. Auf diese Art und Weise wird sichergestellt, dass sich die späteren Ermittlungen auf einen ausreichend genauen Zeitstempel im Hinblick auf die protokollierte IP-Adresse und weiteren Daten beziehen.
FileWatch enthält einige wichtige Funktionen, die es ermöglichen, Daten über Aktivitäten anderer Clients des Filesharing-Netzwerks zu erheben und in die eigene Datenbank wegzuschreiben. Insbesondere kann das Programm entscheidende Daten mitprotokollieren, wenn ein Client bestimmte Dateien aus dem Filesharing-Netzwerk herunterlädt oder bestimmte Dateien anderen Benutzern des Filesharing-Netzwerks zum Download anbietet.
FileWatch nutzt zur Protokollierung eines Clients grundsätzlich zwei Varianten:
1. Die erste Variante, entscheidende Daten mitzuprotokollieren, ergibt sich, nachdem sich ein Client nach erfolgreichem Handshake mit FileWatch verbunden hat bzw. Informationen über den mit FileWatch verbundenen Client aktualisiert worden sind. Hierbei werden Daten über den jeweiligen Client und über die betreffende Datei ausgetauscht, die sogenannten „Meta-Daten“.
2. Die zweite Variante ergibt sich, wenn ein Client an FileWatch Nutzdaten überträgt (Testdownload). FileWatch nutzt diesen Zeitpunkt aus, da sich zusätzlich zu den Meta-Daten auch noch konkrete Aussagen zu den übermittelten Nutzdaten (d.h. zu den übermittelten Dateiinhalten selbst) sammeln lassen.
Die wichtigsten Daten, die FileWatch mitschreibt, sind die folgenden:
* Sekundengenauer Zeitstempel, der angibt, wann die Protokollierung des beobachteten Clients genau erfolgte
* Filehash-Wert der beobachteten Datei
* Pseudonym, unter dem der Benutzer in der Tauschbörse auftrat
* Hash-Wert, der den Client im eD2K-Netzwerk eindeutig identifiziert
* Name der Tauschbörsensoftware des protokollierten Clients
* Version der Tauschbörsensoftware des protokollierten Clients
* Maximale Anzahl der Parts, die sich für die beobachtete Datei ergeben haben
* Gesamtgröße der beobachteten Datei (in Bytes)
* Anzahl der Parts, die der protokollierte Client tatsächlich zu der beobachteten Datei schon heruntergeladen hat
* IP-Adresse des protokollierten Internetanschlusses
* Internet Service Provider (ISP), der für den protokollierten Client zum fraglichen Zeitpunkt zuständig war
* Graphische Darstellung, welche Parts bereits von dem beobachteten Client komplett heruntergeladen worden sind und welche nicht
* Ein Zeichen, das angibt, ob FileWatch versucht hat, vom protokollierten Client Daten der beobachteten Datei herunterzuladen („d“ für „download“) oder ob der protokollierte Client versucht hat, Daten der beobachteten Datei von FileWatch herunterzuladen („u“ für „upload“).
FileWatch ist in der Lage, einen Client auch über Monate hinweg zu protokollieren, selbst wenn sich die Client-IP regelmäßig ändert.
Neben der Protokollierung von Aktivitäten anderer Clients im eD2K-Netzwerk ermöglicht FileWatch auch das Herunterladen von Dateien, die im Filesharing-Netzwerk angeboten werden.
Da die Media Protector GmbH bei ihren Recherche- und Protokollierungsaktivitäten im Netzwerk nicht selbst als Verteiler von urheberrechtlich geschütztem Material auftreten kann, ist durch eine programmtechnische Besonderheit der Upload von Dateien - im Gegensatz zu den regulären, weit verbreiteten Clients - vollständig unterbunden.
Wie bereits erwähnt, bietet jeder Benutzer, der Dateien aus dem eD2K-Netzwerk herunterlädt, diese Dateien normalerweise auch ohne weiteres Zutun anderen Benutzern im Netzwerk an. Typischerweise geschieht also das Anbieten und Herunterladen von Dateien (quasi) gleichzeitig.
Ein Benutzer hat zusätzlich noch die Möglichkeit, explizit Dateien für das eD2K-Netzwerk freizugeben. Hierzu existiert in den Optionen aller gängigen eD2K-Clients die Möglichkeit, spezielle Ordner oder Ordnerstrukturen freizugeben. Die aus diesen Freigaben resultierende Liste an Dateien wird als „Shared List“ bezeichnet.
Nachdem FileWatch einen erfolgreichen TCP-Verbindungs-Handshake mit einem (anderen) Client durchgeführt hat, wird dieser Client gefragt, ob er seine Shared List an FileWatch übermitteln möchte. Beantwortet der Client diese Anfrage positiv, so wird anschließend die Shared List an FileWatch übermittelt. FileWatch ist dann in der Lage, sämtliche Einträge der Shared List in der eigenen Datenbank abzuspeichern.
Wenn eine Datei innerhalb des eD2K-Netzwerks überwacht werden soll, so wird an FileWatch der Filehash-Wert der Datei übergeben. Der Filehash-Wert wurde zuvor von den Mitarbeitern der Media Protector GmbH für diese Datei berechnet (indem die eD2K-Standardalgorithmen verwendet werden).
Der erste Client, der FileWatch die zu überwachende Datei anbietet, übermittelt FileWatch unter anderem folgende Informationen:
* Liste mit allen Parthash-Werten der Datei
* Filehash-Wert der Datei
Nach der Übermittlung dieser Informationen berechnet FileWatch aus der Liste der Parthash-Werte der Datei den eindeutigen Filehash-Wert der Datei.
Anschließend führt FileWatch folgende Vergleiche durch:
1. Ist der aus den Parthash-Werten errechnete Filehash-Wert identisch mit dem Filehash-Wert der zu beobachtenden Datei?
2. Ist der von dem Client gesendete Filehash-Wert identisch mit dem Filehash-Wert der zu beobachtenden Datei?
Liefern beide Vergleiche ein positives Ergebnis, so wird die Liste mit den Parthash-Werten für eine spätere Verwendung abgespeichert. Liefert einer der beiden Vergleiche einen Fehler, so wird bei einem neuen Client versucht, die Liste mit den Parthash-Werten und den Filehash-Wert zu beziehen.
Wenn die Vergleiche zu einem positiven Ergebnis kamen, beginnt FileWatch, die Datei von dem beobachteten Client herunterzuladen. FileWatch verifiziert den korrekten Download von jedem einzelnen Part der Datei. Dies geschieht dadurch, dass nach dem vollständigen Aufsammeln aller zu einem Part gehörigen Bytes der Parthash-Wert errechnet und mit dem zuvor abgespeicherten Parthash-Wert aus der zuvor übermittelten Liste verglichen wird. Ist die Übereinstimmung der Parthash-Werte positiv, so schreibt FileWatch die relevanten Daten aller Clients, die an der Vervollständigung dieses Parts beteiligt waren, in eine Datenbank. Damit kann FileWatch sicher feststellen, dass von jedem der protokollierten Clients korrekte Daten zu einem bestimmten Part erhalten wurden und es sich nicht um einen sogenannte „Leecher-Client“ handeln kann (unter einem „Leecher-Client“ versteht man einen modifizierten Client, der nur Downloads, aber keine Uploads ermöglicht).
Kann keine Übereinstimmung bei den zu vergleichenden Parthash-Werten festgestellt werden, muss angenommen werden, dass ein Übertragungsfehler stattgefunden hat. In diesem Fall wird der gesamte Part verworfen und der Download-Vorgang wird neu begonnen. FileWatch verwirft ebenfalls sämtliche Daten aller Clients, die an der Vervollständigung dieses Parts beteiligt waren. Auf diese Weise wird auf jeden Fall verhindert, dass Clients zu Unrecht protokolliert werden.
Die Wahrscheinlichkeit, dass ein Parthash-Wert trotz falsch übertragener Daten tatsächlich mit dem Parthash-Wert aus der übermittelten Liste übereinstimmt, geht gegen null (1:2128 – fünf Mal einen 6-er im Lotto hintereinander wäre wahrscheinlicher).
Um einen unerschütterlichen Nachweis führen zu können, dass ein Client tatsächlich die Daten einer zu überwachenden Datei an FileWatch geschickt hat, werden nicht nur die Parthash-Werte verifiziert, sondern zusätzlich noch die ersten 10.240 Bytes an Daten abgespeichert, die der Client für einen Part geliefert hat. Es werden also pro Client und pro Part originäre 10.240 Bytes große Datenblöcke in der Datenbank der Media Protector GmbH gespeichert. Auf diese Weise lässt sich gut nachvollziehen, welche Clients zu welchem Part und damit auch zu einer Komplettierung der gesamten beobachteten Datei beigetragen haben.
Die Größe dieser 10 kB großen Datenblöcke ist übrigens für einen sicheren Nachweis völlig ausreichend, da die Wahrscheinlichkeit, dass zufällig Daten übermittelt wurden, die mit dem Datenblock der originären Datei bzw. Referenzdatei identisch sind, praktisch null ist (genau genommen ist die Wahrscheinlichkeit 1:281.920 – 1000x hintereinander einen 6-er im Lotto wäre deutlich wahrscheinlicher).
Zu jedem Datenblock wird zusätzlich festgehalten, wo er innerhalb der Datei beginnt und wo er endet. Somit ist es möglich, dass nach jedem erfolgreichen Testdownload die 10.240 Bytes automatisiert innerhalb der Referenzdatei (Datei, die von den Mitarbeitern der Media Protector GmbH bereits im Vorfeld positiv auf Übereinstimmung mit dem Originalwerk überprüft wurde und die auf den Archiv-Servern der Media Protector GmbH gespeichert ist) gesucht und auf Übereinstimmung geprüft werden.
Durch dieses Verfahren kann FileWatch nicht nur sicher feststellen, dass von einem protokollierten Client korrekte Daten zu einem bestimmten Part geschickt wurden, sondern auch noch, um welche Daten es sich hierbei handelte. Bei einer positiven Protokollierung des Clients kann ein Leecher-Client ausgeschlossen werden.
Durch die Abspeicherung dieser 10 kB großen Datenblöcke ist sichergestellt, dass der Testdownload von einem bestimmten Client zu einem späteren Zeitpunkt noch unverändert als Beweis vorgelegt werden kann.
Quelle: FileWatch - Wesentliche Merkmale - Stop-P2P-Piracy (http://stop-p2p-piracy.com/site/filewatch-merkmale)
So hiermit wollte ich Euch mal darstellen wie dieses Tool "FileWatch" im Dienste der Abmahnindustrie also Filesharing-Daten loggen tut, bzw. die Funktionsweise dieses Tools.
Dazu auch eine interessante Stellungsnahme von Dr. Rolf Freitag
Technischer Sachverständiger der Initiative Abmahnwahn-Dreipage
“FileWatch“ – was kann der Datenwächter wirklich?
Neben der Hauptarbeit der Initiative Abmahnwahn-Dreipage, der Bereitstellung von Wissen und Musterschreiben, möchten wir die Abgemahnten und Interessierten des Abmahnwesens informieren sowie wo es geht, aufklären. Zu diesem Zweck lassen wir in regelmäßigen Abständen von unserem technischen Sachverständigen, Herrn Dr. Rolf Freitag, eine Einschätzung abgeben, über vorliegende Gutachten der Log-Firmen.
Warum machen wir das? Nicht um die betreffenden Firmen der Lächerlichkeit preiszugeben, sondern nüchtern und einfach festzustellen, was ist mit den Gutachten, Top oder Flop sowie halten diese, was sie versprechen. Sicherlich gab es berechtigte Kritiken, dass man, so wie ich es handhabe, keine Beweise aneignen und verwenden darf. Aber diese Gutachten werden in öffentlichen Verhandlungen verwendet, es herrscht öffentliches Interesse und auf Anfragen regelmäßig eisiges Schweigen. Außerdem, ein Gutachten mit dem Qualitätssiegel unseres Sachverständigen, eine bessere Werbung für die entsprechende Log-Firma, gibt es ja nicht. Aber bis jetzt hat noch kein Gutachten den Freitagschen-Prüfstand unbeschadet verlassen. Natürlich möchten wir neben den Abgemahnten auch Juristen zu dieser Thematik sensibilisieren.
Der heutige Artikel wird in zwei Punkten aufgegliedert. Erstens wird der Sachverständige der Initiative Abmahnwahn-Dreipage, Herr Dr. Rolf Freitag, eine Einschätzung zum Gutachten über die Software: “FileWatch“ abgeben und zweitens wird versucht, einerseits von naturwissenschaftlichen und anderseits vom juristischen Standpunkt aus zu erläutern, welche Maßnahmen wären zwingend notwendig um die Beweiskette sicherer zu gestallten sowie Fehler auszuschließen. Hierzu werden die Herren Dr. Freitag und Dr. Wachs ihren Standpunkt darlegen.
Quelle: Abmahnwahn-Dreipage Aktuell (http://abmahnwahn-dreipage.de/aktuell.html)
Ich hoffe das man nun etwas mehr Hintergrundinfos über dieses Tool hat und auch die Vorgehensweise einzuschätzen vermag.
mfg