<epigraph>
  <attribution>
    Spock and McCoy, <quote>And The Children Shall Lead</quote>,
    stardate 5029.5.
  </attribution>
  <simpara>
    <quote>Evil does seek to maintain power by suppressing the
    truth.</quote>
  </simpara>
  <simpara><quote>Or by misleading the innocent.</quote></simpara>
</epigraph>

  <simpara>
    The fancy output format of <xref linkend="address.of.main"/>
    was chosen for a reason. It is valid input for
    <filename>/bin/sh</filename>.
    Let's see whether <xref linkend="in.the.language.of.mortals"/>
    has <function>main</function> at the same offset.
  </simpara>
  <formalpara>
    <title>Command: src/magic_elf/ndisasm.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/ndisasm.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Output: &config.OUT;/magic_elf/ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/magic_elf/ndisasm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <simpara>
    Both programs have <function>main</function> at the same file offset.
    Unfortunately a brief look through <filename>/bin</filename> proves
    this to be pure chance.
  </simpara>
  <simpara>
    Instead of a real system call for <function>write</function>
    we see a call to strange negative address (check the opcode).
    <citerefentry>
      <refentrytitle>ndisasm</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> resolves this address to a location in glibc.
    However, during development I encountered a configuration of my
    system where
    <citerefentry>
      <refentrytitle>ndisasm</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> failed to do so.
    The rest of the story is still interesting, though.
    Yet another way to do it.
  </simpara>
  <formalpara>
    <title>Command: src/magic_elf/gdb.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/gdb.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <anchor id="output.magic.elf.gdb"/>
  <formalpara>
    <title>Output: &config.OUT;/magic_elf/gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/magic_elf/gdb"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <simpara>
    That strange negative address resolves to a function in a
    shared library. Not shown is a pathetic attempt to single-step
    to the actual code of <function>write</function>.
 </simpara>

<sect2 id="in.doubt.use.force" xreflabel="In doubt use force">
  <title>In doubt use force</title>

  <simpara>
    We can now search for a fine manual explaining how to debug
    shared libraries. Or just compile the bugger static.
  </simpara>
  <formalpara>
    <title>Command: src/magic_elf/cc_static.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/cc_static.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/magic_elf/magic_elf_static</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/magic_elf/magic_elf_static"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    Seems we found an easy way to fill up the hard disk.
    Anyway, what has
    <citerefentry>
      <refentrytitle>gdb</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> to say about it?
  </simpara>
  <formalpara>
    <title>Output: &config.OUT;/magic_elf/static_main.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/magic_elf/static_main.gdb"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    The name of the function changed for no apparent reason.
    But it is reachable for disassembly now.
  </simpara>
  <formalpara>
    <title>Output: &config.OUT;/magic_elf/static_write.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/magic_elf/static_write.gdb"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    There are two man pages giving some overview of system calls,
    <citerefentry>
      <refentrytitle>intro</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>
    and
    <citerefentry>
      <refentrytitle>syscalls</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>.
    The statement <literal>mov eax,4</literal> corresponds to
    the value of <literal>__NR_write</literal> in
    <filename>/usr/include/asm/unistd.h</filename>.
  </simpara>

</sect2>
<sect2 id="in.the.language.of.evil"
  xreflabel="In the language of evil">
  <title>In the language of evil</title>

  <simpara>
    The code generated by
    <citerefentry>
      <refentrytitle>gcc</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> is not suitable for a virus. So here comes hand
    crafted code optimized for size
    (twenty three is the perfect number of bytes &note.twenty.three;).
    I prefer <application>nasm</application> &note.nasm; to
    <application>GNU as</application>.
  </simpara>

  <formalpara>
    <title>Source: src/evil_magic/evil_magic.asm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/evil_magic/evil_magic.asm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Command: src/evil_magic/nasm.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/evil_magic/nasm.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/evil_magic/nasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../&config.OUT;/evil_magic/nasm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    Output is good. But how do we get the resulting machine code?
    We can't just add a call to
    <citerefentry>
      <refentrytitle>printf</refentrytitle>
      <manvolnum>3</manvolnum>
    </citerefentry>
    to the assembly code. Above example is not linked with glibc;
    it does not even have a function called <function>main</function>.
  </simpara>

  <sect3  id="enter.evil" xreflabel="Enter evil">
    <title>Enter evil</title>

    <simpara>
      On the other hand things became a lot easier. There is no
      initialization code that gets executed before
      <function>_start</function>, so the address of
      <function>_start</function> is really the <acronym>ELF</acronym>
      entry point of the executable. A look into
      <filename>/usr/include/elf.h</filename> shows that
      <varname>Elf32_Ehdr::e_entry</varname> is at file offset 24.
    </simpara>

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

    <simpara>
      The entry point is specified as a virtual address in memory.
      By subtracting the base address we get the file offset: 
    </simpara>
    <blockquote>
      <simpara>
	&calc.evil.magic.start.X; - &calc.base.addr; =
	&calc.evil.magic.ofs.X; = &calc.evil.magic.ofs.D;
      </simpara>
    </blockquote>
  </sect3>

  <sect3  id="evil.magic.revealed">
    <title>Evil magic revealed</title>

    <formalpara>
      <title>Command: &config.OUT;/evil_magic/ndisasm.sh</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../&config.OUT;/evil_magic/ndisasm.sh"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara id="evil.magic.evil.magic.asm">
      <title>Output: &config.OUT;/evil_magic/evil_magic.asm</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../&config.OUT;/evil_magic/evil_magic.asm"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
  </sect3>

  <sect3  id="dressing.up.binary.code"
    xreflabel="Dressing up binary code">
    <title>Dressing up binary code</title>

    <simpara>
      There is still one thing left:
      Dressing up the hex dump as C source.
      A small filter written in
      <citerefentry>
	<refentrytitle>perl</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry> would do.
      Because this tool will be used throughout the document
      it provides a lot of features, however.
    </simpara>
    <simpara>
      The <literal>__attribute__</literal> clause is explained in
      <xref linkend="a.section.called.text"/>.
      It is not required at this point.
    </simpara>
    <simpara>
      Initializing the array with string literals (looking like
      <literal>\xDE\xAD\xBE\xEF</literal>) is easier.
      The terminating zero would not work with
      <xref linkend="doing.it.in.c"/>, however.
      But then using a list of hexadecimal numbers introduces
      separating comas, requiring special treatment of the last line.
    </simpara>
    <simpara>
      If command line option <option>-last_line_is_ofs</option>
      is passed to the program then the last line of disassembly
      is meant to specify a offset into the code.
      Actually it's just the last byte of that line.
      You are free to use any dummy operation,
      like <literal>push byte 1</literal>.
      See <xref linkend="Target.infection"/> for an example.
    </simpara>

    <formalpara>
      <title>Source: src/evil_magic/ndisasm.pl</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../src/evil_magic/ndisasm.pl"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output: &config.OUT;/evil_magic/evil_magic.c</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../&config.OUT;/evil_magic/evil_magic.c"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>

    <simpara>
      Calling the string constant <varname>main</varname> is not
      a mistake. Above output is a complete and valid C program.
    </simpara>

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

  </sect3>
</sect2>
