Help - Search - Members - Calendar
Full Version: Security tallies and multiple deckers
Dumpshock Forums > Discussion > Shadowrun
Dashifen
I was concidering something today: what happens when you have more than one decker in the same host generating seperate security tallies. This would also apply to agents, otaku, sprites, etc. Basically, any time one host has more than one illegitimate icon with a security tally.

Here's an example of what I'm wondering:

ESD is a decker with a current tally of 10. Ibem is a second decker with a current tally of 4. ESD triggered a Killer IC resposne at step 9 destroys the IC and moves on with life. Ibem, however, eventually gets to trigger step 9 where the system would want to hit her with the Killer IC. However, ESD already whacked it. Can the system "re-spawn" the Killer IC on the second decker? If so, how long does it take before the re-spawn takes place? Or, since it's a computer and IC is nothing more than a program would the host fork another process and blast Ibem right away when she hits trigger step 9.

Honestly, this never came up in a game for me yet because I've only ever had one decker at a time, but it seems like an interesting problem.
ShadowPhoenix
simply put I believe it would work like a decker's program that has crashed, all the system needs to do is swap the program out of memory and swap a new copy in. just like todays computers, tomorrows can run 2 copies of the same program at once, or rerun an application that's crashed.
Dashifen
My feelings as well. The exceptions would have to be a change in alert status and shutdown. If ESD would have triggered passive alert on step 10, the host itself is on passive alert and therefore Ibem would have to deal with the raised ACIFS subsystem ratings, etc. And, if the system shuts down, then all the deckers are hosed, anyway. Course, if they lasted until host shutdown they either did something right or something very, very wrong wink.gif
Kagetenshi
Hmm... I always read it that the security tally was more a measure of how alert the host was in general, rather than an indication of how "on to" a given decker a host was. Thus, I'd've added their tallies at any given time together to get the "true" tally, but only launched any given IC once.

~J
spotlite
Its a very good question.

I beleive when you crash an IC it actually goes dormant, rather than being destroyed. However, it sends out an alert which is why you have to suppress it. That would mean security tallies could be for seperate deckers. Certain things like passive alert status cover the entire system, so even if you're on trigger step 4, if someone's already alerted the system all the usual modifiers will apply. You would still trigger IC at the appropriate step.

If they don't go dormant, and are actually erased from Active memory which is what sends out the alert, then I think it would still behave the same way - its gone from active memory, and will be loaded up fresh the next time someone hits that trigger step.

If you destroy the IC protecting a specific file or subsystem though (e.g. a scramble 4/Blaster 8 combo specifically assigned to encrypt and protect a Files subsystem), then I would rule that once its gone its gone until the system is rebooted or a sysop notices, raises an alert and reloads it. It can still be suppressed as normal however, so as soon as the offending decker logs off (unless they gracefully log off, which erases the security tally) the fact that this specific IC - which is not depended on trigger steps - has been crashed will be known to the security decker, who will likely put the system on active alert and come for a look-see, which is very bad news for any deckers left in system.

hth
Bearclaw
I'm thinking that the security tally should be cumulative. It's an indicator of the system in general feeling "violated". More deckers doing it just makes the tally go up faster. So, even though you are a ghost, and add only 4 to your tally, the other guy has already added 12, so your 4th one just pushed the number to 16 and triggered the Sparky 12.
Dashifen
Adds an interesting possibility for a "tarred" option on attack utilities that can not only knock the IC out of active memory on the host but also the storage memory (kind of like killing a process running in RAM but also deleting the program from the hard disk). Such an option should significantly increase the programming time and perhaps even require more dice or detection factor to supress due to the damage done to storage memory.

Example:
Instructor is a decking "teacher" leading RealNewbie into a host. Instructor has a Tarred Attack 8D program that he uses to bash IC so that it doesn't hut RealNewbie. Instructor gets hit with a Killer (6) IC but blasts it with his Tarred Attack 8D program. So, the Killer IC that he faced is now dead, but the viral code of the Tarred Attack also infects the storage memory of the host erasing the Killer (6) IC from the host entirely. Instructor them spends 2 of his Hacking Pool to supress the alert from this action.

Perhaps, you could spend 2 from your detection factor, 2 from your hacking pool, or 1 from each to supress -- makes it more of a strategic choice by the decker to save detection factor and/or hacking pool. And, a tarred utility with the adaptive option as well can be set to either use or not use the tar option. Or maybe you can turn it off without needing another option ... shrugs.
Dashifen
QUOTE (Bearclaw @ Feb 17 2004, 12:59 PM)
I'm thinking that the security tally should be cumulative.  It's an indicator of the system in general feeling "violated".  More deckers doing it just makes the tally go up faster.  So, even though you are a ghost, and add only 4 to your tally, the other guy has already added 12, so your 4th one just pushed the number to 16 and triggered the Sparky 12.


I agree with you for the alerts. They are the host feeling "violated." But, the IC responses are tiggered by the security sheaf based on an icon's security tally.

So, if different icons have different tallies they could be facing the "same" IC at different times. But, if one icon triggers an alert then that host is now "violated" and all illegitimate icons suffer the consequences.

Food for thought, I suppose. Not sure it's worth the complexity.
Kagetenshi
I see it more that IC isn't running most of the time, just like antiviral programs, while they may scan frequently, tend not to be set to scan constantly. Once the IC is activated in response to a general feeling of violation it goes after either the most violating target it can see or the target specified by the host, depending on how the host is programmed. Thus, while IC triggered at step 16 would be triggered by a 12-n00b and a 4-ghost, odds are that the IC would go for the n00b unless the ghost got unlucky with specially-programmed stuff.

~J
mfb
by the rules, security tally is counted seperately, and each decker scares up seperate copies of any IC they activate (Matrix p110). the only effects that are shared by multiple deckers are alerts, IC constructs, and (of course) system shutdown.

the explanation for this lies in the idea that security tally represents system glitches being traced back to specific processes. a skilled decker will be able to slip new processes into the queue without leaving a link to the old process; the system will not connect any glitches generated by the new process to the old process. if the decker is unsuccessful, the new process will show as having inherited the old process's functions. eventually, enough current and retired processes will be linked by enough inheritances that the system will recognize the glitches as an intrusion, and act to stop it.

believe me, you don't want to stack sec tallies for multiple deckers, mainly because it increases the difficulty of decking exponentially.
Bearclaw
Which rules? Do you have a reference?
mfb
yes. Matrix, page 110.
Dashifen
QUOTE (mfb)
yes. Matrix, page 110.

notworthy.gif mfb notworthy.gif
Bearclaw
QUOTE (mfb)
yes. Matrix, page 110.

Thanks, I'll read it when I get home biggrin.gif
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