I would have some questions about tracing and redirecting traces in the matrix.

First, it is written that you can trace an icon or a subscription back to its originating node. But is it possible to find someone based on his Access ID only, as long as he is online? If not, why not only log off to avoid the trace (granted, if you are jammed by a black IC, it's not that easy)? In the second Shadowrun Mission of the Denver Campaign, it is possible to track the location of an RFID tag based on its emitting frequency with a Data Search. Maybe something similar can be done to find a hacker based on his Access ID?

Second, about the Redirect Trace action: it seems very unlikely that a hacker will detect that a trace is running on him. This is done by making an Analyze Icon action (SR4A p.228): does that mean you have to actively analyze an icon in order to realize that it is tracing you? Is there no other way? Or can you analyze your own icon to see that you are being traced? The Analyze program can be set to run in the background, but only to detect the presence of other icons in a node.

I swear it seems like this question comes up every month or so.

Prepare for a long debate on what you can and can't trace and such.

One thing I can say for sure, is that logging off is the main way to avoid a trace, and the main way to stop someone doing that before you've finished the trace is to jam them with IC.

I don't think you should be able to trace someone based on their Access ID if only because it means that anyone can trace anyone anytime. Someone's commlink number is basically their phone number, and is almost certainly publicly available. Combine that with the fact that you can easily trace someone as long as their commlink is online (which is 24/7 by all accounts), and you create stupid easy levels of stalking and tracking people.

I believe you have to analyze your own icon to see that someone has stuck a trace onto it. Not a bad idea to have an agent running along with you constantly scanning you for a trace so if you get tagged by one you can just redirect it, or the agent can redirect it for you.

I just read this, Unwired p.100:

I just want to point out with that statement there, that it's saying "trace" not "Trace Action". Two different things.

Though, that said, I'm not sure if they did in fact mean a trace action can be used or if it's just an ID data trail.

I am AWB but just logging off is not enough to prevent a trace as anyone with access to the logs can still run a trace on you. The old rule still applies. "Never hack from home, never hack from any place you are attached to. It Is also a good idea to move after you hack."

The mesh network topology of the matrix 2.0 plus the explicitly stated fact that the data stream itself does not contain access IDs, makes trace an interesting problem.

In a non-mesh topology the access ID would be tied to a geographically stationary piece of hardware at either the endpoint or the last hop. Find that location, and you have the physical address you need.
But with a wireless mesh and no clear indication of path IDs, you have to actually trace the path back hop by hop until you get to the last hop, then have that device report back the physical location you need. One method would involve viral-like self executing code, send a packet to the first hop you know and have it report back the next hop, and repeat until you have the last hop.


Tracing an ID you know but doesn't have an active data connection you can perceive should be possible, but at a ridiculous amount of time. You're basically walking around downtown LA asking "Hey, have you seen Bob?" and hoping the question eventually reaches someone who sees him.

Are you sure about that? Isn't the Access ID required for routing information accross the matrix to the right destination? It is also written that more than one connection to a node with the same Access ID is not permitted. Or that you only need one hit on an Analyze Icon action to get its Access ID. I wonder how all that is possible if the information about your Access ID never makes it to the node you are accessing.

This quote from Unwired (p.65) is quite interesting:


EDIT: another quote, p.104:

The icon of the hacker's presence contains their access ID, which is why you can get it when analyzing their icon (and why the access logs will contain it). But the data streams do not for some reason, which is why you have to analyze a drone rigger's icon to get their ID for spoofing instead of just pulling it from the intercepted data packets.


Your quote from page 65 unwired seems to say that not only is the return datapath encoded into the packets, but that path is persistent across a reasonably long timeframe.
For that to happen without just encoding the access IDs of the hops directly into the packet (making a trace laughably easy), packets probably contain a hash of the path that works as an identifier for a unique path. When a node on a route reads the incomming packet, the packets tells it "please send me along path 7reygkuy765885ukjy7", which the node just knows the next hop is over to node carl.
Say nodes A, B, C, D, and E. A is a hacker, E is the paydata node, b, c, and d are the nodes making the path between A and E. A accesses E, creating path ae1 through B, C, and D. A knows the path hash and access IDs for both ends, as does E. B knows that hash ae1 means pass data between neighbors A and C without knowing A is an endpoint and C isn't an endpoint. For security the hash's would only be valid for data comming from either node locally associated with the hash. So if E sent a packet to B telling it to route along ae1, B would ignore it because it only knows ae1 as associated with A and C. If security hacker F jumped on E and tried tracing A by sending the self executing code packet I stated earlier, D would ignore it because it's not comming from E, so F has to spoof the packet to D to claim it came from E, which A's analyze program has a chance of catching and alerting him to (spotting the trace).




Of course it could all be quantum routing, and works on the idea that if you model the interaction of cheese with a random falling object you can extract the address of the closest italian/thai/australian fusion restaurant to the target node and can route via simulated drunken butterfly left wing flaps from there...

those hashes may well be the way, as i think a real life problem with mesh networks are the routing table sizes. They grab very large very fast, iirc.

A Trace can be run on Access ID alone, this is clearly stated. If the device tied to that Access ID is no longer online, the Trace will report the last node that the device was online. Your Commcode is not your Access ID. Giving someone your comm number is not allowing them to trace you. There is a deliberate break between the two so that a person can switch interface devices (eg. get a new commlink) and still have the same Commcode - equivalent to their phone number and email address. Tracing someone via their Commcode alone would involve first hacking into the MSP that handles the routing of their calls and finding their Access ID there.

To determine if a Trace is running against you, you must Analyze the icon that is performing the Trace, not your icon. All of this is why changing your Access ID is so simple, and should be done all the time by a security conscious shadowrunner.

Who said anything about a commcode?

I was addressing this:


Yes, someone's "commlink number" is their phone number, and probably is publicly available, but it is not their Access ID and you cannot trace someone by Commcode alone.

For the "techies" out there: a commcode is a combined email address and phone number, and the Access ID is the MAC Address of your commlink.

given the direction google seems to be heading with gmail, gtalk and google voice, i would say that they would be one of the first commcode providers. And if skype got some kind of email service going, they would have pretty much the same.

and i pondered the use of a hash to id a data route, and it makes a fair bit of sense.

when things are initially set up, your comlink fires of a generic "connect me to access id xyz" with a attached hash. Then every other comlink in range repeats that, unless they have already seen the hash before. With enough repeats, this will hit the comlink with the requested access id. Then that comlink replies, with the same hash attached, saying "hi". While this is going on, if the initial connection request should come in from a alternate route at any point in the chain, the routing comlink would keep the source on list as a potential alternate route should the primary route fail.

Could you please tell me where this is clearly stated? I have read that you can trace someone from an icon, a subscription or an access log. But nothing says that the Access ID is used for that in any of those cases. Moreover, it is written that a successful trace reveals a user's Access ID, which is quite confusing if it is used to initiate the trace in the first place.

Or just have a spoof chip installed in your commlink to change your ID as often as you feel like it. Probably the best 500 you'll ever spend in this regard.



Any device. So your commlink, your gun, or whatever that is dependent on an access ID can have a spoof chip installed to scramble the ID whenever you want.

Bio-monitor linked to your spoof chip. If black ice knocks your out it spoofs your access ID automatically, instantly cutting the connection.

Possibly killing you with the dumpshock, although the question would be whether or not simply changing the access ID offlines you. Perhaps a better option might be an IC on your home comlink that unloads on your icon with a regular matrix attack if it notices you pass out thereby disconnecting you or one that just shuts off your comlink which would certainly disconnect you.

You're down anyway, resisting dumpshock is generally a better prospect than letting the IC have free reign over your link. Especially if it leisurely loads a trace and reports your physical location to on site security.
You've got a better chance of getting first aid and a heal spell if there aren't a dozen security professionals breathing down your team's necks.

If changing the access ID while you're online doesn't log you off, just set the spoof chip to cycle it as soon as the bio-monitor catches that you're unconscious, though this then makes the spoof chip a much, much cheaper and way more reliable alternative to the spoof software. Probably would get errated as saying you can't use a spoof chip to change your access ID while you're actually in the middle of using it (like in a great hack).

Could, though, set something else to get you logged off once you've been knocked out by a blackhammer or such, and as soon as you're logged off the spoof chip cycles your ID. Just hide out at a coffin motel when you do a hack, and now you've got potentially dozens of other people who could also be the hacker if things turn south.

This is my take on it as a GM take it with a grain of salt. I would conclude that changing your access ID does not log you off automatically. The system would treat it as if you access path had changed. Now you could build a chip or modify your comlink to sever the connection when your bio signs flatline and I'd certainly allow that sort of solution. But as I have mentioned above they can still trace you to where you last connected via the access logs.

Unwired page 99, Spoofing a datatrail online: States that not only can you spoof and change your access ID online, but this severs all your connections quickly.


Access IDs are your commlink's unique identifier, all actions you take online are tied to it. If you change your access ID, you suddenly become a whole different icon in the eyes of your subscribed nodes, an icon without any registered login events to give you any permissions.

It's time for, Tossed Together Explanation Theater!
Starring Mr Hacker, Mr Nexus, and Mr Security!
Act 1, Scene 1:
Hacker commlink, access ID "carl": "Hello mr paydata nexus, I'm carl, I'd like to login as administrator account butterface, password purple purple squiggle fuzzy-triangle."
Paydata nexus: "Why hello there carl. Password accepted, you now have access to account butterface."
Carl: "Yay. Ok, lets find some files, shall we?"
Paydata: "Certainly."
Security hacker "guido67": "Hrm, odd, butterface is on vacation and should be sipping margaritas right now, not looking at files. I better make sure this "carl" node is realy in the carribean." *starts trace*
Carl: "Oh no, he is tracing me! I can't let him find my location, my low orbit satlink will rat me out here in the barrens! I better spoof my access ID, so he can't trace me." *spoof!*
Bob, formerly known as carl: "Haha, now that I am access ID bob, that security hacker will get a dead end when he asks the satellite to triangulate carl's position."
Guido67: "Hrm, carl is gone and the trace can't find hide nor hair of him."
Bob: "Haha, I'm safe. Ok now mr paydata, send me that file with the secret blueprints of next season's designer chihuahua booties. I can already taste the job's payoff."
Paydata: "No."
Bob: "What?"
Paydata: "No. You have no permissions for that file, how do you even know where it is?"
Bob: "But you gave me admin permissions earlier, under the account butterface!"
Paydata: "No I didn't, I didn't even know you existed until 3 packets ago. You're name is bob and I don't know anyone called bob, especially not tied to admin account butterface. Infact that account is already in use by someone with a different access ID that isn't yours, so even if you tried logging in I won't let you because butterface is already in use."
Bob: "... Please?"
Paydata: "No."
Bob: "Aww, c'mon, you know me, I'm bob, I logged in with butterface not 3 seconds ago. You remember, bob?"
Paydata: "No, you are bob, and bob is not butterface, carl is butterface, and you are definitely no carl. Now stop bothering me while I alert guido67 of your attempts to access files you have no permissions for."

*curtain draw* Fin.

Bonus points for the fun to read example.

Even if Carl changes his Access ID, he can still be traced based on the access logs to the last known location where he still had that Access ID. So I don't think Carl is safe by simply changing his Access ID to Bob. Moreover, this action would automatically kick him out of the Paydata nexus. He could, however, still log on with the account butterface.

About tracing someone based on his Access ID alone, if this was indeed possible, then AI characters would be really screwed:

Location of last hop, not last known location. Mr hacker was atleast smart enough to use a satlink, so the last hop is kilometers above and covers a huge geographic area. If he were to have done it from downtown megamall foodcourt, his last hop would probably end up being 10m away at the McStufferking's Taco Shack.
And yes, it did kick him out of the paydata nexus. That part about the nexus telling him no?

I understand what you mean and I agree with you on a technical level. However, the idea of satellite links in Shadowrun is that you trade in Response for non-traceability. Low-earth orbit satellites don't suffer the Response loss, but they don't make you non-traceable either:

So, if you use standard rules for Track Tests based on information in the access log:

An that location would be determined with the following precision:

I can see why GMs would rule out that the trace stops at the satellite when the user is no more online though, even for LOE satellites. In that case however, you'll end up with every hacker using LOE satellites uplinks (only 500 nuyen) for this particular advantage they procure, without any drawback.


Sorry, misunderstanding on my part. I had the impression the hacker was still trying to do things on the node, without being linked to any account.

For added fun and games, keep in mind that Anarchist groups, hacker collectives etc. maintain pirate matrix subscriptions Runners can buy, that, while it in theory will lead the trace to the matrix service providers, can very likely lead tracking traces or hackers directly into a chunk of ICE, counter-agents and other nastiness.

Actually, I don't think he could log back on.



If you hacked in with a particular access ID and then spoof your access ID to a new one, that new ID does not have any authorization unless you had set it up ahead of time.

The confusion here is easy to understand. When exploiting, your basically setting up a fake account to your current access ID. Change the ID and you have to exploit again to set up authorization/authentication for the new ID.

Whats often forgotten is that if you got the info by social networking then you have to first spoof your ID to an authorized ID, even if you have the password.

Interesting. So when using a public terminal, you can't log on to any node requiring an account. The same happens when you buy a new commlink. And how could you share a passcode with others, as described below (taken from the official FAQ):

I know, seems kinda silly right? Maybe I can explain a bit better.

I see like this: Some accounts allow ANY access ID but have multiple authentications.

Example 1 Low Security:
Dumpshock allows people to have accounts. You have to know both your name and your passcode to log in. Well, your "name" here isn't your access ID. The name is something you made up. Your access ID is more like your MAC address. Dumpshock allows any MAC address to log into an account with two forms of authentication, a name and passcode. This is fine for any node that sees public use, etc.

Example 2, High Security:
Lets say the Dumpshock admins are super crazy about not letting anyone but admins get administrator access. They not only require a two forms of authorization (name and passcode), but require that the authorization only comes from a MAC address specified in some secret security file somewhere. Now, you could have 1 account tied to several MACs if an admin liked to use several different computers if you liked, but it would still be required to come from a registered access ID.

This is the jist of it as I see it.

As for sharing, I don't see why they can't just tell you what their access ID was as well as the passcode, or passcodes.

*edited for IP -> MAC n_n

I'm not sure the IP address is a good analogy to the access ID, because IP addresses can change dynamically.

What this means in Shadowrun is that your account is tied to your commlink (or maybe several), and if you want to log on from another node, you can't. Unless you spoof your ID of course, but that's not something a standard user is supposed to do. I guess it's ok since nearly everybody has his own commlink. But public terminals then become quite useless. Unless, as you suggest, it's a mechanism only used for very secure nodes.

i think the accepted dumpshock analogy is the MAC address found on all network cards, wifi radios and such. This address, while burned to the chip of said equipment, can be overridden in software (tho the standard says that this should be noted by a 1 in a part of the address thats 0 for all hardware related addresses).

http://en.wikipedia.org/wiki/MAC_address

One more question:

It is written that you can trace an icon back to its originating node or a subscription back to its other end. How does that second case work exactly? Do I have to intercept the trafic between the two nodes first? Analyze the node on one end of the subscription? Log on to that node? Or simply have that node in mutual signal range?

The story preceding the chapter about the Matrix in SR4A describes how Slamm-O! causes a security rigger to check on a drone so that he can trace the communication from the drone back to the rigger. Is it really necessary to wait until the rigger accesses the drone to do that, or is the subscription linking him to the drone enough?

Actually slamm-o! caused the drone to question the rigger, the rigger hadn't checked on the drone at that point. What he did was cause the drone to send a query to the rigger for more instructions (which, like text messages, don't have to be answered immediately), and followed that datatrail.