faq.txt

this is aes algorithm

Q: What machines will the PXE scraper work on?
A: The scraper code will run on any x86 system that has PXE support. This
   includes systems with built-in NICs and PXE-capable BIOSes and older
   systems with add in ethernet cards that have their own PXE ROMs (i.e.
   the Intel PRO/100 NIC with management support).

Q: What systems have you tested the scraper code on?
A: My laptop (Averatec Intel Celeron processor with RealTek 10/100 NIC)
   Sun w2100z Javastation (dual AMD Opteron, Broadcom BCM5703 NIC)
   IBM ThinkPad (also Broadcom NIC)
   Intel Cappel Valley development board (Intel PRO/1000 NIC)
   Soekris net4801 board (NatSemi DP83816 NIC)

Q: Doesn't the scraper binary overwrite some of the target's memory itself?
A: Yes, but there's no getting around that. It's designed to use as little
   memory as possible. A typical binary image is only about 8K in size.
   (And yes, the scraper will capture an image of itself.)

Q: Are 64-bit systems supported?
A: Yes. Both the PXE and disk based scrapers can be built either as
   32-bit or 64-bit executables. The 64-bit versions will run on any
   x86-64 system, including those with AMD Opteron, AMD Athlon 64,
   Intel Xeon and Intel Core 2 Duo CPUs.

Q: Will the 32-bit scraper work on 64-bit systems?
A: Yes, but it will only run in 32-bit mode, and as such it won't be
   able to access the entire 64-bit address space. (This means it will
   only be able to access 3.5GB of RAM, even if your 64-bit system has
   more than that.) If your 64-bit target system has less than 4GB of
   RAM, then there's really no need to use the 64-bit scraper anyway.

Q: Are there any limitations to the 64-bit version?
A: In order to access more than 4GB of address space, an x86-64 CPU must
   run in long mode, and paging must be enabled. Paging requires the use
   of page tables, which consume additional memory. The bare minimum
   configuration requires 3 4K page directories, which allows access to
   up to 1GB of RAM. (Each page table contains 512 entries, and pages can
   be either 4KB or 2MB in size. Using the 2MB page size, 2MB times 512
   yields 1GB.) Once the first 640K segment of RAM has been dumped, both
   scraper programs will populate an additional 63 page tables and add them
   to the page directory, which provides access to up to 64GB of RAM.
   It is possible to increase this limit by modifying the code in
   bios-pc/x86-64/memmap.c, but 64GB is considered to be a reasonable
   limit for the time being.

Q: Will I be able to capture a useful memory dump from any system?
A: Not necessarily, no. The amount of time data will remain viable in
   RAM once power is removed varies enormously depending on a number
   of factors, including the memory chip design, presence (or absence)
   of filter capacitors, resistive loading, and even how hot the chips
   are (cooler chips tend to retain their contents longer). Also, the
   BIOS may destroy the contents of RAM immediately on startup. In some
   cases, this is due only to a memory test, which is sometimes optional
   and can be disabled. In other cases, it's because the system has ECC
   RAM.

Q: Why does it make a difference if I have ECC memory?
A: ECC memory typically must be "scrubbed" (i.e. its entire contents
   overwritten with zeros) by system bootstrap software before ECC
   support can be enabled in the system memory controller. When the RAM
   module is first powered up, all of its bits -- including the parity
   bits used to detect memory errors -- are in unknown, garbage states.
   If error detection is turned on before the RAM is scrubbed, the
   uninitialized parity bits will signal false parity errors. To avoid
   this, every memory cell must be written at least once prior to
   enabling the error correction hardware in order to initialize all of
   the parity bits to valid states. Unfortunately, this has the effect
   of destroying whatever may have been in the memory to begin with.

Q: Can I get around the ECC memory scrubbing?
A: Some BIOSes offer a configuration option to disable ECC support. This
   may also prevent the BIOS from scrubbing the RAM.

Q: Do many PCs have ECC memory?
A: Surprisingly, no. ECC memory is expensive, and as such it's used mainly
   in high availability systems (such as servers).

Q: Why doesn't the scraper code build on MacOS X?
A: While the C compiler and assembler supplied with the Apple Xcode
   distribution can compile the scraper code, I have yet to find a
   way to convince the linker to link it properly. Also, the Xcode
   environment does not include a full set of GNU binutils: most notably,
   objcopy is missing. Without it, there's no way to generate a flat
   binary image from the linked scraper executable.

Q: Does that mean MacOS X can't be used at all?
A: No: you can still use MacOS X to build the scraper, but first you'll
   need to build a GCC cross compilation environment. This is not that
   hard to do, since the scraper code does not need libgcc (which is
   usually the hardest thing to generate when building a cross compiler).
   If you build a cross compiler (and a set of GNU binutils) targeted for
   i386-elf, you should be able to compile and link the scraper. Similarly,
   a compiler and binutils targeted for x86_64-elf can be used to build
   the 64-bit version.

Q: Is the scraper a miniature operating system?
A: No, it's a standalone program. It's entirely single-threaded: it does
   not support multitasking, interrupt handling or memory protection.

Q: I want to write my own OS. Will you help me?
A: No.

Q: How does the power down feature work?
A: When the scraper quits, it attempts to shut down the system using
   an APM BIOS call. An APM power-off should work on any system that
   supports APM BIOS version 1.1 or later. (It works on my laptop
   which has an AMP 1.2 BIOS.) This is not guaranteed to work however,
   because APM has largely been deprecated in favor of ACPI. Sadly,
   it's not practical to add ACPI support to the scraper. If the target
   system has no APM BIOS, the scraper will trigger a CPU reset instead,
   which should reboot the system.

Q: Can I build this code on Windows?
A: You can build the 32-bit versions of the PXE and USB scrapers, if you
   install the Cygnus tools from www.cygwin.com or the MinGW tools from
   www.mingw.org. Building the 64-bit versions has not been tested on
   Windows, but will likely require building a cross compiler.

Q: I want to modify/improve/experiment with this code, but the
   compile/test/reboot cycle is very time consuming/tedious. Is
   there a better way?
A: Yes: I strongly recommend you use the QEMU simulator instead of real
   hardware for testing (http://fabrice.bellard.free.fr/qemu). Version 0.9.0
   and later support PXE simulation, network simulation, and support for
   remote debugging via GDB. You need to set up the 'tap' pseudo-interface
   driver in your OS to be able to load the scraper into the simulator via
   simulated PXE. I typically use a command similar to the following to
   launch qemu:

   # qemu -boot n -net nic,macaddr=0:0:e8:1:2:3,model=rtl8139 -net tap
     -S -s -p 1234 /dev/null

   This launches the simulator, but freezes the CPU at startup to allow
   time to attach gdb. To debug the code, you should compile it with the
   -g option (which is not done by default) and then do:

   % gdb scraper
   (gdb) target remote localhost:1234
   (gdb) c

   You can also debug from the QEMU monitor, which can be accessed by typing
   CTRL-ALT-2 in the QEMU window. (CTRL-ALT-1 returns to the main display.)

Q: How can I build a 64-bit cross compiler that can be used to build the
   64-bit scraper code?
A: I used the following steps, which should work for you:

   - Download the following packages:

     ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.3.0/gcc-core-4.3.0.tar.bz2
     ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.18.tar.bz2
     ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.2.1.tar.gz
     ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.3.0.tar.bz2

     GCC 4.3.0 and binutils 2.18 are the latest available as of this
     writing. Earlier versions may also work, however these were the
     versions which were used in development. The GMP and MPFR libraries
     are required to compile GCC 4.3.0. If you already have them on
     your system, you can skip downloading and installing the,

   - Build and install the GMP library first:

     % cat gmp-4.2.1.tar.gz | gzip -d | tar -xvf -
     % cd gmp-4.2.1
     % configure --prefix=/usr/local/gnu
     % gmake
     % gmake install
   
   - Build and install the mpfr library next:

     % cat mpfr-2.3.0 | gzip -d | tar -xvf -
     % cd mpfr-2.3.0
     % configure --prefix=/usr/local/gnu --with-gmp=/usr/local/gnu
     % gmake
     % gmake install

     Note that you may find shared versions of the GMP and MPFR libraries
     have been built as well. These will end up in /usr/local/gnu/lib. If
     /usr/local/gnu/lib isn't in your LD_LIBRARY_PATH, then gcc, when linked
     against the shared versions of the libraries, may complain that it
     can't find them. You can either set your LD_LIBRARY_PATH to include
     /usr/local/gnu/lib, or you can move the shared libraries somewhere
     that the linker won't see them, leaving just the static libraries
     behind:

     % cd /usr/local/gnu/lib
     % mkdir shared
     % mv *.so* shared

   - Build and install a set of binutils targeted for x86_64-elf:

     % cat binutils-2.18.tar.bz2 | bzip2 -d | tar -xvf -
     % cd binutils-2.18
     % mkdir mycrossbuild
     % cd mycrossbuild
     % ../configure --prefix=/usr/local/gnu --target=x86_64-elf
     % gmake
     % gmake install

   - Lastly, build and install GCC. GCC 4.3.0 wants to link against the
     GMP and MPFR libraries. The following instructions assume that
     they've been installed in /usr/local/gnu as shown above:

     % cat gcc-core-4.3.0.tar.bz2 | bzip2 -d | tar -xvf -
     % cd gcc-4.3.0
     % mkdir mycrossbuild
     % cd mycrossbuild
     % ../configure --prefix=/usr/local/gnu --target=x86_64-elf --with-gmp=/usr/local/gnu --with-mpfr=/usr/local/gnu
     % gmake
     % gmake install
     % cd x86_64-elf/libgcc
     % gmake install

     Note that the GCC cross compilation will probably not complete (it
     will fail when it gets to libssp). This is fine: libssp expects a
     runtime environment, but we don't have one. All we really need is
     the C compiler itself. Note that the instructions above also install
     libgcc, but we don't actually need it.

  Once these steps are completed, a complete cross build environment
  should be available in /usr/local/gnu. This is the procedure that was
  used to build the cross compiler used for development on FreeBSD/x86.
  It should work on Linux or MacOS too.

Q: How do I set up an iPod memory dumper?
A: Do the following:

   1) Get an iPod
   2) iPods were (and possibly still are) available in two flavors: Mac and
      Windows. The difference between them is that the Mac flavored ones
      have an Apple HFS+ filesystem and partitioning scheme, while the Windows
      ones use a PC-style MBR partitioning scheme and FAT filesystem. In order
      to boot a PC from an iPod, it will need to be configured for Windows
      flavor. Either make sure to obtain a Windows flavor one, or be prepared
      to reconfigure your Mac flavored one. (The procedure for this is not
      too difficult, but does require deleting any music currently on the
      device.)
   3) A Windows flavored iPod has a partition table and two partitions:
      partition 1 contains just the iPod's firmware, and partition 2 takes
      up all remaining storage space and contains all of the iPod's music
      and/or video files. You will need to repartition the iPod to reduce
      the size of the music/video content partition so that you can create
      a separate partition to hold memory dumps. Note that this will destroy
      the contents of the existing data partition (unless you have a special
      disk editing software that is smart enough to preserve it). If possible,
      back up files on this partition so that you can restore them later.

      You want to partition the iPod's disk so that it contains 3 partitions:

      Partition 1] iPod firmware
      Partition 2] iPod data (MSDOS/FAT)
      Partition 3] <unused>
      Partition 4] Memory dumps

      Partition 4's type field can be anything: the scraper software doesn't
      look at it. All that's important is that an entry for partition 4 exist
      in the partition table in the master boot record, and that it be big
      enough to hold memory dumps (say, 3 or 4GB, at least).
   4) The USB scraper includes a special bootstrap loader, boot.bin, which
      should be installed into the master boot record in sector 0. This boot
      code should be used instead of the standard MS-DOS boot block. Exactly
      how you install this code depends on what disk editing tool(s) you use.
      With FreeBSD, it can be installed with the fdisk command:

      # fdisk -b boot.bin -B da0

   5) Dump the scraper.bin code into partition 4 of the iPod. In FreeBSD, this
      can be done as follows:

      # dd if=scraper.bin of=/dev/da0s4

   6) Reset the iPod and make sure that it can still load its firmware and
      operate correctly. The amount of available storage on the iPod will
      be reduced, since some of the disk space is now dedicated for use by
      the memory dumper. Restore your music files to the data partition (or
      load new ones, if you didn't save the old ones).

   7) Plug the iPod into a target machine, and reset it. Tell the BIOS to
      boot from the iPod instead of the internal disk. The BIOS will load
      the boot sector into RAM at address 0x7c00 and run it, just like a
      normal OS bootstrap. The boot block will then load the scraper binary
      from the start of partition 4 and start it running. It should
      automatically dump the entire contents of RAM to the iPod on partition
      4, immediately after the scraper code. The dump process just writes
      the memory contents directly do the disk in raw form, without using
      any filesystem formatting.

   8) Plug the iPod back into your host system, and recover the memory dump
      using the usbdump command. On FreeBSD, this can be done as follows:

      # usbdump /dev/da0s4 > memdump

   9) You can use the iPod to capture another dump at any time. Any previous
      dump will be overwritten.