Skip to main content

"Immanuel Kant was a real piss-ant who was very rarely stable.
 Heideggar, Heideggar was a boozy beggar who could
  think you under the table.
 David Hume could out-consume Schopenhauer and Hegel.
 And Whittgenstein was a beery swine who was just as
  sloshed as Schlegel.
 There's nothing Nieizsche couldn't teach 'ya 'bout
  the raising of the wrist.
 Socrates, himself, was permanently pissed.
 John Stewart Mill, of his own free will,
  after half a pint of shanty was particularly ill.
 Plato, they say, could stick it away, 'alf a crate
  of whiskey every day!
 Aristotle, Aristotle was a bugger for the bottle,
  And Hobbes was fond of his Dram.
 And Rene Descartes was a drunken fart:
  "I drink, therefore I am."
 Yes, Socrates himself is particularly missed;
 A lovely little thinker, but a bugger when he's pissed."
                             The philosopher's song, Monty Python 

                        by Chris Brookes

 Well that's debateable. It has been asked of me, or should I say 
suggested  to me - by Richard,  to write this article on  how  it 
came about,  the principles involved, and generally give a little 
back-ground data to it. Certainly. Here is the low down on how it 
came  about,  which  inevitably leads to the principle  it  uses. 
Sorry, did I sound a bit reluctant there?!

 It  all started a few months ago whilst I was in the  middle  of 
writing  a completely different program.  I can't quite  remember 
which, but that's not really important. Anyhow, I was just at the 
compile-link-run  stage  when  all  of  a  sudden  the  mouse   x 
coordinate flipped... after a few moments of playing with it (I'm 
still  talking about the mouse you know...) I switched  off,  and 
booted  up  my  virus killer.  After 5 minutes  of  cleaning  the 
important  disks  (it was here that I made my  mistake),  I  then 
loaded up a certain program by IKI of TSB so that I could install 
some custom boot-sectors.  One of them happened to be BOULBOOT 3, 
and don't ask my why,  but I happened to like this one.  So on my 
disks it went.

 After  getting  back to my program writing,  and after  about  2 
hours/1  meal/3 cups of coffee,  the Ghost virus reared its  ugly 
head again.  It appeared that I hadn't cleansed all of my  disks. 
So,  I  put my virus killer disk into the drive and hit the  soft 
spongy  thing at the back of my ST.  Up popped the BOULBOOT  anti 
virus,  but instead of telling me it had installed, it zapped the 
screen with a funny colour lasting for a lengthy pause.  It  then 
told  me that it thought it had erased a virus.  Well I  knew  it 
had,  but  instead of loading up my virus killer and sorting  the 
virus out, I wanted to see the colours again. Don't laugh... they 
were quite good, sort of diagonal lines across the screen, and in 
over-scan mode.  Very impressive in a boot sector,  never mind an 

 Imagine  my disappointment when they didn't come on again  after 
hitting  reset.  Well,  no matter how I tried,  how many times  I 
pressed reset, it would not display those colours again... and so 
there  I sat wondering what was going on.  After a few minutes  I 
came  up with a tried and trusted method.  Try to  regenerate  my 
steps exactly. I did... it worked... but it wasn't good enough. I 
wanted  to know exactly what was going on.  It was at this  point 
that I had my first vision of SVP,  because I had worked out  the 
steps involved.  Firstly,  infect the ST with the virus, and then 
secondly,  run the BOULBOOT boot-sector.  After doing  this,  the 
Ghost virus was fooled into thinking it was already installed.

 My  program was going to do everything the others did,  all  the 
steps  in one go,  and it was going to do it in  GFA  Basic.  The 
first problem, and perhaps the most difficult, was trying to work 
out  what EXACTLY the Anti-virus did to your memory,  and to  the 
resident virus.  On that particular night,  it was getting  late, 
and writing a routine to just take coordinates from the mouse was 
getting difficult,  so I called it a night. I had toyed with many 
ideas  for the Anti-virus 'Emulation' in GFA...  such as  storing 
the Anti-virus with INLINE,  then writing it to the boot  sector, 
then running the boot sector,  then erasing it...  but in typical 
programmer fashion... I was taking a sledgehammer to crack a nut. 
I was going round the houses... beating round the bush... totally 
avoiding working out what the Anti-virus actually DID.  So,  as I 
just said, I called it a night and went to bed.

 The next day,  I started on it with a fresh mind and this helped 
enormously.  I  finally figured out that the Ghost Virus must  be 
altering some system vectors, and thus enabling the Anti-virus to 
recognise the altered vectors and do something about them.  So  I 
set up a watch on vectors that I new were likely to be changed by 
the virus. These were basically, HDV_BPB, a few other HDV_'s, and 
the  reset  vector.  After a few minutes of trial  and  error  it 
turned  out  to be the HDV_BPB (if I remember  rightly)  and  the 
Reset vector that were being modified. After that, it didn't take 
long to realize that all BOULBOOT was doing was to reinstate  the 
proper values to a modified vector.  So,  I had overcome half  of 
the hurdle already. If the Ghost Virus was installed in memory, I 
could  change the vectors it modified back to how what they  were 
supposed  to  be with no problems,  and so  eliminating  BOULBOOT 

 The  next major step involved in the production of SVP was  that 
of  installing  the virus into memory myself  from  GFA.  Well... 
first  I had to work out where exactly it installed  itself  into 
memory. This was easier than you might think, because I just took 
a  guess based on where the modified system vector's pointed  to. 
With my address that I had guessed,  I then wrote a small program 
to copy the area of memory around that value into a file on disk. 
The  program  took about 512 bytes either side  of  the  address. 
After  writing  this program,  I first ran it without  the  virus 
installed, and then with the virus installed. Again, by this time 
of  the  day  it was late and I had been on my  ST  for  about  8 naturally I had a serious headache developing.

 The  next  time  I continued 'Developing' SVP was  some  2  days 
later,  due  to not having much spare time.  I then had to use  a 
program simply called COMPARE, which, believe it or not, compares 
two  files.  It then tells you which bytes are the same  etc.  In 
doing this, I discovered that there was a block of 473 bytes that 
were  identical.  This  was the virus.  From this I was  able  to 
calculate,  without  much work,  where the virus  installed  into 
memory. I then repeated the memory copying to disk again, so that 
I had only had the 473 byte block of code on disk.  So now, I had 
almost overcome the major hurdles.

 Now I am a perfectionist by heart,  and the thought of having an 
extra file for the virus data didn't appeal to me at all, firstly 
because it would mean having an accessible virus on the disk, but 
mainly because I wanted 1 little neat file that nobody could play 
with.  To  remedy  this,  I wrote yet another  program  to  whizz 
through  the virus file adding the appropriate DATA $  statements 
to every byte,  and then saving it back. After doing this, I just 
merged the data into GFA basic, and that was that problem solved. 
It was at this point that I realized I had virtually made a  form 
of  Trojan virus with this after quickly ridding  my 
mind of such nasty thoughts,  I carried on.  After all of that, I 
finally  tidied up the program somewhat,  and did my  first  test 
with the viruses address,  and then CHANGED THE SYSTEM VECTORS to 
what they should be. It worked! Now call me daft, but it was here 
that  I realized that there is absolutely no point in POKING  THE 
SYSTEM  vectors,  only to RE_POKE them to their  original  values 
straight after!  That MAJOR HURDLE I had overcome a few days  ago 
(BOULBOOT) now just faded away into insignificance.

 By that time in it's development stage I had a firm idea of  the 
principle  behind  SVP.  I new exactly what  the  virus  did.  On 
booting  with  an  infected disk,  it checked to see  if  it  was 
already  present by looking for a specific byte,  at  a  specific 
address.  The question was... which byte and at what address? Now 
after  a  LARGE amount of time trying to find  this  out,  I  did 
eventually discover it.  And so it turns out that in only 1  line 
of  code,  you can protect your ST from the Ghost  Virus.  I  no- 
longer needed to install the full 473 bytes... just the one!
 All  my work over the past 3-4 days all accumulated into 1  line 
of code! 1 line!

 What  I  had to do next was to make it into a useable  piece  of 
software.  I  made it pretty versatile,  in that it could be  run 
from  an auto folder (more later) and give options by  text,  and 
also so that it could be run from GEM and make full use  of,  un- 
suprisingly, GEM. Just for sheer useability, I made it so that it 
could boot as an accessory also.

 And  that's it!  I suspect I'll see a 101 clones of this in  the 
near future now I've spilled the beans,  or so to speak,  but who 
cares... I stumbled on the idea and made the program first!

 Oh  yes,  almost  forgot.  How do you recognise an  auto  folder 
booted program from GFA?  Well,  it's quite easy really,  just do 
CLS, then PLOT(1,1) and then check with POINT to see if the pixel 
is there...if it is,  then GEM is installed,  otherwise you're in 
an AUTO folder. (sneaky, I know!!)

 If  anyone wants to write to me for any reason,  then please  do 
so.  I'll be happy to exchange software etc.,  or possibly  write 
the  odd custom program for somebody.  See my address in the  doc 
file to SVP.
 The  program  and  document files may be  found  in  the  folder 
"S_PROTEC" in the "PROGRAMS" folder on this disk of ST NEWS

The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.