Moinmoin

Da mir die Zusammenstellung der Matrix Knoten im Unwired eindeutig zu wenig war, habe ich mich daran gemacht ein kleines Script zu basteln, welches zufällige Matrixknoten generiert.

Es ist noch einiges an Arbeit daran zu tun bis er so weit ist, wie ich es mir wünsche, aber vielleicht kann das Ding ja auch in seiner derzeitigen Funktionsweise dem einen oder anderen von Euch ein wenig behilflich sein.

Bei jedem Aufruf der URL wird ein neuer Knoten generiert.

http://dndkiel.dn.funpic.de/shadowrun/matrix/

Ich freue mich über Feedback,

TalonZorch

Ist schon einmal eine gute Sache, da es Leute gibt, die immer den perfekten Knoten wollen
Bastel schön weiter, freu mich schon, wenn es richtig fertig

Echt hammer das Programm, Wäre cool wen man das downloaden könnte da wir am Spieltisch kein i-net haben

Was da nicht berücksichtigt wird, ist der Standort desjenigen, der ins Netz will.
In Deutschland wirst du hauptsächlich im Frankfurterknoten landen und nicht in China oder sonstwo.
Da fehlt ein Pulldownmenü für den Startpunkt. Dann eine Berechnung der Entfernung zu den Knoten + bissl Zufall (5-10%)
Die Verbindung entsteht nicht zufällig, es geht um beste und schnellste Verbindungswege. Daher ist Startpunkt in Bezug zu den einzelnen Servern wichtig. Ein bisschen Zufall spielt dann doch rein, aber nicht viel.
Das man sich dann weiterhangeln kann zu anderen Knoten, ist klar.
Es gibt im Netz Traceprogramme, benutz mal eins und schau was raus kommt.

Moinmoin

Ich habe dieses Projekt schlicht vergessen, da meine Gruppe derzeit lieber im Star Wars Universum zockt, habe mich vorgestern aber daran gemacht das wieder aufzunehmen um es "fertig"zu schreiben.

Danke für das Feedback - eine neue Version wird zum nächsten Wochenende hin live gehen.

Aktueller Status:

Ich programmiere Grundlagenfunktionen für das Datenbankbackend, damit eine einfache Pflege und Wartung des Programmes möglich wird - und es auch dank Datenbankanbindung tiefgreifendere Funktionen bieten können wird.

So - das ganze interne Backend läuft.

Jetzt gehts für mich an die Realisierung der neuen Funktionen. Folgendes ist das Ziel:

Code: Alles auswählen

   <<Titel>>, <<Standort>>
   <<Beschreibung>>
   <<Hardware>>
   <<Privilegien>>
   <<Attribute>>
      <<Knoten>>{<Firewall> <x>; <Prozessor> <x>; Signal <x>; System <x>}
   <<Spiders>>
      <<Spider>>{Werte}
   <<IC>>
      <<IC>><Stufe>
   <<Nodes>>
      <<Node>>{<Programm>   <x>}
   <<Topology>>
      <Beschreibung des Linkngs der einzelnen Nodes>

   || -- <<Titel>> --  ||
      Der Titel klassifiziert den Knoten.
      Dabei beginnen wir zu bestimmen, wem der Knoten gehört. Davon hängt dann im Folgenden auch ab, was für eine Art von Knoten wir hier vor uns haben.
      Als mögliche Besitzer kommen daraufhin an:
         Konzern
         Privatperson
         Staatliche Behörde
         Kriminelle Vereinigung
         Verein
         Policlub
         ...
      Auf Basis des Besitzers können wir dann den Typ des Knotens näher definieren.
         Geschäft (reell)
         Virtuelles Geschäft
         Online Spiel
         Spielsalon
         Werbeauftritt
         Produktionseinrichtung
         ...
      Sobald dann die Knotendefinition steht, können wir noch eine Art "Unterfunktion" des Knoten definieren. Das mag nicht in jedem Fall sinnig sein, aber
      bei manchen Knotentypen kann das doch Sinn machen... denke ich.
         Buchhaltung
         Kundenkontakt
         Internes Mitarbeitersystem
         P/R Abteilung
         F/R Abteilung
         Catering Service
         Logistik
         ...
      An dieser Stelle sei noch erwähnt dass jeder der oben genannten Punkte - wie "Konzern" oder "Produktionseinrichtung" noch auf eine weitere Datenbank
      zurückgreift. Wir haben also eine Datenbank mit den Konzernen (und ihren Klassifikationen aus dem Corporate Guidebook zwecks Darstellung und
      korrekter Repräsentation des Matrixsicherheitslevels - natürlich adaptiert an heutige Kons und Charakteristika), eine mit Personen, Behörden etc.
      Behörden bilden dabei einen Sonderfall - da diese stärker als andere Dinge Locationgebunden sein müssen, gleichsam Vereine / Policlubs. Generell ... wird das
      an dieser Stelle noch einiges an Aufwand.
      Des weiteren bekommt jede dieser Auswahlen einen Wert zugeschrieben. Beispielsweise bekommt ein "Konzern" einen höheren Wert als ein Verein, eine
      Produktionseinrichtung einen höheren als ein Waschsalon und die Buchhaltung einen Höheren als der Kundenkontaktknoten.
      Dadurch, dass hier Rankings eingegeben werden, kann man in der späteren Sicherungd es Knotens sicherstellen, dass "große" Knoten und wichtige Knoten von
      Global Playern im Durchschnitt besser gesicerht sind als der Tante Emma Laden um die Ecke.
      Das wird Feintuning erfordern - aber hey - solange es spass macht!
      
   || -- <<Standort>> --  ||   
      Beim Standort unterscheiden wir in Zukunft zwischen zwei Standorten.
      a) Standort des Knotens
      b) Standort des Hackers
      
      Den Standort des Hackers geben wir händisch ein - default wird wird Nordamerika, UCAS, Seattle, Redmond Barrens, Redmond Way No. 1
      Beim Standort des Ziels haben wir jetzt Spass.
      
      Dazu definieren wir folgende Standortklassifikationen:
      <Kontinent> <Land> <Bundesland sofern anwendbar> <Stadt> <Stadtteil sofern anwendbar> <Strasse sofern anwendbar> <Matrixsicherheitsstufe des Stadtteils>
      
      Diese Tabelle muss natürlich noch mit Daten gefüttert werden, aber mein Ziel dabei ist es, dass ein Hacker in Redmond der mal schnell einen Knoten hacken will, meist
      keinen Knoten wählen will, der in Tansania liegt. Kurzum: Das System soll standardmässig einen Knoten in der Nähe auswählen und nur im selteneren Fall den Hacker weiter
      weg von zu Hause führen.
      
      Natürlich sollten auch die Zielparameter einstellbar sein - so dass man beispielsweise vorgeben kann "Ich will einen Knoten von Saeder Krupp in den ADL hacken".
      Dabei ist zu beachten dass für jeden Kontinent und für jedes Land erst einmal Werte vorgegeben werden sollten - damit die Auswahl möglich wird. Spätere Addendums in das System sollen durch User
      möglich sein (dieses Interface zur Eingabe funzt auch schon *g*).
      
      Die Ziellocation sollte auch starken Einfluss darauf haben, was für ein Ziel wir haben werden. Beispielsweise soll es in den ADL warhscheinlicher sein einen Knoten von, sagen wir AG Chemie
      zu finden, als beispielsweise einen von ARES. Oder in Japan wesentlich höhere Chancen auf einen Knoten der Yakuza kontrolliert ist, als einen, der durch die sizilianische Mafia geleitet wird.
      Dies wird gelöst werden indem jeder Konzern pro Kontinent ein Rating bekommt, wie "mächtig" er dort ist. Wenn ich ganz irre bin, mache ich das auch pro Land - wäre etwas aufwändiger, aber eine einmalige Arbeit, die dann später recht leicht zu warten ist.
      
      Ebenso soll ein Random Effekt nachfragen, ob wir uns in einer Statischen oder einer Spamzone befinden. (GRW S. 258)
      
   || -- <<Beschreibung>> -- ||
      Bei der Beschreibung wird es lustig. Hier möchte ich mit variablen Textkonserven arbeiten, welche anhand verschiedenester Charakteristika zu einem hübschen Fließtext zusammengesetzt werden. So
      soll man beispielsweise ein gewisses Look and Feel bei allen Knoten der sizilianischen Mafia der Pedrollinifamilie haben, welches nach Möglichkeit aber immer noch divergiert, je nach dem wo der
      Knoten steht, welchem Zweck er dient etc.
      Ob das überhaupt etwas wird in dem Maße, oder ob es einfach nur generische Beschreibungen werden ... weiss ich nicht. Aber das wäre einer der Parts, die am meisten Spaß machen werden.
   
   || -- << Hardware >> -- ||
      Was macht das Tool derzeit? Derzeit wählt es aus den im Unwired genannten Knotentypen einen aus oder generiert einen eigenen.
      Das ist nicht, was ich will.
      Ich will, dass dieses Tool Location und Besitzerbasiert den Knoten entscheidet, aber auch bei jedem Auftreten eines random Nexus diesen speichert, mit einem Hersteller versieht,
      dem Knoten einen hübschen zum Hersteller passenden Namen gibt (möglichst variabel), und dieser danach auch bei anderen Knotengenerierungen auftreten kann. Ja - das bedeutet eine hübsche
      Masse an späteren generierten Hardwarenamen - aber hey - glauben wir wirklich dass jede "high end" firma das eine Nexusmodell von der Stange hat? Nö. Und das sollte sich dadurch realisieren lassen.
      
      Bei dieser Generierung soll insbesondere im Fall von Konzernknoten das Matrixranking herangezogen werden um zu bestimmen wie ualitativ Hardare und später auch Software sein wird.
      
   || -- << Privilegien >> -- ||
      Hier haben wir die Zugriffsmöglichkeiten auf die Daten des Knoten.
      Standard
      Sicherheit
      Admin
      Speziell
   
   || -- << Authentifizierung >> -- ||   
      Zugangskennung
      Web of Trust
      einfaches Passwort
      erweitertes Passwort
      Verbundenes Passwort
      Standard Zugangsschlüssel
      Nanotech Zugangsschlüssel
      Alchemischer Zugangsschlüssel
      
   || -- << Attribute >> -- ||
      Die Attribute werden durch die Hardware definiert
      
   || -- << Spiders >> -- ||
      An dieser Stelle soll bestimmt werden ob ein bestehender Knoten
      a) überhaupt über eine Spider verfügt
      b) Welche Stufe die Spider gemäss Unwired hat (oder ob - im "later(tm)" Bereich sogar ein Custom Spider gesetzt wird
      c) Ist die Spider resident oder auf einem Patroullienturnus (wenn ja, wann kommt sie wieder)
      d) Wird die Spider nur bei ARC ausgelöst oder prüft sie so schon?
      
   || -- << IC  >> -- ||
      Hier .. will ich mich austoben.
      Zum einen stehen natürlich die Standardisierten IC Varianten aus GRW und Unwired zur Verfügung, zum anderen möchte ich
      meine perfiden Eigenkreationen des IC hier auch einflechten - natürlich auch brav mit der Option nur die Standard Dinger zu verwenden.
      
   || -- << Nodes >> -- ||
      Die Option sollte hier gegeben sein, dass Nodes mit dem Knoten verbunden sind. Sei es Peripherie oder andere Knoten.
   
   || -- << Topology  >> -- ||
      Hier soll entsprechend der Beschreibung des Knoten eine entsprechende Topologie definiert werden.
   
   || -- << Paydata >> -- ||   
      Welche Paydata befindet sich im System?
      Was kostet die Paydata?
      Und dann das lustigste: Was ist das für Paydata?
      Das sollte sich demnach verändern, je nachdem was das für ein Knoten ist. Es sollte die Wahrscheinlichkeit höher sein im "Pizzaladen" Knoten die Paydata "Onkel Enzos Pizza Margaritha Rezept" zu finden, als in der F/E Abteilung von Ares.


Wenn einer von euch Ideen hat was man da noch reinbauen kann wäre ich happy.

Eventuell kann man ja Kategorien erstellen.

Kaum Sicherheit Hohe Sicherheit usw...

es sollten die Werte auch zusammenpassen.
-auf einem rechner mit IC im Wert von 50k, wird sicher kein Analyse 1 laufen. Gleiches mit Firewall. Jeder Knoten der irgendwie geschützt werden muss, wird als erstes Analyse und Firewall so hoch wie möglich haben. Das ist spottbillig im Vergleich zu Spiders oder IC.
-sind Programmstufen nicht auf System gecapped?

Also eine Eingabemöglichkeit:
"Knotensicherheit: Keine - Leicht - Mittel - Schwer - Mörderisch - Ich will den Hacker tot sehen - Dodger"

Zu den zusammenpassenden Werten.
Da hast du Recht mit. Gerade Analyse und firewall sind ja doch sehr wichtig. Ich werde das mit einfliessen lassen. Danke für den Tip.