<?xml version="1.0"?>
<!DOCTYPE article PUBLIC  "-//OASIS//DTD DocBook XML V4.1.2//EN"
    "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd">

<!-- "http://docbook.org/xml/4.1.2/docbookx.dtd" -->

  <article>
  <articleinfo>
    <title>Honeynet Project Scan of the Month - Scan 26 (February 2003)</title>

    <author>
      <firstname>Nick</firstname>
      <surname>DeBaggis</surname>
      <affiliation>
	<address>
	  <email>lucky at ncounty dot net</email>
	</address>
      </affiliation>
    </author>

    <author>
      <firstname>Eloy</firstname>
      <surname>Paris</surname>
      <affiliation>
	<address>
	  <email>peloy at chapus dot net</email>
	</address>
      </affiliation>
    </author>

    <abstract>
   <para>
      This is a submission to the <ulink
      url="http://www.honeynet.org">Honeynet Project</ulink> <ulink
      url="http://www.honeynet.org/scans/scan26/">February 2003 Scan
      of the Month</ulink>.
      In the case involving Joe Jacobs from the <ulink url="http://www.honeynet.org/scans/scan24/">October Scan 24 challenge</ulink>, evidence was found implicating his dealer, Jimmy Jungle.
      A result of the previous forensic investigation was a search warrant on Jimmy Jungle's residence, the
      search turned up a single floppy disk in the vacated residence.  During this investigation, we have
      uncovered several other suspects related to this case.  Namely, Jimmy's probable suppler, John Smith, and Jimmy's pickup
      location contact, Danny.  We have successfully extracted and analyzed all hidden data and have answered all
      the questions posed by the police.  It is our belief the evidence obtained in this case will assist the police
      in conducting a rapid and successful investigation.

    </para>

    <para>
      The analysis is in some parts very detailed. If you are a
      grader, have several submissions to read and can't go over all
      the details, or are just a casual reader, feel free to go
      directly to <xref linkend="questions"/>, which contains the
      answers to all the questions of this challenge. The questions
      (and answers) provide a good summary of the most important
      aspects of this challenge. However, just reading the answers is not
      the best way to understand some of the details nor the process we
      followed to analyze the forensic disk image, so we encourage you to read
      the whole submission.
    </para>
    </abstract>

    <keywordset>
      <keyword>honeynet</keyword>
      <keyword>eloy paris</keyword>
      <keyword>linux</keyword>
      <keyword>steganography</keyword>
      <keyword>steganalysis</keyword>
    </keywordset>

  </articleinfo>

  <!--  start  -->

  <sect1 id="questions">
    <title>Questions</title>

    <sect2 id="q1"><title>Q1: Who is the probable supplier of drugs to Jimmy
    Jungle?</title>

      <para>
	<emphasis role="bold">A</emphasis>: John Smith is Jimmy Jungle's
	most probable supplier of drugs. We have reached this conclusion
	after reading the Microsoft Word document <ulink url="John.doc">
	John.doc</ulink>, which was hidden using steganography in the
	<ulink url="jpeg.jpg">JPEG file</ulink> stored in
	the floppy disk image at offset 16896.  The John.doc file was also password protected with
   Microsoft Word's password protection scheme.  The string "pw=help" found in the unallocated
   disk space of the floppy unlocked the file.
      </para>

	<para>
		The Word document contains the following text:
	</para>

	<screen>
Dear John Smith:

My biggest dealer (Joe Jacobs) got busted. The day of our scheduled
meeting, he never showed up. I called a couple of his friends and they
told me he was brought in by the police for questioning. I'm not sure
what to do. Please understand that I cannot accept another shipment
from you without his business. I was forced to turn away the delivery
boat that arrived at Danny's because I didn't have the money to pay
the driver. I will pay you back for the driver's time and gas. In the
future, we may have to find another delivery point because Danny is
starting to get nervous.

Without Joe, I can't pay any of my bills. I have 10 other dealers who
combined do not total Joe's sales volume.

I need some assistance. I would like to get away until things quiet
down up here. I need to talk to you about reorganizing. Do you still
have the condo in Aruba? Would you be willing to meet me down there?
If so, when? Also, please take a look at the map to see where I am
currently hiding out.

Thanks for your understanding and sorry for any inconvenience.

Sincerely,

Jimmy Jungle</screen>

	<para>
	We believe this letter warrants further investigation of
	Mr. John Smith and his relationship with Jimmy Jungle.  The person
   named Danny should also be questioned.
	</para>

    </sect2>

    <sect2 id="q2"><title>Q2: What is the mailing address of Jimmy Jungle's
    probable drug supplier?</title>

      <para>
	<emphasis role="bold">A</emphasis>: By running the
	<command>strings</command> Unix command on the floppy disk
	image we see that there is one mailing address stored in a
	random location of the image. This address is:
      </para>

      <screen>
1212 Main Street
Jones, FL 00001</screen>

	<para>
		The address is stored with the comment "John Smith's
		address", which does not leave much doubt about where
		to find Mr. John Smith.
	</para>

    </sect2>

    <sect2 id="q3"><title>Q3: What is the exact location in which Jimmy Jungle
    received the drugs?</title>

      <para>
	<emphasis role="bold">A</emphasis>: The <ulink url="John.doc">
	Microsoft Word Document</ulink> we mentioned in Question 1
	implies that drugs are delivered by boat at Danny's. Looking at the map in the <ulink url="jpeg.jpg">JPEG
	file</ulink>, we can see that Danny's is located at Pier 12 on
	Shore Line Drive, close to the intersection between Shore Line
	and N. Main Street.
      </para>

    </sect2>

    <sect2 id="q4">
    <title>Q4: Where is Jimmy Jungle currently hiding?</title>

		<para>
		<emphasis role="bold">A</emphasis>:
		22 Jones Ave. - near the intersection of Smith Ave.
		</para>

      <para>
      Jimmy Jungle's hiding place is shown in the bitmap image.  The bitmap image was found
      at offset 49664 of the forensic floppy image and has a length of 1166454 bytes.
      </para>

      <para>
      <ulink url="bitmap.bmp">Bitmap of Jimmy's hiding place (bitmap.bmp).</ulink> Note: this file is rather large,
      if you are on a dial-up connection then you may want to save some time and take a look at
      <ulink url="bitmap.jpg">(bitmap.jpg)</ulink> to get the visual perspective of the original file.  Though understand that the
      bitmap.bmp file is the <emphasis>real</emphasis> file we extracted and contains the hidden Jimmy.wav file.
	</para>

    </sect2>

    <sect2 id="q5"><title>Q5: What kind of car is Jimmy Jungle driving?</title>

		<para>
		<emphasis role="bold">A</emphasis>:
		Jimmy Jungle drives a blue 1978 Mustang with Ontario license plates.
      </para>

		<para>
		Finding the HTML comment string "PW=right" in the dfrws.org site allowed us to extract
		the WAV sound file <ulink url="Jimmy.wav">"Jimmy.wav"</ulink> using Invisible Secrets 2002 with the Twofish encryption algorithm selected.
      When played, we hear Jimmy directing the listener to meet him at the pier: "This is Jimmy, meet me at the pier tomorrow.
		I drive a blue 1978 Mustang with Ontario license plates".
		</para>

    </sect2>

    <sect2 id="bonus"><title>Bonus: Explain the process that was performed so that there were no entries in the
		root directory and File Allocation Table (FAT), yet the contents of each file remained
		in the data area?</title>

      <para>
		<emphasis role="bold">A</emphasis>:
		The steganographic image files were copied to the diskette, the diskette was then formatted either through
      Windows or DOS using the format command with the quick format switch applied.  A test was performed on a PC running Windows 98
      to compare with the forensic image; the results matched, the FAT and root directory were empty but the data area
      retained the original files.  The quick format option clears and
		reinitializes the FAT and root directory while leaving the data area intact, thus "quickly formatted".
		For DOS the command is: <command>format a: /q</command>.  This may be done through Windows as well, right-click the floppy drive object and
		choose Format - Quick.
      </para>

    </sect2>

  </sect1>

  <sect1 id="inspection">
    <title>Initial Inspection</title>

	<para>
		Our initial inspection of the forensic floppy image followed the typical examination path.
      We first verified the MD5 hashes supplied for this challenge.  We then checked the file
      type of the scan26 binary disk image, proceeded to mount the disk image and performed a directory listing on it:
	</para>
   <screen>
$ file scan26
scan26: x86 boot sector
$ sudo mount -o ro,loop,nodev,noexec scan26 mnt/
$ ls -l mnt/
total 0</screen>

   <para>This appears to be an empty floppy disk so a low-level analysis should uncover
   any data that may still be on the disk.  Using several tools to analyze the image will produce
   the offsets to any interesting data on the disk.  The tools used during this phase of the
   examination consisted of: emacs, vi, strings and khexedit.</para>

   <para>We now begin to do a manual examination of the scan26 image and as shown below
   we find all offsets to the interesting data left on the disk.</para>

   <para>The first thing we notice is the empty FAT1 and FAT2 sections of the disk, these
   appear normal for an empty disk as the leading 3 bytes followed by all null bytes signify the FAT is empty.  We follow down
   to the beginning of the disk data area at offset 0x4200 and notice the root directory is
   also empty along the way.</para>

   <screen>Fat 1:
0000:0200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Fat 2:
0000:1400 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</screen>

<para>We have arrived at the beginning of the disk data area, we see there is the tell-tale signature for
a JPEG image here: 0xff 0xd8 and JFIF.  Following down through this JPEG until we hit the two bytes 0xff 0xd9 which
signify the End Of Image for a JPEG, we can now calculate the file length for the JPEG as
0xc15a - 0x4200 = 32602 bytes.</para>

<screen>
Start of JPEG:
0000:4200 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 ......JFIF.....H
0000:4210 00 48 00 00 ff fe 00 4c 11 53 6e 55 47 b3 2d 44 .H.....L.SnUG.-D
0000:4220 35 d2 23 66 6b 1d bd 76 3c 89 68 69 d4 17 60 e8 5.#fk..v&lt;.hi....
0000:4230 a8 a4 2d 09 59 19 ab 28 1a de 5e 98 60 c2 a5 c3 ..-.Y..(..^.`...

End of JPEG:
0000:c140 80 88 88 08 88 80 88 88 08 88 80 88 88 08 88 80 ................
0000:c150 88 88 08 88 80 88 88 3f ff d9 00 00 00 00 00 00 .......?........
0000:c160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</screen>

<para>Proceeding down we find another tell-tale signature, this one for a BMP image.
Following down through the BMP we eventually hit the formatting codes 0xf6 that are
typical of a Windows/MSDOS formatted disk.  These codes will signify the end of the
bitmap image since they mean those positions are unallocated on the disk.  We could also simply
grab the file size from the bitmap header.  The file size is located at offset
0xc202 for 4 bytes length (just after "BM"), reading them in little-endian order
we have 0x0011cc76 = 1166454 bytes.</para>

<screen>
Start of bitmap:
0000:c200 42 4d 76 cc 11 00 00 00 00 00 36 00 00 00 28 00 BMv.......6...(.
0000:c210 00 00 d0 02 00 00 1c 02 00 00 01 00 18 00 00 00 ................
0000:c220 00 00 40 cc 11 00 00 00 00 00 00 00 00 00 00 00 ..@.............
0000:c230 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ................
0000:c240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

End of bitmap:
0012:8e60 ff fe fe ff fe ff ff ff ff fe ff ff fe ff ff fe ................
0012:8e70 ff fe fe fe ff fe f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0012:8e80 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................</screen>


<para>Again, we subtract to find how many bytes are between: 0x128e76 - 0xc200 = 1166454 bytes, which matches
the size in the BMP header.</para>


<para>Moving on we find two ASCII text strings located in the unallocated disk space towards the
end of the disk.  Running the Unix <command>strings</command> command on the image also reveals
these strings.</para>

<screen>
0012:bb40 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0012:bb50 70 77 3d 68 65 6c 70 f6 f6 f6 f6 f6 f6 f6 f6 f6 pw=help.........
0012:bb60 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................

0015:6750 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0015:6760 4a 6f 68 6e 20 53 6d 69 74 68 27 73 20 41 64 64 John Smith's Add
0015:6770 72 65 73 73 3a 20 31 32 31 32 20 4d 61 69 6e 20 ress: 1212 Main
0015:6780 53 74 72 65 65 74 2c 20 4a 6f 6e 65 73 2c 20 46 Street, Jones, F
0015:6790 4c 20 30 30 30 30 31 f6 f6 f6 f6 f6 f6 f6 f6 f6 L 00001.........</screen>

<para>This certainly looks like a potential password and John Smith's address.  We continue to the end
of the image file with no other findings, so we will now commence to the analysis phase
using the information we have.</para>


  </sect1>

  <sect1 id="analysis">
    <title>Analysis</title>


      <para>
     Note that nearly all of our analysis was conducted prior to finding the hidden HTML comments in the dfrws.org web site,
      if we had found these earlier, this section would have been <emphasis>much</emphasis> shorter.
      Armed with file offsets and lengths, we can now extract the files from the scan26 image file.  First we
      summarize with a table of offsets and lengths for reference.
      </para>

    <table frame="all">
      <title>Disk image data types with offsets and lengths</title>
      <tgroup cols="4">
        <thead>
          <row>
            <entry align="center">Description</entry>
            <entry align="center">Hex Offset</entry>
            <entry align="center">Decimal Offset</entry>
            <entry align="center">Decimal Length</entry>
          </row>
        </thead>
        <tbody>
          <row>
            <entry>jpeg.jpg graphics file</entry>
            <entry>0x00004200</entry>
            <entry align="right">16896</entry>
            <entry align="right">32602</entry>
          </row>
          <row>
            <entry>bitmap.bmp graphics file</entry>
            <entry>0x0000c200</entry>
            <entry align="right">49664</entry>
            <entry align="right">1166454</entry>
          </row>
          <row>
            <entry>ASCII string</entry>
            <entry>0x0012bb50</entry>
            <entry align="right">1227600</entry>
            <entry align="right">7</entry>
          </row>
          <row>
            <entry>ASCII string</entry>
            <entry>0x00156760</entry>
            <entry align="right">1402720</entry>
            <entry align="right">55</entry>
          </row>
        </tbody>
      </tgroup>
    </table>

      <para>Extract and check the file type for the JPEG graphic:</para>
      <screen>
$ dd if=scan26 of=jpeg.jpg bs=1 count=32602 skip=16896
32602+0 records in
32602+0 records out
$ file jpeg.jpg
jpeg.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), "SnUG.-D5.#fk.v.h.............Y.", 72 x 72</screen>

   <para>Notice how the <command>file</command> command spit out part of the JPEG comment section, but the
   comment is not entirely human readable.  This is a tip-off that something may be hidden in the JPEG file. Since
   a JPEG comment can contain upto 65533 bytes of data and a JPEG file can contain multiple comments
   without rendering them to the screen, the comment area is a good hiding place.  The drawback is the file size is increased
   using this method of hiding.
   </para>

      <para>
      Extracting the Windows bitmap from the forensic disk image:
      </para>
      <screen>
$ dd if=scan26 of=bitmap.bmp bs=1 count=1166454 skip=49664
1166454+0 records in
1166454+0 records out
$ file bitmap.bmp
bitmap.bmp: PC bitmap data, Windows 3.x format, 720 x 540 x 24</screen>

      <para>This gives us basically the same image as the JPEG, but there is a new location drawn on
      the map, and the file format is obviously different.  To quickly recap, we now have the following
      information about our scan26 image:
      </para>
    <itemizedlist>

		<listitem>
		<para>
      A JPEG image showing "Danny's Pier 12 Boat Lunch" and containing a strange comment section .
		</para>
		</listitem>
		<listitem>
		<para>
      A large 24 bit color BMP image showing a "hideout".
		</para>
		</listitem>
		<listitem>
		<para>
      A string showing "pw=help"
		</para>
		</listitem>
		<listitem>
		<para>
      Another string showing John Smith's address.
		</para>
		</listitem>
   </itemizedlist>

      <para>Let's work on the JPEG first.  We run <ulink url="http://www.outguess.org/detection.php">Niels Provos' stegdetect</ulink> tool on it to determine the possibility of
      it having steganographic content.</para>

      <screen>
$ stegdetect jpeg.jpg
jpeg.jpg : invisible[7771](***)</screen>

      <para>Stegdetect seems to think the <ulink url="jpeg.jpg">JPEG</ulink> has steganographic data embedded in it and was created with
      Invisible Secrets steganography software.  The numbers reflect the potential length of the stego data.
      At this point, we decided to download and install Invisible Secrets and a handful of other Windows based
      stego packages.  We tried to decrypt the JPEG using the password "help" with no results.  We also thought about
      the reason for the disk having "dfrws.org" written on it (see the <ulink url="http://www.honeynet.org/scans/scan26/scenario.html">
      police report</ulink>) and so made a trip to their site.  A brief examination
      of the site produced very little.</para>
      <para>A manual extraction of the two JPEG comment sections revealed a little more information to us.  We did
      find that the first comment section contains 74 bytes of data and the second comment section contains 7775 bytes of data.
      An assumption we made was the first comment contained the encryption key hash and/or some
      type of structure descriptor of the encrypted data, and the second comment contained the actual
      encrypted/compressed data.  This assumption produced little since we don't know
      exactly <emphasis>how</emphasis> Invisible Secrets stores that information.</para>

      <para>
      Jumping ahead to the <ulink url="bitmap.bmp">BMP</ulink> image, we can visually see that a "hideout" has been added with an address.  But our intuition
      says there may be stego in the BMP as well. So for the bitmap image, a small C program was written to enhance the
		image based on the value of a specific bit in each color byte of image data (see <xref linkend="files"/>).  Since a 24 bit
		bitmap typically contains only a header section and raw RGB triplets, it was fairly easy to determine
		that a Least Significant Bit insertion based steganography was applied to it (this is a common way
      to embed stego in a BMP image so the file size does not change).  The image below is a consolidated
		image map of our bit enhancement procedure.  From top left to bottom right (reading across) we have the enhanced
		images of bit 7 through 0.  It's quite obvious bit 0 is very different; it looks random, which is typically
		a sign of compressed and/or encrypted data.
		</para>

		<mediaobject>
			<imageobject>
				<imagedata fileref="enhanced.png"/>
			</imageobject>
		</mediaobject>

		<para>
		A Google search for "analyzing steganography" turned up the site: <ulink url="http://www.pipo.com/guillermito/invisiblesecrets/">
		http://www.pipo.com/guillermito/invisiblesecrets/</ulink>
		which has a very good analysis of how Invisible Secrets 2002 implements steganography in an image file.
		Take special notice to the similarities between our enhanced bit 0 image and the examples on that site.
		</para>

      <para>
		We are now confident both graphics files contain steganography.  We are also confident it is Invisible Secrets steganography.
      But, the password "help" is not working out for us.  We again brought up the issue about "dfrws.org" being written on the floppy disk,
      and decided to take a more detailed look at the dfrws.org site.  This time we closely analyzed the HTML source code
      and found the key to Jimmy Jungles' whereabouts and next move.  In the HTML comments on the page <ulink url="http://www.dfrws.org/dfrws-overview.html">
      http://www.dfrws.org/dfrws-overview.html</ulink> we found the following:
      </para>
      <screen>
Invisible Secrets
http://www.invisiblesecrets.com
PW=lefty
Algorythm= twofish
PW=right</screen>

    <para>
      We used these passwords and settings to extract the files John.doc and Jimmy.wav from the JPEG and BMP respectively.
      The JPEG's password is "lefty" and the BMP's is "right".
      As far as the "pw=help" string, well that was used as the Microsoft Word password protection on the John.doc file.
    </para>
    <para>It is our recommendation to obtain an additional search warrant for the dfrws.org site's web server hard drive
    as this may give more information regarding this case.  It's apparent Jimmy Jungle has some type of access, legal or illegal
    to that site's web server since that is the only way those comments got into the HTML source.</para>

  </sect1>

  <!--  end  -->

  <appendix id="files">
    <title>Files</title>

    <para>
      The following files where generated during this Scan of the
      Month:
    </para>

    <itemizedlist>

		<listitem>
		<para>
		<ulink url="jpeg.jpg">jpeg.jpg</ulink>: Graphic in JPEG
		format that contains a map with the location
		where Jimmy Jungle receives drugs. This file uses
		steganography to hide the Microsoft Word file
		John.doc.
		</para>
		</listitem>

		<listitem>
		<para>
		<ulink url="bitmap.bmp">bitmap.bmp</ulink>: Graphic in Windows
		Bitmap (BMP) format that contains a map with the location
		where Jimmy Jungle is hiding. This file uses
		steganography to hide the WAV file Jimmy.wav.
		</para>
		</listitem>

		<listitem>
		<para>
		<ulink url="John.doc">John.doc</ulink>: Microsoft Word
		document that provides information about Jimmy
		Jungle's drug supplier. This document was hidden using
		steganography inside a <ulink url="jpeg.jpg">JPEG file</ulink>, and
      also has Microsoft Word's password protection scheme set on it.
		</para>
		</listitem>

		<listitem>
		<para>
		<ulink url="Jimmy.wav">Jimmy.wav</ulink>: Sound media in Wave (WAV)
      format that contains a recording of Jimmy Jungle directing
      someone (probably John Smith) to meet him at the pier.
		This document was hidden using
		steganography inside a <ulink url="bitmap.jpg">Windows
		Bitmap file</ulink>.
		</para>
		</listitem>

		<listitem>
		<para>
		<ulink url="src/bmplsb.c">bmplsb.c</ulink>: Bitmap bit enhancer,
		enhances a bitmap based on the value of the selected bit.
		</para>
		</listitem>

      <listitem>
		<para>
		<ulink url="src/bmpextract.c">bmpextract.c</ulink>: Bitmap bit extractor,
		extracts the bitmap image data based on the value of the selected bit.
		</para>
		</listitem>

      <listitem>
		<para>
		<ulink url="src/bmp.h">bmp.h</ulink>: Bitmap header definition.
		</para>
		</listitem>


      <listitem>
	<para>
	  <ulink url="xmlsrc/">XML sources for this
	  document</ulink>: this HTML document was generated using
	  DocBook XML. This directory contains all the files used in
	  the generation of this document.
	</para>
      </listitem>

    </itemizedlist>

  </appendix>

  <appendix id="refs"><title>References</title>

   <itemizedlist>
   <listitem><para>Steganography and Cryptography</para>
      <itemizedlist>
      <listitem>
      <para>
      Schneier, Bruce. Applied Cryptography. 2nd Ed. 1996 Wiley.
      </para>
      </listitem>
      <listitem>
      <para>
      <ulink url="http://www.pipo.com/guillermito/stegano/index.html">Steganalysis - http://www.pipo.com/guillermito/stegano/index.html</ulink>
      </para>
      </listitem>
      <listitem>
      <para>
      <ulink url="http://www.outguess.org/detection.php">Provos, Neils. Stegdetect - Stegbreak</ulink>
      </para>
      </listitem>
      <listitem>
      <para>
      <ulink url="http://www.invisiblesecrets.com">Invisible Secrets</ulink>
      </para>
      </listitem>
      </itemizedlist>
   </listitem>
   </itemizedlist>

  </appendix>

  <appendix id="methodology">
    <title>Work Methodology</title>

    <para>
      This submission was prepared jointly by Nick DeBaggis and Eloy Paris.
      Nick and Eloy did not know each other prior to this Scan of the
      Month, although both had participated independently in past
      Honeynet Project's Scans of the Month.
    </para>

    <para>
	For this Scan of the Month both authors worked independently
	while analyzing the problem and finding the answers, and then
	joined forces to write the final submission.
	</para>

	<para>
	The submission was prepared using DocBook XML, and then
	converted to HTML using Tim Waugh's xmlto XML converter. A CVS
	repository was set up to keep track of changes, allow authors
	to work independently, and allow authors to see each other's
	changes.
	</para>

  </appendix>

  <appendix id="thanks">
    <title>Thanks</title>

    <para>
      Thanks to ...
    </para>

    <itemizedlist>

      <listitem>
	<para>
	  (Eloy) Nick, for teaming up with me on this Scan of the Month and
	  for working so hard on it. Write ups are always hard, but
	  you've made this one a breeze!
	</para>
      </listitem>

      <listitem>
	<para>
	  (Eloy) Ken, for providing an exceptional work environment
	  and for encouraging me to pursue educational exercises like
	  the Honeynet Project's Scans of the Month.
	</para>
      </listitem>

      <listitem>
	<para>
      (Nick) Jen, for saying yes, for being the solution to <emphasis>my</emphasis> puzzle, and for tolerating
      my many "projects"; I <emphasis>am</emphasis> getting the better part of this deal!
      Eloy, for somehow finding the time to team up on this challenge and
      teaching me some new Linux tricks along the way.
   </para>
      </listitem>

      <listitem>
	<para>
      (Nick) Cathy and Steve, for taking a chance, allowing me to grow into such a cool job, and
      not minding too much when I show up a bit late after staying up all night doing Honeynet Challenges!.
   </para>
      </listitem>


      <listitem>
	<para>
	  (Both) As always, the <ulink url="http://www.honeynet.org">Honeynet
	    Project</ulink> for these nice and entertaining challenges.
	</para>
      </listitem>

    </itemizedlist>

  </appendix>

  </article>
