<epigraph>
  <attribution>Donald J. Atwood, General Motors</attribution>
  <simpara
    >To take a significant step forward, you must make a series of finite 
    improvements.
  </simpara>
</epigraph>

<simpara
  >This chapter introduces the framework of a first stage infector
  written in plain C. The program will insert and activate one chunk
  of code into executables specified on the command line.
  It is not insertable itself.
</simpara>
<simpara
  >The code is split it into many parts that manipulate a central
  data structure. The idea is to replace some of these parts
  in later chapters to implement improvements and different infection
  methods. Parts are shown in random order and without any
  <literal>#include</literal> statements or prototypes. Identifiers
  prefixed with <literal>TEVWH_</literal> are defined in generated file
  <filename>config.h</filename>. See &yref.verifying.installed.packages;.
  If you need full details a look into the sources of this document
  should do. <xref linkend="mirrors"/> shows where to get it.
</simpara>

<sect2 id="dressing.up.binary.code" xreflabel="Dressing up binary code">
  <title>Dressing up binary code</title>

  <simpara
    >This script is used throughout the document to convert binary
    files into valid C code, i.e. definition of a byte array.
    This could have been a small filter written in
    <citerefentry> 
      <refentrytitle>perl</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>, but we actually need a lot of features.
  </simpara>
  <simpara
    >We need to process the output of both
    <application>ndisasm</application> and
    <application>objdump</application>, on multiple platforms.
    Examples for valid input (i386, sparc, alpha):
  </simpara>
  <programlisting><inlinemediaobject><imageobject><imagedata
    fileref="../intro/example.asm.txt"
    format="linespecific"
  /></imageobject></inlinemediaobject></programlisting>
  <simpara
    >The <literal>__attribute__</literal> clause is explained in
    &yref.a.section.called.text;.
  </simpara>
  <simpara
    >Initializing the array with string literals (looking like
    <literal>\xDE\xAD\xBE\xEF</literal>) is easier. The terminating
    zero would not work with &yref.doing.it.in.c;, however.
    But then using a list of hexadecimal numbers introduces
    separating comas, requiring special treatment of the last line.
  </simpara>
  <simpara
    >If command line option <option>-last_line_is_ofs</option>
    is passed to the program then the last line of disassembly
    is meant to specify a offset into the code.
    Actually it's just the last byte of that line.
    You are free to use any dummy operation, see the example input above.
    A real world example is at &yref.infection.1;.
    The last instruction itself is not emitted to the byte array.
    Instead enum constant <literal>ENTRY_POINT_OFS</literal> is defined.
  </simpara>

  <formalpara>
    <title>Source: src/platform/disasm.pl</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
        fileref="../src/platform/disasm.pl"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="target.h" xreflabel="target.h">
  <title>target.h</title>

  <formalpara>
    <title>Source: src/one_step_closer/target.h</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
	format="linespecific"
	fileref="../src/one_step_closer/target.h"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="main">
  <title>main</title>

  <formalpara>
    <title>Source: src/one_step_closer/main.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/main.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="target.open">
  <title>target_open</title>

  <simpara
    >Modifying a file in place, as opposed to writing a copy,
    is possible but difficult. And between first and final
    modification contents of the target is invalid.
    Imagine a worst-case scenario of a virus infecting
    <filename>/bin/sh</filename> being interrupted through a power
    failure (or emergency shutdown of a hectic admin).
  </simpara>
  <para
    >There are a few approaches to change a file while copying.
    <itemizedlist>
      <listitem>
	<simpara>Use
	  <citerefentry>
	    <refentrytitle>lseek</refentrytitle>
	    <manvolnum>2</manvolnum>
	  </citerefentry>,
	  <citerefentry>
	    <refentrytitle>read</refentrytitle>
	    <manvolnum>2</manvolnum>
	  </citerefentry>
	  and
	  <citerefentry>
	    <refentrytitle>write</refentrytitle>
	    <manvolnum>2</manvolnum>
	  </citerefentry>
	  to load pieces of the source into memory,
	  patch them, and write them to destination.
	  A lot of work. Can be really inefficient.
	</simpara>
      </listitem>
      <listitem>
	<simpara>Use
	  <citerefentry>
	    <refentrytitle>read</refentrytitle>
	    <manvolnum>2</manvolnum>
	  </citerefentry>
	  to get the whole source file in one go. Requires more memory.
	  But then even the largest executable files have only a few MB.
	</simpara>
      </listitem>
      <listitem>
	<simpara>Use 
	  <citerefentry>
	    <refentrytitle>mmap</refentrytitle>
	    <manvolnum>2</manvolnum>
	  </citerefentry>.
	  In my humble opinion obviously the best way.
	</simpara>
      </listitem>
    </itemizedlist>
    Using <constant>MAP_PRIVATE</constant> for argument
    <parameter>flags</parameter> of 
    <citerefentry>
      <refentrytitle>mmap</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>
    activates copy-on-write semantics. You can read and write
    as if you had chosen the read-in-one-go method, but the implementation
    is more efficient. Unmodified pages are loaded directly from
    the file.  On low memory conditions these pages can be discarded
    without saving them in swap-space. 
  </para>

  <formalpara>
    <title>Source: src/one_step_closer/open.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/open.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="target.close">
  <title>target_close</title>

  <formalpara>
    <title>Source: src/one_step_closer/close.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/close.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="target.is.suitable">
   <title>target_is_suitable</title>

  <simpara
    >A visible virus is a dead virus. Breaking things is quite the
    opposite of invisibility. So before you even think about polymorphism
    and stealth mechanisms you should go sure your code does nothing
    unexpected.
    On the other hand exhaustive checks of target files will severely
    increase code size. And verifying signatures and other constant
    values is likely to make the virus code itself a constant signature.
    A better approach is to compare the target with the host executable
    currently running the virus.
  </simpara>
  <simpara
    >Finding a meaningful set of tests is an art in it itself.
    For example some executables of Red Hat 8.0 have an additional
    program header of type <literal>GNU_EH_FRAME</literal>.
    This means that <varname>e_phnum</varname> can differ between
    infector and target.
  </simpara>

  <formalpara>
    <title>Source: src/one_step_closer/suitable.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/suitable.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>

<sect2 id="target.patch.entry.addr.1">
  <title>target_patch_entry_addr #1</title>

  <simpara
    >This function is independent from the chosen infection method.
    The directory name <filename>e1</filename> means that this is
    the first (orthogonal) implementation.
    Anyway, without this function the behavior of the target is
    not modified. If the infection methods prevents double infection
    by design, this can be used for vaccination in the true meaning
    of the word: Infection with a deactivated mutation makes the
    target immune against less friendly attackers.
  </simpara>

  <formalpara>
    <title>Source: src/one_step_closer/e1/patch_entry_addr.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/e1/patch_entry_addr.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="target.write.infection.1"
  xreflabel="target_write_infection #1">
  <title>target_write_infection #1</title>

  <simpara
    ><varname>infection</varname> is an array of bytes generated by
    <xref linkend="dressing.up.binary.code"/>. Constant
    <constant>ENTRY_POINT_OFS</constant> points to the location
    inside this array to patch with the original entry address.
  </simpara>

  <formalpara>
    <title>Source: src/one_step_closer/write_infection.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/write_infection.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
