• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Copy Bot ist wieder da ?

Nach deiner Logik müssten Waffen generell verboten sein. Schlaftabletten übrigens auch. Und wahrscheinlich die Hälfte aller Dinge, die man kaufen kann, weil man sie immer jemand auf den Fuß hauen kann, den Kopf einschlagen, den Stoffwechsel damit vergiften und und und.

Ich kann dich grundsätzlich verstehen, ich war auch mal LibSL-Gegner aus den gleichen Gründen wie du. Das war, bevor ich angenfangen habe, nützliche, legale Dinge damit zu machen.

Doktor Schnyder schrieb:
Ich finde das jedenfalls voll krank eine Software auf den Markt zu bringen die gegen meine eigenen AGB verstösst.

Dann bau mal deinen CD-Brenner aus, denn du könntest ja theoretisch damit illegale Kopien von Audio-CDs machen.
 
Natürlich bin ich gegen die Abschaffung von Waffen :)

Aber mal im Ernst , ich bin kein Gegner der LibSL ganz im Gegenteil nutz das ja selber aber diese Import/Export Funktion könnte man doch wirklich von vornerein so einstellen das es TOS konform ist.


Ist ja nur noch eine Frage der Zeit wann der reguläre Client die Funktion auch inne hat.
 
Doktor Schnyder schrieb:
Ist ja nur noch eine Frage der Zeit wann der reguläre Client die Funktion auch inne hat.

LOL

der nomale, hoch offizielle Client kann alles, was auch der Copybot kann. In deinem Cache liegen neben den Skripten, die du modden kannst auch Animationen, Guestures und vor allem alle Texturen im jpeg2000-Format von LL.
Dabei ist das Format kein Geheimnis, die Spezifikation ist offen:
http://wiki.secondlife.com/wiki/Texture_Cache

Und es ist für einen Programmierwer ein leichtes, den Code des Viewers so umzuschreiben, dass der auch dein Inventory auf Festplatte speichert. Und alle Prims, die man im Viewer sieht.
Zumindest ist es kein bisschen schwerer als sich aus libsl einen Copybot zu bauen.

Nebenbei kann man auch mit den beiden unerwähnetn Kennungen, die Isandra da anfügt, keinen dran hindern, nach SL zu connecten.
Das ist nämlich lediglich einmal die MAC-Adresse der Netzwerkkarte mit der man online geht und einmal die UUID der ersten Festplatte im Rechner.
Und da kann der Bot auch einfach irgendwelche zufallsdaten generieren und die Senden.
Und schwups ist man wieder drinne.

Und das schönste ist:
Man kann einen Viewer so programmieren, dass er sich 100% wie ein Offizieller Viewer verhält.
Und wenn man einen Knopf drückt, dann arbeitet der einfach als Copybot, ohne diese Limitationen, die das libSL Dings hat.
Und danach drück man wieder einen Knopf und schon ist es wieder ein ganz normaler Viewer.
Und der Server oder aussenstehende bekommen davon überhaupt nix mit.


==> Wer libsl verbieten will um die Bots abzuschaffen, der muss auch forden die Quellen des Viewers closed source zu machen, die Spezifikationen von SL nicht mehr offen zu legen, das OpenSim Projekt einzustampfen - und der hat trotzdem keinerlei Sicherheit, dass nicht doch wer ein Programm am laufen hat, dass die Texturen aus dem Cache entschlüsselt und das Objekte kopiert.

Und ganz nebenbei:
OpenGL hat eine debug-Schnittstelle, und über die kommt man auch an alle Daten, die die Grafikkarte anzeigt. Also auch an die Texturen und an die Geometriedaten von Objekten.
Und das schöne an der Geschichte ist:
Die Anwendung von GLintercept (das istdas debug-Programm) wird nicht mal bemerkt, und sie ist an sich nicht verboten.
Auch nicht bei der nutzung von SL. Denn da wird überhaupt nicht in den Server eingegriffen, das passiert alles lokal auf dem heimischen Rechner.
Verboten ist es nach der TOS/DMCA lediglic,h die Texturen anderer ohne deren Einwilligung ausserhalb von SL zu nutzen bzw. die Texturen anderer wieder als eigene hochzuladen.

==> Es gibt keinen Schutz gegen Kopieren von Inhalten aus SL.
Das ist technisch nicht realisierbar.

Der einzige Schutz vor "Copybots" ist eben nix mehr hochzuladen, das nicht in falsche Hände gelangen soll.

Und der einzige 100% Schutz vor Bots ist alt+F4, wenn man in SL ist.
 
Swapps Swenson schrieb:
Ezian Ecksol schrieb:
Nur weil ein paar wenige Leute jemand anderem mit einem Hammer den Kopf einschlagen, sollte man keine Hammer verbieten.

Rethorisch sehr schön argumentiert. Sowas nenne ich dann
"Totschlag-Argumente".

Also ist auch die Rethorik ein Hammer. Sollten wir ihre Anwendung sicherheitshalber in den Forenregeln ausschließen? :)
 
Shirley Iuga schrieb:
Nebenbei kann man auch mit den beiden unerwähnetn Kennungen, die Isandra da anfügt, keinen dran hindern, nach SL zu connecten.

Sagte ich ja das man da hinein schreiben kann was immer man will und man kann trotzdem connecten, ich sagte lediglich das der damalige vorcompilierte copybot der damals in sl verhökert wurde und der auf den !quit befehl reagierte von llabs anhand der beiden kennungen gesperrt wure, alle anderen bots blieben ja davon unbeeinflußt.
 
Es gibt mittlerweile GANZ andere Möglichkeiten Content zu stehlen.

:roll:


einen Copybot braucht im Grunde niemand mehr.

Diese neue Möglichkeit kommt aus den Reihen von Linden.

Sicher sind eure Sachen schon lange nicht mehr.

:lol:
 
Scripte sind keinesfalls im lokalen Cache zu finden. Alles was wegen OpenGL auf dem lokalen Rechner zu finden ist sind die Texturen. Objekt- und Animationsdaten sind sicherlich auch vorhanden aber eben nicht so einfach wiederzuverwenden wie die Texturdateien. Dafür benötigt man schon profunde OpenGL-Kenntnisse bzw. Tools, die mir nicht bekannt sind und hier auch gar nicht bekannt gemacht werden sollen.
 
Swapps Swenson schrieb:
Scripte sind keinesfalls im lokalen Cache zu finden. Alles was wegen OpenGL auf dem lokalen Rechner zu finden ist sind die Texturen. Objekt- und Animationsdaten sind sicherlich auch vorhanden aber eben nicht so einfach wiederzuverwenden wie die Texturdateien. Dafür benötigt man schon profunde OpenGL-Kenntnisse bzw. Tools, die mir nicht bekannt sind und hier auch gar nicht bekannt gemacht werden sollen.

Doch... scripte sind im cache, aber zugänglich sind nur welche, die man mod hat und die man bearbeitet hat, ebenso wie abgespielte sounds und derartiges. Neben dem Textur-Cache gibts auch noch einen cache, indem diese Dinge sind, und auch das Inventory wird als kleine UUID-Datenbank in den Cache geladen.

Nicht-Mod scripte sind nicht als lsl, sonern höchstens als lso verfügbar, also als compilierter binärcode. Und mit dem fängt man in SL nix an.

Deswegen kann man mit dem hier:

http://www.libsecondlife.org/wiki/Slice_Source

Seinen cache auslesen und evtl. Dinge wieder herstellen, wenn mal was kaputt ist (oder aus versehen ganz gelöscht).
(Dabei ist da eine kleine Abfrage drinne, die verhindert, dass z.B. Texturen "wiederhergestellt werden", die einem nicht gehören, man kann also keinen Unsinn damit anstellen ohne das Dings umzuprogrammieren...)

Und Programme wie "Secondinventory" oder sowas machen auch nix anderes als die Daten zu verwerten, die über dieses Cachen an den Viewer gelangen.

Letztendlich werden dabei einfach die offenen Spezifikationen verwendet. Der SL-Viewer und die Protokolle usw. sind offen.

Und mit den OpenGL-Debug Infos ist das wie mit der Anzeige der UUID bei den Texturinfos, die man beim normalen Viewer nur über umwege bekommt, die man aber früher einfach mit zweiTastaturshortcuts anzeigen lassen konnte:

Man kann das dazu verwenden um die UUID zu holen von Texturen und die dann mit llSetTexture illegal zu kopieren - man kann damit aber auch wunderschön und einwandfrei nachweisen, dass jemand die Textur geklaut hat. Denn auch wenn dieses Feature deaktiviert ist in den neuen Viewern - die Textur UUID kann man sich über einen kleinen Umweg noch immer holen!
Aber:
Wenn die UUID auf einem Objekt ist, auf dem die ganz sicher nix verloren hat, dann kann das nämlich Grundlage sein für ein weiteres Vorgehen.

Und nicht anders ist das bei dem OpenGL-Debugger.
Da kann man einwandfrei sehen, ob der Skin nur ziemlich ähnlich ist, oder ob da z.B. ein geklauter Skin oder andere geklaute Texturen verwendet wurden. Man muss nur die Texturen aus SL mit den Texturen vergleichen, die man selbst gemacht hat, und mit den richtigen Filtern und Kanalberechnungen sieht man dann z.B. im Photoshop recht schnell ob da wer illegal kopiert hat - und da nützt auch ein leichtes Nachbearbeiten der geklauten Texturen dann nix!
Meist reicht sogar ein Simples Übereinanderlegen in zwei Ebenen und der Dieb ist überführt. Und gerade bei den gern geklauten Skins kann der Dieb im Zweifel z.B. dann keine originale "HQ"-Textur in 1024x1024 vorweisen, da er durch das Klauen nur an eine 512x512 gekommen ist - nachträglich Aufblasen bringt auch nix mehr gegen den Informationsverlust!


Wer wirklich was gegen Texturdiebstahl in SL unternehmen will, der sollte also den Leuten nicht die Werkzeuge wegnehmen, mit denen sie so einen Diebstahl schnell und relativ umkompliziert erkennen können, sondern sich vielmehr dafür stark machen, dass endlich ein Wasserzeichen oder sowas in die Texturen eingebaut wird beim encoden in jpeg2000, das man nachträglich schnell und einfach überprüfen kann.
Denn bisher steht da lediglich eine UUID mit dem Ersteller dabei.
 
Zu Texturen:
Das mit den Texturen hast du sehr schön erklärt.

Scripte:
Die eigenen Scripte sind nur deshalb im Cache zu finden weil sie eventuell zuvor im Editor geöffnet wurden. Wer mit leeren Cache sein Land betritt ohne seine Scripte zum bearbeiten zu öffnen wird wohl auch kaum seine eigenen Scripte plötzlich im Cache vorfinden.

Objektdaten:
Wenn ich dich richtig verstanden habe, werden also Objektdaten (Prims) gar nicht wirklich kopiert, sondern nur die fremden UUID für eigene Objekte verwendet/missbraucht. Richtig?
Oder kann man die Formen mit OpenGL komplett auslesen und dann eben doch wieder in SL damit neue eigene Objekte erstellen?
 
AFAIK ist es so:

Swapps Swenson schrieb:
Oder kann man die Formen mit OpenGL komplett auslesen und dann eben doch wieder in SL damit neue eigene Objekte erstellen?

d.h. die Formen werden ausgelesen und automatisiert in SL wieder neu aufgebaut.

Wohingegen es bei Texturen reicht, den Key zu kennen, um die Textur auf Inworld-Objekten neu zu setzen.

Bei Scripten ist es eben auch so, wie du sagst, Swapps. Wenn wir von Scripten reden, müssen wir zwischen den Quelltexten und dem Pseudocode unterscheiden. Nur die Quelltexte von Scripten, die man selbst bearbeitet hat, werden gecached. Der kompilierte, ausführbare Pseudocode eines Scripts liegt auf den Asset-Servern und wird auch hauptsächlich von den Simulatoren ausgeführt, d.h. eine Kopie davon gelangt überhaupt nicht in den Client. Dorthin gelangen nur Anweisungen für den Client, wenn es für ihn etwas zu tun gibt.

Und selbst wenn eine Kopie des Pseudocodes eines Scripts auf den lokalen Rechner gelangen würde, und es gelingen würde, sich diesen durch Reverse Engineering wieder in lesbaren LSL-Quellcode zu wandeln, dann sehe ich darin ehrlich gesagt einen so hohen Aufwand, dass es für einen Benutzer mit diesen Fähigkeiten i.d.R. wesentlich einfacher wäre, die Funktionalität eines Scriptes einfach nachzuprogrammieren.
 
Swapps Swenson schrieb:
Scripte:
Die eigenen Scripte sind nur deshalb im Cache zu finden weil sie eventuell zuvor im Editor geöffnet wurden. Wer mit leeren Cache sein Land betritt ohne seine Scripte zum bearbeiten zu öffnen wird wohl auch kaum seine eigenen Scripte plötzlich im Cache vorfinden.

Wenn man no-mod Scripte im Inventory hat und das in ein Objekt einbaut, dann landet wohl eine Kopie davon im Cache. Allerdings als Bytecode/Maschinencode z.B. mit Anweisungen für den Viewer.
Damit fängt man, wie Ezian sagt, nur indirekt was an, denn selbst wenn man das skript so nachkonstruieren kann - es ist viel einfacher das kurzerhand nachzuskripten. Und das ist nich mal verboten...in SL gibts keine Patente.

Objektdaten:
Wenn ich dich richtig verstanden habe, werden also Objektdaten (Prims) gar nicht wirklich kopiert, sondern nur die fremden UUID für eigene Objekte verwendet/missbraucht. Richtig?
Oder kann man die Formen mit OpenGL komplett auslesen und dann eben doch wieder in SL damit neue eigene Objekte erstellen?

Wenn ein Prim in SL erzeugt wird, dann bekommt es eine neue UUID.
Aber ein Prim besteht in SL aus einem Datensatz wie:
["3783-387802hjheu-2782","Box",2, 0, <0.000000, 1.000000, 0.000000>, 0.000000, <0.000000, 0.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, <0.000000, 0.000000, 0.000000>,FALSE,TRUE,4, 0, <0.000000, 1.000000, 0.000000>, 0.000000, <0.000000, 0.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, <0.000000, 0.000000, 0.000000>]
(nur mal symbolisch)

Und der Viewer bekommt da jede Einzelheit wie Textur-UUID, Form, Material usw. über jedes Prim geliefert, damit er weiß was er da Zeichnen muss. Deswegen ist es ein leichtes diese Parameter einfach abzuspeichern und die dann auf ein neues Prim zu übertragen, etwa mit einem "gehackten" viewer.

Aber auch über die OpenGL-Schnittstelle kann man an die Geometriedaten kommen. Und die dann z.B. in einem 3D-Programm wie Maya o.Ä. verwerten.

Das ist eine Möglichkeit z.B. den Avatar aus SL als Geometriedatensatz zu holen, den in ein 3D-Progamm zu importieren und dann den Skin oder die Kleidung zu Rendern und die Texturen zu baken und so z.B. Fotorealistische Skins zu machen.
Nur um mal eine weitere völlig legale Anwendung von OpenGL debuggern anzuführen.

Klar kann man so auch an Geometriedaten von anderen Objekten in SL kommen - aber die kann man dann nicht so ohne weiteres wieder in SL erstellen...da muss man noch einiges machen, so dass auch da dann das direkte Erstellen eigener Objekte meist deutlich schneller und einfacher ist.
 
Wird ja immer interessanter hier :)

Also das mit den Scripten war mir echt neu das die auch gecached werden, wenn auch nur in Maschinensprache.

Aber jetzt noch mal zum Verständnis:
Wenn ich das mit den Texturen und den Prims hier richtig interpretiert habe hat die LibSL eigentlich von Hause aus ne Sperre, das man keine fremden Objekte und Texturen kopieren kann , also so eine Art Abfrage wem das Teil gehört.

Aber ein paar schlaue Programmierer haben diese Abfrage ausgehebelt, so das LibSl da Rechtlich aus dem Schneider ist.

Kann man dem soweit zustimmen oder liege ich völlig daneben ??
 
Das ist der relevante Codeteil im Testclient der libopenmv:

Code:
if (Properties.OwnerID != Client.Self.AgentID &&
 Properties.OwnerID != Client.MasterKey &&
 Client.Self.AgentID != Client.Self.AgentID)
{
   return "That object is owned by " + Properties.OwnerID + ", we don't have permission " +
   "to export it";
}

Da steht, dass das Exportieren von Objekten nicht erlaubt ist, wenn die eigene AgentID ungleich der eigenen AgentID ist. Haeh? Also greift dieses "Sicherheits-Feature" nie. Also muss man im Testclient auch nix ändern, damit man die Objekte [libary:68a6e9c12c]Ein [Objekt] in [SecondLife] besteht aus einem oder mehreren [Prims] und kann wiederum mit anderen [Objekte] befüllt werden.[/libary:68a6e9c12c] von jedem exportieren kann.
 
Das ist doch ein Schnipsel aus ExportCommand.cs, oder?

So wie ich das sehe fehlt da die eigentliche Funktion, die das Exportieren als xml-datenpaket übernimmt. Das ist lediglich die Abfrage ob die Permissions passen oder nicht.
Und da ist wohl auch ein Fehler drinne...das stimmt.
das eine client.self.AgentID muss wohl ein client.network.AgendID sein...oder?

Eventuell kann sich das ja mal wer ansehen, der mehr von C#-Coding versteht als jemand, der sich durch Info-Grundvorlesungen für Nebenfächler gemogelt hat *g*
 
Doktor Schnyder schrieb:
Aber ein paar schlaue Programmierer haben diese Abfrage ausgehebelt, so das LibSl da Rechtlich aus dem Schneider ist.

Kann man dem soweit zustimmen oder liege ich völlig daneben ??


Selbst wenn die eine Funktion programmieren würden, mit der man alles und jeden in SL kopieren kann und mit denen man IM abhören könnte ohne dass das wer mitbekommen wär das alles noch legal.

Illegal ist nicht das Tool an sich, Illegal ist die Nutzung dieses Tools auf eine bestimmte Art und Weise.

Das ist ähnlich wie z.B. mit Software-CDs. Die kann man ja Kopieren.
Und dafür gibts Programme wie z.B. Nero oder Alcohol120%, die das eben können. Kann man im Mediamarkt oder bei Saturn oder so käuflich erwerben.

Weder diese Programme noch die Bestimmungsgemäße Benutzung der Kopierprogramme ist illegal, bei Software-CDs darf man sogar den technisch wirksamen Kopierschutz (was auch immer das sein soll..)einfach aushebeln und umgehen, falls vorhanden - der ist da nicht geschützt. Und man darf dann z.B. eine Sicherungskopie der wertvollen Original-CD anfertigen.

Was man nicht darf, das ist diese Software einfach Kopieren um sie an Freunde weiterzugeben. Das wäre eine illegale Handlung.

Und so darfst du den Testclient ganz legal dazu nutzen um z.B.Objekte auf deinem eigenen OpenSimulator Server als xml-datei zu kopieren, aber du darfst ihn nicht nutzen um damit in SL Texturen und Prims zu kopieren.

Noch gibt es kein "Waffengesetz" für derartige Software - in Deutschland ist lediglich "Hackersoftware" verboten, die dazu geeignet ist, Passwörter und sonstige Sicherungscodes zu knacken.
Und das auch nur, wenn man damit eine Straftat begehen will.

Aber in den USA ist auch so eine Software legal.
 

Users who are viewing this thread

Zurück
Oben Unten