<epigraph>
  <attribution>Marcus Terentius Varro</attribution>
  <simpara>The longest part of the journey is said to be the passing of
    the gate.</simpara>
</epigraph>

<simpara
  >If we decide to leave <literal>entry_point</literal> as it is,
  we have to patch something else. One approach is to disassemble
  the code, starting at <literal>entry_point</literal>, find the first
  <literal>call</literal> (or <literal>jmp</literal>) and abuse it.
  This requires way too much intelligence for a virus, though.
  But then we are operating in a homogeneous environment,
  having one compiler and one C run-time library for all.
  The startup code should be the same for every executable.
</simpara>
<simpara
  >We uses the tool from <xref linkend="e_entry"/> to retrieve the
  entry point. On some shells a <literal>read</literal> from a pipe
  opens a sub-shell, i.e. it does not export the variables to the
  surrounding scope. The <literal>while</literal> loop is executed
  just once. Its only purpose is to build a block for
  <literal>read</literal>.</simpara>

<anchor id="command.entry.point.sh.gdb"/>
<formalpara>
  <title>Command: &config.PRE;/entry_point/gdb_core.sh</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../&config.PRE;/entry_point/gdb_core.sh"
    /></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>
<anchor id="output.entry.point.sh.gdb"/>
<formalpara>
  <title>Output: &config.OUT;/entry_point/sh.gdb</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../&config.OUT;/entry_point/sh.gdb"
    /></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>

<sect2 id="disassemble.it.again" xreflabel="Disassemble it again, Sam">
  <title>Disassemble it again, Sam</title>

  <simpara>
    Of course we have to implement a check whether the code at the
    entry address really looks like above output. Just in case the
    target is already infected (by a superior virus).
    To implement a comparison we only need offset and size,
    not actual opcodes. But I will feel better after I have them
    straight in front of me. And
    <citerefentry>
      <refentrytitle>ndisasm</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> starts counting with zero,
    which demands less brain activity.
  </simpara>

  <anchor id="command.disassemble.it.again"/>
  <formalpara>
    <title>Command: &config.PRE;/entry_point/&config.ASM.STYLE;.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.PRE;/entry_point/&config.ASM.STYLE;.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/entry_point/sh.disasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/sh.disasm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

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

  <simpara>
    There is one remaining issue. <varname
      >&config.ELF.EHDR;::e_entry</varname> is an absolute
    address, as is the value popped off the stack by
    <literal>ret</literal>. The operand of <literal>call</literal> and
    <literal>jmp</literal> is encoded relative to the location of the
    following instruction, however. The following is taken from the
    documentation of <application>nasm</application>.
    <footnote><simpara>
      Section A.2 at &url.nasmdoc.A.2; and A.13 at &url.nasmdoc.A.13;.
    </simpara></footnote>
  </simpara>
  <blockquote>
    <para
      ><literallayout
        >CALL imm                      ; E8 rw/rd             [8086]</literallayout>

      [&hellip;] 

      The codes <literal>rb</literal>, <literal>rw</literal> and
      <literal>rd</literal> indicate that one of the operands to the
      instruction is an immediate value, and that the difference between
      this value and the address of the end of the instruction is to be
      encoded as a byte, word or doubleword respectively.
      Where the form <literal>rw/rd</literal> appears, it indicates that
      either <literal>rw</literal> or <literal>rd</literal> should be
      used according to whether assembly is being performed in
      <literal>BITS 16</literal> or <literal>BITS 32</literal>
      state respectively.</para>
  </blockquote>

  <formalpara>
    <title>Source: src/one_step_closer/e2/patch_entry_addr.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../src/one_step_closer/e2/patch_entry_addr.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/one_step_closer/e2i1/cc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/one_step_closer/e2i1/cc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/one_step_closer/test-e2i1</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/one_step_closer/test-e2i1"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Second verse, same as the first</title>

  <simpara>
    Output looks nice, but we had that
    <link linkend="off.we.go">already</link>.
    What has increased code size and complexity gained us?
  </simpara>

  <formalpara>
    <title>Source: &config.PRE;/entry_point/entry_point.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.PRE;/entry_point/entry_point.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/entry_point/entry_point</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/entry_point"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    OK. One vulnerability of the infection is not visible to
    <citerefentry>
      <refentrytitle>readelf</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> anymore. But does that really help?
    It's still possible to write a heuristic scanner for it.
    All it takes is to verify the operand of <literal>call</literal>
    shown in the disassembly listing.
  </simpara>

  <formalpara>
    <title>Output: &config.OUT;/entry_point/e2.disasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/e2.disasm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    <link linkend="disassemble.it.again">Original value</link> is 
    &calc.sh.disasm.call0.addr.X;, which resolves into a shared library.
    The new value is local to the executable and easy to spot:
    &calc.infe2.disasm.call0.addr.X;. So what's the point?
  </simpara>

</sect2>
<sect2 id="use.the.source.luke" xreflabel="Use the Source, Luke">
  <title>Use the Source, Luke</title>

  <simpara>
    <citerefentry>
      <refentrytitle>gdb</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>
    <link linkend="output.entry.point.sh.gdb">revealed us</link>
    the name of the function whose <literal>call</literal> we abused:
    <function>&calc.sh.gdb.call0.name;</function>.
    I can't help thinking that it is part of glibc, but don't be hasty.
  </simpara>

  <formalpara>
    <title>Command: &config.PRE;/entry_point/ldd.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.PRE;/entry_point/ldd.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/entry_point/ldd</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/ldd"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    Now that we have a filename we can search the function in the library.
  </simpara>

  <formalpara>
    <title>Command: &config.PRE;/entry_point/nm.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.PRE;/entry_point/nm.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/entry_point/nm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/nm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    First class service. We even got a line number from
    <citerefentry>
      <refentrytitle>nm</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
  </simpara>

  <formalpara>
    <title>Source: src/entry_point/__libc_start_main</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../src/entry_point/__libc_start_main"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    If you have a procedure with 10 parameters,
    you probably missed some (according to an old saying).
  </simpara>
  <simpara>
    Let's see what this declaration tells about the
    <link linkend="disassemble.it.again">disassembled code</link>.
    For one thing, arguments are pushed in reverse order on the stack.
    This is the traditional way of the C.
    It allows easy implementation of functions like 
    <citerefentry>
      <refentrytitle>printf</refentrytitle>
      <manvolnum>3</manvolnum>
    </citerefentry>
    that take an arbitrary number of arguments.
    Actual values for arguments:
    <parameter>main</parameter> =
    <literal>&calc.sh.disasm.push2.X;</literal>,
    <parameter>init</parameter> =
    <literal>&calc.sh.disasm.push1.X;</literal>,
    <parameter>fini</parameter> =
    <literal>&calc.sh.disasm.push0.X;</literal>.
  </simpara>
  <simpara>
    The case of <parameter>rtld_fini</parameter> needs more documentation.
    &note.linuxassembly.startup;
    A comment from glibc's <filename>/usr/include/asm/elf.h</filename>:
  </simpara>
  <programlisting
    >/* SVR4/i386 ABI (pages 3-31, 3-32) says that when the program
    starts <literal>%edx</literal> contains a pointer to a function
    which might be registered using <function>atexit</function>.
    This provides a mean for the dynamic linker to call
    <literal>DT_FINI</literal> functions for shared libraries that
    have been loaded before the code runs.
    A value of 0 tells we have no such handler.</programlisting>

  <simpara>
    Anyway, even without looking at the complete source of
    <function>&calc.sh.gdb.call0.name;</function> I would guess that
    each of these function pointers is invoked at some time.
    Efforts are concentrated on <parameter>main</parameter>.
  </simpara>

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

  <formalpara>
    <title>Source: src/one_step_closer/e3/patch_entry_addr.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../src/one_step_closer/e3/patch_entry_addr.inc"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/one_step_closer/test-e3i1</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/one_step_closer/test-e3i1"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Two is company, three is an orgy</title>

  <simpara>
    We see the same nice output <link linkend="off.we.go">again</link>
    and <link linkend="target.patch.entry.addr.2">again</link>.
    So what's different this time?
  </simpara>

  <formalpara>
    <title>Output: &config.OUT;/entry_point/e3.disasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/entry_point/e3.disasm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    The difference to the
    <link linkend="disassemble.it.again">original</link>
    is less obvious. Both values of <parameter>main</parameter> are local
    to the executable. But <link linkend="second.scan">again</link> the
    modified value is less than &calc.sh.LOAD1.align.D; bytes from the end
    of the code segment.
  </simpara>
  <simpara>
    It seems that we achieved little. But the concept of studying
    source code to find patch points looks promising.
  </simpara>
</sect2>
