Dumbframes und Agenten

Zitat

Ja, und wieso könnte ein Frame oder Agent selbständig auf anderen Systemen laufen, wenn schon ein einfaches 3-Zeilen-Skript früher oder später auffällt, sogar dann, wenn es nichts tut?

Ich denke mal, dass ein Agent in der Lage ist sich aktiv zu verstecken, oder mal eben das RTG zu wechseln um sein Sicherheitskonto wieder auf 0 zu senken.
Ein Skript liegt dagegen nur rum und wartet, dass es entdeckt wird.

ein programm (agent/smartframe/dumbframe/etc.) braucht immer eine gewisse rechenpower des systems in dem es sich gerade aufhält, vielleicht nicht ganz soviel, aber ein bisschen schon.

Vergleiche:
LAN - Games, man kann ein Spiel auch bei einem Kumpel auf dem rechner starten, der rechnet das auch alles aus, aber dein eigener PC muss trotzdem ein bisschen rechenleistung opfern, für Grafik, Sound, ein und ausgabe, sowie für die berechnungen der datenübertragung.

Was folgt daraus? Das Deck muss online bleiben, solange der Agent unterwegs ist. Nicht mehr und nicht weniger.

Kein gutes Beispiel.
Solange der Agent am "Forschen" ist muß ich nicht Online sein, denn ich will mir seine Suche weder ankucken noch sein Gemurmel beim Durchforsten von Daten hören.

Ich bin Online
Setze ihn in die Matrix
Gehe Offline und lasse ihn Arbeiten
Gehe je nach "Arbeit" irgendwann Online
Schaue nach was er herausgebracht/geändert/verwüstet hat

So verstehe ich den Sinn und die Funktion eines Agenten.

(meint meine Barbie)

Hallo!

Ja, das und als "Kampfdrohne", wenn es um die Wurst geht.
Daß der Decker derweil Kaffee kochen kann, ist auch unstreitig, denke ich.
Die Frage ist nur, ob er auch sein Deck derweil abschalten kann, und das sehe aus erwähnten Gründen nicht so.

Gruß

Quichote

"Quichote" schrieb:

Bei einem Systemwechsel würde das ja bedeuten, daß der komplette Frame mit all seinen vielen MP sich jedes Mal von einem Gitter in's nächste kopiert, und das ohne Probe (die Zugangsprobe besschreibt ja nur das reine Login) und ohne daß es ein erhöhtes Risiko für das Sicherheitskonto bedeutet.

Nö, der Frame als Icon muß ganz normal seine Proben würfeln und hat sein eigenes Sicherheitskonto. Verläßt der Decker den Host, bleibt der Frame zunächstmal genau da, wo er ist, nämlich im alten Host.

Hallo!

Zitat

Nö, der Frame als Icon muß ganz normal seine Proben würfeln und hat sein eigenes Sicherheitskonto. Verläßt der Decker den Host, bleibt der Frame zunächstmal genau da, wo er ist, nämlich im alten Host.

Das ist doch gar nicht die Frage.
Wenn sich ein Decker in einen Host einloggt, legt er dazu die Zugangsprobe ab. Das bedeutet aber zunächst mal nichts anderes, als daß er limitierte Leserechte auf diesem Host bekommt, also Datafeed in sein Deck. Datenverarbeitung findet dann dort statt. Auch der Datafeed zurück in den Host, beispielsweise zur Interaktion oder ICON-Darstellung, geht vom Deck aus. Alle weiteren Aktionen wie lesen, schreiben etc. fordern weitere und durchaus schwierige Proben.
Ein Frame oder Agent, der (mit Decker oder selbständig, was sie ja unstreitig können) nicht auf dem Deck selber laufen würde, müßte sich im vollen und großen Umfang selber auf den Host "kopieren", also ständig schreiben, und für Datenverarbeitung FLOP-Leistung (oder deren 2060-Pendant) vom Host benutzen.
Bei allen weiteren Vorgängen unterscheiden sich die Proben für Frame und Decker ebenfalls nicht. Es ist aber einfach unlogisch, daß ein illegal auf einem Host laufendes Programm solcher Größe genau so operieren kann wie eines, das seine Rechenleistung woanders herbezieht. Laufende Tasks sind der erste und wichtigste Punkt bei der Systemüberwachung, aus Sicherheits- wie Performancegründen, was sich ja auch in den Regeln für Skripte widerspiegelt.

Gruß

Quichote

Zitat

Ein Frame oder Agent, der (mit Decker oder selbständig, was sie ja unstreitig können) nicht auf dem Deck selber laufen würde, müßte sich im vollen und großen Umfang selber auf den Host "kopieren", also ständig schreiben, und für Datenverarbeitung FLOP-Leistung (oder deren 2060-Pendant) vom Host benutzen.

Öhm, das macht der Frame nicht von alleine. Der Decker muß ihn hochladen. Das ist für mich auf jeden Fall eine Systemprobe.

Ich sah das ganze bislang so, dass der Decker in dem Moment, wo er den Agenten / das S-Frame hochlädt eine Art Nische in der Systemüberwachung erzeugt, die das Frame/Agent dann nutzen kann um seine Operationen auszuführen.
Oder das ganze als registriertes/legales Programm einträgt...

Hallo!

Zitat

Öhm, das macht der Frame nicht von alleine. Der Decker muß ihn hochladen. Das ist für mich auf jeden Fall eine Systemprobe.

Ja, aber doch nur das erste Mal! Und eine Datei hochladen ist ganz und gar nicht dasselbe wie einen fremden Host zum Ausführen eigenen Codes zu zwingen ...

Gruß

Quichote

Meine Güte fragt einen Hacker wenn ihr sowas wissen wollt

Es gibt auch heute schon sehr gute Hacker, die einem Host, ohne das dieser es merkt, Festplattenspeicher, RAM oder Prozessorleistung wegnehmen können.
Dem System wird vorgegaukelt, die vollen Kapazitäten zu haben, das heisst weder das System noch der User merken, dass etwas fehlt. Wärenddessen läuft in aller Ruhe im Hintergrund ein Prozess . Hacker benutzen auf diese Art ungeschützte Systeme für Passwort-Brute-Force-Attacken.
Viele Hacker lagern auch gerne ihre Pornos auf diese Art in ungeschützten Systemen ab.
Das is alles kein Problem, wenn man gut genug ist.
Und so ist es auch bei Shadowrun - der Decker "installiert" also seinen Agenten am Zielhost, loggt sich aus und der Agent arbeitet. Der Decker hat also den Agenten vorher im aktiven Speicher, kopiert ihn in den Host und kann sich anschliessend ausloggen.
Ein AUfspür-IC kann den Jackpoint des Deckers herrausfinden wenn es den Agenten findet. Blöderweise ist der Decker dann halt shcon über alle Berge.
Und überschätzt mal Agenten nicht. Selbständig können die kaum RTGs wchseln. Die verstehen nur simple Befehle, komplexe, verschachtelte Anweisungen bringen die schnell zum Absturz (sie Matrix-Handbuch, Pilot-Stufe eines Agenten).

lg
Karlotius

Hallo!

Wie Du richtig und mehrfach schreibst: Bei ungeschützten Systemen, ja. Aber von denen reden wir ja nicht. Du wirst wahrscheinlich zustimmen, daß genau diese Überwachung von Tasks und fremden Codes die herausragende Sicherheitsaufgabe ist. Für nichts anderes sind schließlich die DMZs zwischen Firewalls da.

Ich hätte auch keine Schwierigkeiten damit, wenn ein Frame in einem grünen System laufen würde. Spieltechnisch aber macht es für die Lauffähigkeit (wenn ich ihn erst einmal herabgeladen habe) keinen Unterschied, ob das Ding in einem blaßblauen oder tiefdunkelroten System arbeitet, was für mich ein weiteres Indiz ist, daß er eben nicht auf fremder Prozessorlast läuft.

Und ein Agent mit Gepäck ist ohne weiteres in der Lage, Hosts zu wechseln. Natürlich kommt er nicht alleine in eine Bank. Für einen schwachen orangen Hosts aber kann es, je nach Aufgabenstellung, reichen.

Insgesamt ist aber, so scheint es mir, alles dazu gesagt, was man irgendwie argumentieren kann. Wasserdicht beweisbar ist wohl weder nach Regeln noch nach Logik keine Seite, weswegen es mal wieder auf das gute, alte "Spielleiter! Sag was!" hinausläuft

Gruß

Quichote

Wenn jedes System ungeschützt wäre gäbe es keine Decker, keine Cyberdecks, keine DeckingUtilities etc.
Kein System is perfekt geschützt und du kannst als Spielleiter deinem Decker nicht einfach sagen "nein das geht nicht, das System ist geschützt". Da käme ich mir zumindest sehr verarscht vor. Alles ist möglich, unterschiedlich schwer und gefährlich, aber möglich ist alles (vor allem in der Matrix).

Ein Agent, der auf einem Host läuft ist im Prinzip nichts anderes, als ein eingeloggte Benutzer für das System. Er kurvt halt rum und macht dies und das. Ein eingeloggter Benutzer frisst ja auch Ressourcen. Der Agent macht nix anderes. Die Erkennung, ob das, was er macht legal oder illegal liegt läuft genauso ab wie bei einem Decker. Das System kann ohne genauem Scan einen Agenten vorerst nicht von einem Decker unterscheiden. Und einen derartigen Scan führen meines Wissens nach keine IC sondern nur Sicherheitsdecker durch.

Ein interessantes Problem sind aber Utilities, die der Agent benutzt. Ein Decker, der Utilities benutzt scheint diese laut Regelwerk ja alle lokal laufen zu lassen. Diese lokal laufenden Utilities überprüfen offenbar nur den Datenstrom, der definitiv am Deck landet, also nicht den ganzen Host.
Utilities, die für einen Agenten zur Verfügung stehen müssen also laut Regelwerk am Host liegen, wofür sie Speicherplatz brauchen.
Nun gibt es ja die Regel, dass man sich für Programmierarbeiten Platz auf Hosts mieten kann. Soweit ich weiß, kann man sich diesen Platz auch illegal besorgen.
Eine durchaus angebrachte Regel wäre also, dass der Decker zuerst dafür sorgen muss, dass seine Utilities auch ein Platzerl zum laufen haben bevor er den Agenten raufläd. Oder er sagt seinem Agenten, er soll dafür sorgen, dass die Utilities eines haben (falls der Host/das Gitter gewechselt wird). Das wär dann aber dann schon was für einen Semi-Autonomen Knowbot

"Quichote" schrieb:

Ja, aber doch nur das erste Mal! Und eine Datei hochladen ist ganz und gar nicht dasselbe wie einen fremden Host zum Ausführen eigenen Codes zu zwingen ...

Mehr als einmal muß er doch gar nicht. Für alles, was der Frame danach macht, muß er ganz normal seine Systemproben würfeln. Und wenn er nichts macht, muß er halt auf die Dauer Nulloperationen würfeln.

Hallo!

Zitat

Kein System is perfekt geschützt und du kannst als Spielleiter deinem Decker nicht einfach sagen "nein das geht nicht, das System ist geschützt". Da käme ich mir zumindest sehr verarscht vor. Alles ist möglich, unterschiedlich schwer und gefährlich, aber möglich ist alles (vor allem in der Matrix).

Erstens: Nein, es ist nicht alles möglich. Die Natur der Matrix und der Sinn des Hosts gibt Grenzen vor.
Und ich sage auch gar nicht ""nein das geht nicht, das System ist geschützt" und habe das auch nie so dargestellt. Ein Decker soll seinen Agenten gerne benutzen. Ich lasse ihn nur nicht derweil sein Deck ausstöpseln und den Flug nach irgendwo nehmen.

Zitat

Ein Agent, der auf einem Host läuft ist im Prinzip nichts anderes, als ein eingeloggte Benutzer für das System.

Doch. Er frißt ein erhebliches Mehr an Ressourcen. Er ist also mehr ein Wurm als ein illegaler User. Und gerade weil er genauso behandelt wird wie ein Decker, bin ich der Meinung, daß er auf dem Deck läuft und nicht auf dem Host.
Ähnliches gilt für Utilities. Ein Programm, was für ein Deck geschrieben wurde (vor allem, wenn es reichlich Programmieroptionen intus hat), würde auf einem Host nicht laufen. Anderes OS, andere Architektur, andere Protokolle. Ein Agent, der auf dem Host liefe, wäre also bei ausgeloggtem Deck ohne Utilities ...

Gruß

Quichote

Warum muß ich dann die Utilities in den Agenten laden und warum ist er so groß? Warum braucht er eigene Utilities mit möglicherweise begrenzter Stufe und kann nicht einfach auf die vom Decker im aktiven Speicher abgelegten zurückgreifen?

Claw trifftes auf den Punkt.
Der Agent muss die Utilities, die er benützen will an selben Ort haben an dem er aktiv ist.
Er kann nicht auf den Speicher des Cyberdecks des Deckers zurückgreifen, weil er völlig unabhängig von diesem operiert.
Und ja, er braucht Speicher - sowohl für seine KI-Routinen als auch für seine Utilities.
Als Meister, der es genau nimmt, muss man also den Decker-Spielern sagen, dass sie dafür sorgen müssen, auf dem Zielhost Speicher für den Agenten und seine Utilities zu hacken.
Dies ist genau so zu behandeln wie das illegale "mieten" von Speicherplatz von Hosts zwecks Programmierarbeiten (steht im Matrix-Buch irgendwo).
Und man kann sich auf jedem Host beliebig viel Speicherplatz "hacken". Es is nur unterschiedlich auffällig (Stichwort Dateisystem korrumpieren).

Derartige Dinge unterbrechen meiner Meinung nach den Spielverlauf - die Regeln im Matrix-Buch sind so schom komplex genug, also versucht lieber mal mit denen zu spielen

Wieviele Kopien eines Frames kann man eigentlich laden?
Ich stelle mir mal Folgendes vor: angenommen ich habe einen Agenten programmiert. Angenommen ich habe den mehrfach kopiert. Wieviele Kopien kann ich in die Matrix laden? Ich will ja keine Schwämme verursachen.

Kannst du aber...