<epigraph>
  <attribution>Confucius</attribution
  <para>
    The superior man understands what is right;
    the inferior man understands what will sell.
  </para>
</epigraph>

<para>
  On <link linkend="credits">Silvio Cesare</link>'s site is a
  text file named <filename>elf-pv.txt</filename>.
  Complete title is <quote>Unix ELF Parasites And Virus</quote>,
  dated October 1998.
  It gives some background and then describes the gap between
  code and data segment, as illustrated in <xref linkend="readelf">
  (for some strange reason he does not mention that command anywhere).
</para>
<para>
  At the end of the text is an uuencoded file
  <filename>unix-linux-pv-src.tgz</filename> containing sources.
  The package is also available as plain
  <filename>vit-src.tgz</filename>.
  This is explained on the first page of
  <ulink url="&silvio_cesare;">&silvio_cesare;</ulink>:

  <blockquote>
    <para>
      [&hellip;] The name of this virus by curiosity was given by the
      people at FProt who noticed the virus created a temp file using
      the letters VIT.
    </para>
  </blockquote>

  In another text he calls the concept
  <quote>the text segment padding virus (padding infection)</quote>.
</para>
<para>
  Anyway, the code is hard to read as he started development with 
  a piece of plain C and applied several transformations.
  It seems that he released the stuff the very second it produced results.
</para>

<sect2>
  <title>Three years later</title>

  <para>
    <ulink url="&securiteam_5MP022K5GE;"
      >Remote Shell Trojan: Threat, Origin and Solution</ulink>
    on <ulink url="&securiteam;">&securiteam;</ulink> is dated
    10/9/2001.
  </para>
  <para>
    Perhaps they had to cut out all interesting details to protect
    their source. But what I read on that page makes little sense to me.
    Supposedly script kiddies got hold of experimental
    back door code and planted it on sites they had access to.
    No names, dates, sites or legal consequences given.
    No details on the method used by intruders to gain access.
  </para>

  <blockquote>
    <para>
      [&hellip;] From this point, the virus seemed to spread in
      the wild.
    </para>
  </blockquote>

  <para>
    Well, how does it spread? There is no reference to a root
    exploit, either local or remote. It is explained that if
    root starts an infected program owned by another user, a virus
    can pollute the whole system. But how many people really do this?
    (a poll on <ulink url="slashdot.org">slashdot.org</ulink>
    might give answer) And the question on how the virus spreads
    to other machines remains.
  </para>
  <para>
    It is plausible that script kiddies copy root kits
    (including viral back doors) wholesale to cracked machines.
    It is possible to combine a remote exploit with such a virus
    to build a persistent worm, though creative work of this
    extent is by definition out of reach for script kiddies.
    But in both cases the problem is the used exploit,
    not the qualities of the installed back door.
  </para>
  <para>
    Anyway, the concluding remark is strange:
  </para>
  <blockquote>
    <para>
      [&hellip;] Again, it is strongly recommend that anybody running
      Linux run the detector to see if their system is infected.
      Even if they do not expect anything, they can always optionally
      immunize their system. This is the only way we can fight the
      further spread of this virus.
    </para>
  </blockquote>
  <para>
    We should make another poll on
    <ulink url="slashdot.org">slashdot.org</ulink>
    about how many people used the detector.
    It must have been all of them. Or is there another explanation
    that the predicted catastrophe did not occur?
  </para>
  <para>
    Attached to the article is Perl and C code that detects
    and vaccinates against RST. Though I never encountered the culprit,
    seeing the antidote makes me sure it is a variation of Silvio
    Cesare's concept.
  </para>
  <para>
    I am certain that my
    <link linkend="turn_the_pages">shabby piece of Perl</link>
    would detect RST, if I had a copy (add collecting to my list
    of incompetencies). And that a
    <link linkend="patchEntryAddr">deactivated</link> infection with
    <xref linkend="one_step_closer"> has the same effect as the
    immunizer on that page. 
  </para>
  <para>
    Anyway, the code is fooled by the improvements made in
    <xref linkend="entry_point">. It checks whether the entry
    point is exactly 4096 from the end of the code segments.
    If not, the executable is considered immune.
  </para>

<programlisting
>  psize = (textseg.p_vaddr + textseg.p_filesz) - ehdr.e_entry;
  poffset = (textseg.p_offset + textseg.p_filesz) - psize;
  if (psize != 4096)
    return 0; /* Binary already cleaned */</programlisting>

  <para>
    The code also tries to clean infected executables by restoring
    the entry point. I don't trust that part, however:
  </para>
<programlisting
>   // read original entry point, that according to my reverse engineering
   // is stored on the parasite at offset 1
   if (fseek(fp, poffset+1, SEEK_SET)!=0) goto err;
   if (fread(&amp;oldentry, 4, 1, fp) != 1) goto err;
  
   // restore the binary's entry point to point to the real program again,
   // avoiding the execution of the parasite code.
   // this pernamently disables the parasite code and makes the binary immune
   // to further infection attempts.
   ehdr.e_entry = oldentry;
   if (fseek(fp, 0, SEEK_SET) != 0) goto err;
   if (fwrite(&amp;ehdr, sizeof(ehdr), 1, fp) != 1) goto err;</programlisting

  <para>
    I can't see any attempt to verify the retrieved address.
    Silvio Cesare's classic pieces stored the original entry point
    at a non-intuitive address in the middle of infective code.
  </para>

</sect2>
