Despite an innate dislike of them I believe I have an apt analogy to add. Jeff is a bouncer who's very handy on the door but has no common sense. The manager duly instructs Jeff to take orders from him and only him. Anyone else making enquiries must be referred to the manager's office, even if it only concerns Jeff. One day a magician uses his Mask spell to trick Jeff into thinking he is the manager. Does Jeff obey the spellcaster? Of course, because he only has to think it's his boss, it doesn't have to actually be his boss. How could Jeff ignore the order without resisting the spell?

In conclusion of this fairly arbitrary comparison, subscriptions/connections are not ethereal cables stretched out between nodes to keep communications exclusive. The only thing stopping a slave's node from being commanded is that it has orders not to if the command is not 'signed off' by the master. A spoofed command sent directly to the slave is simply a normal command with a forged signature. If you happen to have learned the required signature in advance you need not worry about the master at all.

But what is an already established subscription? I can tell you what it isn't. It isn't a physical link between two nodes. And if it isn't a physical link between two nodes, it can be faked through the wireless, because without a physical link, there is no way to actually physically determine the origin of one packet of data as opposed to another packet of data.

If a device has a subscription to Device B, and you send something that looks like it came from Device B, then it looks like it came along an already established subscription.

You still continue to fail to point out what kind of an action 'spoof access to' is, though you bring it up as a requirement



It's great that you interpret it that way, but there are absolutely no rules for doing something like that. None. Are you suggesting that half a sentence was intended to create a new action that has no rules for it what-so-ever?

The whole problem here is that you aren't allowing for the fact that the word spoof has multiple definitions. In the case of 'spoof an access ID' it can only have the meaning 'pretend to be' logically applied, because you don't spoof as in 'send a fake command to' an access ID, you do it to a node.


@deek Actually, my example already placed the rustler on the ranch. The ranch isn't the master node, it is just part of the matrix. The ranch hand is the master node. Interestingly TJ's idea of how things work falls apart completely with this analogy (because then it becomes something like 'first you have to put on the ranch hand's skin' or maybe 'You have to bounce a thrown knife off the ranch hand to cut the rope'). This doesn't make idea wrong, but it is something interesting to point out for an analogy that otherwise works fairly well.

Spoof the Access ID of the master means one of exactly two things:

1. Actually alter your node's Access ID to match (per the rules I quoted above). This arguably allows you to just send commands, which is a quicker action than the Spoof Command action. (Note that, under normal hacking circumstances, logging in with a duplicate Access ID causes a security response; spoofing, however, is not logging in. Your persona is not present, and you don't have a subscription.)

2. The sentence actually means 'spoof the slave *as* the master', which is the simpler, normal method. While the wording is awkward, it fully makes sense to specify here that the only way to spoof the slave is as the *master*. Indeed, we should expect this.

In no case could this ever mean some unprecedented thing like 'temporary connection to the master and send commands through it'. That's called 'hacking the master', and it's *already* #2 in the list of 3 ways to beat slaving.

That's a very good analogy. When trying to determine who someone is, we can generally only tell by how they look and maybe how they sound or act, and the digital equivalent is an Access ID. Just like you wouldn't necessarily be able to tell the difference between Bob and someone pretending to be Bob with a Mask spell, a node can't necessarily tell the difference between something from Access ID B, and something from something spoofing access ID B.

The slave/master relationship could be viewed as the equivalent of someone pretending to be a friend of yours, instead of someone you don't really know particularly well.

The RL term for that is "security through obscurity". It doesn't work as well as people want it to and it's expensive to maintain. It's not worth adding to the game because (let's be honest here) watching hackers hack in real life is even less exciting than watching chess players play chess. Players who use these sorts of things to protect themselves deserve to face these sorts of things as part of the challenge and they'll quickly get annoyed at having to do the legwork now required to hack the system. "The hacker will spend the first two days probing. Someone pick up some pizza while we roll dice."

That depends on what the manager tells Jeff to do, because Jeff is aware of magic and what it can do (even if artificially inflated by trids).

Nodes might not be able to use that kind of deduction though.

Well, I think the assumption is that Jeff isn't exactly the sharpest knife in the drawer, and is in fact much closer to a mallet. Still, you're right, still likely wouldn't obey the order to kill himself or something like that, but nodes don't have that kind of self-preservation logic or the ability to think 'hmm, does this really sound like something the master would have me do?' and question an odd order.

Sure they do. IF they have been set to query each order with further authentication, then it fails, because the Spoofer does not receive the Authentication Query. It is even simple and easy to do.

Which is already part of the spoof program. That's why there is an opposed test in the first place. The original device requires some form of authentication (As stated in the books) already, which is part of what spoof has to fake. If a device didn't require authentication then it wouldn't get an opposed check against the spoof command.

You miss my point... You spoof the COmmand (with appropriate AID and everything)... Node Receives Command... Node Re-Authenticates Command by requesting Re-Authentication, Spoofer does not receive Command, because he is not the Master Node. Master Node Gets Authentication Request... Master Node invalidates Request... Spoofed Command does not take place.

This tends to occur with Drones more than anything else, because the Pilot may have a Scrpt mandating this procedure, but a Normal Node may also have this script in place.

Yes, it is very ineffecient, becasue this takes multiple IP's to complete any requested action. But it can be done.

It really comes down to how difficult the GM wants to make the System/Node/Drone/Whatever to hack...

You lost me there. The Slave sends out a wireless signal that the spoofer node antenna doesn't get but the master node antenna gets?

That is indeed correct, because you only Spoofed the AID, you are NOT the AID...

EDIT: Here is a better comparison... You can Spoof Admin Level Commands; the fact that you Spoofed an Admin Level Command does not give you actual Admin Access Rights. If you had Actual Admin Level Access Rights, you would not have to spoof them.

You could change your commlink's access ID, and receive the authentication query that way I suppose, which just adds to the fact that slaved nodes are more of a pain to subvert?

Usually... Once you physically change your own AID, you need to resubscribe all your subscriptions. As well, you cannot change your AID in the middle of a Matrix Run. You have to disconnect and then reconnect, which is generally a pain. That is why Spoof is so useful. Hopefully, you have no Agents out either, because once you change your AID, they lose track of you as well.

Anyways...

The re-authentication Tymeaus is describing is specifically addressed in the FAQ, actually. That's what I was referring to.

Ahhh... A FAQ reference... How is it worded?

Edit: Looked it up, so never mind...

Okay Everyone...

I said I understood your points of view and I do...
Having not reviewed the FAQ in a LONG time (Mostly because of its inaccuracies), I have just done so. Thanks Yerameyahu...

I will have to agree with Yerameyahu (and by extension Ghost_in_the_System and Suoq.)

Leaving aside Options 1 and 2 for Accessing a Slaved Device, Option 3 is pretty Cut and Dried, and I will admit, my interpretation is (was) a little odd. And is obviously at odds with a lot of People. But there you go. However, after a review of the FAQ, I think I have determined where my interpretation went off course. So, let me clarify my current position.

Leaving aside that you can only Spoof Agents, Devices with a Pilot Rating (Drones usually), and Peripheral Nodes; You Must do two things to Spoof one of the Above Slaved Devices.

Well, 3 Things actually.

1st. You must obtain the AID of the Master Node. (Goes without saying, but did anyways to clarify my line of thinking)
2nd. You must set your hardware to emulate said AID. (This is tedious, and often not worth doing, as a Hack would take less time).
3rd. Then you may Spoof commands to the Slaved Node.

Note: You CANNOT SPOOF a Slaved Node that is not any of the above (because it is, for all intents and purposes a part of the Master Node, as I have indicated earlier in the series of posts), except in very specific situations (For Example: When an Alert is active, and all access for the AID you are using is termminated, you may then spoof commands at an appropriate access level, with the appropriate penalties. Assuming, of course, that you have access to the appropriate AID's to aid you in your spoof attempts).

I agree that my terminology was uselessly complex, and ultimately wrong on a few levels. But the core concept remains the same. It is verifiably easy to Spoof a Non-Slaved Node. It is often Uselessly complex to Spoof a Slaved Node (which is why you should use them for certain things).

Note also that you cannot use Spoof to change a Nodes Settings (Access Rights, Subscription Lists, etc.), as some have suggested.

Regardless... I have thoroughly enjoyed the discussion, even when it got a little heated. Thanks for the Discourse...

No, faking authentication is part of what the spoof program does, unless you're saying that it waits several seconds before it sends something to the master to confirm the choice (which is different from authentication). Otherwise that is all part of how a node operates, and defeating that authentication is all part of the spoof program.


2 is not correct. You do not need to mess with your hardware, and if you did change your hardware, you would not need to use spoof, you could just send commands directly.

Edit: If 2 was needed, it would say that you need to spoof your own access ID (in this case spoof meaning fake or change), Unwired p52.

You *can* set up additional, 'handshaking' authentication. It's just bad. Again, it's in the FAQ.

See, I disagree here. But that is okay, no need to ignite another argument.
That is how I am going to proceed from now on.

Oh, just found another way to beat slaving: The puppeteer trojan. Infect the master with it and then you can use it to send commands through the master. I suppose this might just be seen as a different version of option 3 though.

You do at least acknowledge that if you weren't dealing with a slave, you wouldn't have to perform step 2, correct?

I think the biggest problem with option three is that it uses unique terminology that is not repeated elsewhere in any of the books. There is no other reference to spoofing an access ID (except your own)

There is reference to spoofing a command, which is the most commonly thought of function of spoof.
There is reference to spoofing a node, which is simply another form of the above.
There is reference to spoofing an agent/pilot/sprite, which is simply another form of the above.
There is reference to spoofing your own access ID which means the long involved change like TJ is talking about.
There is reference to spoofing your own access ID to look like someone else's, which is a specific form of the above.
There is reference to spoofing your persona, which is used for tricking limitations.

But no where else is there anything where it uses spoofing someone else's access ID. It could be taken to mean that you spoof the node that access ID belongs to, it could mean that you spoof your own access ID to look like that access ID. It could mean that you are spoofing (pretending to be) that access ID as part of the regular usage of spoofing and is simply clarifying that you have to use the master's access ID as opposed to that of something else.

I suppose the easiest thing to do would be to spoof the master itself with a command to send a (totally legitimate) command to the slave. Some small chance of being noticed, but only if the master is watching the slaves like a hawk, in which case you're likely to get noticed quickly anyway.

Indeed...

And yes, if you are not dealing with a Slaved Device, Step 2 is completely unneceessary. In fact, I never had an issue with non-slaved Spoofing at all.

Okay, so it is just that one undefined line that really can be interpreted in several ways. I think it is excessive to have to change your Access ID, and could argue against it by pointing out how it says it only accepts connections from the master as opposed to a master or the masters, but it isn't a big deal. If I'm ever at your table I'll just use spoof against the master to send a legitimate command to the slave and be done with it (Or maybe stay away from the matrix entirely )

Heh... No worries...

Good analogy. I did the same thing about 4 pages back, but it got ignored, and I used T2, because Arnold is always awesome.