A subscription is a requirement, because a Spoof Command issues a Command, and only subscriptions can support such things according to Unwired.

Subscriptions and Data Requests are two completely different animals.

I dunno. If a subscription is a requirement, spoofing anything is impossible. I read that bit about commanding drones (not devices) as referring to a persistent "sensible" connection that you *maintain* with your drones. It's not the same as being able to send a single command to a given device.

Except that subscriptions are only for two way links. They are a Fast, two way, maintained connection. Completely unnecessary for Spoofing.

Right.

TJ: Normally I think you have solid grasp of the SR rules. But I think in this one, you have a fundamental disconnect.

I see where TJ is going on this. Its kind of like a VPN connection. When the master and slave negotiate the connection, they are authenticating each other and making a secure tunnel between each other and only traffic using that secure tunnel, is valid.

This assumption, I think, is more between the lines then RAW. We can certainly argue both points. TJ is supported by the book saying a slaved node can only accept commands from the master node and the text saying you need access to the master node to send commands to the slave. That "feels" like there is a secure connection between the two that cannot be spoofed.

Ghost has a case, because nowhere in the book does it say spoof can't spoof, well, anything.

I think it comes down to how powerful you want to let the spoof command be and how tough you want to make slave nodes from being hacked...

I think it comes from the fact that it says you need to spoof the master then spoof the slave. It is using two different definitions for the word spoof. "Spoof the master" means 'spoof' as in 'pretend to be' while "Spoof the slave" means 'spoof' as in 'send a fake command'. When put together you 'pretend to be the master then send a fake command' which is covered in a single spoof action.

except that VPN is not a slave connection.

VPN is an encrypted connection, which is something completely different.
The way to cockblock spoof, is of course to encrypt your slave connection.

Then you need to:
Sniff the traffic
decrypt the traffic
spoof the AID
encrypt properly
spoof your command using your spoofed aid and the new encryption.

the exact wording is:
You can spoof the access ID of the master node, and then spoof commands to the slave.

It does not say:
You can spoof the access id fo someone with access to the master node, and spoof commands to the master that will be relayed to the slave.

You would still need to use spoof if you didn't have a security or admin access on the master node. It kind of goes back to what I was saying. You could hack into the master node as a user and then spoof commands to the slaves. Or, you could create a legitimate account in the master node and just send commands without fear of setting an alarm. Hacking the master node for a security or admin access to begin with is making it more difficult to get in without setting off an alarm.

READ page 55 of the book. It doesn't say any of those things. It says, hard hack the slave, hack the master, or spoof the slave.

You could also user hack the Master, and then use spoof to send commands to the slave.

How is this tunnel created? What prevents another device from sending something that looks like it came from the master? What method of identification above and beyond Access ID that cannot be duplicated is being used to confirm that something actually came from the master and not another source?

Now, I did just realize that for added security, you could encrypt the connection between master and slave, which would then require the encryption to be broken so that the hacker could properly encrypt the spoofed command so that it gets recognized properly by the slave.

Almost correct, but you don't need to spoof your AID as a separate action, that is part of what spoofing a command does.


That doesn't change anything. Just replace 'master' with 'access ID of the master node' and you still get 'pretend to be the access ID of the master and then send a fake command' which is still a single spoof action.

I never said anything remotely approaching that.

Sometimes, just sometimes, I miss the days when everything in the matrix was very standard, and you had rectangle data stores and hexagon CPUs and little triangle access points

double post again, freaking internet here is bonkers today.


On a side note, is there a way to delete a post?

Ghost, we're on the same side on this

I was talking to Deek and TJ who both DID say that.

I do admit, having a more abstracted system like that has its advantages, because you don't have people comparing it to real life. It also means somewhat less freedom though, so there is that.

I just want to make sure we're down to the following impassible barrier.

Side 1: "Spoof the Access ID of the Master Node" = Spoof the Master Node
Side 2: "Spoof the Access ID of the Master Node" = Get the Access ID of the Master Node

Any other points of contention?

No you got it in 1

Ghost and I think that #2 is the right interpretation, TJ and Deek think #1 is.

I was just adding some information to support TJ and make a case that it made sense and could be interpreted this way. I would say that the tunnel creation is a part of the slaving a node process. That's all part of the setup and the effects of slaving a node. Obviously, its not spelled out in detail, but some of the wording used in RAW supports that.

I could also see you bypassing the whole thing and taking sabs (I think) point and taking a -6 to your spoof if the target is a slaved node. Then you could send whatever command you want using spoof. Just at a -6 die pool. And, you'd also have to know the master nodes AID, which is easy enough to get. A -6 to spoof is likely not a trivial matter for most.

I'm not saying either is right actually. But I do agree those are the 2 points of intention.

I can see where TJ is coming from and can read into some of the text to support that. I can also see where Ghost and sabs is coming from.

Personally, I'd prefer my players to feel safer when they slave their comm to the master hacker and not have to worry about being spoofed. That puts the spotlight on the hacker if someone is screwing around with hacking comms. And, I also feel that was the intention of the rules introducing slaving as an option. Not to make anything unhackable, but make it a single point of entry on a assumedly harder target.

PS: I do like the tag team debate going on here. It is rather enjoyable.

You need to define spoof in side one, because spoof has two major meanings 1) pretend to be 2) send fake command with fake credentials to. So, to further clerify:

Side 1: "Spoof the Access ID of the Master Node" = Send fake commands to the Master Node
Side 2: "Spoof the Access ID of the Master Node" = Get the Access ID of the Master Node (so that it can be used as part of the "Spoof a Command" action)
Side 3: "Spoof the Access ID of the Master Node" = Use Spoof to make yourself temporarily have the access ID of the Master node (And yet still have to spoof commands instead of sending regular commands)

I'm not entirely sure if TJ is on side 1 or 3 or both. I know that I am firmly in 2 because that is how the rules for spoofing a command work, and nothing in slaving says that spoofing works any differently from normal.

Note: I believe you would suffer the -6 penalty for the spoofing because you are using an admin account.

I think you are misunderstanding what spoofing is.
In Shadowrun, spoofing and hacking are two different things. In real life, of course, spoofing is one of the main tools of a hacker.

When you spoof, you are attempting to convince the recieving node that the sending node is a different node, such as the system that it's slaved to. It already has a subscription.
If you were to have a subscription you would have had to hack it, and there would be no point in spoofing.

Again, I am not confused here. I do know that the two tasks are completely different in Shadowrun. You cannot treat both Normal Nodes and Slaved Nodes the same for purposes of Spoof. And the Rules support that.

And Ghost_in_the_System, Essentially Option 3 above (which is exactly what Unwired says). You are creating a temporary access remotely (using the Master Node AID) that will use the Master Node to communicate with the Slaved Node. The reason that this is necessary is because the Slaved node will not accept any other connections except that of the Master Node. You then use this temporary poiont of access (the Spoofed Master Node) to send that Spoofed COmmand to the Slaved Node. It is NOT a Hack, because you are not actually implanting anything on the Master Node at all. You are using its own protocols and subscriptions to gain your own ends.

The reason the Slaved node will not accept commands outside of the Subscription port that is subscribed, is because the Slave will forward ANY other connection attempts right back to the Master node. This is a result of how Subscriptions and Slaving interact. You cannot generate a Command connection without a successful Subscription. Slaved Nodes ONLY accept a such commands through the Subscription that the Master Node has established for itself (as it only needs the one).

Now, functionally, there are ways around that. The 3 discussed routes are the methods established on Page 55 in Unwired. Another possible method, which has been briefly talked about, is to completely disrupt communications in such a way that the subscription is disconnected. Then you can attempt to re-establish the connection using your own hardware and the Spoofed AID of the original Master Node. Thsi will, in theory, work, if you can pull it off. It is harder than you think it is to do so, however.

The only Surefire ways to do so are the 3 ways described in Unwired.

In any case, you should still suffer the -6 penalty to the Spoof attempt upon a Slaved Node becasue you have to do so with Administrative Access.

I continue this debate because, otherwise, Spoofing a Slaved node is no harder than spoofing a non-slaved node, and this is obviously NOT the intent of the rules as presented in Unwired. The Story in the SR4A Book, with Slamm-O! and Netcat, only uses Basic Rules, which does not include Slaving. If they were the same difficulty, then why have slaving at all, as there would be no functional difference?

Anyways...

Sure you can. Tell me where it says you can't. Spoofing is not a connection, and does not require a connection, so don't try pulling out the connection thing again (Unless you can also tell me where is says that spoofing is or requires a connection)

Yes it does, Spoofing a Slaved Node requires a connection to the Slaved Node, otherwise you cannot spoof it. That is the benefit of Slaving.

Whoops... Double Post...

Slaving is a big benefit against Spoofing, and a Poor one agains actual Hacking. Why? Because if you hack the system, you do not have to hack ANY of the Slaved Nodes. You just command them. Unlike a normal system, where you may have to hack each node in sequence (some are set up that way, and some would not be). Slaving removes completely the need to hack into the slaved nodes.

Just to be clear, I'm in the #2 camp. But I follow the "Thank you for Smoking" rules of debate.

I can't convince TJ and as far as I can tell, everyone else supports or at least understands the #2 camp so there's no "them" to convince.

And that is okay...
And for the record, I never said I did not understand Position 2, just that I disagreed with it, and why.

Where does it say this?

Slaved Nodes require a Subscription... It is on Page 55 of Unwired, Middle of the Page, in the Box that describes exactly what needs a Subscription. A Subscription is a Direct Link Connection.

It requires a subscription to be slaved to something, it doesn't require a subscription to be spoofed.

You cannot Spoof a Slaved Node directly, Because it will not accept your communications attempt. The ONLY Communications it accepts are along the Subscription. Which is a Direct Link.

Spoof, by the basic book needs nothing else, because the bassic book knows nothing about slaving. In Unwired, there are only 3 ways to Spoof a Slaved Node. We have gone over those. Is this more difficult than a normal Node being Spoofed? Somehwat, though not heavily so. Is it often better to just Hack that Master Node in the first place? Most of the Time, Yes.

As I indicated before. Slaving gives more security against actual Spoofing, but removes a bit of the Security for Actual Hacking. There are tradeoffs.

I'm trying to think how I can possibly break this down any more simply.

A connection is established between A and B, if you spoof a command pretending to be B, it looks exactly like anything else that comes from B, and so is impossible to distinguish from 'communications along the subscription'. Also, a direct link is not required for a subscription, nor does having a direct link matter at all in this instance, because a direct link is no more secure against spoofing than a routed link.

We have not gone over 3 ways to spoof a slaved node, we've gone over three ways to gain access to a slaved node (You are once again mixing up terms). And there are no additional requirements set out in Unwired about requiring anything like a subscription or connection (which existed in BBB, and so should have been mentioned there regardless), despite an entire section being about spoofing.

And no, slaving is actually designed to make hacking more difficult, not less. And slaving makes spoofing... mildly more difficult, but not excessively so by virtue of a limited Access ID list and required use of an admin account.

You also have to realize that your interpretations are... asinine at best. In order to spoof a slaved device you first have to hack the master? Which means you already have complete control over the slave, so there is no reason to do so. Or something about... I don't know, bouncing the spoof off the master for which there are no rules for? I don't quite remember as I didn't quite understand at the time.

You also claim that there is some magical force that distinguishes a spoofed command from a legitimate command, despite that being exactly the entire purpose of spoofing a command.

Your right... 3 Ways to Access a Slaved Node, Not Spoof a Slaved Node...
As for Slaving and for Hacking Difficulty, all it does is use a more robust system instead of the slaved system. Unfortunately, once you have cracked the Master Node, all slaved nodes are available with no further hacking required whatsoever. It makes Spoofing More Difficult, in the end, and Hacking Less Difficult in the End...

And I never said you had to hack the Master Node to get to the Slaved Node. Way to twist the words there. I said it is likely more efficient to hack the Node than it is to Spoof it. Completely different thing.

Quite twisting what I said... Especially since you know that it it NOT what I said.

And you and I are never going to agree on this one. So, No worries...

I'm not exactly sure how having to hack a more secure system to get at a less secure system makes hacking easier, unless you happen to care about the other slaved node, which you may or may not, and which may or may not even exist. It is harder to hack into a given node, but easier to hack the system as a whole.

And maybe I've gotten what you've said mixed up. Would you mind explaining to me what exactly you do have to do to spoof a slaved node then? Every single action, target, and requirement.

The Slaved nodes are less secure in the long term, because once you have hacked the Master Node, they are wide open. If they were not slaved, you would potentially have to hack each and every node in succession to access them. When they are slaved, this is not required. SO you are trading a Heavily Defended Node for the Initial Hack, hoping that it will stop the hacker, but once he is in, any slaved nodes are easily accessible, since they are not required to be hacked.

Accessing any Node that is slaved has only 3 options. The 3rd is likely the easiest. To Spoof that slaved node, you must first gain access to the communications port that the Slaved node is using to communicate with the Master node (which is on the master node). You sppof access to that master node, and then you spoof your commands to the Slaved Node through its Subscription. THIS IS NOT A HACK. It is simpler than a Hack at its core, but takes more steps.

YOU Cannot access a Slaved Node through Wireless protocols (or even wired ones) Unless you are the Master Node, because it will only accept communications From that Master Node, On the Master Node's Subscription. Not sure why that is so hard to understand.

Spoofing A Slaved Node is not the same as Spoofing a Non-Slaved Node. You are trying to make them the same.

You keep bringing up 'spoof access to' but that isn't an action of any kind. There are no rules for 'spoofing access to' a thing, so I don't know what kind of roll is required. Is it opposed, is it a threshold, is it extended? It is difficult to perform an action which does not exist.


Yes, it will only accept communications that appear to come from a master node, but there is no way to tell the difference (besides the opposed device check of course) between a spoofed communication set to look like it is coming from the master node, and an actual communication from the master node. A subscription does not provide some magical unspoofable communication between two devices. Really, all a subscription does is set up that two things need to be ready to devote large amounts of bandwidth to one another. Other than that, there is nothing special about a subscription.


Because it is the same thing, you are trying to make them different when there is not a single word in the entire book that says spoofing them is any different. The only thing even remotely close is the single line on p55 which I have explained above does not constitute multiple actions, or indeed anything outside the normal parameters of a spoof.

Again, I think this comes down to how powerful you want the Spoof program to be at your table. If you want it to control a slaved node by simply having he master node's AID and sending a spoofed command for every action, then you can do that. I think it makes slaving nodes a lot less secure than Unwired intended them to be, but that may fit your style better.

Now this whole argument only holds up if there is no way to tell the difference between communications coming from the master node and spoofed communication set to look like it is coming from the master node. And this is in the realm of feasibility for the spoof program.

I just think it weakens the whole purpose for slaving a node. I think the spirit of the rules are that there is a difference between communications coming from the master node and communications not coming from the master node, whether they are spoofed or not. I think the whole purpose of slaving nodes is to make it harder to hack them (which, you could argue, spoofing at -6 meets that purpose).

Basically, you are saying the only difference between spoofing a non-slaved node and a slaved node is the -6 penalty. That may be enough for most. But I like the feel of making the initial hack harder to get into the master node and once there, able to have access to all slaves by default. I think the flavor of that, as well as the practical gameplay of it make good sense. The team's hacker then gets to focus on defending just his own commlink against hackers instead of worrying about all his teammates having crappy defenses. And he knows that if he doesn't defend his node, then the whole team has the potential to get hosed (matrix-ly speaking).

One more thing, it seems that ghost and sabs assume that hacking the master node is always done at the admin level. I still disagree with that, as it is quite viable to hack that master node at a user level and then use your spoof program to send commands to the slaves (as you'd have to use spoof because user level access doesn't allow control of slaves). I think that is the easiest way in.

Obviously, if you do hack the node at admin level, then you don't need to spoof any commands, nor risk setting any alerts, and can just start sending regular commands to any slave you desire. But I doubt that many hackers will want to spend the extra rolls with a +6 for admin and risk setting an alert. You set off an alert in some hacker's master node, and you can pretty much be guaranteed he's got countermeasures against you as well as cut links to his slaves to minimize the effects of the breach.

Well, actually the -6 is just from the fact that you're spoofing to an admin account, which could occur on any device, not just slaved devices, it is just that with slaved devices, it is the only option. For instance, if you wanted to spoof a command to create a new account for you to log into a non-slaved device, that would require admin access, which would face the -6 penalty.

Also, being able to spoof the device doesn't necessarily give control of the slaved device, it simply allows you to perform one command at a time. While that command might be able to bring over control, it doesn't necessarily. Also keep in mind that by encrypting the connection, you could easily force a hacker to spend several turns just decrypting the encryption, then applying the encryption to her spoofed commands. Slaving a commlink does make it more resilient to spoofing, just not as resilient as it does to hacking.

As for admin access on the master node, well, depends. Admin access may not be required to give commands to slaves, or it may, depends on the setup. And really, what you're doing is your going back to SR3 rules with your 'break in so that you can get access to the secondary devices'. There aren't gates like in the wireless system. Those can work on hardwired systems, because you can detect if a command is actually coming through a particular line or not. With wireless though, it is all information being broadcast out into the ether, and being plucked out of it. There is no true way to verify where it came from beyond it telling you as much, and faking that is exactly what spoof is all about.

Personally I think that spoof being able to bypass the master after a fashion makes the hacker's job more interesting. She now has to consider more than simply getting the biggest firewall with an IC that runs analyze constantly. She now has to encrypt connections and do her best to keep tabs on if people are trying to sneak past her. And if they do, well, now she suddenly has something to do, go find the theif, and hack into their system to retrieve the now lost commlink.

Hmm, just thought of an analogy. Pretend hackers are cattle rustlers. Normally cattle just stand around and are fairly vulnerable to being rustled by someone throwing a lasso over them and being dragged off (Hacked). With slaving though, you have them all on ropes being held by a ranch hand. The rustler now has the option of going right up to the cattle and attempting to remove the rope from its neck(hacking via a physical link), beating up the ranch hand and taking all the cattle's ropes from him (Hacking the master), or sneaking behind the ranch hand, cutting the rope, and then slipping away with the cattle (Spoofing the slave). Basically the rope is the master/slave connection. It doesn't matter much to the cattle who is actually on the other end of the rope, so long as it seems like it is the same person, which it must be because there is still that same rope. A cow can't distinguish one human from another (Okay, maybe it can, but for the sake of the example...).

It may not be a 100% accurate example, but I think it fits pretty well (And who doesn't love a strapping cowboy? )

Edit: In the above example, the cowboy would have his back turned on the cattle, with the ropes and possibly mooing being an indicator that something is wrong, just like a master device doesn't do much with the slave device unless something is actually wrong.

This is pretty silly. There's no reason the list would include 'spoof the slave' if you couldn't do it (that is, if it required you have access to the master). As I said way back, if you want a dedicated 'locked' master-slave connection, encrypt it. Otherwise, the whole point of spoofing is precisely the reason that spoofing works: it pretends to be from the master. It doesn't have to actually be from the master, because it's spoofing. That's the whole point.

Which again, is an interpretation and setting a certain level of power to the Spoof program.

You could also take the phrase, "only accepts communcations from the master node" and interpret that as TJ has already done.

Please understand, TJ has said several times he understand what the argument is (as do I), but we don't agree with your interpretation. Which, really doesn't affect anyone at all unless you are playing at someone's tables that run a different rule for spoofing slaved nodes.

Ghost, I do like your analogy. And to add the "other" interpretation to your analogy, the cattle are covered with a giant tarp (meaning you can occasionally here a moo, but you really can't see any cattle, but you kind of know they are there) and you can't access any of the ranch-hands ropes until you are on the ranch (i.e. in the master node).

I'm with TJ on this. I understand what you are saying and I think its a valid interpretation. I just think that there is more than one valid interpretation here, based on the wording in the books.

No, you really can't 'interpret' it that way. The way it knows who the communication is from is the Access ID, which spoofing spoofs. That's why spoofing exists, to appear to *be* a communication from the master.

It's not 'setting' the power of anything. The book has 3 options, and one of them is nonsensical if you change the rules in the way you're describing. Again, to require master node access is literally option #2 of those three option *already*. There is no reason why the book would offer the spoofing option at all if it was identical (or identical-but-inferior) to the 'access the master' option.

I appreciate your attempts to be evenhanded, I really do, but not everything is an opinion.

Since I have had a reasonable amount of rest last night, Let me try this Tack...

1. You have a Slaved Node
2. You want to spoof Commnads to that Slaved Node.
3. You do not, yet, have the Access ID of the Master node.
4. You Trace a User on that Node to get Their AID to access the Master Node.
5. Now, you use the Users AID to Spoof a Command to the Master Node.

Now, why do you do that? Notice that the rule does not say that you Trace the Master Node to get its AID, because that is already assummed. Let me put it back up here again. It says...



So, why are you Spoofing the AID of the Master Node? I interpret this as a direct, temporary connection through the Master node so that you may communicate with the Slaved Node. Why? Because the Slaved Node will accept No New Connections from any nodes. Why? Because it already has a Direct Linked Connection, Via the Subscription that is already in place (See Subscription Rules, and implement Slaving Rules). It does not need to accept another connection, and in fact, will not accept any pther connection whatsoever.

6. Ultimately, you want that command to go to the Slave, but the Master Node will not Run that Command on its own, so...
7. Once the Master Node has been Spoofed, you grab the Master's AID and you now Spoof the Slaved Node, using the Master's AID.
8. The Slaved Node does what it has been commanded to do.

It is a completely different interpretation than you use, Ghost_in_the_System, because it has to be. Otherwise your Slaved Nodes and Your Standard Nodes are treated identically for purposes of Spoof, and that is not the intent, as outlined in the rules above.

Do both systems work? Of Course they do. But by using the exact same system for both types of Nodes, you have just invalidated the Slaving Rules. Why? Because you already Must have an Appropriate AID for the Node to be Spoofed. The reason a Slaved node is HARDER too Spoof than the Standard Node, is because the Slaved Node will not accept any other outside communications whatsoever, which is not true for the Standard Node.

Hopefully this is a bit more coherent than my sleep addled ramblings from last night...

Anyways. It really is academic, as Deek stated, because each table is going to use the rules as they see fit, no matter any other's interpretations.

You're spoofing the master's ID:That's simply not how subscriptions work in the wireless world. The Access ID is exactly (and solely) how it knows that incoming communications are from the master. Spoofing is not a 'new connection'.
This doesn't make sense, not as far as "spoof the access ID of the master node" is concerned. It doesn't mean (and doesn't say) 'spoof the master' nor 'spoof your way *into* the master'.

It is not the case the slaved nodes are supposed to be especially resistant to spoofing. It is not 'against the intent' for them not to be. Slaving has the purpose of not letting people *log in*. Your 'interpretation' is fundamentally denying the central function of spoofing and its reason for existing: to pretend communications are from the correct node or 'connection'.

Actually it is not, but that is okay, you and I have different opinions. What else is new, right?

The Slaved node knows it is the Master Node for 2 rasons. It has the Master's AID, and it comes along an already established Subscription, through which it communicates with the Master Node. There are 2 parts there.

The problem with your argument is that you will not ever connect to that Slaved node wirelessly, (or wired without Physical access) unless you do so From (or through, if you will) the master Node, because the Master node already has a connection and a new one cannot be created while the Node is Slaved, Unless the Master Node Actually Creates It. You are completely ignoring that the Slaved Node will not allow further connections. At All. And since the Master Node already HAS a connection, there is no need to create a new one. So, unless you are using the Master Node's connection (that already exists), you are trying to create a new connection, which will be refused. You cannot argue that point, because that is what a Slave is supposed to do. Forward ALL Connection Attempts back to the Master. If you are not the Master, with an already Subscribed Link, you cannot form another one.

As I said. You have to look at the Subscriptiuon rules, as well as the Slaving rules. Anything else makes no sense.

This is where you lose me every time. I don't see how spoofing an AID = spoofing a node. The problem is the rules say you have to "Spoof an AID" and there's no rules for spoofing an AID. You've decided it means "spoof a node" and we've decided it means "Get the AID (because we need it for the spoof action)".

No. We're tricking the slave node into thinking our spoof is FROM that connection. It's a wireless signal. We're convincing it that our transmission is part of that connection. By spoof we mean we're trying to get it to authenticate as if it came from the right place, even though it isn't. We're using the right frequency, the right protocol, the right numbers, the secret handshake, etc. etc to make our wireless transmission appear to be an authentic wireless transmission from the master.

There is no link between a slave node and master node that automatically tells the slave node that a communication is or is not from it's master node, besides Access ID.

It's not like some magic tunnel is established between the two nodes, that nobody else can breach. It's wireless. To send a command, a master node broadcasts a message packet into the ether stamped with it's Access ID. To receive a command, a slave node listens to the ether for message packets bearing the right Access ID.

A slave node receives a command. The slave node authenticates it, and if it's got the right ID it executes the command. As far as the slave node is concerned it DID receive a command from it's master node. That is the whole point of spoofing, to pretend to BE the master node.

Now, the master node may be able to tell the slave node is being spoofed, because the slave node is likely to send out a broadcast saying, "Command received". At which point the master node wonders what is going on because it did not in fact send a command.

Really, this should be easy to prevent, because it'd be trivial to establish a non-standard authentication scheme that does not follow any established procedures. Like altering your drones to only execute a command if it receives certain encrypted keywords along with the command, keywords that get switched with every communication. Or have the slave node only accept commands at specific changing intervals of time. But there's no rules for that kinda thing.


-k

It's *not* a connection, as I told you. If you want a VPN (again, as I told you), you need an encrypted subscription. Otherwise, the *entire* purpose of spoofing is to pretend to be that original trusted source. The sole method slaving uses to accept/reject incoming communication is Access ID. There is no 'is this the magic connection?' test, because that's what Access ID is for. What makes no sense is for the book to give 3 ways to beat slaving, except the third one is the same as the second one (except worse).

suoq, in fact there are rules for spoofing an Access ID. I quoted them just now. It's not a required step for all spoofing, but it does save you time for multiple commands (and "commands" plural is specifically what the slaving-beating list mentions).

Those kinds of measures are indeed conceivable, though the FAQ deals with one such example. The basic idea is that you could spoof any relevant authentication, so it's just an escalating game of really annoying cat and mouse.