<epigraph>
  <attribution>Groucho Marx</attribution>
  <simpara>Outside of a dog, a book is a man's best friend.</simpara>
  <simpara>Inside a dog it's too dark to read.</simpara>
</epigraph>

<simpara
  ><acronym>ELF</acronym> provides two parallel views of a file's
  contents. The linking view is defined by the section header table,
  an array of <literal>&config.ELF.SHDR;</literal>. The
  execution view is defined by the program header table, an array
  of <literal>&config.ELF.PHDR;</literal>.
</simpara>
<simpara
  >Theoretically the <acronym>ELF</acronym> specification is quite
  liberal. Position, contents and order of sections and segments are
  not restricted. But in real life an operating system is to used to
  just one program loader, one linker and few compilers.
  This makes the work of virus writers easier. We can reverse engineer
  the de-facto standard, a tiny subset of what the <acronym>ELF</acronym>
  standard allows. On a typical system only a minority of programs
  violates this subset, so ignoring them does not lower chances of survival.
</simpara>
<simpara
  >The entries of both section header table and program header table are
  ordered, consecutive, non-overlapping and cover every byte of the file.
  The standard describes section headers as optional for programs,
  but you can't build dynamically linked executables without them.
  Still worse,
  <citerefentry>
    <refentrytitle>strip</refentrytitle>
    <manvolnum>1</manvolnum>
  </citerefentry> performs a destructive operation on the section
  headers that will break infected executables if we don't maintain
  the section headers as well.
</simpara>

<sect2 id="segments" xreflabel="Segments">
  <title>Segments</title>

  <simpara
    >Let's get a bit more serious and examine the assembly program from
    <xref linkend="language.of.evil"/>. A standalone executable
    built from assembler source is probably the most trivial example
    we can find.
  </simpara>

  <simplesect>
    <title>objdump</title>

    <formalpara>
      <title>Command: &config.PRE;/readelf/segments/objdump.sh</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../../&config.PRE;/readelf/segments/objdump.sh"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output: &config.OUT;/readelf/segments/objdump</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../../&config.OUT;/readelf/segments/objdump"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
  </simplesect>

  &xml.readelf.evil.magic.segments.readelf;
  &xml.readelf.evil.magic.segments.elfdump;

  <simplesect>
    <title>Observations</title>

    <para
      >Nice to see the <link linkend="e_entry">entry point</link>
      (&calc.evil.magic.entry.point.X;) again.
      Program layout is a simplified variation of
      <xref linkend="sort.of.an.answer"/>.
      The value of <literal>FileSiz</literal> includes
      <acronym>ELF</acronym> header and program header.
      The size of this overhead is:
      <blockquote>
	<para
	  >overhead =
	  <literal>Entry point</literal> - <literal>VirtAddr</literal> =
	  &calc.evil.magic.start.X; - &calc.base.addr; =
	  &calc.evil.magic.ofs.X; = &calc.evil.magic.ofs.D; bytes
	</para>
      </blockquote>

      So effective code size is:
      <blockquote>
	<para
	  >code size =
	  <literal>FileSiz</literal> - overhead =
	  &calc.evil.magic.LOAD1.filesiz.X; -
	  &calc.evil.magic.ofs.X; =
	  &calc.evil.magic.codesize.X; =
	  &calc.evil.magic.codesize.D;
	  bytes
	</para>
      </blockquote>

      This matches with the
      <link linkend="devil.in.disguise">disassembly listing</link>.
      However, the ratio of file size to effective code deserves the title
      <quote>Bloat</quote>, with capital B.
      <blockquote>
	<para
	  >code size / file size =
	  &calc.evil.magic.codesize.D; /
	  &calc.evil.magic.size.D; =
	  &calc.evil.magic.bloat;
	</para>
      </blockquote>

      Only &calc.evil.magic.bloat.percent; percent of the file actually
      do something useful!
    </para>
  </simplesect>

</sect2>
<sect2 id="sections" xreflabel="Sections">
  <title>Sections</title>

  <simpara
    ><citerefentry>
      <refentrytitle>readelf</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> features another option, <option>-S</option>.
    <citerefentry>
      <refentrytitle>objdump</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> calls that <option>-h</option>.
  </simpara>

  <simplesect>
    <title>objdump</title>

    <formalpara>
      <title>Command: &config.PRE;/readelf/sections/objdump.sh</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../../&config.PRE;/readelf/sections/objdump.sh"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>
    <formalpara>
      <title>Output: &config.OUT;/readelf/sections/objdump</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../../&config.OUT;/readelf/sections/objdump"
	/></imageobject></inlinemediaobject></programlisting>
      </para>
    </formalpara>

    <simpara
      ><application>objdump</application>'s output for sections is
      outright disgusting. A real problem is the broken numbering due
      to ignored entries in the section table. The item on index 0 is
      actually of type <literal>SHT_NULL</literal>. Its index
      (<literal>SHN_UNDEF</literal> = 0) serves to mark an unused value
      of <varname>sh_link</varname>. Less troublesome is the ignored
      string table, a section of type <literal>STRTAB</literal>.
    </simpara>
  </simplesect>

  &xml.readelf.evil.magic.sections.readelf;
  &xml.readelf.evil.magic.sections.elfdump;

  <simplesect>
    <title>Observations</title>

    <simpara
      >The most interesting entry is <literal>.text</literal>.
      The start of this section,
      <literal>&calc.evil.magic.text.addr.X;</literal>,
      equals the entry point.
      This is not a coincidence or the degenerated case of a
      trivial program. Further down it is demonstrated on
      <filename>&config.PATH.SH;</filename>.
      And &yref.scan.entry.point; shows it to be generally true,
      though it is nowhere specified in the standard.
      A search through standard places like
      <filename>/bin</filename>:
    </simpara>

    <formalpara>
      <title>Output: &config.OUT;/scanner/entry_point_big</title>
      <para>
	<programlisting><inlinemediaobject><imageobject><imagedata
	  format="linespecific"
	  fileref="../../&config.OUT;/scanner/entry_point_big"
	/></imageobject></inlinemediaobject></programlisting
      ></para>
    </formalpara>

  </simplesect>

</sect2>

<sect2 id="bashful.glance" xreflabel="Bashful glance">
  <title>Bashful glance</title>

  <simpara>
    Anyway, we see that even for trivial examples the code is surrounded
    by lots of other stuff. Let's zoom in on our target.
  </simpara>

  &xml.readelf.sh.segments.readelf;

  <simpara
    >Looks intimidating. But then the <acronym>ELF</acronym> specification
    says that only segments of type <quote>LOAD</quote> are considered for
    execution. Since the flags of the first one include
    <quote>execute</quote> but not <quote>write</quote> it must be the
    code segment. The other one has the <quote>write</quote> flags set,
    so it must be the data segment. There is one possible deviation:
    On sparc-sunos most executables built by Sun feature a data segment
    with <quote>execute</quote> flag.
  </simpara>

</sect2>
<sect2  id="self.modifying.code" xreflabel="Self modifying code">
  <title>Self modifying code</title>

  <simpara>
    Previous examples in <xref linkend="language.of.evil"/> used an
    <literal>__attribute__</literal> clause to put the code into
    section <literal>.text</literal>. Without that it would end up
    in section <literal>.rodata</literal>. Both are members of the
    code segment which is executable in it its entireness; in this
    regard that would make no difference.
  </simpara>
  <simpara>
    But what about putting the code a write enabled data segment?
    These settings can probably be changed by
    <citerefentry>
      <refentrytitle>mprotect</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>. But what are the default settings?
  </simpara>

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

</sect2>
<sect2>
  <title>Final observations</title>

  <simpara
    ><literal>MemSiz</literal> (&calc.sh.LOAD2.memsiz.X;) is larger
    than <literal>FileSiz</literal> (&calc.sh.LOAD2.filesiz.X;) in
    the data segment. Just like with
    <citerefentry>
      <refentrytitle>mmap</refentrytitle>
      <manvolnum>2</manvolnum>
    </citerefentry>
    excessive bytes are defined to be initialized with 0.
    The linker takes advantages of that by grouping all variables
    that should be initialized to zero at the end. Note that the last
    section of segment 3 (counting starts with 0) is called
    <literal>.bss</literal>, the traditional name for this kind of area.
  </simpara>
  <simpara
    >The mapping for segment 2 looks even more complex. But I would guess
    that <literal>.rodata</literal> means <quote>read-only data</quote>
    and <literal>.text</literal> contains productive code, as opposed
    to the administrative stuff in the other sections.
    <acronym>LSB</acronym> &note.lsb; has a good overview of section
    names. &note.lsb.specialsections;
    Anyway, a detailed look on section <literal>.text</literal> shows
    that its start address (&calc.sh.text.addr.X;) equals the entry point.
  </simpara>

  &xml.readelf.sh.sections.readelf;

  <simpara
    >Some executables of Red Hat 8.0 have an additional program header of
    type <literal>GNU_EH_FRAME</literal>. <!-- FIXME -->
  </simpara>

</sect2>
