<epigraph>
  <attribution>Dr. David Butler, British psephologist</attribution>
  <simpara>
    The function of the expert is not to be more right than
    other people, but to be wrong for more sophisticated reasons.
  </simpara>
</epigraph>

<simpara>
  Writing a program that inserts code into another program file is one
  thing. Writing that program so that it can be injected itself is a
  very different art. Although this document shows a lot of code
  and technique, it is far from being a
  <quote>Construction Kit For Dummies</quote>.
  You can't build a working virus just by copying whole lines from
  this text. Instead I'll try to show how things work.
  Translation of infecting code to a assembly is left as a
  (non-trivial) exercise to the reader.
</simpara>
<simpara>
  An astonishing number of people think that viruses require
  secret black magic. Here you will find simple code that patches
  other executables. It is not hard to write a virus (once you
  have a good understanding of assembler, compiler, linker and
  operating system). It's just hard to let it make any impact.
</simpara>
<simpara>
  Regular users can't overwrite system files (at least under serious
  operating systems). So you need root permissions. You can either
  trick the super user to run your virus. Or combine it with a
  root-exploit. But since all popular distributions come with
  checksum mechanisms, a single command can detect any modification.
  Unless you implement kernel-level stealth functionality&hellip;
</simpara>
<simpara>
  I do believe that free software is superior, at least in regard
  to security.  And I strongly oppose the argument that &config.UNAME;
  viruses will flourish once it reaches a critical mass of popularity.
  On the contrary I question the credibility of people whose income
  relies on widespread use of ridiculously insecure operating systems.
</simpara>
<simpara>
  This document is my way to fight the FUD. &note.jargon.FUD;
  Use the information presented here in any way you like.
  I bet that &config.UNAME; will only grow stronger.
  <footnote><simpara>
    This is not a prediction on the future of FreeBSD and Solaris.
    I doubt that viruses will have much influence on their fate, though.
  </simpara></footnote>
</simpara>

<sect2 id="what.exactly.is.a.virus">
  <title>What exactly is a virus?</title>

  <simpara>
    The plural of virus is neither <foreignphrase>viri</foreignphrase>
    nor <foreignphrase>virii</foreignphrase>, nor even
    <foreignphrase>vira</foreignphrase> nor
    <foreignphrase>virora</foreignphrase>.
    It is quite simply viruses, irrespective of context.
    &note.virus.plural;
  </simpara>
  <simpara>
    The jargon files contain a good definition.
    For my purposes it is not technical enough, though.
  </simpara>

  <itemizedlist>
    <listitem>
      <simpara>
	A virus &note.jargon.virus; is a program that
	infects other programs stored in inactive form. This document
	concentrates on copying the executable code of the virus into
	another file. Other possible targets are boot sectors and
	programmable ROMs.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
	A worm &note.jargon.worm; is a program that penetrates other
	running programs. Penetration means to copy the executable
	code of the worm into the active process image of the host.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
	A trojan program &note.jargon.trojan; is deliberately started
	by a user because of advertised features, but performs covert
	malicious actions.
      </simpara>
    </listitem>
  </itemizedlist>

  <simpara>
    The jargon files include programs infected by a virus into their
    definition of trojan. I don't consider this helpful. The survival
    strategy of viruses is to stay below the level of perception of
    humans, operating systems or scanners.
    But trojans don't hide. They obfuscate their real intend by delivering
    a good show. Good advertising can persuade the user to install
    necessary system components, deactivate security checks,
    and throw overboard all common sense.
  </simpara>
  <simpara>
    The jargon files also claim that
    <quote>a virus cannot infect other computers without assistance</quote>.
    Widespread use of write-enabled network shares has made this a bold
    statement. It is correct that patching an executable file over
    the net is meaningless if that program is not executed somewhere.
    But I want to stress that it's not the media containing the target
    that distinguishes worms from viruses.
    A virus polluting a RAM-disk is still a virus. A worm saved to disk by
    the hibernation feature of a laptop is still a worm.
  </simpara>

</sect2>
<sect2 id="worm.vs.virus" xreflabel="Worm vs. virus">
  <title>Worm vs. virus</title>

  <simpara>
    The main difference between worms and viruses is persistence and
    speed.  Modifications to files are usually permanent and remain after
    reboot. On the other hand a virus attached to a host can get active
    only when that host program is started. A worm takes immediate control
    of a running process and thus can propagate very fast.
  </simpara>
  <simpara>
    Usually these techniques are combined to effectively cause mischief.
    Viruses can get resident, i.e. attach themselves to a part of the 
    system that runs independent of the infected executable.
    Worms can modify system files to leave permanent back doors
    &note.jargon.backdoor;.
    And tricking the user into executing the very first infector
    is a lot easier than finding and exploiting &note.jargon.exploit;
    buffer overflows &note.jargon.buffer.overflow;.
  </simpara>
  <simpara>
    But Unixes have traditional concepts to limit the possible damage of
    a malicious process. Network services can be run under the access
    permissions of a non-privileged account. File systems can be mounted
    read-only (e.g. <filename>/usr</filename>) or as
    <literal>noexec</literal> (e.g. <filename>/home</filename>).
    Some file systems have extended attributes that can prohibit
    access even when <command>ls <option>-l</option></command>
    tells otherwise
    (on <literal>ext2</literal> this is
    <citerefentry>
      <refentrytitle>chattr</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>).
    Probably the strongest defense is 
    <citerefentry>
      <refentrytitle>chroot</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
  </simpara>
  <simpara>
    Every single one of these techniques can stop a vandalizing human,
    virus or worm to take over the entire machine. But while it is easy
    to control viruses, it is very hard to stop worms.
    To exploit a vulnerable network service a worm needs permissions
    for an incoming connection. To compromise the next machine on the
    network it needs an outgoing network connection. Nothing else.
  </simpara>

</sect2>
<sect2 id="freedom.is.security" xreflabel="Freedom is security">
  <title>Freedom is security</title>

  <simpara>
    I will now put on a black hat and an evil grin.
    Using material already published on the net, contributions sent to me,
    and all documentation available, I will try to build a virus to do in
    ELF for good. All concepts, ideas and experiments - along with enough
    working code to prove my conclusions - will be released to public
    ridicule through this document.
  </simpara>

  <simpara>
    Should the quest fail this may have a few reasons:
  </simpara>
  <orderedlist>
    <listitem>
      <simpara>I am incompetent.</simpara>
    </listitem>
    <listitem>
      <simpara>Nobody cared to sent in evidence for #1.</simpara>
    </listitem>
    <listitem>
      <simpara>
        It already has been done,
	but They will prevent #2 to maintain #1. 
      </simpara>
    </listitem>
    <listitem>
      <simpara>
	Optimistic readers could think that the inevitable big mistake of
	developers and distributors will be released soon, but just isn't
	available right now.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
	Even more adventurous spectators might say that design,
	development model, or distribution concept make &config.UNAME;
	immune against a direct attack.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        This is just one of the more boring episodes in the matrix.
      </simpara>
    </listitem>
  </orderedlist>

  <simpara>
    Anyway, it is not a problem if we, or someone using this document,
    succeeds. The correct name for that situation is opportunity.
    Should you happen to take this document - and especially above
    agenda - too seriously, the story of <quote>Osama bin virus</quote>
    &note.vmyths.osama; can help.
  </simpara>
  <simpara>This text written under influence of an evil grin.</simpara>

</sect2>

<sect2 id="copyright">
  <title>Copyright &amp; trademarks</title>

  <simpara>
    This document,
    <emphasis>The &config.UNAME; Virus Writing HOWTO</emphasis>,
    is copyrighted (c) 2002 by <emphasis>Alexander Bartolich</emphasis>.
  </simpara>
  <simpara>
    Permission is granted to copy, distribute and/or modify this
    document under the terms of the <xref linkend="license.FDL"/>,
    Version 1.1, or any later version published by the
    Free Software Foundation; with no Invariant Sections,
    with no Front-Cover Texts, and with no Back-Cover Texts.
  </simpara>
  <simpara>
    All accompanying source code, build scripts and makefiles is
    free software; you can redistribute it and/or modify it under
    the terms of the <xref linkend="license.GPL"/> as published by
    the Free Software Foundation; either version 2 of the License,
    or (at your option) any later version.
  </simpara>
  <simpara>
    All copyrights are held by their respective owners, unless
    specifically noted otherwise. Use of a term in this document
    should not be regarded as affecting the validity of any trademark
    or service mark.
  </simpara>
  <simpara>
    Naming of particular products or brands should not be seen
    as endorsements.
  </simpara>

</sect2>

<sect2 id="disclaimer">
  <title>Disclaimer</title>

  <simpara>
    No liability for the contents of this documents can be accepted.
    Use the concepts, examples and other content at your own risk.
    As this is a new edition of this document, there may be errors
    and inaccuracies, that may of course be damaging to your system.
    Proceed with caution, the author does not take any responsibility.
  </simpara>
  <simpara>
    All software is distributed in the hope that it will be useful,
    but without any warranty; without even the implied warranty of
    merchantability or fitness for a particular purpose. 
    See the <xref linkend="license.GPL"/> for more details.
  </simpara>
  <simpara>
    <emphasis>
      Who am I kidding? This is dangerous stuff!
      Stop reading immediately or risk lethal pollution of your systems!
    </emphasis>
  </simpara>
  <simpara>
    You are strongly recommended to take a backup of your system
    before major installations and backups at regular intervals.
  </simpara>
</sect2>

<sect2 id="credits" xreflabel="Credits">
  <title>Credits</title>

  <simpara>
    Everything in this document is either plain obvious or has been
    written by someone else long time ago. My meager contribution is
    nice formatting, reproducibility and the idea to take the subject
    to mainstream media. But I'm certainly not innovative.
  </simpara>

  <formalpara>
    <title>Silvio Cesare</title>
    <para>
      <email>silvio@big.net.au</email>
      Founder of the trade. Keeper of the source.
      &note.silvio.cesare; Admire the release date.
    </para>
  </formalpara>

  <formalpara>
    <title>John Reiser</title>
    <para>
      <email>jreiser@BitWagon.com</email>
      Found one bug and two superfluous bytes in
      &yref.in.the.language.of.evil;.
      Proved that I can't code a straight &calc.evil.magic.codesize.D;
      byte <quote>Hello World</quote>.
    </para>
  </formalpara>

  <formalpara>
    <title>paddingx</title>
    <para>
      Contributed technical details and implementation for
      &yref.additional.cs; and &yref.doing.it.in.c;.
    </para>
  </formalpara>

  <formalpara>
    <title>Rick Moen</title>
    <para>
      <email>rick@linuxmafia.com</email>
      Has a very inspiring site. &note.rick;
      And I shamelessly quote him in the
      <link linkend="index">abstract</link>.
      <!-- xref to abstract is not possible with all DSSSL -->
    </para>
  </formalpara>

  <simpara>
    A lot of people helped me shape language and ethical position of
    this document (sorted by
    <citerefentry>
      <refentrytitle>perl</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>, blame Larry): &calc.credits;.
  </simpara>

</sect2>
<sect2 id="feedback" xreflabel="Feedback">
  <title>Feedback</title>

  <simpara>
    Feedback is most certainly welcome for this document.
    Please send your additions, comments, criticisms, flames
    and <quote>contributions</quote> to the following
    email address: <email>alexander.bartolich@gmx.at</email>
  </simpara>
  <simpara>
    A few people sent me executables for that other operating system.
    I am very grateful for this kindness. But you should know that this
    document is about <acronym>ELF</acronym> only.
  </simpara>

</sect2>
