<epigraph>
  <attribution>Donald Knuth</attribution>
  <simpara>
    A person who is more than casually interested in computers
    should be well schooled in machine language, since it is a
    fundamental part of a computer.
  </simpara>
</epigraph>

<simpara>
  The scanners in <xref linkend="turn.the.pages"> and
  <xref linkend="second.scan"> check program layout for deviations.
  On a typical Linux distribution this yields good results
  since all programs are compiled and linked with the same
  set of tools. But there are legitimate reasons for executables
  to look different. Some rescue tools and non-free executables
  are linked statically to be independent of the target system.
  And then there is
  <ulink url="&http.asmutils;">asmutils</ulink> on
  <ulink url="&http.linuxassembly;">&http.linuxassembly;</ulink>
</simpara>
<blockquote>
  <simpara>
    asmutils is a set of miscellaneous utilities written in
    assembly language, targeted on embedded systems and small
    distributions (e.g. installation or rescue disks); also it
    contains a small libc and a crypto library. It features the
    smallest possible size and memory requirements, the fastest
    speed, and offers fairly good functionality.
  </simpara>
</blockquote>

<simpara>
  The next best approach is to follow the flow of control
  and verify visited code, starting from the entry point.
  Again this relies on a certain homogeneity of executables.
</simpara>

<orderedlist>
  <listitem>
    <simpara>
      A very simple check is alignment.
      We handle that <link linkend="copy.and.infect">here</link>
      and <link linkend="copy.and.infect.v2">here</link>.
      <citerefentry>
	<refentrytitle>gcc</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry> never starts functions on odd addresses.
      But neither VIT nor
      <link linkend="rst"><acronym>RST</acronym></link> seem to care
      and put the infection after the last byte of the code segment.
    </simpara>
  </listitem>
  <listitem>
    <simpara>
      The improved versions of <function>patchEntryAddr</function>
      in <xref linkend="entry.point"> do a primitive check of the call
      to <function>&calc.sh.gdb.call0.name;</function>.
      Since we leave the entry point unmodified we pass this test.
    </simpara>
  </listitem>
  <listitem>
    <simpara>
      The next step is to check entry code of functions called by
      <function>&calc.sh.gdb.call0.name;</function>,
      especially <function>main</function>.
      We are vulnerable to this.
    </simpara>
  </listitem>
</orderedlist>

<sect2 id="disassembly" xreflabel="Disassembly">
  <title>Disassembly</title>

  <simpara>
    <xref linkend="patch.entry.addr.3.0"> patches the call of
    &calc.sh.gdb.call0.name; to invoke our virus code instead
    of <function>main</function>. To stay undetected our code
    should mimic the real thing. The
    <link linkend="output.magic.elf.gdb">disassembly</link>
    of our <link linkend="the.language.of.mortals">first program</link>
    shows everything we need to know.
    But then that listing was retrieved through heavy cheating.
  </simpara>
  <simpara>
    To disassembly the <function>main</function> of a regular
    executable we extend the exercise of
    <xref linkend="disassemble.it.again">.
    The script performs no kind of error checking.
    Feeding anything else than executables built by
    <citerefentry>
      <refentrytitle>gcc</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> can have strange effects (like no output at all).
    There is also no limit on output length. In the examples below
    the <filename>Makefile</filename> building this document used 
    <citerefentry>
      <refentrytitle>head</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
  </simpara>

  <formalpara>
    <title>Command: src/stub_revisited/ndisasm.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/stub_revisited/ndisasm.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    First a simple test. Compare with above mentioned
    <link linkend="output.magic.elf.gdb">disassembly</link>.
  </simpara>
  <formalpara>
    <title>Output: out/i386/stub_revisited/magic_elf.ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/stub_revisited/magic_elf.ndisasm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    A look at <filename>tmp/doing_it_in_c/e3/sh_infected</filename>.
  </simpara>
  <formalpara>
    <title>Output: out/i386/stub_revisited/sh_infected.ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/stub_revisited/sh_infected.ndisasm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>And this is plain <filename>/bin/bash</filename>.</simpara>
  <formalpara>
    <title>Output: out/i386/stub_revisited/sh.ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/stub_revisited/sh.ndisasm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    The first two instructions, making up three bytes, are constant.
    They are followed by an optional series of <literal>push</literal>
    to save special registers. Then comes a <literal>sub esp</literal>
    to reserve space for local variables. This also seems to be constant.
    Trivial <xref linkend="the.language.of.mortals"> does not
    use local variables and still ends up with a
    <literal>sub</literal>.
  </simpara>

  <simpara>
    For the exit code of <filename>/bin/bash</filename> we need
    a better filter.
  </simpara>
  <formalpara>
    <title>Command: src/stub_revisited/ndisasm_ret.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/stub_revisited/ndisasm_ret.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/stub_revisited/sh_ret.ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/stub_revisited/sh_ret.ndisasm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    I call this weird. It seems that <literal>0xc</literal> byte
    are reserved on the stack just to stay unused. And why does
    one program use <literal>leave</literal> and the other
    <literal>pop ebp</literal>? A quote from
    <ulink url="&http.nasmdoc;nasmdoca.html##section-A.94"
      >section A.94</ulink> of the documentation of
    <ulink url="&http.nasm;">nasm</ulink>:
  </simpara>
  <blockquote>
    <para
      ><literallayout
        >LEAVE                         ; C9                   [186]</literallayout>
      <literal>LEAVE</literal> destroys a stack frame of the form
      created by the <literal>ENTER</literal> instruction
      (see <ulink url="&http.nasmdoc;nasmdoca.html##section-A.27"
        >section A.27</ulink>). It is functionally
      equivalent to <literal>MOV ESP,EBP</literal> followed by
      <literal>POP EBP</literal>.
    </para>
  </blockquote>
  <simpara>
    I guess that we are safe on that front.
    It's easy to check the existence of fixed byte values at a
    certain location (the entry code).
    But I doubt whether a static scanner could really realize
    whether a given exit code is just a dummy. Or what instruction
    a <literal>ret</literal> effectively jumps to.
  </simpara>

</sect2>
<sect2 id="stack.dump" xreflabel="Stack dump">
  <title>Stack dump</title>

  <simpara>
    Let's examine the stack of
    <link linkend="output.magic.elf.gdb">In the language of mortals</link>
    just after the <literal>sub</literal> was executed.
    Note that you don't have to quote character
    <quote><literal>$</literal></quote> in interactive 
    <citerefentry>
      <refentrytitle>gdb</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> sessions.
    Instead of <quote><literal>\$sp</literal></quote> you type plain
    <quote><literal>$sp</literal></quote> to reference the stack pointer.
  </simpara>

  <formalpara>
    <title>Command: src/stub_revisited/stack.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/stub_revisited/stack.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/stub_revisited/stack</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/stub_revisited/stack"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Another look at the source</title>

  <simpara>
    The program was stopped at address
    <literal>&calc.evil.magic.gdb.stack.frame0.ret.X;</literal>
    in function <function>&calc.evil.magic.gdb.stack.frame0.ret</function>,
    which was called from
    <function>&calc.evil.magic.gdb.stack.frame1.ret;</function>.
    We already encountered file
    <filename>&calc.evil.magic.gdb.stack.frame1.source;</filename>
    in <xref linkend="use.the.source.luke">. For sheer curiosity
    a look at line &calc.evil.magic.gdb.stack.frame1.source.D;:
  </simpara>

  <formalpara>
    <title>Command: src/stub_revisited/get_libc_start_main.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/stub_revisited/get_libc_start_main.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Command: src/stub_revisited/__libc_start_main</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/stub_revisited/__libc_start_main"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>Looks plausible.</simpara>

</sect2>
<sect2>
  <title>A few bytes on the stack</title>

  <simpara>
  </simpara>

  <informaltable frame="topbot" pgwide="1">
    <tgroup cols="2">
      <colspec colname="address">
      <colspec colname="esp">
      <colspec colname="ebp">
      <colspec colname="contents">
      <colspec colname="description">
      <spanspec spanname="hspan" namest="address" nameend="description">
      <thead>
	<row>
	  <entry>Address</entry>
	  <entry>esp</entry>
	  <entry>ebp</entry>
	  <entry>Contents</entry>
	  <entry>Description</entry>
	</row>
      </thead>
      <tbody>
        <row>
	  <entry spanname="hspan">
	    The top three values on the stack are just random junk.
	    The instruction just before our break point decremented
	    <literal>esp</literal> by <literal>0xc = 12</literal> to
	    use that space for local variables. They are not
	    initialized yet, though.
          </entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack0.addr.X</literal></entry>
          <entry><literal>esp + 0</literal></entry>
          <entry><literal>ebp - 12</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack0.X;</literal></entry>
          <entry>random junk</entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack1.addr.X</literal></entry>
          <entry><literal>esp + 4</literal></entry>
          <entry><literal>ebp - 8</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack1.X;</literal></entry>
          <entry>random junk</entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack2.addr.X</literal></entry>
          <entry><literal>esp + 8</literal></entry>
          <entry><literal>ebp - 4</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack2.X;</literal></entry>
          <entry>random junk</entry>
        </row>
        <row>
	  <entry spanname="hspan">
	    Everything further down - including the next two values -
	    must be preserved for the host code.
          </entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack3.addr.X</literal></entry>
          <entry><literal>esp + 12</literal></entry>
          <entry><literal>ebp + 0</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack3.X;</literal></entry>
          <entry>saved ebp</entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack4.addr.X</literal></entry>
          <entry><literal>esp + 16</literal></entry>
          <entry><literal>ebp + 4</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack4.X;</literal></entry>
          <entry>return address</entry>
        </row>
        <row>
	  <entry spanname="hspan">
	    The next three values are the arguments of
	    <function>main</function>. We declared the function
	    as plain <literal>main()</literal> so 
	    <citerefentry>
	      <refentrytitle>gdb</refentrytitle>
	      <manvolnum>1</manvolnum>
	    </citerefentry>
	    does not know about these identifiers.
          </entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack5.addr.X</literal></entry>
          <entry><literal>esp + 20</literal></entry>
          <entry><literal>ebp + 8</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack5.X;</literal></entry>
          <entry><varname>argc</varname></entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack6.addr.X</literal></entry>
          <entry><literal>esp + 24</literal></entry>
          <entry><literal>ebp + 12</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack6.X;</literal></entry>
          <entry><varname>argv</varname></entry>
        </row>
        <row>
          <entry><literal>&calc.evil.magic.gdb.stack7.addr.X</literal></entry>
          <entry><literal>esp + 28</literal></entry>
          <entry><literal>ebp + 16</literal></entry>
	  <entry><literal>&calc.evil.magic.gdb.stack7.X;</literal></entry>
          <entry><varname>environ</varname></entry>
        </row>
        <row>
	  <entry spanname="hspan">
	    The next few values up to &calc.evil.magic.gdb.stack3.X;
	    (saved <literal>ebp</literal>) are local variables of
	    <function>&calc.evil.magic.gdb.stack.frame1.ret;</function>.
	  </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>

  <simpara>The new stub must fulfill a few constraints.</simpara>
  <itemizedlist>
    <listitem>
      <simpara>Both entry code and exit code is fixed.</simpara>
    </listitem>
    <listitem>
      <simpara>
        The stack below <literal>ebp + 0</literal> must not be modified.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        After executing infectious code it must jump to the
	original host code.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        Original host code expects the value of <literal>esp</literal>
	to be <literal>&calc.evil.magic.gdb.stack4.addr.X</literal>
	and the value of <literal>ebp</literal> to be
	<literal>&calc.evil.magic.gdb.stack3.X</literal>
	(values are not constant, just given for illustration).
      </simpara>
    </listitem>
  </itemizedlist>

</sect2>
<sect2>
  <title>First implementation</title>

  <simpara>
    If we keep original exit code then we must modify the stack.
    The simpliest approach is to move the original
    <literal>ebp</literal> one position (4 bytes) down.
    Original entry code already reserved 12 unused bytes so we
    don't have to adjust <literal>esp</literal>.
    In the free space we store the address of host code.
  </simpara>
  <formalpara>
    <title>Source: src/doing_it_in_c/i2/infection.asm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/doing_it_in_c/i2/infection.asm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    The following disassembly shows stub and the first function
    of the C part, called <function>body</function>.
    The stub ends with a few <literal>nop</literal> instructions
    to align its size. Flow of control just continues from stub
    to <function>body</function>. Since this is a regular C function
    it also has standard entry code. But this does not matter because
    standard exit code starts with a <literal>leave</literal>.
    No matter how much stuff was pushed on the stack between
    end of stub and exit code of <function>body</function>,
    the <literal>leave</literal> instruction will pop off the
    moved <literal>ebp</literal>. The following <literal>ret</literal>
    then jumps to host code.
  </simpara>
  <formalpara>
    <title>Source: out/i386/doing_it_in_c/e3i2.ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/e3i2.ndisasm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>First test</title>

  <formalpara>
    <title>Output: out/i386/doing_it_in_c/e3i2/cc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/e3i2/cc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output: out/i386/doing_it_in_c/test-e3i2</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/test-e3i2"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Second implementation</title>

  <simpara>
    This is the same idea, only obfuscated by an intermediate
    <literal>call</literal>. Variations on this topic are endless.
  </simpara>
  <formalpara>
    <title>Source: src/doing_it_in_c/i3/infection.asm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/doing_it_in_c/i3/infection.asm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Source: out/i386/doing_it_in_c/i3/infection.inc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/i3/infection.inc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>Second test</title>

  <formalpara>
    <title>Output: out/i386/doing_it_in_c/e3i3/cc</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/e3i3/cc"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output: out/i386/doing_it_in_c/test-e3i3</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/doing_it_in_c/test-e3i3"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

</sect2>
