Help - Search - Members - Calendar
Full Version: Matrix interpretations
Dumpshock Forums > Discussion > Shadowrun
kerbarian
I recently read Serbitar's guide to the matrix, and I like a lot of the ideas in there. It does (by its own admission) introduce interpretations and mechanics that aren't explicitly backed up by the rules.

After thinking about Matrix workings a bit, I have a few alternate interpretations that seem like they could work out well. In particular, I started out by thinking about the issue of relays. As Serbitar describes in SGM, why not buy several commlinks and relay your connection through all of them, so that an attacker has to hack through several systems to get to your commlink?

Interpretation #1: All relays are essentially open relays, for the purposes of hacking.

If a device is set up so that it can communicate with the Matrix in general, then the Matrix in general can communicate back, regardless of any relays in the path. If you can receive a phone call, you can receive a hacking attempt. Relays can, of course, filter for legitimate traffic. As a result, when hacking into a node behind relays set up to filter traffic, the target node can use the highest Firewall rating amongst itself and any of the relays (new rule -- not addressed in SR4). Any actions taken inside the node (after you've hacked in) only deal with the node's actual Firewall rating.

This has some significant implications. It means that if Joe wageslave inside a secure corporate facility can make a phone call to his wife (over the Matrix), then anyone can hack directly into Joe's commlink, and from there potentially into a host deep inside the corp network, bypassing any chokepoint hosts. That's no good, and corps would realize it. To deal with that, the standard setup in any facility with a secure network is:

1) All hosts are configured to not allow outgoing connections except from personas/programs running on that host. This means that none of them act as relays.

2) Employees are required to run their personas on the chokepoint hosts if they want outside access. Their own commlinks can still be used as input/output devices, but that's not where the persona runs. From the chokepoint, they can connect inward to sensitive corp hosts or outward to the rest of the Matrix. Anyone can directly attack those chokepoint hosts from the Matrix, but no one will ever be relayed through them.

This forces quite simple network layouts, which I think is a good thing for playability. Standard networks will just have hosts that are all directly connected to the Matrix. Secure networks will have a single chokepoint host that you have to hack into first, and from there you can directly connect to any of the other hosts inside the network.

This would also be the standard model for a PAN. The commlink acts like the chokepoint host (where the user's persona is running), and the commlink doesn't allow relaying, so any other devices on the PAN can only be accessed by a persona running on the commlink.

Interpretation #2: Subscription lists don't prevent direct hacking.

The language in the rules about subscription lists is a bit fuzzy. It says that "you may configure your devices so that they only interact with another specific device ... or a specific network". This "offers a degree of protection from snoopers and hackers." My interpretation of this is that subscription lists are just like any other security measure -- hacking can bypass them, and in fact that's a normal part of the hacking attempt.

So what does subscription mean, then, if it doesn't provide unhackable access control? It means that the node does its best to only allow traffic from subscribed nodes -- it will operate in hidden mode, and it will only allow legitimate traffic from nodes on its subscription list. For example, say you've planted a backdoor admin account in a security camera, but the camera is subscribed to a central security node. You couldn't log into the camera using the backdoor account, because the node rejects normal traffic from anywhere other than the security node. However, you could still hack into the camera directly (after you detect its hidden node).

Yes, this means that a hacker within 3m can hack directly into your rating 1 cyberlimb without going through your commlink. One way to deal with that is to purchase the Skinlink upgrade for all the devices on your PAN, which I imagine would be a fairly standard practice for runners.

Interpretation #3: Encrypting a node means setting a minimum encryption level for its communications.

The rules talk about encrypting a node or device, but they don't ever describe what that means. The best I've been able to come up with is that encrypting a node would mean that you're requiring a minimum level of encryption for all of its communications. For example, a rigger has a few Fly-Spy drones that run Encrypt 3 and a commlink that runs Encrypt 5. He encrypts the drones so that they only allow connections with encryption 3 or higher. Normally, he wouldn't set minimum encryption for his commlink at all, so that he can interact with unencrypted Matrix services (like checking out the menu of that restaurant he's walking past). On a run, he'd likely set his commlink to a minimum encryption of 3, since that's the best his drones can manage. The other runners on the team all have commlinks running encrypt 5, so everyone else sets their minimum encryption to 5. The rigger can still interact with the other runners because his commlink is running Encrypt 5, but the other runners couldn't interact with the drones.

In order to hack into a node, you first need to break the minimum level of encryption it requires. To avoid changing any SR4 rules, this can just be a standard Decrypt action that must be completed before you can hack in. I prefer a version, though, that uses a new rule: This decryption becomes part of the hacking attempt, as you're probing the system with various ciphers and examining the responses. For hacking on the fly, you make a Hacking + Decrypt (minimum encryption rating x2, 1 Initiative Pass) Extended Test. As normal with hacking on the fly, each time you make a test, the target node also makes an Analyze + Firewall (Stealth) Extended Test, and the successes are cumulative with those made later, when the real hacking attempt (Hacking + Exploit) begins. Probing the target is similar. You must make the same Hacking + Decrypt extended test before starting to hack in, but the interval is the same as for hacking while probing: 1 hour in VR, 1 day in AR. The target node does not get to make tests to detect you during the decryption extended test.

Interpretation #4: Spoofing is not helpful in hacking into a system.

Spoofing can be used for three specific actions only:

1) Spoof an access ID. The rules don't state that you can spoof the access ID of a specific user or that doing so would let you impersonate that user. My interpretation is that spoofing your access ID just lets you come up with a new, fake access ID.

2) Redirect Trace. This one is pretty straightforward -- you can use Spoof to confuse someone who's trying to trace your connection.

3) Spoof a command. This can only be used against drones and agents, not against nodes (per the text on p.224). As described in the rules, you must first figure out the access ID of the legitimate controller. If the agent or drone is currently subscribed to a persona, you can find the access ID of that persona by intercepting, decrypting, and analyzing traffic from the agent/drone. If the agent/drone is unsubscribed and operating independently, you have to track down the owning persona through some other means. Once you have the access ID, you can attempt the Spoof Command action.



I think that's enough for now. I'm planning to next come up with some sample network setups and hacking runs that go along with these interpretations, but that will have to wait until tonight.
deek
I think you can expand Interpretation #2 a bit. I agree with your statement, that a subscription list does not prevent hacking, but it does make it harder. And I think that is where spoofing comes into play...

Example:

If Hobie is running his commlink in hidden mode and using only a subscription list, then Haxor, cannot attempt to hack into his comm until he does a few things. He first needs to intercept traffic between the comm and one of the devices in the subscription list. If it is encrypted communication, Haxor also has to break that. Once that is done, he now has an access id.

So, he can begin hacking Hobie's comm, but must spoof all his communication, otherwise Hobie's comm is just going to ignore all communication attempts.

With that being said, subscribing doesn't prevent hacking attempts, but it does make it harder because you have several additional steps to take...and the nice thing about a subscription list is that if you are not communicating at all, then there is no way a hacker can intercept traffic and gain that access id...

Anyways, just my .02.
kerbarian
QUOTE (deek)
I think you can expand Interpretation #2 a bit. I agree with your statement, that a subscription list does not prevent hacking, but it does make it harder. And I think that is where spoofing comes into play...

What you describe is basically what's in SGM. The main issue I had with that idea is that if subscription lists really are an extra barrier to hacking, they'd always be in use for all passive or hidden nodes. If you're not accepting traffic from random Matrix nodes, then you might as well use a subscription list as the mechanism for filtering your traffic. That means you'll always have to spoof an access ID when hacking into anything other than an active node. I suppose that's not so bad, but it's not quite how I imagined things would work.

QUOTE
If Hobie is running his commlink in hidden mode and using only a subscription list, then Haxor, cannot attempt to hack into his comm until he does a few things.  He first needs to intercept traffic between the comm and one of the devices in the subscription list.  If it is encrypted communication, Haxor also has to break that.  Once that is done, he now has an access id.

So, he can begin hacking Hobie's comm, but must spoof all his communication, otherwise Hobie's comm is just going to ignore all communication attempts.

A couple notes here. I'd assume you'd need to perform a matrix perception test on the traffic (after decrypting it) in order to get the access ID. Also, the mechanism for spoofing the access ID would be a one-time Hacking + Spoof (2) test as described at the bottom of p.224.

One question that leads to is: can a node use multiple access IDs at once? If not, does that mean you couldn't hack into two different subscribed nodes at the same time (because each requires a specific, different access ID)? I don't offhand see a reason to prevent the use of multiple access IDs at once...

QUOTE
With that being said, subscribing doesn't prevent hacking attempts, but it does make it harder because you have several additional steps to take...and the nice thing about a subscription list is that if you are not communicating at all, then there is no way a hacker can intercept traffic and gain that access id...

You can also get an access ID by observing a persona. If you want to hack into someone's cyberarm and it's not communicating with anything, you could still hack into their commlink, observe their persona, and then try to use that access ID to connect to the cyberarm.

Also, the rules differentiate between subscription lists and subscribed nodes. I'd say that any time one node is actually subscribed to another (as opposed to just on the list), there would always be traffic passing back and forth between those nodes. For example, if you're expecting a fight, you'd want your gun to be subscribed to your commlink. Otherwise you'd have to spend a complex action to log onto it at the start of the fight in order to start using smartlink data. If your gun is subscribed, though, that means there's traffic passing back and forth between it and your commlink, and a hacker can extract an access ID from that.
Serbitar
QUOTE (kerbarian)
I recently read Serbitar's guide to the matrix,

0.9 or 1.0 beta ?

Your interpretations #2 and #4 are in 1.0 and #1 and #3 kind of.
Note that 0.9 is fully RAW compatible, while 1.0 is a complete rewrite
kerbarian
QUOTE (Serbitar)
0.9 or 1.0 beta ?

Your interpretations #2 and #4 are in 1.0 and #1 and #3 kind of.
Note that 0.9 is fully RAW compatible, while 1.0 is a complete rewrite

0.9 -- I hadn't seen 1.0. I'll look at that tonight and see how it all fits together.
RunnerPaul
QUOTE (kerbarian)
3) Spoof a command.  This can only be used against drones and agents, not against nodes (per the text on p.224).

Note that per the FAQ, the game developer feels that spoof also applies to nodes:

QUOTE (SR4 FAQ v1.1)
Spoof can be used to issue falsified commands to any node. Spoofed commands will seem to come from the authorized user you are spoofing, and so will be treated as having the same access privileges (personal, security, or admin) as that impersonated user.


While they didn't feel strongly enough about it to incorporate that as errata to p.224, the subject may get touched upon in Unwired.
kerbarian
QUOTE (RunnerPaul)
Note that per the FAQ, the game developer feels that spoof also applies to nodes:

Hmm, I forgot about that. I hadn't reread the FAQ since I started looking into Matrix interpretations. There's actually some useful stuff in there.

As far as spoofing commands to nodes goes, the first thing I'd think of would be spoofing the command "create a new admin account for me", as an alternate way to break into a system. It would require admin access, which the FAQ says could apply a -6 dice modifier, but it looks like you could just keep trying until you succeed. Of course, you could only spoof the command if there's an admin currently logged into the node (you need someone to impersonate).

Of course, Spoof Command says that "If successful, the target drone or agent believes the orders came from its controlling persona." That implies that if the test fails, the drone or agent (or node) knows that someone just tried to submit a fake command. Presumably this would be grounds to go on alert, and a node at least could go on alert and get +4 to its firewall against further actions by the spoofer. I don't think drones or agents can go on alert, so they just have to suck it up and hope the spoofer doesn't succeed next time. The -6 dice for spoofing admin commands helps a lot, though, since runners would presumably be communicating with their drones and agents as admins.

The FAQ also says that "You can tell a Pilot to ignore certain commands or to only follow pre-specified commands, but this is only going to be a protection from spoofing attacks, and it will, of course, prevent you from using your own agent/drone in certain ways." That seems like good grounds to flatly disallow some of the nastier spoofed commands, like telling a drone to only obey commands from a new master -- riggers would always tell their drones to ignore such a command. It would also be reasonable to say that it's standard to not allow creation or modification of admin accounts except via local (wired) access, so you can't spoof a command to create an admin account. You'd probably be able to create a security account, though.
RunnerPaul
The FAQ also speaks of hardware limitations on Admin accounts, which is why I imagine that most drones would have some kind of hidden kill-switch that must be held down for certain admin commands to be processed.
hobgoblin
or have a physical console connection used to access some admin rights.

and that was touched by posters here on the forum from the day that SR4 was released iirc.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Dumpshock Forums © 2001-2012