Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Ulrich Haupt <sandman@****.UNI-OLDENBURG.DE>
Subject: one or two VR2 questions (not short)
Date: Tue, 26 Jan 1999 13:28:53 +0100
If you have a system like the following one:

!-----! !------! !------! !----! !-----!
!LTG A!----!Host A!----!Host B!----!PLTG!---!LTG B!
!-----! !------! !------! !----! !-----!
!
!
!------!
!Host C!
!------!

The decker starts his run from a matrix connection with
loggin onto the LTG A and raises his security tally (ST)
from 0 to 2. He than enters Host A.

BTB the ST would be take by a PLTG (e.g. if the decker had
come from LTG B to the PLTG his ST wouldbe 2) .
Is the actual ST of the decker in Host A 2 or 0?

Does the decker automatically see both hosts (B&C) without
making any system tests?

The decker wants to know the main purposes of the host (e.g.
salesroom and staff management). What tests would be
appropriate? Or is it obvious?

There are of course some IC in this host - proactive and
reactive. Is it possible to locate any IC BEFORE the ST
rises to the level neccessary ("you see a dog sitting under
a bush and (roll dice) it seems to be a trace IC) or do the
IC appear just in the moment the ST triggers the step?

Further on:
The decker acumulates a ST of 11 and has to suppress two IC.
Therefore his detection value is lowered by two. For
simplicity both are simple white IC. The decker now leaves
host A and enters Host C.

What is his ST in this host C? O(startup) or 2(LTG) or
11(Host A)?
I suppose 0 is standard.

What happens to the suppressed IC on Host A?
a) The decker needs to keep them suppressed?
b) If the decker releases them they follow him (if slowed)
and/or his ST raises from 11 to (IC1+IC2+11)?
c) Since the decker is no longer on Host A they vanish. They
reappear if the decker reenters Host A with his ST not
lowered under the trigger step necessary for the IC activation.

IF the deckers ST on Host C is high enough to activate
several IC do they all appear and attack(or whatever they
do) ? (Not a funny thing for the decker.)



On Host C the ST raises to 16!
The decker leaves Host C back to Host A.
He has spend only 30 seconds on Host C so there is no system reset!

What's his ST?
Is is 11 (last value which I think it is) or 16 or 0(new
start, seems senseless) or 2(LTG)?

What has happened to the IC he was supressing?
If he has a ST of 11 and both white IC reappear what are
their condition monitors? Do they start with no damage or is
all the same as the decker left the Host?
If they stayed the same - when do they reset? I think they
do it the moment the ST resets below the trigger step of the
IC, after XD6 minutes.


Now the decker leaves Host A and enters host B and runs for
the PLTG.
* hey I didn't need Host B in my run *

What's his ST on the PLTG?
Is it 0? (That's what I read by the letters)
Or is it 2 from LTG A?

Is it 2 if LTG A and LTG B are the same?

What's its value if LTG A & B ly within the same RTG or are
connected to different RTG's?



I know I have asked some questions several times so I thank
you for reading my confusing trip and if you take some time
to answer som of my questions you can help me very much?


Sandman
Message no. 2
From: Starjammer <starjammer@**********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Tue, 26 Jan 1999 12:39:53 -0500
At 01:28 PM 1/26/99 +0100, Ulrich Haupt wrote:
>If you have a system like the following one:
>
>!-----! !------! !------! !----! !-----!
>!LTG A!----!Host A!----!Host B!----!PLTG!---!LTG B!
>!-----! !------! !------! !----! !-----!
> !
> !
> !------!
> !Host C!
> !------!

Bearing in mind that I'm not the hottest decker in the drawer, I'll try.

>The decker starts his run from a matrix connection with
>loggin onto the LTG A and raises his security tally (ST)
>from 0 to 2. He than enters Host A.
>
>BTB the ST would be take by a PLTG (e.g. if the decker had
>come from LTG B to the PLTG his ST wouldbe 2) .
>Is the actual ST of the decker in Host A 2 or 0?

Zero. The security tally is based on the decker's activities on the host.
I wasn't aware of PLTGs carrying over the tally from another LTG, but I
would assume that to be a specific property of PLTGs.

>Does the decker automatically see both hosts (B&C) without
>making any system tests?

Probably not, unless the system architecture was specifically designed to
allow them to do so, and I don't see a reason why it would be. Based on
what I can find, I think an Analyze Subsystem op would be the way to locate
the SANs to those systems.

>The decker wants to know the main purposes of the host (e.g.
>salesroom and staff management). What tests would be
>appropriate? Or is it obvious?

Analyze Host.

>There are of course some IC in this host - proactive and
>reactive. Is it possible to locate any IC BEFORE the ST
>rises to the level neccessary ("you see a dog sitting under
>a bush and (roll dice) it seems to be a trace IC) or do the
>IC appear just in the moment the ST triggers the step?

The Locate IC op doesn't specify whether it works on inactive IC, but I'd
give the decker the benefit of the doubt and say that it'd work for him.

>Further on:
>The decker acumulates a ST of 11 and has to suppress two IC.
>Therefore his detection value is lowered by two. For
>simplicity both are simple white IC. The decker now leaves
>host A and enters Host C.
>
>What is his ST in this host C? O(startup) or 2(LTG) or
>11(Host A)?
>I suppose 0 is standard.

Zero.

>What happens to the suppressed IC on Host A?
>a) The decker needs to keep them suppressed?
>b) If the decker releases them they follow him (if slowed)
>and/or his ST raises from 11 to (IC1+IC2+11)?
>c) Since the decker is no longer on Host A they vanish. They
>reappear if the decker reenters Host A with his ST not
>lowered under the trigger step necessary for the IC activation.

AFAIK, you can only suppress IC on a system that you're actually on. So
when the decker leaves the system, those programs will become unsuppressed
and the tally on that system will rise.

Since you have to crash IC programs before suppressing them (except for
Trace IC), the IC shouldn't be in a position to follow. Suppressed Trace
IC would probably be freed to complete the location cycle.

>IF the deckers ST on Host C is high enough to activate
>several IC do they all appear and attack(or whatever they
>do) ? (Not a funny thing for the decker.)

Yes, passing multiple trigger steps on the tally activates all of those
steps at the same time.

>On Host C the ST raises to 16!
>The decker leaves Host C back to Host A.
>He has spend only 30 seconds on Host C so there is no system reset!
>
>What's his ST?
>Is is 11 (last value which I think it is) or 16 or 0(new
>start, seems senseless) or 2(LTG)?

His tally should now be what it was when he left the system, with the
addition of the IC that became unsuppressed when he left the system.

>What has happened to the IC he was supressing?
>If he has a ST of 11 and both white IC reappear what are
>their condition monitors? Do they start with no damage or is
>all the same as the decker left the Host?

The IC he crashed would still be crashed, but the suppression would be gone
and the tally would reflect this.

>If they stayed the same - when do they reset? I think they
>do it the moment the ST resets below the trigger step of the
>IC, after XD6 minutes.

I think that's correct.

>Now the decker leaves Host A and enters host B and runs for
>the PLTG.
>* hey I didn't need Host B in my run *
>
>What's his ST on the PLTG?
>Is it 0? (That's what I read by the letters)
>Or is it 2 from LTG A?

It should be zero.

>Is it 2 if LTG A and LTG B are the same?

Yes, it should be. The decker's datatrail routes back through the LTG even
though not directly, and he's still subject to the effects of that tally.

>What's its value if LTG A & B ly within the same RTG or are
>connected to different RTG's?

Should be zero.



--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 3
From: Starjammer <starjammer@**********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Tue, 26 Jan 1999 13:02:15 -0500
At 12:39 PM 1/26/99 -0500, Starjammer wrote:
>At 01:28 PM 1/26/99 +0100, Ulrich Haupt wrote:
>
>>Now the decker leaves Host A and enters host B and runs for
>>the PLTG.
>>* hey I didn't need Host B in my run *
>>
>>What's his ST on the PLTG?
>>Is it 0? (That's what I read by the letters)
>>Or is it 2 from LTG A?
>
>It should be zero.
>
>>Is it 2 if LTG A and LTG B are the same?
>
>Yes, it should be. The decker's datatrail routes back through the LTG even
>though not directly, and he's still subject to the effects of that tally.
>
>>What's its value if LTG A & B ly within the same RTG or are
>>connected to different RTG's?
>
>Should be zero.

Well, I knew I'd probably make at least one mistake, and I did. I went
back and reread the section on Grid Security Tallies. Security Tallies
carry over between all the LTGs on an RTG and the RTG itself, and also to
any PLTG connected to a grid on that RTG.

So as long as LTGs A and B are on the same RTG, and the PLTG is connected
to that grid, the ST from the LTG carries over to all of them.

My mistake, sorry.


--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 4
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 01:03:56 -0600
:If you have a system like the following one:
:
:!-----! !------! !------! !----! !-----!
:!LTG A!----!Host A!----!Host B!----!PLTG!---!LTG B!
:!-----! !------! !------! !----! !-----!
: !
: !
: !------!
: !Host C!
: !------!
:
:The decker starts his run from a matrix connection with
:loggin onto the LTG A and raises his security tally (ST)
:from 0 to 2. He than enters Host A.

Since he weant from a LTG to a provate host, his tally in the new host
is 0.

:Does the decker automatically see both hosts (B&C) without
:making any system tests?
:
:The decker wants to know the main purposes of the host (e.g.
:salesroom and staff management). What tests would be
:appropriate? Or is it obvious?

By no means is that imediately obvious- it is sometimes intentionally
concealed(the sample Yakuza host has this setup). I don't think anlize
host would normally reval WHAT was being done, either- it reveals how the
host functions, not what the users do with it.
To figure out what it does, you have to poke around- read some files,
analize some slaves, etc. But in most cases, the aperance of the system
will relate to its function- and you also geneally know where you are
going!


:There are of course some IC in this host - proactive and
:reactive. Is it possible to locate any IC BEFORE the ST
:rises to the level neccessary ("you see a dog sitting under
:a bush and (roll dice) it seems to be a trace IC) or do the
:IC appear just in the moment the ST triggers the step?

I'd say yes, loacte IC would do that. "analize IC", pg 111, says you
can analyze any ice you have located using this function OR been attacked
by, so you must be able to locate it before you are attacked, using
"locate IC".

:
:Further on:
:The decker acumulates a ST of 11 and has to suppress two IC.
:Therefore his detection value is lowered by two. For
:simplicity both are simple white IC. The decker now leaves
:host A and enters Host C.
:
:What is his ST in this host C? O(startup) or 2(LTG) or
:11(Host A)?
:I suppose 0 is standard.

Yes, I would think so- it would be 0, unless something really hinky
was up.


:What happens to the suppressed IC on Host A?

Who really cares? He's not on that host any more! :)

:a) The decker needs to keep them suppressed?

I suppose so. It doesn't say anywhre that you get your detection
factor back, so I'd say they remain supressed.

:b) If the decker releases them they follow him (if slowed)
:and/or his ST raises from 11 to (IC1+IC2+11)?

No, normal IC does not travel from host to host in VR2. In a way, it
is part of the host, just like the security ratings.

:c) Since the decker is no longer on Host A they vanish. They
:reappear if the decker reenters Host A with his ST not
:lowered under the trigger step necessary for the IC activation.

That seems likely, but I think they would reamin supressed (and the
deckers detection factor reduced). I vaugley remebr a story where
something similar happened- the program was hung, the decker goes in,
works, and then goes back by it on the way out. I believe the decker can
voluntarily UN-suppress IC at any time.


:IF the deckers ST on Host C is high enough to activate
:several IC do they all appear and attack(or whatever they
:do) ? (Not a funny thing for the decker.)

Yes. But it won't usually jump up all at once like that.


:On Host C the ST raises to 16!
:The decker leaves Host C back to Host A.
:He has spend only 30 seconds on Host C so there is no system reset!
:
:What's his ST?
:Is is 11 (last value which I think it is) or 16 or 0(new
:start, seems senseless) or 2(LTG)?

11. The section on host reset makes this claer, in the last
paragraph.

:What has happened to the IC he was supressing?

IMO, it stays supressed, if the decker continues to (voluntarily) suffer
the reduced detection facor.

:If he has a ST of 11 and both white IC reappear what are
:their condition monitors? Do they start with no damage or is
:all the same as the decker left the Host?

Good question. It would seem the re-apear fresh, but (given what I
said above), that makes letting the ST drop something of a DIS-advantage.
I'd say, until the decker jacks out or is dumped, the IC remains affected,
at least as far as that decker is concerned.

:If they stayed the same - when do they reset? I think they
:do it the moment the ST resets below the trigger step of the
:IC, after XD6 minutes.


P 65 VR2 gives 2 sets of reset times- one for the ST to drop to zero,
if no alert is triggered (2-3d6 minutes, color dependant), and another for
it to go down by 1d6 (5-15 minutes) if an alert was triggered.
IC would not, I think, be able to "reboot" against a decker who did
not jack out.


:Now the decker leaves Host A and enters host B and runs for
:the PLTG.
:* hey I didn't need Host B in my run *
:
:What's his ST on the PLTG?
:Is it 0? (That's what I read by the letters)
:Or is it 2 from LTG A?

Depends. In your digram, PLTG and LTGA don't have a connection, so the ST
is not handed off. Besides, a regualr host almost never "hands off" a ST,
especially not to a 'TG host.


:Is it 2 if LTG A and LTG B are the same?

Yes.

:What's its value if LTG A & B ly within the same RTG or are
:connected to different RTG's?
:

2. Basically, ST's follow you within a RTG, to and inside a PLTG.
Somebody else answered this nicely.


:I know I have asked some questions several times so I thank
:you for reading my confusing trip and if you take some time
:to answer som of my questions you can help me very much?

I hope so. VR2 doesn't so much not answer these questions, as it
doesn't make the answers easy to find.

One major problem we had was in dealing with multiple deckers- each
gets thier own ST, but this is by no means obvious, and in some cases, the
results of one ST will affect the others.
One reson I decided IC would remain "dead" until a decker jacked out
is that a host CAN identify a decker whan he returns to that host (in as
much as thier individual tally remains high)- I figured that must be a 2
way street.

:Sandman


Mongoose
Message no. 5
From: Ulrich Haupt <sandman@****.UNI-OLDENBURG.DE>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 15:08:44 +0100
Thanks Mongoose & Starjammer for your effords!

Mongoose continued this thread with the following "question":

> One major problem we had was in dealing with multiple deckers- each
> gets thier own ST, but this is by no means obvious, and in some cases, the
> results of one ST will affect the others.
> One reson I decided IC would remain "dead" until a decker jacked out
> is that a host CAN identify a decker whan he returns to that host (in as
> much as thier individual tally remains high)- I figured that must be a 2
> way street.

I handled the problem in the same way you did. Each decker
has it's own ST and the host remembers that. I always (oh-
just two times if fact) handled it that the triggered IC
sees only the decker who activated the trigger step. The
other one is still invisible though he always helped his fellow.

What do you think happens if two deckers trigger the same
trigger step each:

decker A has a ST of 5, decker B has a ST of 6. Both gain 4
points on their ST and reach 9(A) and 10(B).
At a trigger level of 8 grey IC is activated!

Do one or two IC appear? (Silly thought: what happens if 400
deckers enter a host trigger IC?)

Another question:
If one IC is crashed by two deckers whose ST raises?
a) the decker who activated the IC
b) the decker who crashed the IC (what I read in the letters
of VR2)
c) both


And just a last question (I hope):

Scenario:

A decker has a ST of 11:
He wants to wait until his ST has dropped to zero.

With the null operation he can wait and the host can roll
against him.
In the text (I missed the page#) there were several time
steps like 10 seconds, 1 minute, 1 hour, 12 hours.
Does the host roll at each step or only for the last one?
Aand does the host reset of the decker is still logged on?
Or must the decker be logged out?

And a very last question :-)
To go from host A to host B in my first example the decker
has to perform a successful logon to host B. Does he have to
make a graceful logoff from host A or is it just the last
action before jacking out without being dumped?


Sandman
Message no. 6
From: David Buehrer <dbuehrer@******.CARL.ORG>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 08:32:14 -0700
For the mere cost of a Thaum, Ulrich Haupt wrote:
/
/ Thanks Mongoose & Starjammer for your effords!
/
/ Mongoose continued this thread with the following "question":
/
/ > One major problem we had was in dealing with multiple deckers- each
/ > gets thier own ST, but this is by no means obvious, and in some cases, the
/ > results of one ST will affect the others.
/ > One reson I decided IC would remain "dead" until a decker jacked out
/ > is that a host CAN identify a decker whan he returns to that host (in as
/ > much as thier individual tally remains high)- I figured that must be a 2
/ > way street.
/
/ I handled the problem in the same way you did. Each decker
/ has it's own ST and the host remembers that. I always (oh-
/ just two times if fact) handled it that the triggered IC
/ sees only the decker who activated the trigger step. The
/ other one is still invisible though he always helped his fellow.

I disagree :)

If a host can identify a decker then it should toss all it's IC at him
and notify the system administrator and/or shutdown. If you were an
administrator and your system could identify a decker as soon as his ST
reached 1, would you set the system so that it blithly ignores the decker
until his ST reaches higher levels before sending in deckers or shutting
down the system?

IMO it would seem that the ST is a general rating that is cumulative
from all deckers. If 3 STs are attributed to one decker and 5 STs are
attributed to another decker than the ST should be 8.

-David B.
--
"Earn what you have been given."
--
email: dbuehrer@******.carl.org
http://www.geocities.com/TimesSquare/1068/homepage.htm
Message no. 7
From: Micheal Feeney <Starrngr@***.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 12:06:05 EST
In a message dated 99-01-27 09:07:26 EST, you write:

> Another question:
> If one IC is crashed by two deckers whose ST raises?
> a) the decker who activated the IC
> b) the decker who crashed the IC (what I read in the letters
> of VR2)
> c) both
>
I guess it would depend on the situation, but I would tend towards B or C. B
if only one decker dealt with the IC, but if the deckers worked together to
defeat the IC both deckers should have the appropriate penalties... just split
between them. As in -1 to their deception rateings for every piece of IC they
jointly crashed and are keeping supressed.
Message no. 8
From: Starjammer <starjammer@**********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 13:29:40 -0500
At 03:08 PM 1/27/99 +0100, Ulrich Haupt wrote:
>
>Mongoose continued this thread with the following "question":
>
>> One major problem we had was in dealing with multiple deckers- each
>> gets thier own ST, but this is by no means obvious, and in some cases, the
>> results of one ST will affect the others.
>> One reson I decided IC would remain "dead" until a decker jacked
out
>> is that a host CAN identify a decker whan he returns to that host (in as
>> much as thier individual tally remains high)- I figured that must be a 2
>> way street.
>
>I handled the problem in the same way you did. Each decker
>has it's own ST and the host remembers that. I always (oh-
>just two times if fact) handled it that the triggered IC
>sees only the decker who activated the trigger step. The
>other one is still invisible though he always helped his fellow.

I wouldn't work it that way. Rather, each decker has his own ST, but what
one decker triggers all deckers suffer. In the case of IC, the IC will
probably locate and attack the triggering decker first since he's the one
who set it off, but not necessarily. Or, if the IC trashes the intruding
decker, it may start hunting for other intruders. In the case of system
deckers, it's first come first served.

>What do you think happens if two deckers trigger the same
>trigger step each:
>
>decker A has a ST of 5, decker B has a ST of 6. Both gain 4
>points on their ST and reach 9(A) and 10(B).
>At a trigger level of 8 grey IC is activated!
>
>Do one or two IC appear? (Silly thought: what happens if 400
>deckers enter a host trigger IC?)

No. Only one program to a host. However, as I said above, I think that
what one decker triggers can become a problem for other deckers in the system.

>Another question:
>If one IC is crashed by two deckers whose ST raises?
>a) the decker who activated the IC
>b) the decker who crashed the IC (what I read in the letters
>of VR2)
>c) both

Honestly, I'd say that any crashed IC in the system would raise the tallies
of ALL deckers in the system, whether they were involved in the cybercombat
or not. It's the fact that the IC has crashed that tips the system off,
not the act of crashing it.

By way of compensation, though, I'd probably also allow any decker to
suppress the IC, if they're aware of it. I'd probably also allow them to
hand off suppression duty between them, if they can coordinate.

>And just a last question (I hope):
>
>Scenario:
>
>A decker has a ST of 11:
>He wants to wait until his ST has dropped to zero.
>
>With the null operation he can wait and the host can roll
>against him.
>In the text (I missed the page#) there were several time
>steps like 10 seconds, 1 minute, 1 hour, 12 hours.
>Does the host roll at each step or only for the last one?
>Aand does the host reset of the decker is still logged on?
>Or must the decker be logged out?

You only make one test, but the TN for the test is modified by how long
you're sitting still and doing nothing.

Opinions vary on host reset. My opinion is that the system cannot reset
until the decker logs out, or at least, it shouldn't. System reset
basically happens when all the little errors and crashed programs and
processes caused by the decker have been reset to their initial conditions.
This, of course, is predicated by the idea that either the system or the
admins notice that these things have gone wrong, and correct them.
Noticing these things will almost certainly indicate that the system's been
breached, especially for a large tally.

While a decker's in the system, Masked, Sleazing, and suppressing IC, he's
basically trying to fool the system into not noticing that anything's
wrong. If he stops doing that, he's going to get spotted. If he doesn't
stop doing that, then the system won't reset.

Any system breach is going to be noticed eventually, IMHO. The trick for
the decker is to get in and out before the breach is noticed, and to leave
as few clues as possible as to his activities on the system.

>To go from host A to host B in my first example the decker
>has to perform a successful logon to host B. Does he have to
>make a graceful logoff from host A or is it just the last
>action before jacking out without being dumped?

Graceful Logoff is only to jack out without being dumped. Graceful Logoff
also has the added bonus that it completely dismantles your datatrail
behind you, shutting down any attempts to trace you. Jacking out without a
GL op leaves you vulnerable to dump shock and also leaves the remains of
your datatrail up for a few turns, until the system notices the loss of
signal and shuts it down. You can potentially be traced in that interval.


--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 9
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 16:10:02 -0600
:Mongoose continued this thread with the following "question":
:
:> One major problem we had was in dealing with multiple deckers- each
:> gets thier own ST, but this is by no means obvious, and in some cases,
the
:> results of one ST will affect the others.
:> One reson I decided IC would remain "dead" until a decker jacked
out
:> is that a host CAN identify a decker whan he returns to that host (in
as
:> much as thier individual tally remains high)- I figured that must be a
2
:> way street.
:
:I handled the problem in the same way you did. Each decker
:has it's own ST and the host remembers that. I always (oh-
:just two times if fact) handled it that the triggered IC
:sees only the decker who activated the trigger step. The
:other one is still invisible though he always helped his fellow.

When he does so, the IC CAN see him, though, (you can see any icon
that attacks you) and is likely to counter (even if its probe, I'd say it
starts tagging anybody who attacked it).


:What do you think happens if two deckers trigger the same
:trigger step each:
:
:decker A has a ST of 5, decker B has a ST of 6. Both gain 4
:points on their ST and reach 9(A) and 10(B).
:At a trigger level of 8 grey IC is activated!
:Do one or two IC appear? (Silly thought: what happens if 400
:deckers enter a host trigger IC?)

I'd say 2 gray IC. I think IC Is a type of procedure, and can operate
only so well against an icon, even if the machine has the proccesing power
to run multiple copies. Basically, the machine just takes the info
gathered while the ST is being raised (info about what processes /
operations the deckers deck is running, stuff needed to crash / kick that
decker) and feeds it to its "IC" program, which than spawns a process that
uses that info to do what it does. The decker can fight against that
PROCESS, and spoof the sytem into thinking it has / is doing its job, but
can't alter the systems abilty to run IC (any more than he can alter his
ST). Spawning another identical IC process won't do any
good against that decker, unless the comp gets some new info (higher ST)
or has better IC
programs (like party IC, or some other way of running multiple attacks).
To answer you "silly" hypothesis- yes, I think there would be 400 IC
"programs",
each lusting after a sperate deckers chitlings. Wheter the host could
handle that sort of thing is a seprate question... 400 doesn't sound like
TOO many. I don't think the max bandwidth for a host is given anywhere-
in VR1, that would be a sure way to crash a node, but hosts are MANY
nodes. Anybody reclall how many nodes a single CPU (and subsidiery SPU's)
could contol in VR1? You could maybe get a guestimate at Host bandwith by
totlaing up the max bandwith of those nodes.


:Another question:
:If one IC is crashed by two deckers whose ST raises?
:a) the decker who activated the IC
:b) the decker who crashed the IC (what I read in the letters
:of VR2)
:c) both

B (they get the XP, also. :P ), though A makes sense also. HMM. I'd
say that could vary from host to host, or even be random, or split among
those involved.

:Scenario:
:
:A decker has a ST of 11:
:He wants to wait until his ST has dropped to zero.
:
:With the null operation he can wait and the host can roll
:against him.

HUH? No, the null op determines how long the decker can do nothing
without having the ST go up (more than it does for the null op roll, at
least). Also, the host will not roll to reset with the decker still
logged on, afaik.

:In the text (I missed the page#) there were several time
:steps like 10 seconds, 1 minute, 1 hour, 12 hours.
:Does the host roll at each step or only for the last one?

No, the host rolls VS dfetection when the op is performed, like any
other op. The EFFECT of the new ST can be aplied any thime during the
null ops duration, usually toward the end.

:Aand does the host reset if the decker is still logged on?
:Or must the decker be logged out?

Per "host reset", p 65, it apears he must log out, or at least not be
active on THAT host any longer.

:To go from host A to host B in my first example the decker
:has to perform a successful logon to host B. Does he have to
:make a graceful logoff from host A or is it just the last
:action before jacking out without being dumped?

When going from host to host, you do not logoff. Graceful loggof is
just a way to disconnect from the matrix, and prevents dumpshock, as well
as
cancelling your matrix presence (preventing trace IC from catching your
"dead air" and nailing your loaction). Logging onto a easy to reach, low
securtiy RTG and then performing a "graceful loggof" is a good idea
sometimes, since it is easier (and hence maybe faster) then doing a
graceful logoff on a system that has black IC on your butt.

Mongoose
Note- I have NEVER played a decker, but really should (and would, if I
knew I wouldn't drive my GM crazy with complex procedures like the
above) - Instead, I GMed my for my GM's Decker character's matrix runs,
and nearly screwed my own PC in the process.

Oh, and visit
http://www.geocities.com/TimesSquare/Chamber/5072/srmnvbr.htm - now with
25% More Technology!
Message no. 10
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Wed, 27 Jan 1999 14:57:56 -0600
David B. wrote-

:/ > One major problem we had was in dealing with multiple deckers-
each
:/ > gets thier own ST, but this is by no means obvious, and in some
cases, the
:/ > results of one ST will affect the others.
:/ > One reson I decided IC would remain "dead" until a decker jacked
out
:/ > is that a host CAN identify a decker whan he returns to that host (in
as
:/ > much as thier individual tally remains high)- I figured that must be
a 2
:/ > way street.


:If a host can identify a decker then it should toss all it's IC at him
:and notify the system administrator and/or shutdown. If you were an
:administrator and your system could identify a decker as soon as his ST
:reached 1, would you set the system so that it blithly ignores the decker
:until his ST reaches higher levels before sending in deckers or shutting
:down the system?

As I pointed out In my other post today, the ST (IMO) represents how
well the system (and its adminstrator / automatic securty measures /
firewalls / whatever) know where and how the decker is getting in and
opperating. It might even represent a percentage certainty that "decker
J. Q. Hacks" IS in fact the one doing procedures X, Y, and Z. Since a
deck with masking probaly uses a screen of revolving fake ID's (or
whatever), the system proably can't afford to boot every ID it knows is
doing something suspecious, but with one decker pulling enough tricks, it
could build up a profile of his "actual" matrix ID and launceh more
effective attacks.
Since the host does NOT should toss all it's IC at him and notify the
system administrator and/or shutdown as soon as it notices a decker, its
obvious it can't. But it obviously can track him well enough to assign
him a security tally and target him with (what it judges to be) apporiate
IC.

:IMO it would seem that the ST is a general rating that is cumulative
:from all deckers. If 3 STs are attributed to one decker and 5 STs are
:attributed to another decker than the ST should be 8.

Every refrence to security tally has it applying to "a decker", never
to "the system".
VR2, p.19, "Security Tally"
The gameaster tallies all the successeses a host/grid acheives while
opposing >a decker< in system tests. This tally runs as long as >the
decker< is logged onto that particular host/grid."
You could perhaps apply the effects of all triggered securty steps to
all present deckers- if one activates a piece of IC, it affects them all.
But the tallies themselves are not cumulative.
If they were cumulative, how could you know when / if there was some
totally unrelated decker on the same host as you? Decking would be a
crapshoot as to when you get lucky and find a sytem you are the only
decker in- something the rules would surely mention, as it would strongly
affect a deckers chance of succes! Hell, most RTG's would be at "Host
shutdown" all the time, just from a few hundred deckers in the same city
traveling around the net. Nobody could make any phone calls, and the grid
owners would loose thier contracts!
Additionaly, in "R:AS", there is a matrix scene whare MANY invading
otaku apear in a host. That would be an unlikely scene if the invaders
tallies were figured cumalatively.

Mongoose
Message no. 11
From: David Buehrer <dbuehrer@******.CARL.ORG>
Subject: Re: one or two VR2 questions (not short)
Date: Thu, 28 Jan 1999 07:24:15 -0700
For the mere cost of a Thaum, Mongoose wrote:
/
/ David B. wrote-
/
/ :If a host can identify a decker then it should toss all it's IC at him

[snip]

/ Since the host does NOT should toss all it's IC at him and notify the
/ system administrator and/or shutdown as soon as it notices a decker, its
/ obvious it can't. But it obviously can track him well enough to assign
/ him a security tally and target him with (what it judges to be) apporiate
/ IC.

Okay, I think I understand your point of view.

The host keeps track of every user/icon on it's system. The host
assigns every icon a security tally when they enter the host. If an
icon does something innapproriate their security tally increases. When
an icon's security tally reaches a certain point then the host will
focus it's attention on the icon. Whereas other icons (deckers) may
have bumped up their security tallies, the host only cares about the
icon that has increased it's security tally above the limits set by the
host's administrator(s). If other icons later increase their security
tally above that level then the host will also focus it's attention on
them. The only way an icon's security tally would affect all the icons
on a host would be if the icon's security tally reached a point that
required the host to shut down.

/ Every refrence to security tally has it applying to "a decker", never
/ to "the system".
/ VR2, p.19, "Security Tally"
/ The gameaster tallies all the successeses a host/grid acheives while
/ opposing >a decker< in system tests. This tally runs as long as >the
/ decker< is logged onto that particular host/grid."

All I can say is that on my first read through I got the impression that
the security tally was cumulative. I'll have to sit down and read through
VR2 again :)

/ If they were cumulative, how could you know when / if there was some
/ totally unrelated decker on the same host as you? Decking would be a
/ crapshoot as to when you get lucky and find a sytem you are the only
/ decker

Actually, that idea appeals to me. Maybe as a GM I'm a little to
Evil(TM) ;)

/ something the rules would surely mention, as it would strongly
/ affect a deckers chance of succes!

Good point. Even though Shadowrun is notorious for lack of examples
where they are really needed, I'd say that this point lends a lot of
credence to the "decker security tally" interpretation as being the
intention of the author of VR2.

That doesn't mean that I'm going to switch from the "host tally"
interpretation :) Like I said, I'm an Evil(TM) GM ;) But you've given
me a lot to think about.

-David B.
--
"Earn what you have been given."
--
email: dbuehrer@******.carl.org
http://www.geocities.com/TimesSquare/1068/homepage.htm
Message no. 12
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: one or two VR2 questions (not short)
Date: Thu, 28 Jan 1999 13:50:37 -0600
:/ If they were cumulative, how could you know when / if there was
some
:/ totally unrelated decker on the same host as you? Decking would be a
:/ crapshoot as to when you get lucky and find a sytem you are the only
:/ decker

:Good point.
:That doesn't mean that I'm going to switch from the "host tally"
:interpretation :) Like I said, I'm an Evil(TM) GM ;) But you've given
:me a lot to think about.


Good, Because I just realized I've posted a lot more on this issue,
and am probably starting to sound redundant and / or belligerent. One
obvious point is that having individual security tallies does potentially
make co-ordinated teams of deckers very effective. IMO, they should be-
Echo Mirage certainly was, and the Otaku tribe supposedly can get in
ANYWHERE. Decker operations on that scale seem unlikely in normal
campaigns, and even so, busting a really nasty system would STILL be a
challenge, from my experience.

I'm going to shut up about this now. :)

Mongoose

Further Reading

If you enjoyed reading about one or two VR2 questions (not short), you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.

Thwap!