User:Zamujasa/Station Network

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, View and Download ##. Using View will give you a list of available messages (usually only one, the "threat report") that you can get; using Download (id) will send the message directly to your terminal, which you can print out with file_print. Keep in mind that the information on the threat report 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

Mainframe radio, mostly used for talking to the GuardBuddy bots when they're away from chargers.

Capturing packets with the power of the mainframe:

1. Make a folder for the frequency you want to monitor, e.g. /mnt/radio/1149
2. Periodically ls /mnt/radio/1149 to see if any packets have appeared
3. cat /mnt/radio/1149/Q2158018 to view packets

The mainframe will capture any packet sent to a frequency that has a directory created.

Note: The actual mechanics behind this are a bit different (there's some communications going on between the mainframe and radio) but for the most part this will get you what you want.

Regardless, packet dumps (raw, not bothering to explain): [19:41:7]:command=term_message; data=_command=add&_freq=1149; render; address_1=02002303; sender=02002275; [20:03:3]:command=term_message; data=_freq=1149&command=text_message&message=butt&sender_name=fart; render; address_1=02002303; sender=02002275; [45:35:6]:address_1=02002275; data=echo test=butt ^ x; command=term_message; sender=02018e2a; [45:35:6]:command=term_message; data=command=status&status=success; address_1=02002275; sender=02002303; [45:35:6]:command=term_message; data=_freq=1149&test=butt; render; address_1=02002303; sender=02002275;

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

The various testing apparatus in the artifact lab

SRV_TERMINAL

????

PNET_NUCCHARGE

The nuclear charge. Authentication is easily spoofed by using the mainframe's built in nuke manager nukeman. Just use the same packet you used to spoof superuser access when asked to login with an authorized ID, then repeat with 2 more login packets under 2 different names (the registered= field).

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)

PDA Ping ranges. Sending may be similar (or unlimited size?). Measured by dropping a PDA and seeing how far away it would still respond.

• min: 16 tiles
• med: 32 tiles
• max: 64 tiles

Note that pings go through Z-levels! If you manage to pin down a signal but there doesn't seem to be anything there, it's probably in the debris field or in one of the adventure zones. Welp!

114.9 - Various devices

PDAs

• Device name: NET_PDA_51XX
• Broadcast range: ≥ 64 tiles (127 × 127)

Packets:

• 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, including but not limited to:
  • file_send_req Used send file send requests, can't actually send anything without using the PDA clip board
    • file_size The size of the file
    • file_ext The file extension (PPROG, TXT, etc.)
    • file_name The name of the file
  • file_send_acc Used to accept file send requests, doesn't work unless someone's sending you a file
  • file_send Used to send files after send requests are accepted, doesn't work without an accepted file request
  • report_pda The scan function in the pda messenger
  • report_reply Replies to report_pda, can be used to change your pda's name to other people on the messenger
• 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!

Ruckingeur kits

• Device name: NET_RKANALYZER
• Broadcast range: ≥ 64 tiles (127 × 127)

Ruckingenur kits, like the one in the Electronics lab.

Packet sent when adding something to the database via PDA scan:

• command: add -- Adds something to the database. Doesn't actually specify what it is. D'oh.
• address_1: 02xxxxxx -- Address of the kit, as usual

After that, the kit will send out a PDA text message to the sending PDA informing them that it has been added to the database.

Spoofing the packet does nothing. Scanning a device using a Device Analyzer sends no packets at scan or on addition to the kit.

WNET_ADAPTER - Security computer

Security computers, like the filing cabinet in the Morgue. Doesn't send or receive any packets when interacting with it normally.

Morgue filing cabinet:

• Broadcast range: 18 tiles (35 × 35)

Others may be different.

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

• Device name: DOR_AIRLOCK
• Broadcast range: 6 tiles (11 × 11)

Doors only broadcast signals nearby, so you'll have to be close if you want to see anything. 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. Alternatively, screwdriving the access panel open will reveal the network address, as well.

Doors broadcast certain details whenever they're interacted with, as well as a few moments later when they auto-close.

• user_id: Person whose ID was used (e.g. Pubbie Jones). If a mob like Beepsky opens a door, this is ??? (yes, three question marks) instead.
• If the door opens:
  • data: denied, if someone who didn't have access tried to open a door
• Otherwise:
  • door_status: State the door is in (e.g. open, closed)
  • lock_status: State of the door bolts (e.g. locked, unlocked)
  • tag: This appears to always be blank.

Sending packets manually to open/close doors:

• address_1: Network address of door (required)
• 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.

141.1 - PNET_PR6_RADIO

?

141.9 - PNET_PR6_RADIO

? The actual device is a 'Network Radio' (a unique looking terminal). It's located in the CE office(cog2), or the computer cores in Cog1 and Destiny. (Some) messages send to it will be converted into a DWAINE network packet and relayed to the mainframe.

If you switch a 'portable computer' to it's wireless mode, it's network card will default to this frequency. If you run FROG (or restart the laptop with TermOS disk), you can ping the network and connect to this device. This will allow you to use the DWAINE network on the laptop, with all of it's perks. (have not yet figured out how to spoof the the 'super user' login yet.)

143.1 - Secure Lockers

• Device name: WNET_SECLOCKER
• Broadcast range: 3 tiles (5 × 5)

Secure lockers, including personal lockers in the Crew Quarters. Personal lockers don't send messages when opened/claimed with an ID.

143.1 - More Patrol Shit

What's sending these? Who knows!

[13:28:2]:findbeacon=patrol; address_1=!BEACON!; sender=02008ad5; 
[13:28:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access; 
[13:28:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage; 
[13:28:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters; 
[13:28:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; 
[13:34:3]:findbeacon=patrol; address_1=!BEACON!; sender=02008b00; 
[13:34:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access; 
[13:34:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage; 
[13:34:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters; 
[13:34:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; 
[13:34:4]:findbeacon=patrol; address_1=!BEACON!; sender=02008af3; 
[13:34:4]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access; 
[13:34:4]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage; 
[13:34:4]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters; 
[13:34:4]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; 
[13:47:5]:findbeacon=patrol; address_1=!BEACON!; sender=02008ad5; 
[13:47:5]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access; 
[13:47:5]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage; 
[13:47:5]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters; 
[13:47:5]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; 
[13:54:2]:findbeacon=patrol; address_1=!BEACON!; sender=02008b00; 
[13:54:3]:beacon=Living Quarters; netid=02008c21; patrol=1; next_patrol=Lab Access; 
[13:54:3]:beacon=Central Junction; netid=02008c08; patrol=1; next_patrol=Storage; 
[13:54:3]:beacon=Storage; netid=02008b0d; patrol=1; next_patrol=Living Quarters; 
[13:54:3]:beacon=Control Room; netid=02008aad; patrol=1; next_patrol=Central Junction; 

143.3 - Hydroponics trays

• Device name: WNET_PACKETSPY, WNET_GENERIC, WNET_DETECTOR, WNET_SYN%%^#FF
  • They randomly cycle between these on each ping.
• Broadcast range: ≥64 tiles (129 × 129)

Packets:

• netid: 02001234 -- The address of that particular tray
• data: One of the following:
  • event_new: A seed was planted in the tray
  • event_death: The plant died. RIP
  • event_cleared: The plant (dead or otherwise) was removed from the tray

Doesn't seem to be a way to actually make any of this information useful.

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 - Robot patrol beacons

Securitron and 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.

Tour Guide beacon, this one from the Escape Arm:

• Location: tour16
  • 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)

Patrol beacon, a fictional example (TODO: get a real one):

• Location: sec
  • patrol: 1 -- Marks it as a patrol beacon
  • next_patrol: bar -- Which beacon comes after this in the route (TODO: verify the name)

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 - ?

Something to do with patrolling and beacons. TODO: Packet captures, etc

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
    • This is because a byond atom reference is being passed in the packet, printing this reference will yield its name ("(the) floor"). It is impossible to replicate this packet. I'd recommend bringing this to IBM's attention. --Marquesas
  • 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.