Zitat von watt_ihr_volt

...Warum die Arbeit, dieser immense Aufwand?!...
Hinterfragt Ihr jetzt schon jenes legendäre Gutachten, ...

Ich hinterfrage grundsätzlich jedes Gutachten im Computer/Netzwerke-Bereich, bevor es überhaupt begonnen hat.
Meine Erfahrung sagt mir nämlich, dass gerade in diesem genannten Bereich entweder die falschen Fragen gestellt werden, oder auf Dinge "geantwortet" wurde, die gar niemand gefragt hat. Besser gesagt, das Ding ist völlig am eigentlichen Problem vorbeigelaufen, und hat letztendlich nichts gebracht. Vor allem Gutachten "Made in Germany" sind darin besonders gut.

Nach unserem Test kann sich keiner mehr rausreden, dass er "die richtigen Fragen" nicht gekannt hat. Darum der aufwändige Test schon vorab.

-CityLight-

Zitat von CityLight

Ich hinterfrage grundsätzlich jedes Gutachten im Computer/Netzwerke-Bereich, bevor es überhaupt begonnen hat.
Meine Erfahrung sagt mir nämlich, dass gerade in diesem genannten Bereich entweder die falschen Fragen gestellt werden, oder auf Dinge "geantwortet" wurde, die gar niemand gefragt hat. Besser gesagt, das Ding ist völlig am eigentlichen Problem vorbeigelaufen, und hat letztendlich nichts gebracht. Vor allem Gutachten "Made in Germany" sind darin besonders gut.

Nach unserem Test kann sich keiner mehr rausreden, dass er "die richtigen Fragen" nicht gekannt hat. Darum der aufwändige Test schon vorab.

-CityLight-

Ich finde richtig gut was du da machst CityLight. Nicht viele Leute opfern ihre Zeit um die technischen Hintergründe aufzudecken.

Weiter so!

Zitat von CityLight

Ich hinterfrage grundsätzlich jedes Gutachten im Computer/Netzwerke-Bereich, bevor es überhaupt begonnen hat.
Meine Erfahrung sagt mir nämlich, dass gerade in diesem genannten Bereich entweder die falschen Fragen gestellt werden, oder auf Dinge "geantwortet" wurde, die gar niemand gefragt hat. Besser gesagt, das Ding ist völlig am eigentlichen Problem vorbeigelaufen, und hat letztendlich nichts gebracht. Vor allem Gutachten "Made in Germany" sind darin besonders gut.

Nach unserem Test kann sich keiner mehr rausreden, dass er "die richtigen Fragen" nicht gekannt hat. Darum der aufwändige Test schon vorab.

-CityLight-

Absolut super Spitzenklasse - sowohl die Arbeit, als auch der kritische Geist der dahinter steckt

Zitat von CityLight

Nachdem das streitgegenständliche Filmmaterial im Rahmen einer Suchanfrage lokalisiert worden ist, wird eine direkte Verbindung zwischen den Rechnern über das Internet hergestellt, auf welchen sich das streitgegenständliche Filmmaterial befindet. Eine solche Verbindung wird unmittelbar die IP-Adresse hergestellt, welche von unserer Mandantin mitsamt weiteren Informationen mitprotokolliert wird und über welche das streitgegenständliche Filmmaterial von Mitarbeitern unserer Mandantin geladen und gespeichert wird. Hierbei findet eine Überprüfung hinsichtlich der Authentizität des streitgegenständlichen Filmmaterials statt.

Von wem stammt diese Aussage eigentlich und von wann ist sie?

1000 mal pro Woche vermeindliche Urheberrechtsverletzer zu befragen, ob diese ein bestimmtes Werk im Angebot haben, stellt technisch ja kein Problem dar, selbst wenn die Überwachungssoftware jedes mal einen kleinen Teil des Werkes "anladen" würde. Dass jedoch immer und von jedem vermeintlichen Urheberrechtssünder ein Komplettdownload durchgeführt wird, ist unmöglich. Daher nochmal meine Frage: Wird das denn tatsächlich aktuell und daher relevant so behauptet?

Zitat von Hadron

...Daher nochmal meine Frage: Wird das denn tatsächlich aktuell und daher relevant so behauptet?

Hier sind mal alle Augen gefordert, bezüglich der eigenen Abmahnung.

Zitat von Hadron

Von wem stammt diese Aussage eigentlich und von wann ist sie?

Heute spät abend per PN, muss nämlich jetzt noch mal wech.:wut:

-CityLight-

Hier ist der nächste Teil des angekündigten Testberichtes.

###############################################
Beginn zum Forum-Bericht: Teil-1 Teil-B
###############################################


1.4) Die Log-Software erhält fehlerhafte oder manipulierte Daten von der Gegenstelle
In diesem Abschnitt wollen wir nicht auf alle Möglichkeiten eingehen, die sich bezüglich Manipulation ergeben. Hier sind vor allem mal der Datei-Hash (MD4 und MD5) genannt, und dann diese ominösen Hash-Fakes und Hash-Doubletten. Was übrigens nach meiner Auffassung nicht das Gleiche ist. Hier soll gleich mal auf diesen lustigen Web-Auftritt verwiesen werden. Meine Ansicht dazu, dummes Geschwätz, natürlich gerührt und nicht geschüttelt. Eine MD4-Hash-Doublette von einer großen Video-Datei zu erzeugen, die man mit einem P2P-Prog mit Media-Plugin nicht gleich als Fake erkennt, ist nämlich gar nicht so einfach. Mit einem MD5-Hash kann man das nach meiner Ansicht gleich vergessen. Zudem erfordert das auch bei einem MD4-Hash schon ganz ordentlich Rechenpower. Einen MD4-Hash-Fake, also einfach nur eine komplette Müll-Datei, den bekommt nach meiner Ansicht jeder interessierte Computer-Kiddie hin. Er braucht nur einen ordentlichen Rechner und ne gesunde Portion Neugier.
Man kann also die im o.g. WebLink aufgeführten Behauptungen allenfalls als Wunschkonzert betrachten, oder einfach nur als besonders dämliche Eigenwerbung. Aus diesem Grund erläutern wir in den folgenden Punkten mal nur drei Probleme, mit denen eine automatisch arbeitende Log-Software konfrontiert wird. Was letztendlich sich dann natürlich auf die Abmahnung bzw. den Abgemahnten auswirkt.
<a>
An dieser Stelle soll auch auf dieses Dokument verwiesen werden, wo im übrigen neuerdings die Seite 2 fehlt (hat wohl die Lösch-Wut wieder zugeschlagen). Macht aber nix, ich hab sie immer noch. Und gerade aus dieser Seite 2 konnte man sehr wohl entnehmen, dass die Log-Software einfach nur gestartet, kurzer Kontroll-Blick, und dann die ganze Nacht automatisch vor sich hinrödelt. Gerade bei dieser sog. Fachfirma sollte man eigentlich wissen, dass nicht nur Menschen, sondern auch Maschinen mit Software jede Menge Mist produzieren, wenn man nicht ständig mal nach dem Rechten schaut. Nun gut, weiter Gates .
<b>
Diesen Punkt "Fake-Dateien" erläutern wir jetzt mal ganz besonders im Detail, da es für die Begriffe "Fake-Name", "Hash-Fake" und "Hash-Doublette" eigentlich keine richtige Definition gibt. Zum besseren Verständnis noch einmal das Bild012 anschauen.
>> TestScreen012 << - hier sind die Datei-Details
Diese Anzeige basiert nämlich auf dem Media-Plugin, dass nicht nur die Clients, sondern auch zahlreiche Server besitzen. Damit ist es recht einfach Audio- und Videodateien zu entlarven. Sofern aus dem ersten Chunk der Datei-Header erkannt werden konnte, was leider in einigen Fällen manchmal auch versagt (Stichwort: Werk ist kaum verfügbar).
Ich versuche es mal so zu definieren (bezogen auf Audio- und Videodateien):
- Fake-Name
Der Datei (Datei-Hash) wurde einfach ein anderer Name verpasst. Das erfolgt i.d.R. immer von einem Client aus, der diese Datei entweder im Share stehen hat, oder zum Download angefordert hat bzw. gerade Downloaded.
- Hash-Fake
Irgendeine Müll-Datei, die in Größe und Name mit der "Original-Datei" (Datei-Hash) übereinstimmt. Da hierbei auch kein ordentlicher Datei-Header vorhanden ist, wird so etwas von "Media-Plugins" bemerkt. Hierzu muss man wissen, diese Dinger ermitteln nämlich auch den "Codec"-Typ und die Bitrate.
Es kann sich aber auch um eine "vermurkste" Hash-Doublette handeln, deren Erstellung nicht so recht geklappt hat (Datei-Header vorhanden, stimmt aber nicht überein).
- Hash-Doublette
Wie Hash-Fake, jedoch befindet sich im ersten Chunk nicht nur ein korrekter Datei-Header, sondern auch ein Stück Mediendatei (Audio oder Video), die auf "Codec" und "Bitrate" der Originaldatei angepasst wurde. Damit erkennt das Media-Plugin den Fake am ersten Chunk nicht mehr. So was zu erzeugen ist zumindest bei einem Video außerordentlich schwierig. Zudem müssen ja der Datei-Hash, und der erste Teil des Part-HashSet passen. Zur Erinnerung, Bild018.
>> TestScreen018 << - Part-HashSet in Programm-Form
Eine große Audio- oder Videodatei als Fake zu generieren, in der das gesamte Part-HashSet passt, halte ich für nicht machbar. Und wenn doch, dann soll er es mal belegbar vorzeigen.
<c>
Und jetzt noch ein paar kurz kommentierte Screens zu diesem Thema:
>> TestScreen028 << - Nur Fake-Namen, kein Werk zu sehen
Also wer wohl diese Fake-Namen verbreitet ? Nicht mal der Original-Dateinname ist verfügbar.
>> TestScreen029 << - Werk aus Bild028 im Februar 2010
Das Werk ist so selten verbreitet, dass es bis heute noch nicht mal gelungen ist, den Medientyp (Codec+Bitrate) zu ermitteln. Fragt sich nur, wie der Logger das zum Beweis und zur Ansicht aus dem Netz heruntergeladen haben will.
>> TestScreen030 << - skurile Fake-Namen, der Medientyp wurde aber erkannt
>> TestScreen031 << - auch der Medientyp "mpeg" wird erkannt, auch beim Fake-Namen
>> TestScreen032 << - Fake-Namen, schlimmer gehts nimmer, auch die werden erkannt
>> TestScreen033 << - ist da ein Hash-Doublette ??
Die fast leere Codec-Zeile, aber eine verfügbare vollständige Quelle. Das könnte eine Hash-Doublette sein, oder mal eine werden ? Wir wissen es auch nicht. Ich habe zumindest bis jetzt noch keine einzige Hash-Doublette bei einer so großen Medien-Datei finden können.
>> TestScreen034 << - eine vermurkste Hash-Doublette ??
Man beachte die Zeile mit dem "wmv3 Codec". Da hat sich offenbar mal jemand an einer Hash-Doublette versucht, ist aber dann doch schief gegangen. Das "Media-Plugin" hat es dennoch rausgefunden. Trotzdem, respektable Arbeit. Ich bin beeindruckt.
An dieser Stelle beenden wir erst mal das Thema Fake-Dateien.

1.4.1) User-Hash (GUID)
In diesem Abschnitt gehen wir auf das Thema User-Hash ein, die sog. GUID. Angeblich beweissicherer Bestandteil jeder Abmahnung, und !!, die einzige !! Möglichkeit für den Logger, einen P2P-User der mit dynamischer IP-Adresse unterwegs ist, nach einem Zeitraum von mehr als 24 Stunden (Regelzeitraum in Folge der sog. Zwangstrennung) in einem Log-Datensatz überhaupt wieder zu finden. Und ausgerechnet diesen beweissicheren? Bestandteil kann der P2P-User selbst mit wenigen Handgriffen verändern, und somit dem Logger jegliche "Wiedererkennung" zu nichte machen. Am Beispiel des eMule wurde das in diesem Posting bereits eingehend erläutert. Ich kenne selbst einige User, die das vor jedem Start des eMule automatisch erledigen lassen. Das weitere Thema "Nick-UserName" wird nicht mehr erwähnt, das sollte eigentlich mittlerweile in den Köpfen drin sein.
<a>
Aber mehr noch, diese angeblich beweissichere GUID lässt sich sogar ganz gezielt manipulieren, und somit auch einer fremden Idendität zuordnen. Bedeutet in der Praxis, wir klauen einem anderen User die GUID. Wenn wir damit jetzt noch über einen sog. TOR-Proxy abmahnwürdiges Zeugs saugen, dann sind wir selbst für den Logger praktisch nicht mehr idendifizierbar. Und jetzt stellen wir uns einfach folgendes Szenario vor. Am Tag-1 wird der User-A mit seiner GUID und seiner IP geloggt, obwohl er einen Leecher-Mod (also null-Upload) verwendet. Am Tag-2 sind wir mit seiner geklauten GUID unterwegs, und werden ebenfalls sogar mit Upload geloggt. Dummerweise kann aber der Logger mit unserer IP nix anfangen, er wird unseren Klarnamen dazu nicht ermitteln können. Was wird wohl hier dem User-A passieren ? Richtig, abgemahnt mit nachgewiesenen Upload. Dass der zweite Log-Datensatz gar nicht korrekt zugeordnet werden konnte, interessiert eh keinen. Mit solchen veröffentlichten Log-Mängeln kann man nämlich kein Geld verdienen. Schon gar nicht Gerichte überzeugen.
Und jetzt sehen wir uns mal an, wie einfach das funktioniert. Wie man das genau macht, werde ich hier natürlich nicht erläutern.
<b>
>> TestScreen035 << - der User-Hash (GUID) des eMule
Der User-Hash steht ganz unten rechts im eMule-Hauptfenster, wenn die Registerkarte "Server" ausgewählt wurde.
>> TestScreen036 << - eine fremde GUID aus dem P2P-Netz
Von dem P2P-User in der untersten Zeile (Strich-Markierung) werden wir uns jetzt die GUID schnappen. Der Eintrag wurde nicht zufällig, sondern sorgfältig ausgesucht. Denn wir achten auf den Nick-UserName, und vor allem darauf, dass die Grundversionsnummer mit der unsrigen übereinstimmt. Zudem müssen wir natürlich noch warten, bis entweder der "fremde" User mit seiner GUID vom verbunden Server verschwunden ist, oder wir Connecten nach dem eMule-Neustart manuell auf einen anderen Server. Denn nicht nur die meisten eMule-Versionen erkennen einen solchen User-Hash-Klau, sondern auch zahlreiche Server. Also warten wir. Dann die Manipulation händisch in wenigen Minuten, und eMule neu starten.
>> TestScreen037 << - die manipulierte GUID
Hat super geklappt. Wir sind mit der fremden GUID wieder Online, haben ne hohe ID, und nicht mal der gleiche Server hats bemerkt. Wer aufmerksam hinschaut, wird bei "Kad Netzwerk" eine jetzt fehlende Option bemerkt haben. Hängt damit zusammen, dass mit der Manipulation auch bestimmte Optionen wieder auf die Grundeinstellung rückgesetzt werden. Ist aber kein Problem.
Man kann jetzt die beschriebene Aktion als böse und rücksichtslos verteufeln, fakt ist aber, es wird gemacht. Und das nicht zu knapp. Ich kenne selbst einige User, die sogar auch das automatisiert haben. Wenn ein solch o.g. Betrug möglich ist, bzw. die Software das nicht verhindern kann, dann wird es auch gnadenlos ausgenutzt, ohne Rücksicht auf Verluste. Irgendwie kennen wir so etwas Ähnliches ja bereits von den Abmahnzellen. Das eigentliche Problem am Thema User-Hash (GUID) ist eigentlich, dass hiesige Gerichte/Richter das immer noch nicht geschnallt haben. Oder es interessiert einfach gar nicht. Nicht substantiiert, schon wieder.

1.4.2) fehlerhafte Daten?? von der Gegenstelle
In diesem Abschnitt haben wir ein höchst seltsames fehlerhaftes?? Verhalten bei unseren Vor-Tests endeckt. Die IP-Adresse war zwar am anderen Ende der Welt, aber das spielt keine Rolle. Kann mit einer Germany-Gegenstelle genauso passieren. Wichtig ist noch, dass wir die recht leistunsgfähige Leecher-Erkennung unserer Mod-Version abgeschaltet hatten. Ob die Loggerbuden diese auch verwenden, kann ich nicht sagen. Die von uns untersuchte Logsoftware (siehe Abschnitt 1.1 <e>) hatte jedenfalls keine.
>> TestScreen038 << - die Gegenstelle hat kein Teil des Werkes
Auf den ersten Blick ist die Anzeige eigentlich gar nicht ungewöhnlich, aber man sollte genau hinschauen. Unser muli wurde dort auf die Warteschlange gesetzt, obwohl es dort von dem Werk gar nichts zu holen gibt (null-Prozent).
>> TestScreen039 << - Client-Details der Gegenstelle
Hier wirds noch konfuser. Wir stehen auf Queue-Rank = 1, Datei zum Upload angefordert. Theoretisch hätte unser muli das so gar nicht anzeigen dürfen, denn von der Gegenstelle gibt es absolut nix von der Datei zu holen. Nun könnte man natürlich vage vermuten, die Gegenstelle hat gerade in dem Moment "aufgelegt" (also die Verbindung getrennt). Eine Erklärung für die null-Prozent-Anzeige im Part-HashSet ist das natürlich auch nicht. Also prüfen, mit Whois+Ping und einem TraceRoute.
>> TestScreen040 << - Whois+Ping, Gegenstelle ist noch Online.
Hier haben wir erkannt, dass die Gegenstelle eine dynamische IP hat. Damit können wir auch ausklammern, dass die IP möglicherweise in den paar Sekunden dazwischen erneut vergeben wurde. Wir wüssten von keinem Provider, dass eine eben getrennte dynamische IP-Adresse sofort wieder für den nächsten anwählenden Nutzer vergeben wird. Da liegt immer eine gewisse RollOut-Zeit dazwischen. Je nach dem, wie groß der Adress-Pool des Providers an Dyn-IP's ist. Zumal viele Provider ja auch die aktuelle IP in der Session-ID verankern (entspricht einem DNS-Namen für die aktuelle Login-Session).
>> TestScreen041 << - TraceRoute ist auch OK
Die Anwortzeit ist zwar der absolute P2P-Horror, aber dafür ist die IP ja auch am anderen Ende der Welt. Interessant vor allem, dass unser muli diese Quelle erst nach knapp fünf Minuten aus der Warteschlange geworfen hat.
Wir haben uns mit diesem Problem dann nicht weiter befasst, weil wir der Ursache nicht auf die Spur gekommen sind. Wir hatten wegen einem Datensatz dann auch ehrlich gesagt keine Lust mehr dazu. Geblieben ist aber schon die Frage, was passiert wohl, wenn so ein Datensatz beim Logger aufschlägt. Ich glaube kaum, dass die jedesmal bei tausenden IP's nach solchen Fehlern suchen. Und die "Automatik" beim Logging-Client hat hier eindeutig versagt. Bleibt eben erneut ein fader Beigeschmack bezüglich automatisches Logging, unbeobachtet die ganze Nacht durch. Wie bereits unter (1.4 <a>) angemerkt.

1.4.3) Fatal-Error??, Provider-Zuordnung zur IP-Adresse ist fehlerhaft
In diesem Teil soll ein Fehler im Logging-Vorgang erläutert werden, mit dem wir im "scharfen" Test konfrontiert wurden. Zugegeben, es ist ein Einzelfall. Allerdings haben wir nicht tausende IP-Adressen geloggt, sondern erheblich weniger, und auch noch in begrenzten Zeitabschnitten. Und während dieser Zeit hat immer einer von uns dauerhaft vor den Control-Rechnern gesessen. Die Technik hat also nicht vollautomtisch die ganze Nacht vor sich hin geloggt. Wie und was wir genau mit der Technik angestellt haben, dass wird im noch folgenden Teil-1 Teil-C (der noch fehlende Punkt 1.5) genauer erläutert. Damit werden zwar einige Beschreibungen in diesem Abschnitt etwas schwerer nachvollziehbar, aber wie bereits in diesem Posting erwähnt, habe ich diesen Abschnitt vorgezogen, der ursprünglich erst im Teil-2 vorgesehen war.
Wie schon angemerkt, dieser Fehler ist uns bereits bei relativ wenigen geloggten Datensätzen passiert. Es ging um das Problem, dass der Logging-Client zu einer geloggten IP die IP-Range des Providers kannte, und das Live-Whois-Tool auf dem Control/Datenbank-Client den falschen Provider zuordnete. Es war nämlich überhaupt kein Provider, sondern das [URL="http://www.ripe.net/"][U]RIPE-NCC.
Zunächst einmal sind ein paar verkürzte Basics erforderlich, um das o.g. IP-Problem in der Log-Umgebung zu verstehen.
<a>
Einigen werden bereits die "Länderflaggen" im Bild024 (Abschnitt 1.3 <b>) aufgefallen sein. Eine Spezialität der Mod-Versionen. Um das richtige Land (Flagge) dem richtigen IP-Bereich zuzuordnen, gibt es in der Mod-Version eine spezielle csv-Datei, in der alle IP-Ranges abgelegt sind. Kurzer QuerLink: Die IP-Adressen sind hier in dezimale Zahlen umgerechnet. Wie das funktioniert, hat mal jemand im gulli-Board hier und hier sehr einfach erklärt. Wir haben die o.g. csv-Datei-Liste auch dafür benutzt, unseren Logging-Client zusätzlich immer dann einen interen "Alarm-Datensatz" erzeugen zu lassen, wenn eine IP-Adresse aufschlägt, die nicht in dieser Liste enthalten ist. Die Mod-Version zeigt dann eine schwarze Flagge mit rotem Kreuz. Die Zuordnung der IP-Ranges zu den Providern (nur für Germany) haben wir mit einer speziell präparierten "ipfilter.dat" gelöst.
>> TestScreen042 << - Spezial-IP-Filter aus den Vorab-Tests
Der Unterschied zur Funktion der "Original"-ipfilter.dat besteht nur darin, dass wir diese Datei nicht zum Blockieren, sondern zum Filtern aller IP-Ranges in Germany benutzt haben. Gleich aufgeschlüsselt nach Providern. Und wie man im Bild042 (ab Zeile 2) sehen kann, auch alle Loggerbuden haben wir hier nicht vergessen. Wichtig noch an dieser Stelle, alle unsere IP/Provider-Listen sind auf dem Stand von Dezember 2009. Eine aktuellere Liste lag auf dem FTP-Server des RIPE-NCC im Januar 2010 noch nicht vor.
Und um das jetzt mal abzukürzen, also immer dann wenn eine IP aufschlägt die aus Germany kommt, und die unser Logging-Client keinem Provider zuordnen kann, dann wird Alarm ausgelöst. Dieser Alarm erstellt einen zusätzlichen Log-Datensatz, macht einen ScreenShot auf dem Logging-Client, schickt einen Script-Befehl zum Control-Client, der wiederum löst ein Live-Whois+Ping aus, usw...usw... Im Technik-Teil (Punkt 1.5) gibts dann ne genau Erklärung, wie wir das alles gelöst haben.
<b>
Nun zum eigentlichen Fehler.
>> TestScreen043 << - die fehlerhafte IP
Den Rest habe ich mal zur Anschaulichkeit abgedeckt. An den Flaggen kann man sehr schön sehen, hier gibts ein Problem.
>> TestScreen044 << - Live-Whois+Ping (das Tool erledigt immer gleich beides)
Die Session-ID zeigt uns eindeutig "UnityMedia", aber das Live-Whois sagt uns beim Provider "RIPE-NCC". Jetzt wurde es konfus. Bisher hatte das ausgezeichnete Whois-Tool noch nie versagt. Und jetzt das ?? Zudem sehen wir noch, die IP-Adresse ist nicht erreichbar. Allerdings ist das erstmal nichts ungewöhnliches, wenn der Client hinter einer Firewall läuft die nicht auf Pings antwortet. Online muss er jedoch gewesen sein, sonst hätten wir das Bild043 nämlich nicht. Also logische Folgerung, der Client hat gerade in dem Moment "aufgelegt", wo unser Ping vom Live-Whois-Tool ihn anklingelte. Das passiert übrigens öfters. Um solche Sonderfälle natürlich sicher zu machen, schiebt unsere "Alarm"-Kette nämlich automatisch noch ein TraceRoute hinterher.
>> TestScreen045 << - TraceRoute, Stop nach 25 Hops, keine Antwort
Die IP-Adresse ist definitv nicht mehr Online, hat also aufgelegt. Da wir aber ganz Super-gründlich vorgehen, während der Tests hat nämlich einer von uns immer vorm Rechner gesessen (eben wegen solcher Alarme), prüfen wir doch mal die Session-ID ab, ob die tatsächlich Online war.
An dieser Stelle werden sich einige fragen, gibts denn so eine Wunder-Zauberei überhaupt. Die Antwort ist JA, und es ist keine Zauberei. Es gibt nämlich im Netz einen richtig coolen IP/DNS-Tracker. Viele Grüße an @Baxter und an @Shual, die scheinen das Teil nämlich auch besonders zu mögen. Ok, wieder zurück.
Die berühmte Session-ID, im Bild044 rechts in der zweiten Zeile. Das ist im Prinzip ein DNS-Name, vergeben nur für die aktuelle Online-Sitzung. Man beachte die integrierte IP-Adresse, allerdings machen das nicht alle Provider so (nicht nur die Telekom machts übrigens anders). Und was hier ganz besonders wichtig ist, diese Session-ID kann man noch tagelang später abfragen, allerdings !! solange die selbe IP-Adresse nicht erneut an einen anderen Nutzer vergeben wird. Aus diesem Grunde bezeichnen nämlich viele Provider die Session-ID anders (so u.a. auch die Telekom, Alice, Versatel, usw.) und viel eindeutiger (verdopplungssicher). Es machen aber eben nicht alle so.
Also diese Session-ID kann unser DNS-Tracker finden, wenn sie tatsächlich kürzlich Online war (bisher hat er jede gefunden, sofern wirklich Online). Und das Teil ist recht zuverlässig, auch wenns manchmal etwas dauert.
>> TestScreen046 << - Uups, no dns information found
Und Plong, der Tracker fand die Session-ID nicht. Jetzt wurde es schon wieder konfus. Im Normalfall bedeutet dieser Eintrag jetzt für uns, die IP-Adresse war kürzlich nicht Online. Wieso die aber auf unserer Liste gelandet ist (Bild043), konnten wir auch nicht mehr erklären. Wir haben es als Logdaten-Fehler verbucht und abgehakelt.
<c>
Drei Tage später schlug der selbe User-Hash aus Bild043 erneut auf. Der Nick-UserName ist übrigens der Standard-Name einer eMule-Mod-Version, also nicht eindeutig !!
>> TestScreen047 << - der selbe User-Hash von vor drei Tagen
Und wieder stehen wir dort nur auf der Warteschlange, ohne Chance da irgendwas zu Downloaden. Wir sehen aber, er hat 100% des Werkes vorrätig. Und wieder dieser blöde Provider-Alarm (siehe Flaggensymbol), aber Moment. Er hat jetzt ne andere IP-Adresse (vergleiche Bild043).
>> TestScreen048 << - Nee, nich schon wieder, RIPE-NCC als Provider, oooh man.
Aber diesmal ist die IP-Adresse wenigstens Online.
>> TestScreen049 << - der Tracer bestätigt das, sehr gut.
Also hat unser Beobachter, der arme Kumpel hatte an dem Abend echten Stress, gleich den DNS-Tracker gestresst. Das kann er jedoch am mitlaufenden Datenbank-Tool erledigen, denn auch die Session-ID vom Whois-Tool landet mit in unserer Datenbank. Allerdings muss er diesen Vorgang händisch auslösen, und !! er muss hier auch den ScreenShot im Datenbank-Tool händisch anweisen, denn die Antwortzeiten (Bildaufbau) des Trackers sind meist nicht kalkulierbar.
>> TestScreen050 << - sehr schön, diesmal haben wir die Session-ID
Und weil unser Beobachter an dem Abend das Ergebnis noch immer konfus befand (RIPE-NCC als Provider), hat er in seiner vorsorglichen Klugheit mal gleich noch einen händischen ScreenShot vom RIPE-NCC zu der IP angefertigt.
>> TestScreen051 << - Uups, da steht der Provider richtig drin.
<d>
Beraten haben wir über dieses Problem dann erst am nächsten Tag, und waren ehrlich gesagt ratlos. Unser Live-Whois-Tool konnte den Provider nicht richtig auslesen, was es aber nur bei dieser einzig einzelnen IP-Range machte. Wir haben noch andere Adress-Bereiche von UnityMedia in der Liste stehen, da funktioniert das Live-Whois-Tool ohne Probleme. Wir haben das Problem bis gestern noch nicht vollständig untersucht, weil uns auch die Zeit bisher dazu fehlte. Allerdings haben wir gestern noch mal den Logging-Client angeworfen, und mal nach dem User-Hash aus Bild043 gesucht, und haben ihn nicht gefunden. Zur Sicherheit haben wir allerdings nochmal die IP-Adresse aus Bild043 überprüft, und waren schlichtweg erstaunt. Diesmal war die nämlich Online. Aber wie gesagt, die IP-Adresse war Online, nicht der User-Hash. Denn im P2P-Netz hatten zu dem noch immer eingestellten Werk, weder den User-Hash, noch die IP-Adresse in der Warteschlange gefunden.
>> TestScreen052 << - Live-Whois+Ping
>> TestScreen053 << - TraceRoute ist auch OK
>> TestScreen054 << - der Tracker wurde auch fündig
Was an diesem Punkt jetzt völlig unklar ist, ob die eben erst geprüfte IP-Adresse aus Bild052, die vor ein Tagen (Bild043) noch einem P2P-Nutzer gehörte, nicht gestern erneut an einen Nutzer vergeben wurde, der gar kein FileSharing betreibt. Nun, das wissen wir nicht.
<e>
Und jetzt sollte man sich noch einmal oben unter Abschnitt 1.4.3 das Posting im Forum, und vor allem auch den Web-Link von @Frank2009 mal gründlich durchlesen.

Und jetzt darf sich mal jeder, der dieser komplizierten Materie noch folgen konnte, ob denn die IP-Adresse gefälscht??, oder einfach quer durch eine automatisch laufende Logging-Datenbank gerührt (nicht geschüttelt) wurde, und die Abmahnung dann möglicherweise bei einem AI landet, der noch nie FileSharing betrieben hat.

Der eine oder andere erfahrene User sollte sich ruhig mal dazu ein paar Gedanken machen.

###############################################
Trennungspunkt zum Forum-Bericht: Teil-1 Teil-C
###############################################


Damit beende ich diesen Abschnitt erst mal.
Den noch fehlenden Teil-1 Teil-C (Abschnitt 1.5 - Technik) gibts in ein paar Tagen.
Ich muss nämlich erst mal wieder frische Luft tanken.

-CityLight-

Zitat von CityLight

Und jetzt darf sich mal jeder, der dieser komplizierten Materie noch folgen konnte, ob denn die IP-Adresse gefälscht??, oder einfach quer durch eine automatisch laufende Logging-Datenbank gerührt (nicht geschüttelt) wurde, und die Abmahnung dann möglicherweise bei einem AI landet, der noch nie FileSharing betrieben hat.

Der eine oder andere erfahrene User sollte sich ruhig mal dazu ein paar Gedanken machen.

Ich muss nämlich erst mal wieder frische Luft tanken.

-CityLight-

Kompliment, so sieht für mich anständige Forschung aus.

Ich bin weit davon entfernt alles zu verstehen.
Ich hoffe aber doch, richtig verstanden zu haben, dass wesentliche Argumente für die Beweiskraft der log-Methoden wie die GUID nicht stichhaltig sind, und der ganze log-Vorgang, offenbar regelmäßig noch andere Fehler produziert ?!?

Und jetzt brauche ich auch frische Luft um den rauchenden Kopf zu kühlen.

Zitat von CityLight

Hier ist der nächste Teil des angekündigten Testberichtes.

Wenn ich das alles richtig verstanden habe und dazu noch den Vorwurf aus der Abmahnung nehme,

Zu einem tatsächlichen Download durch Dritte muss es dabei gar nicht kommen. Denn der Begriff der "öffentlichen Zugänglichmachung" bezieht sich bereits auf das bloße Download-Angebot. Es ist deswegen völlig irrelevant, ob bzw. wie viele Personen überhaupt auf das Download-Angebot zugegriffen haben. Unabhängig davon wurde der Dateidownload über Ihren Internetanschluss getestet und gesichert.

dann stützt der Abmahner seine Behauptung eines Downloadangebotes lediglich auf einige "Indizien", welches er wohl im Extremfall bei der RICHTIGEN Fragestellung, bspw. durch einen Sachverständigen nie und nimmer beweisen kann.
Dem soll hier wohl schon vorsorglich mit dem Satz:"....völlig irrelevant, ob bzw. wie viele Personen überhaupt auf das Download-Angebot zugegriffen haben." vorgebaut werden.

Das bedeutet auch derjenige User, welcher meinetwegen eine freie Linuxversion über P2P sucht, diese vermeintlich findet und versucht herunterzuladen ist fällig, auch wenn er lediglich einen Chunk beispielsweise einer *.rar-Datei hat, die zwar freieSoftwareXY.rar heisst, aber in wirklichkeit geschütztesWerk.rar heissen müsste.

Zudem bezweifle ich stark, dass sich aus einem Schnipsel einer *.rar Datei belegen lässt, was das genau war. Von der praktischen (fast) Unmöglichkeit eines Komplettdownloads des geschützten Werkes von nur einem User ganz zu schweigen.

Das sollte dringend ein Gericht ein für alle Mal klären!

Zitat von Revoluzzer

Dem soll hier wohl schon vorsorglich mit dem Satz:"....völlig irrelevant, ob bzw. wie viele Personen überhaupt auf das Download-Angebot zugegriffen haben." vorgebaut werden.

Für die Verletzung mag es irrelevant sein. Für die Begründung "gewerbliches Ausmaß" klingt es wenig überzeugend.

@ City




Ach du heilige Sch…, meine Fresse, mir fehlen einfach die Worte.
Ein Riesen Kompliment an Dich und Deine Mannschaft. Unbezahlbar
Selbst ich, als absoluter IT- Muffel ( Taste drücken und es muß funktionieren ) habe Dank Deinen Ausführungen a- dazugelernt und b- sogar ein wenig begriffen.

Zitat:

Das eigentliche Problem am Thema User-Hash (GUID) ist eigentlich, dass hiesige Gerichte/Richter das immer noch nicht geschnallt haben. Oder es interessiert einfach gar nicht.


Und genau da liegt mMn nach die Herausforderung. Alle solche Muffel wie ich. Von der Materie keine Ahnung aber Recht sprechen wollen. Das passt nicht.

Zitat:

Und jetzt stellen wir uns einfach folgendes Szenario vor. Am Tag-1 wird der User-A mit seiner GUID und seiner IP geloggt, obwohl er einen Leecher-Mod (also null-Upload) verwendet. Am Tag-2 sind wir mit seiner geklauten GUID unterwegs, und werden ebenfalls sogar mit Upload geloggt.

Frage zu geklaute GUID, kann diese unendlich oft benutzt werden ?

Nochmal RESPEKT

Auch auf die Gefahr hin, dass sich nun hinter mir eine Menschenmenge auftürmt, die mit dem Finger auf mich zeigt und laut "Spielverderber!" ruft. Ich habe deine Bemühungen registriert, CityLight, und anerkenne sie. Aber:

Zitat von Mahnopfer

Kompliment, so sieht für mich anständige Forschung aus.

Für mich nicht.

Ich bin weit davon entfernt alles zu verstehen.

Muss man das denn? Komplexität verschafft manchmal nur eine Illusion von Bedeutung. Im Exakten, im Nachvollziehbaren und in der Konzentration auf die Fragestellung liegen die Wurzeln wissenschaftlichen Arbeitens. So sehr ich es mir anders gewünscht hätte, diese Klarheit vermisse ich bei der Analyse doch schmerzlich.

Bei allem Respekt, aber der allgemeine CityLight-Applaus steckt mich oft nicht an. CityLight, verstehe das bitte nicht als persönlichen Angriff. Eher bedaure ich, dass du so viel Arbeit investierst, welche mir am Ende doch so ineffektiv, manchmal sogar nutzlos erscheint. Einige Punkte können ganz leicht widerlegt werden und manchmal gehst du auch von falschen Voraussetzungen aus, wodurch deine Ergebnisse auf tönernen Füßen stehen.

Was ich interessant fand, war die Versicherung an Eides statt (ich sehe da übrigens beide Seiten, nicht nur die erste). Unter Punkt 2.3 wird dort die Vorgehensweise bei der Identifizierung der Dateien nicht nur ungenau, sondern falsch dargestellt:

"Die Identifizierung der in einer Internettauschbörse rechtswidrig zum Download angebotenen Dateien durch das Programm der Firma DRS erfolgt im Wege eines Abgleichs der Hashwerte, also anhand eines beim jeweiligen Anbieter heruntergeladenen Teils der Datei selbst. Durch den sog. "Hashwert" kann eine in einer Internettauschbörse angebotene Datei zweifelsfrei identifiziert werden."

Falsch ist diese Darstellung, weil zur Bildung des Datei-Hashwertes immer die gesamte Datei erforderlich ist. Hat man nur einen Teil, kann der Dateihash nicht gebildet werden und ein Abgleich kann nicht stattfinden. Ob nun Absicht oder nur Ungenauigkeit; jedenfalls wird hier einem Sachunkundigen ein falsches Bild über die Beweiskraft vermittelt.

Zitat von Mahnopfer

dass wesentliche Argumente für die Beweiskraft der log-Methoden wie die GUID nicht stichhaltig sind, und der ganze log-Vorgang, offenbar regelmäßig noch andere Fehler produziert ?!?

Spielt die GUID überhaupt noch ein wesentliche Rolle bei der Argumentation der Abmahner? Bei BitTorrent gibt es diese GUID überhaupt nicht, dort allenfalls die nicht direkt vergleichbare PeerID. Sollte aber die GUID kein wesentlicher Bestandteil der Beweisführung sein, kann diese Beweisführung nicht dadurch erschüttert werden, dass man die Manipulationsmöglichkeit der GUID nachweist.

Zitat von Hadron

Auch auf die Gefahr hin, dass sich nun hinter mir eine Menschenmenge auftürmt, die mit dem Finger auf mich zeigt und laut "Spielverderber!" ruft.
......

Spielt die GUID überhaupt noch ein wesentliche Rolle bei der Argumentation der Abmahner? Bei BitTorrent gibt es diese GUID überhaupt nicht, dort allenfalls die nicht direkt vergleichbare PeerID. Sollte aber die GUID kein wesentlicher Bestandteil der Beweisführung sein, kann diese Beweisführung nicht dadurch erschüttert werden, dass man die Manipulationsmöglichkeit der GUID nachweist.

Denke mal nicht das Du wegen konstruktiever Kritik hier gesteinigt wirst. Im Gegenteil (was mich betrifft). Wir sollten alle Für´s und Wieder´s ausloten.
Du scheinst mir techn. auch gut unterwegs zu sein (w.g. ich nicht). Habe ich das richtig verstanden, das die PeerID anders zu bewerten ist wie die GUID?

Zitat von Hadron

Auch auf die Gefahr hin, dass sich nun hinter mir eine Menschenmenge auftürmt, die mit dem Finger auf mich zeigt und laut "Spielverderber!" ruft. Ich habe deine Bemühungen registriert, CityLight, und anerkenne sie. Aber:

Guter Einwand/Einwände.

Sachliche Vorträge sollten bei intelligenten, lösungsorientierten Menschen keine Emotionen auslösen, sondern das Gehirn aktivieren - und das tut dein Beitrag. Gerne mehr davon, auch wenn die Resultate anders aussehen, als gewünscht. Schließlich gehts um Fakten und nciht um ein Wunschkonzert.

Zitat von Hadron

......
Spielt die GUID überhaupt noch ein wesentliche Rolle bei der Argumentation der Abmahner? Bei BitTorrent gibt es diese GUID überhaupt nicht, dort allenfalls die nicht direkt vergleichbare PeerID. Sollte aber die GUID kein wesentlicher Bestandteil der Beweisführung sein, kann diese Beweisführung nicht dadurch erschüttert werden, dass man die Manipulationsmöglichkeit der GUID nachweist.

Dazu möchte ich doch mal einen Auszug aus meiner Abmahnung zum Besten geben:

Die zweifelsfreie Identifizierung erfolgte anhand einer eindeutigen Dateikennung (Hashwert) und dem Globally Unique Identifier (GUID). Darüber hinaus wurde das von Ihnen im Internet angebotene Filmmaterial von unserer Mandantin geladen, gesichtet und zu Beweiszwecken gesichert.

Daraus folgere ich, es wird anhand mehrerer technischer Begriffe versucht, die Aussage zu untermauern, die eigentlich nicht haltbar sind.

Gruß Wieder einer

PS Wenn man in einem Satz mehr als drei Fremdwörter benutzt, schaltet der gegenüber in den Dummymode.

-----Doppelpost zusammengeführt am 17.2.2010 um 11:24:41-----

@ Frank

Ich sehe das wie Revoluzzer:

dann stützt der Abmahner seine Behauptung eines Downloadangebotes lediglich auf einige "Indizien", welches er wohl im Extremfall bei der RICHTIGEN Fragestellung, bspw. durch einen Sachverständigen nie und nimmer beweisen kann.
Dem soll hier wohl schon vorsorglich mit dem Satz:"....völlig irrelevant, ob bzw. wie viele Personen überhaupt auf das Download-Angebot zugegriffen haben." vorgebaut werden.

Die Richtigen Fragen!

Wenn man das vorgehen nicht kennt, wie soll man da die Richtigen Fragen kennen. Wenn ich eine Arbeit begutachten soll, muss ich wissen was da läuft, muss die Materie kennen und die Funktionsweise verstehen. Nur so kann ich Fehler feststellen. Ich sehe da in den Abmahnungen nur immer die Sätze:

Die von unserer Mandantin eingesetzte Spezialsoftware ermittelt — ausweislich eines öffentlich bestellten und vereidigten EDV-Sachverständigen - ausnahmslos korrekte und gerichtsverwertbare Nachweise hinsichtlich der Nutzung derartiger Tauschbörsen.

Oder:

Diese Software liefert, wie durch Gutachten eines öffentlich bestellten und vereidigten EDV- Sachverständigen bestätigt, ohne Ausnahme korrekte und gerichtsverwertbare Ergebnisse.

Genau da stell ich mir die Frage WAS wurde begutachtet?

Ist es wie bei ISO 9001 das alle Dokumente da sind und die Mitarbeiter wissen wo was steht ODER
Man hat die Software und die Quellcodes dahinter begutachtet!

ISO 9001 bekommt man die Zertifizierung im ersten Fall und hat doch keine Aussage zur arbeitsweise.

Zitat von Wieder einer

...
zweifelsfreie Identifizierung erfolgte anhand
...
dem Globally Unique Identifier (GUID)
...

Ergänzend:
Häufigere "Fehler" (die zu falschen Schlussfolgerungen aus Logdaten führen können), die z.B. auftreten:
- es kopiert sich jemand das komplette eMule-Installationsverzeichnis (einzig von Bedeutung dabei das Unterverzeichnis ./config) von einem Freund. Dann hat er die gleiche GUID wie der Freund, solange er bestimmte Konfigurationsdateien nicht löscht (z.B. durch eine Neuinstallation).

- es hat sich jemand aus dem Netz ein komprimiertes Archiv runtergeladen, welches eine vollständige Installation eines eMule-Clienten beinhaltet, weshalb dieser Client nicht neuinstalliert werden muss. Dann hat er ebenfalls die gleiche GUID wie alle anderen auch, die dieses Archiv anstelle der Installationssoftware zur Installation (einfaches Entpacken) verwenden.

Für solche GUID-Kollisionensmöglichkeiten gilt:
für die Funktionalität der p2p-Clients bzw. des Netzwerkes nicht von Relevanz bei gleichzeitigem Betrieb solcher Clients

Mal ne andere Frage,

wäre die ganze Arbeit auch Gerichtsverwertbar und wen ja (ihr wisst, ich hab da so meine Probleme) im Zivil- oder Strafrecht ?

Zitat von Kersare

wäre die ganze Arbeit auch Gerichtsverwertbar und wen ja (ihr wisst, ich hab da so meine Probleme) im Zivil- oder Strafrecht ?

Die Arbeit könnte in einzelnen Punkten von einem Gutachter als Anregung zur Prüfung von Logsoftware verwendet werden (möglichst plausibel, kompakt und verständlich aufbereitet käme man bei einzelnen Richtern womöglich auch ohne Gutachter aus, so man berechtigte Zweifel an der Beweiskraft der angeblichen Abmahnerbeweise wecken könnte). In solchen Fällen dann zivilrechtlich evtl. relevant. Für den strafrechtlichen Bereich sehe ich da keinen Nutzwert solcher Arbeiten.

Zitat von Kersare

Mal ne andere Frage,
wäre die ganze Arbeit auch Gerichtsverwertbar und wen ja (ihr wisst, ich hab da so meine Probleme) im Zivil- oder Strafrecht ?

Die Frage stelle ich mir auch des Öfteren, wenn ich diese ellenlangen Dossiers lese. Habe da so meine bedenken ob sich die werte Richterschaft davon beeinflussen lässt oder in einem Urteil berücksichtigt.


Ups, da war ja einer einen pups schneller!

Zitat von Wieder einer

Daraus folgere ich, es wird anhand mehrerer technischer Begriffe versucht, die Aussage zu untermauern, die eigentlich nicht haltbar sind.

Das folgere ich ebenso. Die Abmahner beherrschen durchaus die Kunst des gepflegten Technobubble.

Wenn ich eine Arbeit begutachten soll, muss ich wissen was da läuft, muss die Materie kennen und die Funktionsweise verstehen. Nur so kann ich Fehler feststellen.

Genau. Deshalb vermute ich hinter der Intransparenz der "Anti-Piracy"-Firmen auch eine bestimmte Absicht. Die kochen mit Wasser, verkaufen das nach außen aber als Wein.

Genau da stell ich mir die Frage WAS wurde begutachtet?

Und natürlich auch: WER hat das mit welchem Hintergrund begutachtet, wer hat ihn bezahlt, was war die Motivation des Gutachters?

Zitat von ulrich

Die Frage stelle ich mir auch des Öfteren, wenn ich diese ellenlangen Dossiers lese. Habe da so meine bedenken ob sich die werte Richterschaft davon beeinflussen lässt oder in einem Urteil berücksichtigt.

Wenn nicht gibt es ja eine Berufungsinstanz (oder nicht?).

Ich denke schon, dass die Arbeit nicht umsonst ist, auch wenn sie in der ersten Instanz vielleicht nicht die gewünschten Erfolge bringt...