<epigraph>
  <attribution>Darth Vader</attribution>
  <simpara>
    Don't be too proud of this technological terror you've constructed.
    The ability to destroy a planet is insignificant next to the power
    of the Force.
  </simpara>
</epigraph>

<simpara>
  This chapter is about a first stage infector.
  A program that inserts <link linkend="evil.magic.revealed">our code</link>
  into any executable we specify on the command line. 
</simpara>
<simpara>
  This code could easily be squeezed into a single function.
  But for clarity I split it into parts that manipulate a central
  data structure. And just for the hell of it I coded it in C++.
  This way I can present the pieces in random order.
</simpara>
<formalpara>
  <title>Source - class Target</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific" fileref="../src/one_step_closer/target.h"
    ></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>

<sect2 id="INFECTION.SIZE" xreflabel="INFECTION_SIZE">
  <title>INFECTION_SIZE</title>

  <simpara>
    The value of <constant>INFECTION_SIZE</constant> exceeds actual
    code size by far. But it is the only amount that works.
    The reason for this is buried in the
    <ulink url="&http.elf.spec.flat.text;">ELF specification</ulink>.
  </simpara>

  <blockquote>
    <simpara>
      [&hellip;] executable and shared object files must have
      segment images whose file offsets and virtual addresses are congruent,
      modulo the page size.
      Virtual addresses and file offsets for the SYSTEM V architecture
      segments are congruent modulo 4 KB (0x1000) or larger powers of 2.
      Because 4 KB is the maximum page size, the files will be suitable for
      paging regardless of physical page size. [&hellip;] 
    </simpara>
  </blockquote>

  <simpara>
    Let's take another look at the
    <link linkend="bashful.glance">output of readelf</link>.
    Above quote means that the last three digits of <literal>Offset</literal>
    must equal the last three digits of <literal>VirtAddr</literal>.
    This is the case for every program header.
    So unless we change <literal>VirtAddr</literal> as well
    (which means relocation of every access to a global variable),
    we are stuck with &calc.sh.LOAD2.align.X;.
  </simpara>
  <simpara>
    Maximum code size is further restricted by alignment.
    The i386 and descendants can execute misaligned code,
    though with a performance penalty. <function>alignUp</function>
    will take at most 15 bytes.
  </simpara>

</sect2>
<sect2 id="Target.infection" xreflabel="Target::infection">
  <title>Target::infection</title>

  <simpara>
    Up to now <link linkend="evil.magic.revealed">our code</link> is
    intended to be stand-alone. The obvious fix is to replace
    the call to
    <citerefentry>
      <refentrytitle>exit</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>
    with a <literal>jmp</literal>.
    But I think it's a better idea to let our code end with
    an unsuspiciuos <literal>ret</literal> instead.
    And we can put the matching <literal>push</literal> at the start
    of the code to have the actual return address at a constant
    location. And while we are at it, saving all registers and the
    flags can't be bad.
  </simpara>

  <formalpara>
    <title>Source - infection.asm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/infection.asm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/infection.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    We reuse the filter from <xref linkend="dressing.up.binary.code">.
    The <literal>__attribute__</literal> clause clause is explained in
    <xref linkend="a.section.called.text">.
    This example works without.
  </simpara>

  <formalpara>
    <title>Output - infection</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/one_step_closer/infection.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>main</title>

  <simpara>
    Nothing special here. Though you could object to the use of
    <citerefentry>
      <refentrytitle>fprintf</refentrytitle>
      <manvolnum>3</manvolnum>
    </citerefentry>
    instead of <varname>cerr</varname>.
    But then
    <citerefentry>
      <refentrytitle>perror</refentrytitle>
      <manvolnum>3</manvolnum>
    </citerefentry>
    is the only other type of diagnostic message you will find below.
  </simpara>

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

</sect2>
<sect2>
  <title>The opening</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 - Constructor</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/ctor.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Source - Destructor</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/dtor.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
   <title>isSuitable</title>

  <simpara>
    A visible virus is a dead virus. Breaking things is quite the
    opposite of invisibility. So before you think about polymorphism
    and stealth mechanisms you should go sure your code does nothing
    unexpected.
  </simpara>
  <simpara>
    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>

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

</sect2>

<sect2 id="patchEntryAddr">
  <title>Patch entry address</title>

  <simpara>
    Without this function the behavior of the target is
    not modified. 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 - patchEntryAddr</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/one/patch_entry_addr.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Source - newEntryAddr</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/one_step_closer/new_entry_addr.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2 id="patching.program.headers">
  <title>Patching program headers</title>

  <simpara>
    Another important issue is avoidance of multiple infections.
    It might take a while until increased file size gets noticed.
    But imagine a <filename>/bin/sh</filename> infected with a few
    dozen instances of the same virus. The runtime overhead of all
    these instances trying to find and infect other executables
    (either sequentially or in parallel forked processes) will
    significantly slow down every single shell script.
  </simpara>
  <simpara>
    Obviously any presence indicator can be used by heuristic scanners.
    My recommendation is to use an innocent property that could also
    be matched by regular executables. It is not a problem if your
    checking routine rejects some suitable targets.
  </simpara>
  <simpara>
    For this example I just declare a bug to be a feature.
    Since <xref linkend="INFECTION.SIZE"> is required to be
    &calc.sh.LOAD2.align.X; bytes, a duplicate infection is impossible
    by design.
  </simpara>

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

</sect2>
<sect2 id="patchShdr" xreflabel="Patching section headers">
  <title>Patching section headers</title>

  <simpara>
    This part is not strictly required. The resulting executable
    works without. But
    <citerefentry>
      <refentrytitle>readelf</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> will bitterly complain. And
    <citerefentry>
      <refentrytitle>strip</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> will break infected executables if not every byte
    of code is accounted for in some section.
  </simpara>

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

</sect2>
<sect2 id="copy.and.infect" xreflabel="Copy &amp; infect">
  <title>Copy &amp; infect</title>

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

</sect2>
<sect2 id="writeInfection" xreflabel="writeInfection">
  <title>writeInfection</title>

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

</sect2>
<sect2 id="off.we.go">
  <title>Off we go</title>

  <formalpara>
    <title>Command - build</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/cc.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output - build</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/one_step_closer/one/cc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>A simple shell script will do as test.</simpara>

  <formalpara>
    <title>Command - test sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/one_step_closer/one-test.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output - test sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/one_step_closer/one-test"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>The Force is strong with this one.</simpara>

</sect2>
