<epigraph>
  <attribution>Doug Gwyn</attribution
  <para>
    Unix was not designed to stop people from doing stupid things,
    because that would also stop them from doing clever things.
  </para>
</epigraph>

<para>
  <xref linkend="evil-magic"> I declared the code generated by
  <command>gcc</command> to be unsuitable for a virus. And then
  rewrote the whole thing in assembly. A less drastic solution is
  to use inline assembly to correct only what's really necessary.
</para>

<sect2>
  <title>System calls</title>

  <para>
    Compare with <xref linkend="in_doubt_use_force">.
    No need for the function to set <varname>errno</varname>.
    We can't access global variables, anyway.
    Actually <link linkend="Target_infection">our code</link>
    does not care for the return value at all.
  </para>
  <formalpara>
    <title>Source - do_syscall</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../src/doing_it_in_c/do_syscall.inc"
      ></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Position independent code</title>

  <para>
    Previous examples required a separate pass to build the insertable
    code. Output of the first pass is one chunk of bytes. 
    The only interface to the infector is the place to patch with
    the original entry address (4 bytes at offset 1).
  </para>
  <para>
    The crucial part are the lines in
    <link linkend="copy_and_infect"
      ><function>writeInfection</function></link>
    where we pass the address of the chunk of bytes to  
    <citerefentry>
      <refentrytitle>write</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>.
    In a real virus these lines will also be part of inserted code.
    Let's have a look at the disassembly.
    Because of C++ name mangling this is not that easy, anyway.
  </para>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../src/doing_it_in_c/gdb.sh"
      ></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output - writeInfection.asm</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../out/doing_it_in_c/gdb_write_infection"
      ></programlisting>
    </para>
  </formalpara>

  <para>
    Member variables are accessed through <varname>this</varname>,
    which is kept in register <literal>ebx</literal>.
    This is a good thing. The bad thing are pushed constants
    <literal>&calc_write_infection_gdb_dword1_X;</literal>
    and
    <literal>&calc_write_infection_gdb_dword4_X;</literal>.
  </para>
  <para>
    The naive approach is to patch these instructions on infection.
    But this again leads to a two-pass process.
    The first is required to find the offset of required patches.
    A more comfortable approach is to make the code position independent
    by calculating absolute addresses at run-time.
    Note that <command>gcc</command>'s option <literal>-fpic</literal>
    does not help this problem at all.
  </para>
  <blockquote>
    <para><literal>-fpic</literal></para>
    <para>
     Generate position-independent code (PIC) suitable for use in a
     shared library, if supported for the target machine.  Such code
     accesses all constant addresses through a global offset table
     (GOT).  The dynamic loader resolves the GOT entries when the
     program starts (the dynamic loader is not part of GCC; it is part
     of the operating system).  If the GOT size for the linked
     executable exceeds a machine-specific maximum size, you get an
     error message from the linker indicating that <literal>-fpic</literal>
     does not work; in that case, recompile with <literal>-fPIC</literal>
     instead.  (These maximums are 16k on the m88k, 8k on the Sparc,
     and 32k on the m68k and RS/6000.  The 386 has no such limit.)
    </para>
  </blockquote>

</sect2>
<sect2>
  <title>IP or not IP</title>

  <para>
    The instruction pointer is a register that holds the address of
    the next instruction to execute. Unlike <quote>real</quote>
    registers there is no direct way to retrieve its value.
    A <literal>call</literal> pushes the current value of
    <literal>IP</literal> onto the stack and adds a relative offset
    to it. Doing a <literal>pop</literal> instead of <literal>ret</literal>
    will load the value <literal>IP</literal> had at a known position
    into a regular register.
  </para>

  <formalpara>
    <title>Source - relocate</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../src/doing_it_in_c/relocate.inc"
      ></programlisting>
    </para>
  </formalpara>

</sect2>
