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

<sect2>
  <title>Executable and linkable format</title>

  <simpara>
    Another natural limitation of viruses is rigid dependency on the
    file format of target executables. These formats differ a lot.
    Even on the same hardware architecture. Or under the same
    operating system. Furthermore executable are not designed with
    post link-time modifications in mind. It's rare for a virus to
    support more than one infection method. This document is about
    the format used on recent versions of Linux, FreeBSD and Solaris.
  </simpara>

  <simpara>
    <ulink url="&http.elf.spec.flat.text;"
      >From the Portable Formats Specification, Version 1.1:</ulink>
  </simpara>
  <blockquote>
    <simpara>
      The Executable and Linking Format was originally developed
      and published by UNIX System Laboratories (USL) as part of
      the Application Binary Interface (ABI). The Tool Interface
      Standards committee (TIS) has selected the evolving ELF standard
      as a portable object file format that works on 32-bit Intel
      Architecture environments for a variety of operating systems.
    </simpara>
  </blockquote>

  <simpara>
    Actually ELF is defined for a variety of both 32 bit and 64 bit
    architectures. This document tries to cover multiple platforms
    through conditional compilation. There is a
    <filename>configure.pl</filename> that determines the host type
    and sets up a <filename>Makefile</filename>.
    The <filename>Makefile</filename> uses individual sub-directories
    for each platform and exports the name of these directories
    (and some other platform specific values) as environment variables.
    Most of the shell scripts invoked by
    <citerefentry>
      <refentrytitle>make</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> are shown here.
    The following table should help to understand them.
  </simpara>

  <table frame="none" pgwide="1">
    <title>Environment variables exported by Makefile</title>
    <tgroup cols="2">
      <thead>
	<row>
	  <entry>Variable</entry>
	  <entry>Value on this platform</entry>
	</row>
      </thead>
      <tbody>
	<row><entry>${ARCH}</entry><entry>&config.ARCH;</entry></row>
	<row><entry>${CFLAGS}</entry><entry>&config.CFLAGS;</entry></row>
	<row><entry>${ELFBASE}</entry><entry>&config.ELFBASE;</entry></row>
	<row><entry>${OUT}</entry><entry>&config.OUT;</entry></row>
	<row><entry>${TMP}</entry><entry>&config.TMP;</entry></row>
      </tbody>
    </tgroup>
  </table>

</sect2>
<sect2 id="the.language.of.mortals" xreflabel="The language of mortals">
  <title>The language of mortals</title>

  <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 &config.HOSTTYPE; the
    following code will emit three magic letters instead of just
    dumping core.
  </simpara>

  <formalpara>
    <title>Source: out/i386/magic_elf/magic_elf.c</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
	format="linespecific"
	fileref="../out/i386/magic_elf/magic_elf.c"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>

  <simpara>
    It is not an error that a file called
    <filename>magic_elf.c</filename> is located
    in a directory called <filename>out/i386</filename>.
    The <filename>Makefile</filename> building this document
    did trivial pre-processing on the original source file.
    ELF is used on many architectures. And each has a different magic value.
  </simpara>

  <formalpara>
    <title>Command: src/magic_elf/cc.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/cc.sh"
      ></imageobject></inlinemediaobject></programlisting
    ></para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/magic_elf/magic_elf</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: src/magic_elf/strings.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/strings.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/magic_elf/strings</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: src/magic_elf/od.sh</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../src/magic_elf/od.sh"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/magic_elf/od</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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>

</sect2>
<sect2 id="address.of.main" xreflabel="The address of main">
  <title>The address of main</title>

  <formalpara>
    <title>Source: out/i386/magic_elf/addr_of_main.c</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/magic_elf/addr_of_main.c"
      ></imageobject></inlinemediaobject></programlisting>
    </para>
  </formalpara>
  <formalpara>
    <title>Output: out/i386/magic_elf/addr_of_main</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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 &calc.magic.elf.addr.main.X;
    is a plausible address of function <function>main</function>.
  </simpara>
  <simpara>
    The fancy output format was chosen for a reason.
    It is valid input for <filename>/bin/sh</filename>.
  </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>
  <simpara>
    If the listing below makes you feel uncomfortable
    you can have a look at <ulink url="&http.linuxassembly;"
      >&http.linuxassembly;</ulink>. If that does not help,
    probably nothing will.
    The <ulink url="&http.HOWTO.assembly;">Assembly-HOWTO</ulink>
    gives description of tools and sites.
    <ulink url="&http.robin.miyagi;"
      >Robin Miyagi's Linux Programming</ulink> features
    a tutorial and some interesting links.
    Advanced topics are at
    <ulink url="&http.agner.org;">Assembly resources</ulink>.
    And then there is
    <ulink url="&http.intel.pentium4;"
      >IA-32 Intel Architecture Software Developer's Manual</ulink>.
  </simpara>

  <formalpara>
    <title>Output: out/i386/magic_elf/ndisasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: out/i386/magic_elf/gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: 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: out/i386/magic_elf/magic_elf_static</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: out/i386/magic_elf/static_main.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: out/i386/magic_elf/static_write.gdb</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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="the.language.of.evil" xreflabel="The language of evil">
  <title>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;"><application>nasm</application></ulink>
    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: out/i386/evil_magic/nasm</title>
    <para>
      <programlisting><inlinemediaobject><imageobject><imagedata
        format="linespecific"
	fileref="../out/i386/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: out/i386/evil_magic/od</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../out/i386/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: out/i386/evil_magic/ndisasm.sh</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../out/i386/evil_magic/ndisasm.sh"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara id="evil.magic.evil.magic.asm">
      <title>Output: out/i386/evil_magic/evil_magic.asm</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../out/i386/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: out/i386/evil_magic/evil_magic.c</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../out/i386/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: out/i386/evil_magic/cc</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../out/i386/evil_magic/cc"
	></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>

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

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

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

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