Jump to content

Kameras Loopen Teil 2


Masaru
 Share

Recommended Posts

Das Bild sieht etwas anders aus (heute wie 2075+).

 

Hier wäre eine schematische Darstellung:

 

(Eine Kamera zeichnet auf und sendet via Live-Stream die einzelnen Datenpakete in einem Datenstrom an eine Datei in z.B. einem Host.
Ein Wachmann liest mittels Kommlink die Datei während er seine Patroullie läuft und lässt sich das Video z.B. in einem ARO in der Ecke seines Blickfeldes einblenden.
Drei weitere Wachleute in der Zentrale schauen auf einen Trideoprojektor, welcher ebenfalls die Kameraübertragung aus der Datei kontinuierlich liest und anzeigt.

Zu guter letzt gibt es im Host noch eine Spinne, die sporadisch auf die Datei zugreift und liest.)

 

 

19035312256_1282de49b8_z.jpg

 

 

Das Thema "Datenstrom" wird außerdem ebenfalls im GRW erwähnt, S.216

 

Manchmal kann man auch einen Datenstrom sehen, der aussieht wie ein mehrfarbiger, flackernder Lichtstrahl.

 

Datenströme werden aber normalerweise nicht in der Matrix dargestellt, weil es so viele davon gibt, dass man sonst gar nichts anderes mehr sehen würde. Wenn man will, kann man diese Filter runterdrehen, aber die Ströme zischen so schnell vorbei, dass man nicht sagen kann, woher sie kommen oder wohin sie gehen, wenn man nicht Sender oder Empfänger ausspioniert.

 

Und was ist in solchen Datenströmen? Richtig: z.B. ein Live-Stream via Nachricht übermitteln (GRW, S. 239)

Außerdem kann er diese verwenden, um eine Live-Übertragung für einen oder mehrere Empfänger zugänglich zu machen.

 

... wie wir letztendlich aber auch wissen, gibt es keine Möglichkeiten (weder im GRW, noch im DT) Einfluss auf "Nachricht senden" (oder andere Datenströme) zu nehmen.

 

 

Nehmen wir mal nun an, es gäbe die eine "Datei" (im Host) nicht, aus der alle Akteure in dem Schaubild lesen auf die Datei zugreifen.

Nehmen wie mal an, die Kamera sendet direkt an alle Beteiligten (über deren Kommnummer als Ziel). Dann würden dennoch X Dateien in Y Geräte (Kommlink, Trideoprojektor, etc.) angelegt werden, bevor diese "visualisiert" werden.

 

Ihr kennt das heutzutage als Buffer.

 

Aber egal wie wir es drehen und wenden, am Ende des Tages kann ein Hacker nur auf eine ... auf eine einzige, effiziente Art und Weise, die Informationen einer Kamera-Übertragung hacken: durch Datei editieren.

Edited by Masaru
  • Like 2
Link to comment
Share on other sites

Klasse Grafik... vermisse so was manchmal im Matrixkapitel!

 

1. DATEI: Hier ist vermutlich die auf dem Host gespeicherte Datei gemeint.

 

Wenn der Wachmann jetzt in Echtzeit auf diese Datei zugreift, sollte es dem Hacker also nicht möglich sein, die Bilder in Echtzeit zu ändern?! Er sieht das Bild... muß was machen ... währendessen laufen weitere Bilder durch. Er ist einfach nicht schnell genug bei ka... 100 Bildern die Sekunde.

Link to comment
Share on other sites

warum nicht, der Hacker zwackt den Datenstrom auf sein Deck ab, und schickt dann statt dar Kamera Daten an den Computer der Wachmänner. Also er klemmt sich praktisch zwischen die Kamera und den Empfänger in den Datenstrom... Sollte kein größeres Problem sein...

Link to comment
Share on other sites

Klar... geht automatisch und ohne Zeitverzögerung. Und dazu gibt es auch so viele passende Handlungen.

 

@Masaru

Der Knackpunkt ist, kann der Stream in Echtzeit editiert werden oder nicht. Regeltechnisch sehe ich eine Möglichkeit. Also weiter... kann die Datei editiert werden, bevor sie der Wachmann auf seinem Trideoprojektor zu sehen bekommt. Imho auch nicht... kein Gehirn ist schnell genug, bei den Bildraten von 2075 die Runner so schnell aus der Datei herauszulöschen/editieren, bevor der Stream am Trideoprojektor ausgegeben wird.

Link to comment
Share on other sites

warum nicht, der Hacker zwackt den Datenstrom auf sein Deck ab, und schickt dann statt dar Kamera Daten an den Computer der Wachmänner. Also er klemmt sich praktisch zwischen die Kamera und den Empfänger in den Datenstrom... Sollte kein größeres Problem sein...

 

Flufftechnisch geht das sicher : Man-in-the-middle-Angriff. Regeltechnisch gehen solche Details halt einfach viel zu weit. Würde ich jeder Runde ganz selbst überlassen - so wurde das ja auch offiziell gemacht und ausnahmsweise finde ich das sehr gut, dass hier die Regeln NICHT so detailliert sind, weil solche Monster wie die Sprengstoff-Regeln für Datei/Stream/Matrixmanipulationen will ich nicht haben.

 

@Corpheus

Ganz einfach, ja er kann in Echtzeit manipuliert werden, weil das Regelwerk keine Unterscheidung trifft, wie wir es in dieser Diskussion tun. Du musst aber jede Kampfrunde eine komplexe Handlung dafür aufwenden und wenn du aufhörst nimmt das Ding wieder normal auf. Ich bin mir sicher, das es Absicht ist, dass die Regeln hier nicht detaillierter sind, weil das Thema einfach sehr schnell sehr kompliziert werden kann (siehe Masarus schöne Info-Grafik). Ich finde das eigentlich ausnahmsweise relativ gut gelöst.

 

Imho auch nicht... kein Gehirn ist schnell genug, bei den Bildraten von 2075 die Runner so schnell aus der Datei herauszulöschen/editieren, bevor der Stream am Trideoprojektor ausgegeben wird.

Macht auch kein Gehirn. Das macht Software.

 

Siehe dazu die Word Lense translate app: https://youtu.be/h2OfQdYrHRs

Da wird auch in "Echtzeit" der Bildstream manipuliert und da sitzt keiner im Studio bei denen und manipuliert mit Photoshop Bild für Bild oder nutzt ein Video-Bearbeitungstool. Ist übrigens generell ein ziemlich geiles Tool.

Edited by Wandler
  • Like 1
Link to comment
Share on other sites

Wandler trifft den Nagel auf den Kopf. Man kann das Konstrukt Matrix in all seinen Facetten unendlich kompliziert machen.

 

Wenn ihr anfangt "heutige" (oder SR4er) IT-Plausiblitäten und Konzepte wirklich 1:1 umfangreich in die Matrix zu übernehmen, dann schlagt ihr der Hydra einen Kopf letztendlich nur ab ... auf den zwei neue wachsen.

 

@Tycho: Wie Wandler schon sagte ... es gibt für die MitM Attacke keine "kurzen" SR5er Regeln. Du könntest Dir welche einfallen lassen, aber wenn Du anfängst eine Regel fürs "Datenübertragung manipulieren" einzuführen, dann öffnen sich wiederum neue Fragen und Ungereimtheiten, z.B. hinsichtlich der Funktionsweise bei "Telefonaten" und wo genau "manipuliert" man, wie kann das ein anderer Hacker entdecken, usw. usf.

 

@Corpheus: Auch Du verkomplizierst Dir nur unnötig die "eigentlich" schlanken Regeln. Du könntest natürlich ein Wertevergleich machen "welche DV ist größer" ... aber macht der Schwa... *hopsala*... Vergleich die Matrix dadurch schöner, besser oder spielbarer?

 

 

Niemand stellt in Frage, dass ein "Vollautomatischer Feuerstoß" auf einen Wachmann, den dahinter stehenden Chummer nicht mit wegpustet. Aber bei einer Matrix-Regel (die explizit so auch im GRW steht), wird gleich die große "Unvollständigkeits/Interpretations-Lawine" los getreten ...

 

 

Findet ihr die Matrix nicht schon komplex und kompliziert genug? 

Reicht nicht das im GRW stehende (und funktionierende) Grundprinzip?

Habt ihr soviel Zeit als SLs in Euren Runden, dass ihr Euren "Hacker-Spielern" noch längere Matrix-Würfelrunden und Komplexitäten antun könnt?

Sind Euch die Basisregeln zu einfach und ihr langweilt Euch über fehlende mathematisch/algorythmische Berechnungen? 

 

Ich sehe es so:

  • Flächenschaden (Granaten) kann nicht "verteidigt" werden.
  • Und Granaten sind dazu gedacht um auf einen Punkt "auf dem Boden" geworfen oder geschossen zu werden.
     
  • Datenströme/Übertragungen kann man nicht manipulieren.
  • Und Kamera-Übertragungen werden an den Dateien durch gelooptes Editieren gehackt.

Es sind Grundregeln, die funktionieren. Shadowrun ist ein Spiel ... und keine Realsimulation ;). Das wird leider viel zu häufig immer wieder bei der Matrix anscheinend vergessen.

 

Irgendwo schrieb ich mal. dass man die Matrix am besten mit den Basismatrixhandlungen und den 5 Basiskomponenten spielen sollte: Datei, Gerät, Host, Persona, Marke.

 

Und das reicht mMn schon vollkommen aus und muss erstmal gemeistert werden.

Edited by Masaru
  • Like 1
Link to comment
Share on other sites

Das Bild sieht etwas anders aus (heute wie 2075+).

 

Hier wäre eine schematische Darstellung:

 

(Eine Kamera zeichnet auf und sendet via Live-Stream die einzelnen Datenpakete in einem Datenstrom an eine Datei in z.B. einem Host.

Ein Wachmann liest mittels Kommlink die Datei während er seine Patroullie läuft und lässt sich das Video z.B. in einem ARO in der Ecke seines Blickfeldes einblenden.

Drei weitere Wachleute in der Zentrale schauen auf einen Trideoprojektor, welcher ebenfalls die Kameraübertragung aus der Datei kontinuierlich liest und anzeigt.

Zu guter letzt gibt es im Host noch eine Spinne, die sporadisch auf die Datei zugreift und liest.)

 

 

19035312256_1282de49b8_z.jpg

 

 

Das Thema "Datenstrom" wird außerdem ebenfalls im GRW erwähnt, S.216

 

Manchmal kann man auch einen Datenstrom sehen, der aussieht wie ein mehrfarbiger, flackernder Lichtstrahl.

 

Datenströme werden aber normalerweise nicht in der Matrix dargestellt, weil es so viele davon gibt, dass man sonst gar nichts anderes mehr sehen würde. Wenn man will, kann man diese Filter runterdrehen, aber die Ströme zischen so schnell vorbei, dass man nicht sagen kann, woher sie kommen oder wohin sie gehen, wenn man nicht Sender oder Empfänger ausspioniert.

 

Und was ist in solchen Datenströmen? Richtig: z.B. ein Live-Stream via Nachricht übermitteln (GRW, S. 239)

Außerdem kann er diese verwenden, um eine Live-Übertragung für einen oder mehrere Empfänger zugänglich zu machen.

 

... wie wir letztendlich aber auch wissen, gibt es keine Möglichkeiten (weder im GRW, noch im DT) Einfluss auf "Nachricht senden" (oder andere Datenströme) zu nehmen.

 

 

Nehmen wir mal nun an, es gäbe die eine "Datei" (im Host) nicht, aus der alle Akteure in dem Schaubild lesen auf die Datei zugreifen.

Nehmen wie mal an, die Kamera sendet direkt an alle Beteiligten (über deren Kommnummer als Ziel). Dann würden dennoch X Dateien in Y Geräte (Kommlink, Trideoprojektor, etc.) angelegt werden, bevor diese "visualisiert" werden.

 

Ihr kennt das heutzutage als Buffer.

 

Aber egal wie wir es drehen und wenden, am Ende des Tages kann ein Hacker nur auf eine ... auf eine einzige, effiziente Art und Weise, die Informationen einer Kamera-Übertragung hacken: durch Datei editieren.

 

Hälst du es möglich in z.b. sowas mittels "Garbage in/Garbage Out"-Befehl irgendwie Sinnvoll einzugreifen?

 

Ich fände es ja schicker, wenn ich irgendwie den Kamerafeed unterbrechen/umleiten (z.B. aufs eigene Commlink/Deck) und den Jungs vor dem Bildschirm z.B. das Überwachungsvideo von z.B. gestern vorspielen könnte.

 

Ich hätte es ja "schön" gefunden, wenn im Data Trails auf solche konstellationen als Beispiel eingegangen worden wäre um zumindest einen groben Anhaltspunkt zu haben, wie die Autoren sich das ganze gedacht haben. ;)

Link to comment
Share on other sites

Ich fände es ja schicker, wenn ich irgendwie den Kamerafeed unterbrechen/umleiten (z.B. aufs eigene Commlink/Deck) und den Jungs vor dem Bildschirm z.B. das Überwachungsvideo von z.B. gestern vorspielen könnte.

Verwende doch die Handlung Übertragung abfangen oder habe ich deine Intention missverstanden?

Edited by Wandler
Link to comment
Share on other sites

Ich sehe jetzt nicht wirklich das Problem bei dem MitM Attack:

 

Der Decker nutzt Snoop und nimmst einen Teil der Datenübertragung der Kamera auf dein Deck auf, danach nutzt du Snoop um das Signal abzufangen und Send Message um dem "Server" deine Aufnahme zu schicken (braucht halt eine Marke auf dem Server und der Kamera.

Link to comment
Share on other sites

Ich sehe jetzt nicht wirklich das Problem bei dem MitM Attack:

 

Der Decker nutzt Snoop und nimmst einen Teil der Datenübertragung der Kamera auf dein Deck auf, danach nutzt du Snoop um das Signal abzufangen und Send Message um dem "Server" deine Aufnahme zu schicken (braucht halt eine Marke auf dem Server und der Kamera.

 

So war das auf jedenfall in SR3 möglich.

 

Wenn man das wirklich machen kann in dem Sinne, dann kann man damit einen Kamera-Loop produzieren solange man eine Marke auf der Kamera liegen hat.

 

 

Eine Eingreifmöglichkeit mit Garbage in/Garbage out in so einen Prozess hätte den positiven Effekt, dass man sogar neustarten kann, ohne dass sich dieses auswirkt.

Zumindest solange wie die das entsprechende Gerät nicht neustarten.

Link to comment
Share on other sites

Ich sehe jetzt nicht wirklich das Problem bei dem MitM Attack:

 

Der Decker nutzt Snoop und nimmst einen Teil der Datenübertragung der Kamera auf dein Deck auf, danach nutzt du Snoop um das Signal abzufangen und Send Message um dem "Server" deine Aufnahme zu schicken (braucht halt eine Marke auf dem Server und der Kamera.

 

Das funktioniert nicht ... Du möchtest den Datenstrom den eine "Kamera" normalerweise an den Host auf einer "sicheren Leitung" schickt hijacken/kappen/terminieren und dann mit der Kommnummer Deines eigenen Cyberdecks Deine Version der Kameraaufnahme via "Nachricht senden" an den Host schicken, damit dieser die dann in die Kamera-Datei schreibt?

 

Wenn die Matrix so easy wäre, bräuchten wir keine Marken mehr :D.

 

Aber das funktioniert glücklicherweise nicht. Der Grund dafür ist schlichtweg, dass es RAW keine Stelle im GRW gibt, nach der Du einen Komm-Anruf (Nachricht senden) als die valide Dateiübertragung faken kannst.

 

Die Spieledesigner von Shadowrun haben für Kommnummern nunmal nicht vorgesehen, dass diese für Spieler hack/fakebar sind. Durch die Registratur auf den Gittern, wodurch es "out-of-scope" der Spieler wird, gilt ähnliches wie für Personas oder Besitzerrechte (letzere haben die eine Ausnahme, aber da sind wir uns alle einige: das ist kein "hack" wie man ihn bei MitM bräuchte).

 

Hacking erfolgt über "Marken" auf Icons. Datenströme bis auf das snoopen sind schlichtweg tabu und netter fluff. Und - ich weiss, ich wiederhole mich - nochmal: Snoop ist ausschließlich eine Matrixhandlung zum:

  1. Mithorchen

    und

  2. um den Empfänger zu lokalisieren

Man kann weder damit modifizieren, kappen/unterbrechen noch sonst irgendwie den Datenstrom manipulieren.

 

Snoopen ist read-only

 

Natürlich könntest Du das hausregeln .. aber ... dann tauchen weitere Köpfe der Hydra auf um die Du Dich kümmern musst.

 

Aber dann bitte mit einer vollständigen Hausregel, die die anderen Köpfe auch mitbetrachtet und löst. Halbgare Hauregeln brauchen wir nicht. Wir haben schon genügend halbare Grundregeln *seufz*.

Edited by Masaru
Link to comment
Share on other sites

Ich hab keinen bedarf an Hausregeln, ich hätte gerne Matrix Regeln die funktionieren, aber das ist bei SR5 wohl zu viel verlangt... Den Haufen Müll zu reparieren überlass ich gerne CGL...

 

Signale Abfangen und Manipulieren sollte eine der Standard-Szenarien sein, die ein Decker können sollte, aber offensichlich ist Bricken ja viel cooler, da kann man sowas schonmal weglassen....

 

 

cya

Tycho

Link to comment
Share on other sites

Hälst du es möglich in z.b. sowas mittels "Garbage in/Garbage Out"-Befehl irgendwie Sinnvoll einzugreifen?

 

Nein, nicht wirklich. 

Gi/Go bietet dir Möglichkeiten jemanden eine kleine Falle zu stellen oder zu ärgern. Du kannst damit z.B. eine Drohne so manipulieren, dass wenn der böse BossMob-Rigger lachend den Befehl gibt zu feuern, sie sich selber mit eine laaaangen Verzögerung neustartet.  

 

 

Ich fände es ja schicker, wenn ich irgendwie den Kamerafeed unterbrechen/umleiten (z.B. aufs eigene Commlink/Deck) und den Jungs vor dem Bildschirm z.B. das Überwachungsvideo von z.B. gestern vorspielen könnte.

 

Wie ich schon erwähnte, ist das nicht in der SR5 Matrix vorgesehen.

- Mithorchen (und auch bei sich mit abspeichern/kopie ziehen): Ja

- Unterbrechen/Umlenken: Nein

 

 

Ich hätte es ja "schön" gefunden, wenn im Data Trails auf solche konstellationen als Beispiel eingegangen worden wäre um zumindest einen groben Anhaltspunkt zu haben, wie die Autoren sich das ganze gedacht haben. ;)

 

Ja *seufz* ich auch ... aber so müssen wir uns selber behelfen. Mit eben dem was uns zur Verfügung steht.

Link to comment
Share on other sites

Ich finde es peinlich dass die Signatur-Aktion von Deckern in den Regeln nicht abgedeckt ist.

 

Meiner Meinung nach sollte ein Decker eine einzelne Probe würfeln um einen Kamerafeed zu manipulieren, und das dann so lange bis er dies nicht mehr tun will.

Im Nachhinein wird es mit einer forensischen Untersuchung möglich sein die Manipulation zu bemerken, egal ob jetzt Runner live aus dem Stream editiert wurden oder die Kamera die letzten 5min der Aufzeichnung erneut aufgezeichnet hat, aber die Bilder der Runner sind verloren.

 

Von der technischen Machbarkeit her könnte man den Verbrauchern (=Datei lesen) eine andere Sprungmarke setzen so dass sie den Inhalt von vor 5min sehen.

Wobei ich eher denke dass alle Verbraucher direkt den Datenstrom konsumieren und die Datei (bzw das PersistenceLayer) einer der Verbraucher ist. Was aber keinen Unterschied macht, die Kamera sendet halt den Inhalt eines Buffers und man verhindert dass dieser gelöscht und neu (vom Kamerabild) beschrieben wird und seinen Inhalt jeweils erneut ausgibt.

 

Die Probe des Hackers ist dann dazu da den Datenstrom so geschickt zu manipulieren dass ein Mikroruckeln nicht auffällt.

  • Like 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...