<epigraph>
  <attribution>
    Spock and McCoy, <quote>And The Children Shall Lead</quote>,
    star date 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>

&xml.language.of.evil.ndisasm;

<simpara>
  While the simplicity of <application>ndisasm</application> is charming,
  the glitches in <application>objdump</application>'s output require
  heavy machinery. Note that character <quote><literal>;</literal></quote>
  starts a comment on <literal>i386</literal>. On <literal>sparc</literal>
  a <quote><literal>!</literal></quote> is used instead.
</simpara>

<formalpara>
  <title>Command: src/magic_elf/objdump.sh</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../src/magic_elf/objdump.sh"
    /></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>
<formalpara>
  <title>Command: src/magic_elf/objdump_format.sh</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../src/magic_elf/objdump_format.sh"
    /></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>
<formalpara>
  <title>Output: &config.OUT;/magic_elf/objdump</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../&config.OUT;/magic_elf/objdump"
    /></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.
  And instead of a real system call for <function>write</function>
  we see a call to strange negative address (check the opcode).
  It resolves to a location in a shared library.
  But what function in what library?
</simpara>

<formalpara>
  <title>Command: src/magic_elf/gdb-core.sh</title>
  <para>
    <programlisting><inlinemediaobject><imageobject><imagedata
      format="linespecific"
      fileref="../../src/magic_elf/gdb-core.sh"
    /></imageobject></inlinemediaobject></programlisting>
  </para>
</formalpara>
<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>
  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;/evil_magic/static_main.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/evil_magic/static_main.gdb"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    The function was called
    <function>&calc.magic_elf.gdb.call0.name</function> before,
    it is called
    <function>&calc.magic_elf_static.gdb.call0.name</function>
    now. Let's look what is behind the name.
  </simpara>
  <formalpara>
    <title>Output: &config.OUT;/evil_magic/static_write.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/evil_magic/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>&xml.language.of.evil.syscall;</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. &xml.language.of.evil.hand.crafted;
  </simpara>

  <formalpara>
    <title>Source: src/evil_magic/&config.ARCH;-&config.UNAME;.asm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../src/evil_magic/&config.ARCH;-&config.UNAME;.asm"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Command: src/evil_magic/&config.ASM.STYLE;.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../src/evil_magic/&config.ASM.STYLE;.sh"
      /></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: &config.OUT;/evil_magic/&config.ASM.STYLE;</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../../&config.OUT;/evil_magic/&config.ASM.STYLE;"
      /></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>

</sect2>
<sect2  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.
  </simpara>

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

  <simpara>
    A look into <filename>/usr/include/elf.h</filename> shows that
    <varname>Elf&config.ELF.ADDRSIZE;_Ehdr::e_entry</varname>
    is really at file offset 24.
  </simpara>

  <formalpara>
    <title>Command: src/evil_magic/od/&config.UNAME;.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
	format="linespecific"
	fileref="../../src/evil_magic/od/&config.UNAME;.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>

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

  <formalpara>
    <title>Command: &config.OUT;/evil_magic/dis-&config.ASM.STYLE;.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
	format="linespecific"
	fileref="../../&config.OUT;/evil_magic/dis-&config.ASM.STYLE;.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>

</sect2>
<sect2  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.
    We use the script from &yref.dressing.up.binary.code;.
  </simpara>

  <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>

</sect2>
