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

<para>
  After emotions cooled down a bit we can examine the infected executable
  and compare it with <link linkend="bashful_glance">the original</link>.
</para>

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

<formalpara>
  <title>Output</title>
  <para>
    <programlisting><inlinegraphic format="linespecific"
      fileref="../out/entry_point/readelf"
    ></programlisting>
  </para>
</formalpara>

<para>
  File size and code segment have grown as expected.
  Data segment and <literal>DYNAMIC</literal> segment moved accordingly:
</para>
<blockquote>
  <para>
    infected.file_size - sh.file_size =
    &calc_infone_size; - &calc_sh_size; =
    &calc_infone_size_delta_D; =
    &calc_infone_size_delta_X;
  </para>
  <para>
    infected.<literal>LOAD</literal>[1].<literal>Filesiz</literal> -
    sh.<literal>LOAD</literal>[1].<literal>Filesiz</literal> =
    &calc_infone_LOAD1_filesiz_X; -
    &calc_sh_LOAD1_filesiz_X; =
    &calc_infone_LOAD1_filesiz_delta_X;
  </para>
  <para>
    infected.<literal>LOAD</literal>[2].<literal>Offset</literal> -
    sh.<literal>LOAD</literal>[2].<literal>Offset</literal> =
    &calc_infone_LOAD2_offset_X; -
    &calc_sh_LOAD2_offset_X; =
    &calc_infone_LOAD2_offset_delta_X;
  </para>
  <para>
    infected.<literal>DYNAMIC</literal>.<literal>Offset</literal> -
    sh.<literal>DYNAMIC</literal>.<literal>Offset</literal> =
    &calc_infone_DYNAMIC1_offset_X; -
    &calc_sh_DYNAMIC1_offset_X; =
    &calc_infone_DYNAMIC1_offset_delta_X;
  </para>
</blockquote>

<sect2>
  <title>First scan</title>

  <para>
    Let's give the
    <link linkend="turn_the_pages">heuristic scanner</link> a try.
  </para>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
	fileref="../src/entry_point/scan.sh"
      ></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
	fileref="../out/entry_point/scan"
      ></programlisting>
    </para>
  </formalpara>

  <para>
    As predicted. This is like playing chess against oneself, and losing.
    Can't do much about it, though.
    I'll fix something else in revenge.
  </para>

</sect2>
<sect2>
  <title>Second scan</title>

  <para>
    The value of <literal>Entry point</literal> changed dramatically.
    In the original it is in the first part of the file:
  </para>
  <blockquote>
    <para>
      entry_point_ofs =
      &calc_sh_entry_point_X; - &calc_base_addr; = 
      &calc_sh_entry_point_start_ofs_X; =
      &calc_sh_entry_point_start_ofs_D; bytes.
    </para>
  </blockquote>

  <para>
    The infected copy moved that to exactly &calc_sh_LOAD1_align_D;
    bytes from the end of the code segment.
  </para>

  <blockquote>
    <para>
      entry_point_ofs =
      &calc_infone_entry_point_X; - &calc_base_addr; = 
      &calc_infone_entry_point_start_ofs_X; =
      &calc_infone_entry_point_start_ofs_D; bytes.
    </para>
    <para>
      end_of_LOAD1 =
      &calc_infone_LOAD1_virtaddr_X; +
      &calc_infone_LOAD1_filesiz_X; =
      &calc_infone_LOAD1_end_X;
    </para>
    <para>
      entry_point_distance_to_end =
      &calc_infone_LOAD1_end_X; - 
      &calc_infone_entry_point_X; =
      &calc_infone_entry_point_dist_to_end_X; =
      &calc_infone_entry_point_dist_to_end_D;
    </para>
  </blockquote>

  <para>
    This is another easy vulnerability to scanners.
    By restructuring <link linkend="Target_infection">our code</link>
    we can make that number even smaller. But for a real cure we
    need stronger voodoo.
  </para>

</sect2>
<sect2>
  <title>Patch me if you can</title>

  <para>
    If we chose 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.
  </para>
  <para>
    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.
  </para>

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

  <para>
    Looks plausible. Anyway, we have to implement a check whether
    the code at the entry address really looks like this.
    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 <command>ndisasm</command> counts
    starting with zero, which requires less brain activity.
  </para>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
	fileref="../src/entry_point/ndisasm.sh"
      ></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
	fileref="../out/entry_point/ndisasm"
      ></programlisting>
    </para>
  </formalpara>

</sect2>
<sect2>
  <title>patchEntryAddr 2.0</title>

  <para>
    There is one remaining issue. <varname>Elf32_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. This is described in the documentation
    of <ulink url="&nasm_site;">nasm</ulink>:
  </para>
  <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 - patchEntryAddr</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../src/one_step_closer/patch_entry_addr_two.inc"
      ></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output - test script</title>
    <para>
      <programlisting><inlinegraphic format="linespecific"
        fileref="../out/one_step_closer/two-test"
      ></programlisting>
    </para>
  </formalpara>

</sect2>
