Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Jai Tao <jdfalk@****.COM>
Subject: Data barrage
Date: Tue, 17 May 1994 23:59:19 -0400
Right now, a programmer over behind the AT&T corporate datawalls
is working on a program which will send hundreds of randomly generated,
completely different messages every minute. Each one would be seperately
piped into a hacked sendmail so that they cannot be traced.
This is, of course, in answer to the now-infamous Canter & Siegel
"Greencard Lottery" debacle. He's a good guy overall, and is just saving
this up for anti-Cybersell propaganda. See, each letter will sound as if
its a real request for information, and each one will have a randomly
generated snailmail address for the info packet to be mailed to.
This would cost C&S quite a bit.

But that's not what I'm here to talk about today. Well, not
completely. In 2054, what would be the most effective way to slow down a
system, almost to the point of inoperability? Just as today, overload its
CPU.
With a seperate I/O SPU, you'd have to find a way to put together
a message or other data packet that would require the attention of the
main CPU. Send enough such packets, each one distict but with equal
priority in the system, and the CPU would be overloaded and slow down,
which might well give an advantage to a decker attempting to get into the
system.
Can anybody think of any reasons this wouldn't work? Or,
improvements to the idea? Or, better yet, how 'bout specific FASA-style
rules?

/-----------------\ "I came alone as me
| Jai Tao | just an idea
| jdfalk@****.com | in a long chain
\-----------------/ of discovery."
-Roy Harper
Message no. 2
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: Data barrage
Date: Tue, 17 May 1994 23:29:29 -0500
On Tue, 17 May 1994, Jai Tao wrote:

[..idea to get back at dirtbag lawyers deleted...]
EEE-VIL! EEE-VIL! EEE-VIL!

> But that's not what I'm here to talk about today. Well, not
> completely. In 2054, what would be the most effective way to slow down a
> system, almost to the point of inoperability? Just as today, overload its
> CPU.

I like Thermite....

> With a seperate I/O SPU, you'd have to find a way to put together
> a message or other data packet that would require the attention of the
> main CPU. Send enough such packets, each one distict but with equal
> priority in the system, and the CPU would be overloaded and slow down,
> which might well give an advantage to a decker attempting to get into the
> system.

No, a well-defined system would have SPUs deal with data first, and then
sort it to other SPUs, with it perhaps never touching the CPU.

____ Robert A. Hayden <=> hayden@*******.mankato.msus.edu
\ /__ -=-=-=-=- <=> -=-=-=-=-
\/ / Finger for Geek Code Info <=> Political Correctness is
\/ Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police"
-=-=-=-=-=-=-=-
(GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)
Message no. 3
From: Luke Kendall <luke@********.CANON.OZ.AU>
Subject: Re: Data barrage
Date: Wed, 18 May 1994 14:26:12 +1000
Jai Tao wrote:

> With a seperate I/O SPU, you'd have to find a way to put together
> a message or other data packet that would require the attention of the
> main CPU. Send enough such packets, each one distict but with equal
> priority in the system, and the CPU would be overloaded and slow down,

> Can anybody think of any reasons this wouldn't work?

Yep. No safe system will allow a sufficient priority to these `foreign'
requests to cause any significant impact on performance for local
(trusted) processes.

luke
Message no. 4
From: Neal A Porter <nap@*****.PHYSICS.SWIN.OZ.AU>
Subject: Re: Data barrage
Date: Wed, 18 May 1994 16:43:21 +1000
Jai Tao commented


Stuff del

> But that's not what I'm here to talk about today. Well, not
>completely. In 2054, what would be the most effective way to slow down a
>system, almost to the point of inoperability? Just as today, overload its
>CPU.
> With a seperate I/O SPU, you'd have to find a way to put together
>a message or other data packet that would require the attention of the
>main CPU. Send enough such packets, each one distict but with equal
>priority in the system, and the CPU would be overloaded and slow down,
>which might well give an advantage to a decker attempting to get into the
>system.
> Can anybody think of any reasons this wouldn't work? Or,
>improvements to the idea? Or, better yet, how 'bout specific FASA-style
>rules?

I don't believe that it would work. Remember the data link to the CPU
requires it to send send info to your deck describing the stuff you see. If
you overload the CPU you will creash this communication link as well. Look
at the stuff in VR about system/node overload. It effects the decker as well.
Its a good idea though. How about crashing the security system before a
run so that they cannt track you. Of course they'll know something is up
and probably call in the physical and magical heavies, but they wont be
able to find out where you are with thier fancy electronic dodads. By far
the best course is to take control of the system and get it to do what you
want.

A'Deus.

Further Reading

If you enjoyed reading about Data barrage, 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!