<epigraph>
  <attribution>Arthur C. Clarke</attribution>
  <simpara>
    Any sufficiently advanced technology is indistinguishable from magic.
  </simpara>
</epigraph>

<simpara>
  Building executables from C source code is a complex task.
  An innocent looking call of
  <citerefentry>
    <refentrytitle>gcc</refentrytitle>
    <manvolnum>1</manvolnum>
  </citerefentry> will invoke a pre-processor, a multi-pass compiler,
an assembler and finally a linker.
  Using all these tools to plant virus code into another executable
  makes the result either prohibitively large, or very dependent on
  the completeness of the target installation.
</simpara>
<simpara>
  Real viruses approach the problem from the other end. They are
  aggressively optimized for code size and do only what's absolutely
  necessary. Basically they just copy one chunk of code and patch a few
  addresses at hard coded offsets.
</simpara>
<para>
  However, this has drastic effects:
  <itemizedlist>
    <listitem>
      <simpara>
	Since we directly copy binary code, the virus is restricted
	to a particular hardware architecture.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        Code must be position independent.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        Code cannot use shared libraries; not even the C runtime library.
      </simpara>
    </listitem>
    <listitem>
      <simpara>
        We cannot allocate global variables in the data segment.
      </simpara>
    </listitem>
  </itemizedlist>
</para>
<simpara>
  There are ways to circumvent these limitations. But they are
  complicated and make the virus more likely to fail.
</simpara>
<simpara>
  For the first example I'll present the simplest piece of code that
  still gives sufficient feedback. Our aim is to implant it into
  <filename>/bin/sh</filename>.
  On practically every recent installation of Linux/i386 the following code
  will emit three magic letters instead of just dumping core.
</simpara>

<sect2>
  <title>In the language of mortals</title>

  <formalpara>
    <title>Source</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
	fileref="../src/magic_elf/magic_elf.c" format="linespecific"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/cc.sh"
      ></imageobject></inlinemediaobject></programlisting
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/magic_elf/magic_elf"
      ></imageobject></inlinemediaobject></programlisting
    </para>
  </formalpara>

</sect2>
<sect2 id="how.it.works" xreflabel="How it works">
  <title>How it works</title>

  <sect3>
    <title>Digested answer</title>
    <simpara>
      The three letters are part of the signature of
      <acronym>ELF</acronym> files. Executables created by
      <citerefentry>
	<refentrytitle>ld</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry> are always mapped into the same memory region.
      That's why the program can find its own header at a predictable
      virtual address.
    </simpara>
  </sect3>

  <sect3>
    <title>Short answer</title>
    <simpara><ulink url="&http.jargon.RTFM;">RTFM</ulink>.</simpara>
    <simpara>
      The raw details are in <filename>/usr/include/elf.h</filename>.
      The canonical document describing the <acronym>ELF</acronym> file
      format for Intel-386 architectures can be found at
      <ulink url="&ftp.elf.spec.canonical;">&ftp.elf.spec.canonical;</ulink>.
      A flat-text version is <ulink url="&http.elf.spec.flat.text;"
        >&http.elf.spec.flat.text;</ulink>.
      And finally <ulink url="&http.teensy.executables;"
        >&http.teensy.executables;</ulink>
      humorously describes how far you can bend the rules to reach
      minimal size.
    </simpara>
  </sect3>

  <sect3 id="sort.of.an.answer" xreflabel="Sort of an answer">
    <title>Sort of an answer</title>
    <simpara>
      <constant>&calc.base.addr;</constant> is not a natural constant,
      but happens to be the default base address of
      <acronym>ELF</acronym> executables produced by
      <citerefentry>
	<refentrytitle>ld</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry>.
      As of version 2.11 of <application>binutils</application> it
      should be possible to change that with options
      <option>-Ttext ORG</option> and
      <option>--section-start SECTIONNAME=ORG</option>, but I didn't
      get it working. Anyway, the layout of executables produced by
      <citerefentry>
	<refentrytitle>ld</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry> is straight forward.
    </simpara>
    <orderedlist>
      <listitem><simpara>
	One <acronym>ELF</acronym> header -
	<structname>Elf32_Ehdr</structname>
      </simpara></listitem><listitem><simpara>
	Program headers - <structname>Elf32_Phdr</structname>
      </simpara></listitem><listitem><simpara>
	Program interpreter (not if statically linked)
      </simpara></listitem><listitem><simpara>
	Code
      </simpara></listitem><listitem><simpara>
	Data
      </simpara></listitem><listitem><simpara>
	Section headers - <structname>Elf32_Shdr</structname>
      </simpara></listitem>
    </orderedlist>
    <simpara>
      Everything from the start of the file to the last byte of code
      is mapped into one segment (named <quote>code</quote> or
      <quote>text</quote>) that begins at the base address.
      There is a whole chapter called
      <xref linkend="readelf" endterm="readelf"> describing a command
      to view all these details.
      In the meantime I will show fancy ways to get by without.
    </simpara>
  </sect3>

</sect2>
<sect2>
  <title>Showing off some tools</title>

  <simpara>
    What would you do if you knew nothing about <acronym>ELF</acronym>
    and just asked yourself how that example works? How can you go sure
    that the executable file really contains those three letters?
  </simpara>
  <simpara>
    A good start for finding text in binary files is
    <citerefentry>
      <refentrytitle>strings</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
  </simpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/strings.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/magic_elf/strings"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <simpara>
    The leading <literal>1:</literal> is written by
    <citerefentry>
      <refentrytitle>grep</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>
    and tells that our three-letter word is the first found string.
    This gives some help where we can find it in a hex dump. 
    It is difficult to search strings in such a dump because of
    line breaks. Interactive tools like
    <citerefentry>
      <refentrytitle>hexedit</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> might be useful.
  </simpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/od.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/magic_elf/od"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <simpara>
    At this point we can guess that file offset 1 and
    <literal>&calc.base.addr; + 1</literal> are not coincidental.
    A test program might help.
  </simpara>
  <formalpara>
    <title>Source - addr_of_main.c</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/addr_of_main.c"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/magic_elf/addr_of_main"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <simpara>
    Looks good. The byte at address <literal>&calc.base.addr; + 0</literal>
    is equal to that at file offset 0. And the address of function
    <function>main</function> is plausible.
  </simpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/ndisasm.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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. The really bad news is the generated code,
    however. Instead of a real system call for <function>write</function>
    we see a strange negative address. Let's have another try.
  </simpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/gdb.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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>
<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</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/magic_elf/cc_static.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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="evil.magic" 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
    (<ulink url="http://www.goethe.de/uk/mon/archiv/gh00/e23.htm"
      >twenty three</ulink> is the perfect number of bytes).
    I prefer
    <ulink url="&http.nasm.site;"><application>nasm</application></ulink>
    to <application>GNU as</application>.
  </simpara>

  <formalpara>
    <title>Source</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/evil_magic/evil_magic.asm"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/evil_magic/nasm.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../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="evil.magic.entry">
    <title>Entry point</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</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../src/evil_magic/od.sh"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../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; - &calc.base.addr; =
	&calc.evil.magic.ofs.X;
      </simpara>
    </blockquote>
  </sect3>

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

    <formalpara>
      <title>Command</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../src/evil_magic/ndisasm.sh"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara id="evil.magic.evil.magic.asm">
      <title>Output</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../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 filter written in
      <citerefentry>
	<refentrytitle>perl</refentrytitle>
	<manvolnum>1</manvolnum>
      </citerefentry> will do.
    </simpara>

    <formalpara>
      <title>Source</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../src/evil_magic/ndisasm.pl"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../out/evil_magic/evil_magic.c"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>

    <simpara>
      The <literal>__attribute__</literal> clause is explained in
      <xref linkend="a.section.called.text">.
      It is not required at this point.
    </simpara>
    <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</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../src/evil_magic/cc.sh"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific" fileref="../out/evil_magic/cc"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>

  </sect3>
</sect2>
<sect2>
  <title>Other roads to <acronym>ELF</acronym></title>

  <formalpara>
    <title>Source</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/other_magic/perl.pl"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/other_magic/perl"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/other_magic/mem.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/other_magic/mem"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <formalpara>
    <title>Command</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../src/other_magic/exe.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific" fileref="../out/other_magic/exe"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
      
</sect2>
