So, in SR4A, there is a fiction piece at the front of the Wireless World chapter, titled Game, Set & Match by Jen Harding and Aaron Pavao. The story was originally intended to be an short example of play, and while the turn-by-turn rules explanation intended to accompany it was dropped in favor of expanding it to become the chapter lead-in fiction, Jen posted that breakdown here.

At one point, Netcat, who has hacked herself admin level access in a drone, attempts to delete the legitimate admin level account of a security rigger who is accessing the same drone she is. The attempt fails because, to quote from the fiction, "The security riggers had programmed the drone to not accept admin account deletions." The posted rules explanations merely parrot this, except to add that "Netcat and the Rigger are at a stalemate."

Further in the thread, other Dumpshockers suggest that this is an option out of Unwired, to which I presume they are referring to the rules for "Limiting Account Privileges" from p.73. While this particular configuration option certainly is a handy way for an administrator to help lock down what can and can't be done on a node, I don't think that it can be applied to this situation. The "Limiting Account Privileges" text specifically states "A simple way to do this is to deny lower account levels the ability to do certain things" and Netcat had admin level access, which is the highest level described by the rules.

Unwired does mention account privileges in another place, on page 53, where it states that one of the Admin Access Rights is to "assign privileges to account levels"; the word lower does not appear here, so presumably even Admin Level privileges such as deleting accounts, could be edited. But as far as I can see, there is nothing stopping Netcat from using her Admin Level access to edit those privileges right back to the default of "No action or command is denied to an admin account." (p.225, SR4A)/"Admin access grants the right to do everything the user wants to on a node." (p.53, Unwired).

At the point in the hack when Netcat is trying to remove the Rigger's account from the access list, the Rigger has not detected her icon, and is unaware of exactly what actions she is taking in the drone's node. The only way he could cause a stalemate in that case is if there were some mechanism in place to alert the rigger that changes have been made to Admin Level privileges (Node script?), and were fast enough to change them back prior to having his account deleted. Doubtful at best.

Alternately, another way to get to the "stalemate" would be if the rigger removed the right to delete admin accounts, and then removed the right to "assign privileges to account levels" from Admin Level Accounts as well. However, if it is possible to lock out that specific privilege, it becomes a lot easier for everyone to Brick their opponent's nodes:
1.) Hack yourself up some Admin Level Access.
2.) Delete all possible privileges from all account levels, including the ability for another admin account to set things back.
3.) ?????
4.) Profit!

Downright insidious. Bricking a node should not be that easy. At least the Crash Node action lets the victim get the node back after reboot, and even the reformatting triggered by the Unplug Virus alerts all security and admin accounts in time to try and stop it. With an attacker doing the proverbial delete *.* on all actions on all account levels, the only recourse for the victim is to try to set up a Hidden Access Point on their own node and use that to restore the privilege list, as Hidden Access Points are not tied to any account level (but require hacking attempts for any actions). And to twist the knife in the wound, any anti-hacking measures in place in the node will still be running, fighting the restoration attempt because it's a hack.

Being able to revoke the right of Admin Access to "assign privileges" is a bit of a non-starter for me, and I don't like the idea of two users with Admin Level access racing into an edit war over the delete admin accounts flag on the privileges list, so how do you achieve the stalemate described in the fiction within the scope of the rules? Or is it, just as toturi described in the other thread, a "GM hand wave"?

heh, if one have ever dabbled in windows access privileges, one know that its fully possible to apply restrictions that are irreversible save for a full reinstall of the os.

Yeah nothink is funnier then aplaying new setting to a computer your remote accessing and a half a second later realise you smartly just dissallowed remote access completdly.

I always assumed SR was a *nix world, don't know why...

even there, one can get more complicated ACL systems. Heck, some see it as a failing of linux that it do not come with a system as fine grained as the one in windows NT by default.

Is there any reason a Node Script couldn't disallow Account Deletions? Its not tied to the legitimacy of the account, or user levels.

I think the question is: What happens if you delete an account that is already logged in? It should not be possible to delet or change accounts that are currently in use.

And another important question is: If I hack a Node. Do I create a new account or do I just get the password for an account of a already existing user?

My understanding is you get the account rights of a user/security/admin level but you don't actually get an account and password unless you spend actions creating those, log out and log back in using the new account. When you hack in, you are still a ghost in the system, but you're tied to a set of account rights.

I think the original poster's point is that Netcat has established that she is Admin, and thus the most powerful user in the system; it would seem that in the absence of a higher authority, it should be impossible to deny her control of any aspect of the system.

There are a few ways around this - first (as has been pointed out) modern network operating systems can distinguish between an account logged in locally (that is, someone with physical access) and someone connecting remotely (that is, over a network connection) and deny certain actions. If we accept that as a feature that survives to 2073, then a decker will never have the sort of ownership over a system that a corporate system administrator will. Personally, I find that appropriate.

Second, it is possible to make changes to the security settings that cannot be revoked without resetting the system to defaults - People allowed to delete administrators: none - People allowed to change that setting: none. The system simply locks out any attempts by anyone to change it, until the operating system is reinstalled or some other massive override is enacted, which cannot be done remotely.

Third, it could be a hard-coded feature of the operating system.

The problem with all of these explanations is that they are ultimately vulnerable to exploitation; a sufficiently subtle hacker should be able to trick the system into doing what she wants, even if it involves apparently impossible feats. Technomancers doubly so. SR4 tends to go back and forth between abstracting this sort of thing to a Firewall vs Exploit battle, and providing the sort of detail that computer security aficionados appreciate, resulting in neither system feeling particularly complete.

That is my thought too, you do not have a a legit account with the access ID being used. The implication being that barring you set up a backdoor to get back in you'll have to rehack the system, cause IMHO any node worth hacking will reset the user name and password to a static list kept elsewhere.

I do agree though that the Admin for the node can be severely restricted. I.E. Admins from node X also have admin provileges on node Y. The admin on Node Y may only change certain things if the are also logged into node X. The problem with RAW though is that gaining ADMIN privleges should be able to circumvent such scripts because otherwise you have not really gained admin access.

Perseonally while I like the fluff in Unwired the rules crunch was still a bit mushy. SR4A helped a bit, but I am still a little weak on the matrix rules.

I found this part about the account creation:

SR4A p.235
and
on SR4A p.236

I know that even admin accounts on win-based system can be limited in their rights. But this is not the way it is stated somewhere in the RAW. Nonetheless it should be possible to do any action with a corresponding hacking roll (even deleting admin accounts). This is what Netcat should have done. BUT this does not answere the question what is happening if I delete an account (admin or not) that is currently in use.

From an RL perspective, if my Win password expires, anything that uses Windows Authentication stops working, returning an error message. I think I can still access network drives, but maybe not. It's a bit annoying since the error messages don't indicate that my password expired or that there are authentication issues. Everything seems to be working fine, but certain services cease. From a hacker-antihacker perspective, I don't know how that would work.

basically it would be a case of "sorry, i cant do that jim".

a similar example from unix. If you delete the binary for the terminal your using, you can still keep using the terminal as its still loaded into ram. But close and try to re-open it, and you will find yourself looking at a error message about no such file found.

so i would say that a admin account being used while deleted can still complete its ongoing actions, but can not initiate new ones. And if one was to be logged out fully, would be unable to log back in.

My random opinions:

A) Before deleting an account it would likely need to be logged out. Most modern OS's try to avoid stupid self-destructive mistakes (from a legit user's perspective) and would probably notice the danger of deleting admin accounts already logged in.

B) Security riggers can probably restore the system back to a previous version very quickly (in da future, that is). I'd use the normal crash restart rules as a baseline, maybe increase the time the node is down by a small multiple.

C) Alternately, authentication on a particular node may actually be remotely hosted, requiring a second hack just to delete the legit records (think LDAP).

D) It is possible that any self-respecting security spider would have not only legit admin accounts, but backup admin accounts and probably even exploited entries into the system. They built the security, they'll know where it is weak. And finally...

E) There is nothing that says deleting an admin account does not trigger a passive alarm, dangerous IC, etc if you do not take some arbitrary pre-step like spouting a magic phrase, running a certain dummy utility (just as some examples). I see no reason that a heavily guarded system or security drone needs to be sculpted purely with ease of destruction in mind. Sure, blowing up all the accounts on someone's hoover-bot is easy but the personnel records nexus of a secure site will probably be designed for annoyance and misdirection (the spiders are on a salary, they don't mind doing busy work)

i wonder if why this is pretty much left up to the GM that the SR4 matrix rules seems so messy.

Pretty much, it creates some real consistancy issues for the living campaign.

Unwired tries to solve a lot of problems that really don't exist, the section on passkey's is more or less irrelevant if you have an actual hacker on the team, they just need to make a seperate stop at the security log. For some reason unwired specifically forbids databombing the security log, which doesn't make a whole lot of sense.

Addendum: I also love how netcat has the paladin sprite redirect attacks from Slamm-O even though that is something that Paladin sprites specifically cannot do.

I think a big problem with the matrix rule set is that most action are quite abstract. Like hacking. Nothing is said about how your exploiting attempt goes on. But on the other hand there are some concepts that are very explicit, like accessID, or user levels. Everybody, even with minor computer knowledge, has an own option what's going on with the accessID. Something like: It's the modern IP address or is more a MAC address style or a combination of both.
The problems seems to occure everytime abstract concepts try to interact with explicit ones.

For myself I think it should not be possible to make a node "unhackable" by actions like: "I have an agent that continuously alters my encryption" or the like. Such dynamic encryption should be already included in the abstract concept of encryption. The same goes for accounts and hacking. The concepts do not fit together because one is abstract and one is not.

To make the game abstract and simple I would say that it does not work. Let the matrix function in such a way so that information is always forwarded in some way or other.

I've changed the encryption rules to reflect that the encryption is a constant cycling of different encryptions and that the programs gives bonuses to teh actual hacking.

Decryption: +Dice equal to program
Encryption: -Dice equal to program

A hacker hacking against an encryption of 4 and having a decryption of 6 would have a +2 dicepool for his hacking attempt as live encryption can only be stopped if an actual physical key is required.

I kind of like the idea to skip some tests entirely. But it should not be possible to gain an advantage if you hack with a decryption program a node that is not encrypted at all. Thus I would limit the effect to negative modifiers.
Are there other matrix related test we could skip just by adding them up to modifiers? This could increase the pace of matrix actions significantly and thus improve the fun of matrix actions.

Good point, I think that was my original idea - I'll think I'll go with that.



Hmm, should be. I'll look around.

Let’s take an example of intercepting a wireless signal that is encrypted.
1.Detecting Hidden Wireless Node
-Electronic Warfare+Scan (4)
2.Decrypt Wireless Signal
-Decrypt+Response(Encryption X2)
3.Intercept Wireless Signal
-Electronic Warfare+Sniffer (3)

These are three tests just to intercept a wireless signal.

If we go by the rule that it usually take 3D6 for each success it would be difficult enough by just adding +3 treshold or giving a defending entity a +3D6 or attacker a -3D6 modifier.

But one should in that case limit amount of rerolls to skill level or suchlike.

The problem is that the hacking rules can't make up their mind how abstract they want to be.

Having a long list of possible things on a system that any given account is allowed to access is a rather dull read, and requires lots of (GM) overhead. Bad.

Not having fine-grained description means you can't use precise control tactics to make hacking more realistic. Bad?



The way I see it, any given account, like "Joe", is roughly equal to a basic account level like Guest, User, Security or Admin. If you take away a lot of permissions, Joe becomes a lower class of account, not some kind of halfway-thingy. The four basic account levels are abstract, and work the same on any system. Whether the "Root" account on System X is de facto more of a Security or an Admin account depends on how "Root" has been configured.

This then allows you to more simply group all the matrix actions by permission level. Which leads to sanity, hopefully.

don't forget you can have the system set up on say a drone where you have to have a physical connection to alter some of the accounts

Where accessing it gets you a fake admin account, that is actually one of the admin accounts (ie you forge the credentials to get Bob's account on drone B, while George logs into the drone to see what's going on because Bob is on vacation if you trigger an alert)

I've run into programs which have an account level above admin.

For example, KDX, creates a Master account the first time a new Server program is accessed. That Master account can never be deleted without deleting the Server program, and it is not possible to limit its access options.

Pretty easy explanation as to why you can't shut a rigger out of his own machine. A corp guy, sure, but anyone who has the independence to run their own tools should have a Master account.

That just makes it easier to screw things up.

...says someone who did a chmod on his home folder and couldn't even log on as an admin.

"The goal of hacking into a node is to create your own account on the target node"

Yeah, the problem is that the current system is a mix of abstracted and detailed rules. The problem with detailed rules is that people keep finding loopholes in the system, requiring more and more rules. The problem with abstract rules is that they are (by definition) general and ambiguous, and so don't provide a lot of guidance when specific issues come up.

Personally, I'd like a more abstract system which just lets the GM adjudicate the individual situations as they come up. The "simulationists" and people that play with a "players vs. GM" mentality really hate that, though.

If this ever happened to one of my networks we would reboot the system and load a secondary OS off USB. Eventually everyone would have to reset their password and we would have to re-encrypt. Pain and time consuming but it is what it is. Back in the mid 90s I had a firewall that was constantly being attacked so we just had a bunch of floppies with different settings/passwords on them that we would reboot and load a new floppy each week. After a few months the attacks trickled off into normal.

A powerful OS will allow you to shoot yourself in the foot. It gives you complete control over your system, but you may occasionally find that you need to reinstall.