Difference between revisions of "User:Zamujasa/Station Network"

From Space Station 13 Wiki
Jump to navigation Jump to search
(Securitrons and MULEs, oh boy! Follow Beepsky around or steal the QM's stuff!)
Line 11: Line 11:


=== Types of networked devices ===
=== Types of networked devices ===
 
Get a list of these by running <code>term_ping</code> on any [[TermOS]] computer that isn't currently connected to something. Not all devices can be connected to via TermOS, though!


==== <code>PNET_MAINFRAME</code> ====
==== <code>PNET_MAINFRAME</code> ====
Line 98: Line 98:
==== <code>SRV_TERMINAL</code> ====
==== <code>SRV_TERMINAL</code> ====
????
????


=== Creating packets ===
=== Creating packets ===

Revision as of 16:27, 23 June 2014

I'd like to make this into a more detailed page at some point, but for now I'm just infodumping what I have.

Until then, here's a basic guide to abusing the station network:


Wired Network

Stuff on the station network connected by red power cables.


Types of networked devices

Get a list of these by running term_ping on any TermOS computer that isn't currently connected to something. Not all devices can be connected to via TermOS, though!

PNET_MAINFRAME

The good ol' mainframe, stored in the bottom half of the Computer Core just below the AI. Connect to this to access DWAINE, and from that, a bunch of other things.

Some of these exist off the station!


MAINFRAME_AI

The AI. Connecting to this will make the AI see "Direct connection from (02001234)". You can chat with the AI by simply sending messages, and it will be able to reply as long as you're connected.


PNET_COM_ARRAY

The communications array! Connecting to this will usually give you a short message with two commands, TODO: what. Using TODO: View? will send the threat report you hear about early in the round directly to your terminal, which you can print out with file_print. Keep in mind that the information on it is usually wildly incorrect.

Packet dump: 

(sent) address_1=020036fd; command=call; shuttle_id=emergency; acc_code=(Authentication code); sender=0200c069; 
(recv) command=device_reply; status=SHUTL_E_SEN; address_1=0200c069; sender=020036fd;

The authentication code above is randomly generated each round -- it looks something like "1234 Alpha-567". You can get it from reading GuardBuddy command packets, which include it. Actually sending this signal can probably be done by using ThinkDOS and the SigCraft builder, but doing that is left as an exercise to the reader.


PNET_ADAPTER

TODO: Probably other terminals on the network?


PNET_S_TELEPAD

The telepad. TODO: Document commands, packets, etc.

You can't change the coordinates with just packets! You can only send, receive, and maybe toggle a portal. (info by AngriestIBM via Luis Smith)

Raw packet dump: 

[18:47:4]:command=term_message; data=command=teleman&args=-p 1 send; address_1=02002182; sender=02001ed4; 
[18:47:5]:command=term_message; data=command=send&session=746; render; address_1=02001cbd; sender=02002182; 
[18:47:5]:command=term_message; data=command=ack&session=746; address_1=02002182; sender=02001cbd; 
[18:48:1]:command=term_message; data=command=OK; render; address_1=02001ed4; sender=02002182; 
[19:10:1]:command=term_message; data=command=teleman&args=-p 1 receive; address_1=02002182; sender=02001ed4; 
[19:10:1]:command=term_message; data=command=receive&session=17; render; address_1=02001cbd; sender=02002182; 
[19:10:1]:command=term_message; data=command=nack&cause=recharge&session=17; address_1=02002182; sender=02001cbd; 
[19:10:7]:command=term_message; data=command=Telepad is recharging.; render; address_1=02001ed4; sender=02002182; 
[19:13:3]:command=term_message; data=command=teleman&args=-p 1 receive; address_1=02002182; sender=02001ed4; 
[19:13:4]:command=term_message; data=command=receive&session=333; render; address_1=02001cbd; sender=02002182; 
[19:13:4]:command=term_message; data=command=ack&session=333; address_1=02002182; sender=02001cbd; 
[19:14:0]:command=term_message; data=command=OK; render; address_1=02001ed4; sender=02002182;


PNET_PRINTDEVC

Printers. Unsure if you can print directly to them (maybe with file_send), generally you just write to the /mnt/lp-whatever folders on the mainframe.


PNET_DATA_BANK

The data banks that contain all of the information on the mainframe. Probably not useful to connect to.


PNET_PR6_CHARG

GuardBuddy chargers.

Raw packet log (likely, might be another device): 

[37:25:5]:command=term_message; data=_command=add&_freq=1219; render; address_1=020020f4; sender=02002182; 
[37:25:5]:command=term_message; data=_freq=1219&acc_code=3635 Bravo-501;command=dock_return; render; address_1=020020f4; sender=02002182; 
[37:25:5]:command=term_message; data=command=status&status=success; address_1=02002182; sender=020020f4; 

[40:30:1]:address_1=02002182; data=prman upload 0200143B heckle name=titusgettemy; command=term_message; sender=0200b5ce; 

[49:37:5]:command=term_message; data=command=status&status=ejected&botid=020032dd; address_1=02002182; sender=0200143b;

Importantly, the acc_code is the same one required to call the shuttle via packet communication. (How to do this still needs to be documented here, though.)

PNET_PR6_RADIO

GuardBuddy radio, used for contacting GuardBuddies when they're away from the chargers.


PNET_IR_DETECT

The IR detectors around the outside of the north part of the Computer Core, guarding the AI. Sends a packet to you immediately upon connect (TODO: put here), doesn't seem to do anything interesting. Note that the top-right IR detector on the AI core, at least, doesn't seem to actually be on the network (it says NO CONNECTION if you check it).


PNET_TEST_APPT

????


SRV_TERMINAL

????

Creating packets

Packets can be created by using the following command:

echo field=value|nfield2=value2|nfield3=value3

To store the packet as a file on the mainframe:

echo ... ^ /home/pjones/filename

To send a file (like a packet!) to your terminal, so you can send it with file_send or print it with file_print, save the file to the /mnt/term directory:

cp /home/pjones/filename /mnt/term/x

If you just need to get the file right away, you can simply save the file in /mnt/term right away:

echo ... ^ /mnt/term/foo


Spoofing the login packet

Faking a login involves a few specific steps. You'll generally always need a valid ID of any kind to do the initial login, though.

  1. Log into the mainframe (insert your card and term_login)
  2. Craft a login packet
  3. Send the crafted packet back to your terminal
  4. Either enter su for admin rights, or disconnect and reconnect to log in as a completely different user
  5. Instead of using term_login, use file_send to send the packet you saved earlier
  6. You are now logged in with your forged user

The login packet looks like this:

  • registered=Pubbie Jones
  • assignment=Staff Assistant
  • access=, followed by a (semicolon? comma?)-separated list of rights -- every access in the ID computer has a different one. The important one for su access is 11

Applying all of the above to create the packet and register it for file_send:

echo registered=Pubbie Jones|nassignment=Hacker|naccess=11 ^ /mnt/term/loginpacket


Keep in mind that you shouldn't use this to set the Guardbuddies to purge or other destructive things unless you're a traitor!


Sending packets using the mainframe's radio

You can use DWAINE to send out packets over the air. The mainframe's radio has a limited range, though, so it won't reach everything.

  1. Create a directory for the frequency you want to transmit on. Directories are the four numbers without the decimal point, e.g. /mnt/radio/1149 for 114.9, by using the command mkdir /mnt/radio/1149
    • If the directory already exists for whatever reason, you can skip this step
  2. Craft your packet
    • Optional: Save it if you need to use it more than once. Otherwise, just use echo and pipe it directly.
  3. Copy or move your crafted packet to the folder you created, e.g. copy packet /mnt/radio/1149 or echo ... ^ /mnt/radio/1149/packet

If it worked, the packet you crafted should automatically be sent out by the radio. You can use the Packet Sniffer program on your PDA to confirm.


Radio Frequencies

Basically everything you can spoof (aside from PDA messages) will require a address_1 field, indicating the target of the message.

sender is added automatically to almost every packet-sending device, though apparently you can get away without one by manually crafting a signal and using a wireless computer's free mode (with greatly reduced range)

114.9 - PDAs

Packets:

  • TODO
  • Really easy to scan, the Network Tools cartridge defaults to this freqency
  • Snoop on people trying to use PDAs to covertly message people! Just be sure to get your ID switched to "NSA Operative" first Clear the log regularly so it doesn't clog up with PDA pings.

Packet spoofing:

  • address_1: Needed if you're targeting one PDA, otherwise it's a mass broadcast to every PDA
  • command: Generally text_message, though there are others (TODO)
  • message: The text you want to send. Surprise!
  • sender_name: What the name should show up as. Leaving it blank will make PDAs show it as !UNKNOWN! (or something close)
  • And more!


121.9 - GuardBuddies

Raw packet log: 

[25:20:0]:data=1248.5; address_1=recharge; sender=02000fbc; 
[25:20:2]:data=1492.5; address_1=recharge; sender=020015e1; 
[25:20:4]:command=recharge_src; data=x=68&y=65; address_1=02000fbc; sender=02001358; 
[25:20:4]:command=recharge_src; data=x=66&y=66; address_1=02000fbc; sender=0200142a; 
[25:20:4]:command=recharge_src; data=x=66&y=67; address_1=02000fbc; sender=0200150a; 
[25:20:4]:command=recharge_src; data=x=71&y=68; address_1=02000fbc; sender=020015e0; 
[25:20:5]:command=recharge_src; data=x=69&y=65; address_1=02000fbc; sender=0200135e; 
[25:20:5]:command=recharge_src; data=x=71&y=66; address_1=02000fbc; sender=0200143a; 
[25:20:5]:command=recharge_src; data=x=71&y=67; address_1=02000fbc; sender=0200151a; 
[25:20:6]:command=recharge_src; data=x=136&y=59; address_1=020015e1; sender=02000fc0; 
[25:20:6]:command=recharge_src; data=x=69&y=65; address_1=020015e1; sender=0200135e; 
[25:20:6]:command=recharge_src; data=x=71&y=67; address_1=020015e1; sender=0200151a; 
[25:20:6]:command=recharge_src; data=x=71&y=68; address_1=020015e1; sender=020015e0; 
[25:20:6]:command=recharge_src; data=x=71&y=69; address_1=020015e1; sender=0200168d; 
[25:20:6]:command=recharge_src; data=x=136&y=59; address_1=02000fbc; sender=02000fc0; 
[25:20:6]:command=recharge_src; data=x=71&y=69; address_1=02000fbc; sender=0200168d; 
[25:20:7]:command=recharge_src; data=x=71&y=66; address_1=020015e1; sender=0200143a; 
[25:20:8]:command=recharge_src; data=x=68&y=65; address_1=020015e1; sender=02001358; 
[25:20:8]:command=recharge_src; data=x=66&y=66; address_1=020015e1; sender=0200142a; 
[25:20:8]:command=recharge_src; data=x=66&y=67; address_1=020015e1; sender=0200150a; 
[25:26:2]:data=1490.5; address_1=recharge; sender=0200143b; 
[25:26:4]:data=1490.5; address_1=recharge; sender=0200168e; 
[25:26:6]:command=recharge_src; data=x=69&y=65; address_1=0200143b; sender=0200135e; 
[25:26:6]:command=recharge_src; data=x=71&y=66; address_1=0200143b; sender=0200143a; 
[25:26:6]:command=recharge_src; data=x=66&y=67; address_1=0200143b; sender=0200150a; 
[25:26:7]:command=recharge_src; data=x=66&y=66; address_1=0200143b; sender=0200142a; 
[25:26:7]:command=recharge_src; data=x=71&y=67; address_1=0200143b; sender=0200151a; 
[25:26:8]:command=recharge_src; data=x=68&y=65; address_1=0200143b; sender=02001358; 
[25:26:8]:command=recharge_src; data=x=71&y=69; address_1=0200143b; sender=0200168d; 
[25:26:8]:command=recharge_src; data=x=69&y=65; address_1=0200168e; sender=0200135e; 
[25:26:8]:command=recharge_src; data=x=71&y=67; address_1=0200168e; sender=0200151a; 
[25:26:8]:command=recharge_src; data=x=71&y=69; address_1=0200168e; sender=0200168d; 
[25:26:9]:command=recharge_src; data=x=68&y=65; address_1=0200168e; sender=02001358; 
[25:26:9]:command=recharge_src; data=x=71&y=66; address_1=0200168e; sender=0200143a; 
[25:26:9]:command=recharge_src; data=x=66&y=67; address_1=0200168e; sender=0200150a; 
[25:27:1]:command=recharge_src; data=x=66&y=66; address_1=0200168e; sender=0200142a;


141.1 - Doors

Doors have a really short brodcast range (± 5 tiles?) so you'll have to be close to ping them. You can sniff packets if you click on a door (or someone else does), or just ping and try to pick the right one from the list.

Packet Sniffing details:

  • user_id: Person whose ID was used (e.g. pubbiejones)
  • door_status: State the door is in (e.g. open, closed)
  • lock_status: State of the door bolts (e.g. locked, unlocked)
  • tag: TBD?


Packet spoofing:

  • command: One of the following:
    • open: Opens a door
    • close: Closes a door
    • lock: Drops the door bolts
    • unlock: Raises the door bolts
    • secure_open: Bolts a door open*
    • secure_close: Bolts a door closed*

*Used by the cryptographic sequencer.


143.7 - Fire Alarms

Packet Sniffing:

  • zone: Fire alarm's location (e.g. Head of Research's Office)
  • type: Alert type (e.g. Fire)
  • netid: Fire alarm's network address?
  • alert: Alert type (e.g. fire, reset, maybe more?)


144.3 - Tour guide stops

Tour guide beacons broadcast on this frequency. They're located under floor tiles, and you can access them by popping them open with a screwdriver and swiping an appropriate card.

For example, here is the data from the one at the Escape Arm:

  • Location: tour16
  • Beacon codes:
    • tour: 1 (Marks it as a tour beacon?)
    • next_tour: tour17 (Which beacon comes after this in the route)
    • desc: In the event of catastrophic station damage... (What the tour guide will say when stopping here)

You can't move the beacons around or create new ones, but you can at least make Murray shout obscenities when describing places. Or make him get stuck into a loop forever. Keep in mind that the text length you're allowed to enter is much shorter than the length of the default tour messages.

Sample log: 

[37:15:3]:findbeacon=tour; address_1=!BEACON!; sender=0200564a; 
[37:15:3]:beacon=tour13; netid=02000e46; tour=1; next_tour=tour14; desc=...; 
[37:15:3]:beacon=tour16; netid=02000fa6; tour=1; next_tour=tour14; desc=...; 
[37:15:3]:beacon=tour14; netid=020016f1; tour=1; next_tour=tour16; desc=...; 
[37:15:3]:beacon=tour15; netid=02001894; tour=1; next_tour=tour16; desc=...; 
[37:15:3]:beacon=tour12; netid=02001905; tour=1; next_tour=tour13; desc=...; 
[37:15:3]:beacon=tour11; netid=020026bb; tour=1; next_tour=tour12; desc=...; 
[37:15:3]:beacon=tour10; netid=02002e0c; tour=1; next_tour=tour11; desc=...; 
[37:15:3]:beacon=tour17; netid=02002e0f; tour=1; next_tour=tour18; desc=...; 
[37:15:3]:beacon=tour8; netid=02003897; tour=1; next_tour=tour9; desc=...;


144.5 - Robot patrols

Basically the same as tour guide stops except on a different frequency, and using patrol=1 instead of tour=1. They also don't have the desc field since patrolling robots generally don't talk.


144.7 - Securitrons and MULEs

Securitrons and MULE bots share this frequency.


Securitrons

Status updates, sent from the bots:

  • type: secbot
  • name: Officer Beepsky -- this is whatever the bot is named. No way to distinguish between identically-named bots
  • loca: Cafeteria -- where the bot is currently located.
  • mode: 0 -- One of various modes (as described by the Securitron control PDA app):
    • 0: Ready (idle)
    • 1: Apprehending Target (chasing after someone set to arrest)
    • 2: (unknown - one of these is probably for when it's actually caught someone, or detaining)
    • 3: (unknown)
    • 4: Starting patrol
    • 5: On patrol
    • 6: Responding to summons (will go to mode 4 and start patrolling when it reaches its destination)


Controlling via the R.O.B.U.S.T. cart's Securitron app:

  • command: One of the following:
    • bot_status: Get the status of the bot
    • go: Start patrolling
    • stop: Stop patrolling
    • summon: Summons the bot
  • active: Officer Beepsky -- again, no way to differentiate between different bots
  • target: the floor -- Only if command=summon. Theoretically should be where the bot should go, but...
    • The target seems to always be the floor, regardless of where you are
    • Bots don't actually respond to these summons, unless they're from the R.O.B.U.S.T. cart's Securitron app


MULE Bots

Status updates, sent from the bots:

  • type: mulebot
  • name: 1 -- Likely the name in the Quartermaster's PDA MULE control app, likely unique to each bot
  • loca: Supply Lobby -- whatever the location of the bot is
  • mode: 0 -- One of the various modes:
    • (TODO, no research on this yet)
  • powr: 100 -- Current cell charge
  • dest: unknown -- TODO. Destination, format is unknown. Probably the name of the location
  • home: QM #1 -- Bot's home location (TODO: Underfloor beacon?)
  • load: Jon Pubbie -- Whatever is currently loaded on top of the bot, e.g. player name, Crate, etc
  • retn: 1 -- Return home after delivery
  • pick: 1 -- Pick up crates at the destination

Controlling via the QM's PDA:

  • TODO. But hey, at least you can tell what's being shipped around (and where), so you can go intercept that nice crate full of goodies.
Retrieved from "https://wiki.ss13.co/index.php?title=User:Zamujasa/Station_Network&oldid=7965"