Eugene Leitl wrote:
> > I have an idea to get all 5 of those (potential) undiscovered Mersenne
> > primes and the $100K prize in maybe a year or less. We'll use the CPU
> > cycles of internet users without asking them. GIMPS-like software will
> > be hidden in a novelty e-mail attachment; while the recipient is
> > laughing at the sight of Kermit the Frog getting a blow job the software
> > will install itself on their computer. As long as the software can 'get
> > out of the way' [...]
> Why going at such great lengths? There are enough holes in network
> protocol stacks and applications to make possible its propagation to
> be purely automatic. Since constituting the bulk of all installations,
> one can essentially concentrate on x86/Win95/98/2000/NT ("Wintel")
> machines, which makes the task of finding buffer overruns quite easy
> (a small exploit library will suffice for starters). Each infected
> machine would occasionally ping a random IP address, trying to infect
> another target.
I did think about a self-reproducing worm. With it we could do away with
the server and let the worms report to each other. For instance, say a worm
has searched data spaces 1, 2, and 3, and, detecting that its host is
on-line, starts propergating to random IPs. Its children do one of two
things; if no worm is detected on the new IP the new worm will take root and
search random data spaces (with probabilities weighted against 1, 2, and 3).
If an existing worm is detected the new worm copies its data (i.e. "data
spaces 1, 2, and 3, searched with no success") to the existing worm and
terminates (or in other terms, it merges -- this could also be used to
update the worm). I'm using random data as much as possible because it cuts
down on data exchange and means the worms don't have to keep track of each
other. Error correction would be through massive redundancy (the worms
would only have an increased probability of avoiding an already searched
space so many searches will be performed on the same space). The whole
system of searching for primes, hiding, merging, copying, and checking for
errors could probably be packed into a very small, very efficient program.
You could expect to unleash it on the net and within months have a fresh new
10 million digit prime and a $100K cheque. Well worth the investment of
some time and a little intellectual hardship.
The reason I went with the novelty attachment idea is that if there were
an unexpected bug in the program (and there's bound to be an unexpected bug
in the program) there'd be less chance of crashing something important and
pissing a lot of people off.
The reason I went with the novelty attachment idea is that if there were an unexpected bug in the program (and there's bound to be an unexpected bug in the program) there'd be less chance of crashing something important and pissing a lot of people off.
> If we would have found an x86 machine code mutator function before
> (Koza's 1000 node Beowulf would be the ideal substrate for this) and
> add a GA buffer overrun seeker module such a software would be very
> hard to kill indeed, because it would mutate faster than patch
> distribution. Trying to infect routers and switches is another good
I don't think detection is much of a threat, the majority of people don't worry about viruses until their system crashes. Of course if someone found out what the purpose of the worm was it might make going public with the results a little more risky. (I'm not sure of the laws concerning viruses, would what I'm suggesting be illegal?)