Archive for the ‘uni’ Category

Practicum Status Update Week 7

Friday, July 16th, 2010
  • Read about Radare. Apparently, they have “USB support” but I could only see a USB communication sniffer. So Radare doesn’t dissect USB pakets :-(
  • Installed GDB from git, because the GDB in Fedora 13 crashes way too often. I didn’t file as many new bugs this week though ;-) I seem to have worked around all my crashers…
  • Fought a lot with git :( It’s incredibly hostile. I tried to rebase stuff and it keeps bugging me with old commits still being visible although I’ve changed them :( I probably haven’t understood what it does yet. Tried to fix as much as possible using git reflog. Of course, the man page references options (–verbose in my case) that are not existant. Brilliant. I don’t know why I actually expected git to help me.
    This is hilarious, too:

    muelli@bigbox ~/git/qemu $ git rebase setup_fds 
    First, rewinding head to replay your work on top of it...
    Applying: Temporary migration to usb_packet_filter_setup_fds
    Using index info to reconstruct a base tree...
    Falling back to patching base and 3-way merge...
    Auto-merging usb-linux.c
    CONFLICT (content): Merge conflict in usb-linux.c
    Failed to merge in the changes.
    Patch failed at 0001 Temporary migration to usb_packet_filter_setup_fds
    
    When you have resolved this problem run "git rebase --continue".
    If you would prefer to skip this patch, instead run "git rebase --skip".
    To restore the original branch and stop rebasing run "git rebase --abort".
    
    
    muelli@bigbox ~/git/qemu $ nano usb-linux.c # hack hack hack
    muelli@bigbox ~/git/qemu $ git add usb-linux.c
    muelli@bigbox ~/git/qemu $ git rebase --continue
    Applying: Temporary migration to usb_packet_filter_setup_fds
    No changes - did you forget to use 'git add'?
    
    When you have resolved this problem run "git rebase --continue".
    If you would prefer to skip this patch, instead run "git rebase --skip".
    To restore the original branch and stop rebasing run "git rebase --abort".
    
    muelli@bigbox ~/git/qemu $ 
    

    WTF?!

    That one is brilliant, too:

    muelli@bigbox ~/git/qemu $ git rebase -i setup_fds
    # Stupid me: I selected "f" for the very first entry in that edit window
    Cannot 'fixup' without a previous commit
    # Fair enough, let me restart then:
    muelli@bigbox ~/git/qemu $ git rebase setup_fds 
    Interactive rebase already started
    # O_o WTF? What else, besides aborting, could I possibly do anyway?!
    muelli@bigbox ~/git/qemu $ git rebase --abort
    muelli@bigbox ~/git/qemu $ git rebase setup_fds 
    # Now it works...
    
  • Reimplemented host side USB filters to obtain valid USB communication. I have various simple filters: PassThrough, Logging and Replacing. The first one does nothing but return the data w/o any modification. The second one writes the bytes it reads and writes to files. The third one replaces 512 “A”s with 512 “B”s. Still need separate packets from the device in question to the host from packets from the host to the device to obtain valid device behaviour without reading all of the documentation. That will give me a good starting point to actually do the fuzzing.

    That replace filter produced interesting results. I replaced every “A” transmitted by a “B”. On the host, I created a file on a mass storage with 4KB “A”s. When “cat”ting the file from the guest, I saw “A”s. But copying the file in the guest resulted in the new file having all “B”s. I expected the “cat” showing all “B”s, too. And as far as I can see, the “A”s are actually replaced for the “cat”.

    Of course, Istanbul crashed while trying to make that screencast.
    Note that the filter code actually changed by now, not only because I enhanced the protocol (in the version you’re seeing, only USB payload is exchanged. In the new version, also the PID, device address and device endpoint are filtered) but also because I refactored the communication bits into a USBPacket class.
    I missed to show the pen drive from the host point of view after having copied the file in the guest, but the “bbbb” file is full of “B”s.

  • I’m on my way to emulating a USB device, i.e. make the guest think it has a USB device attached but the device is a program running on the guest. I basically copied the USB serial driver and the HID driver and modified them to get packets from a pipe and send them to a pipe. I had serious problems with QEmu: QEmu didn’t register my new “device”. Now I called the right function to initialize the USB device and voila, it attaches it like it should.
    Now I need to obtain valid USB communication using the filter so that I can respond to incoming packets properly.
  • Dear lazyweb, I’m wondering whether I could make my OS load an application but then break on main() so that I can attach a debugger. I cannot run the application *with* GDB. Instead, I want to attach a GDB after the program is fully loaded. Maybe LD_PRELOADing on main() will work?

Practicum Status Update Week 6

Friday, July 9th, 2010
  • So the plan is to modify a Linux driver to see results more easily (once the fuzzing part works). So I tried to get a working environment where I can boot my modified Linux kernel in. My problem being, that I don’t necessarily want to create initrds and somehow want the modules to be inside the guest machine. And I do want modules because I don’t want to boot after I’ve changed a tiny bit of the code. So I debootstrapped onto the filesystem on the host and tried to run Qemu with that directory as virtual FAT drive:
    sudo /opt/muelli/qemu/bin/qemu -monitor stdio -m 1G -kernel /opt/ubuntu/boot/vmlinuz-2.6.32-21-generic -initrd /opt/ubuntu/boot/initrd.img-2.6.32-21-generic -hda fat:ro:/opt/ubuntu/ -runas muelli
    But it fails because the directory is too big.
    I then debootstrapped into a fixed size container and for now I’m going with
    /opt/muelli/qemu/bin/qemu-system-x86_64 -m 1G -smp 1 -hda /opt/ubuntu.img -snapshot -kernel ~/git/linux-2.6/arch/x86_64/boot/bzImage -append ‘root=/dev/sda’
    But that doesn’t seem to work well, because the virtual machine just stops working. Attaching a debugger tells me that the qemu process basically stopped. Weird.
    I basically followed these instructions but in order to make Eclipse index my Linux Kernel, I had to start it with -vmargs -Xmx1024M.
    But debugging the kernel is a bit hard because something with the protocol is weird. The suggested fix doesn’t help.
  • QEmu wouldn’t install windows 7 x86_64, because of a “wrong CPU” type of error. Fortunately, the STOP codes are well documented. Trying to install it on x86 is not possible. I booted the ISO for two days without any success.
  • Found a good overview of USB classes per Windows Version. The USB classes themselves are not very well documented though. But in fairness, I haven’t read the 600+ pages spec yet.
  • Spent ages trying to make sscanf split a string on a colon. Jeez, it’s horrible. I even thought about doing a system("python -c 'mystring.split(':')'") or so… Ended up using strtok:
    if (((speedstr = strtok(copy, ":")) == NULL) || ((filterfilename = strtok(NULL, "\0")) == NULL)) {
    error_report();
    else {}
  • gdb attached to a process crashed from eclipse. GDB also likes to crash if the remote server went down.
    And listening to music with Rhythmbox is hard, too >.<
    QEmu crashes if given a wrong kernel image.
  • Found Patents related to fuzzing, but Zotero won’t import those to my library.
  • I had funny results with the filter: I replaced every “A” transmitted by a “B”. On the host, I created a file on a mass storage with 4KB “A”s. When “cat”ting the file from the guest, I saw “A”s. But copying the file in the guest resulted in the new file having all “B”s. I expected the “cat” showing all “B”s, too. And as far as I can see, the “A”s are actually replaced for the “cat”.

Practicum Status Update Week 5

Saturday, July 3rd, 2010
  • Implemented adding and removal of a filter. It works via the monitor or command line. And it does indeed seem to work:


    Sorry for that video being so poorly embedded in this wordpress instance. You might want to try to download the video directly.

    So yeah, we can potentially filter USB packets by now, which allows us in-place fuzzing. But that’s cumbersome because we need to have a device attached to the host. So the goal must be to be able to do USB communication without a device being attached to the host but with a program that emulates the USB device in question.

  • Of course I had problems to build Istanbul, the software I created the screencast with. Other stuff, including my IDE :-( just crashes, too…
  • I used qemu to pass a usb device through to the guest. Hence the Linux on the host detached the device. I desperately tried make Linux reattach the device. I tried to use ioctl() with USBDEVFS_CLAIMINTERFACE but it didn’t really work. After spending many hours, I just unplugged and replugged the pendrive…
    My code is pretty much

        int interface = atoi(argv[1]);
        fd = open("/dev/bus/usb/002/006", O_RDWR);
        result = ioctl(fd, USBDEVFS_RELEASEINTERFACE, &interface);
        //result = ioctl(fd, USBDEVFS_CLAIMINTERFACE, &interface);
        printf("Result: %d, errno: %d %s\n", result, errno, strerror(errno));
    

    and fails with Invalid Argument for RELEASE or for CLAIM with -EINVAL (Invalid Argument) or -ENOENT (No such file or directory). I have no idea what I am doing wrong. So if you do, please tell me :-P
    Oh, and these ioctls are not exported to Python I think. At least I couldn’t find the correct ioctl number for USBDEVFS_CLAIMINTERFACE without progamming a tiny C program to print it out for me.

  • Trying to test anything with QEmu is a pain though: It takes ages to boot anything with QEmu without KVM :( It takes literally a whole night to boot into an Ubuntu installation CD.
  • trying to work with a minimal operating system created by the following command on my Ubuntu box:
    sudo ubuntu-vm-builder kvm lucid --addpkg openssh-server --addpkg screen --addpkg acpid --addpkg htop --addpkg cheese --flavour generic
  • For the record: I build my QEmu with the following command ./configure --prefix=/opt/muelli/qemu/ --disable-strip --extra-cflags="-O0 -DDEBUG" --disable-docs --enable-io-thread --enable-attr --enable-kvm --disable-xen --target-list="i386-softmmu x86_64-softmmu" --enable-curses && make && make install

Practicum Status Update Week 4

Saturday, June 26th, 2010

Again, a small summary of my last week.

  • Filed a couple of bugs that annoyed me. My favourite: My main monitor dies randomly. Let’s hope it’s not a hardware issue. That’d seriously put me back. In fact, it’s quite cumbersome to reanimate my monitor in the middle of a working session… Oh. And qemu crashes :-( That’s really unfortunate for me atm.
  • Subscribed and quickly unsubscribed qemu-devel mailinglist. Way too noisy. Those low-level people don’t seem to like using bug tracker or smth like ReviewPad to submit patches. Very stressful.
  • Enjoyed a long weekend in Hamburg including watching some Worldcup games
  • Read through Qemu code and tried to grasp how things play together.
  • Started to implement simple USB packet filter. spent ages resolving a logical error: I checked for retval != -23 whereas I should have checked for retval == -23 :(

    We can haz new commands

    So I have exported a new command to the QEmu monitor. And we can even attach some logic to that new command:

    Logic attached, nothing works yet though

    Everything returns -1 at this stage though. So the actual implementation still needs to be done.

  • It literally takes a whole night for me to boot anything with qemu though :-( That’s a real pain and I cannot work that way. My CPU is one of the few modern Intel CPUs that does not support hardware virtualisation :-( I need to think of a solution.
  • I still don’t really have a timeline :-|
  • Our deadline is on 2010-08-20 and we are supposed to hand in 3 hard copies and one soft copy. I wondering whether I have to go back to Dublin to hand my hard copies in.

Practicum Status Update Week 2 and 3

Saturday, June 19th, 2010

So I figured that we are supposed to write a blog during our practicum phase. Here I am.

  • I missed the first official week, which was right after the exams anyway. I doubt anybody was able to do anything after the Biometrics exam.
  • In the second week, I moved back to Germany. Slowly though: I attended LinuxTag and visited a friend…
  • The third week began with some administrative stuff (i.e. taxes and care about a grant). I also almost finished running GNOME Foundation Board of Directors elections: Preliminary Result.
  • More work related: I tried to updated from Fedora 12 to Fedora 13 (to get latest QEmu and tools). Didn’t work (as expected) out of the box. Encountered (and reported) a couple of annoying bugs. My favourite: The update tool tries to mount /boot and swap. But /boot is left unclean because the preupgrade tool apparently does a hard reboot (i.e. w/o unmounting the filesystems properly). And swap can’t be found by the upgrade tool (for whatever reason). In both cases the installer just stops working and reboots the machine (sic!), as opposed to just fsck /boot or continue w/o swap.
  • Began to set up working environment: LaTeX Template, cloned qemu repository, looked a bit at QEmu code.
  • Tried to install some Operating Systems to break. Microsoft didn’t let me.
  • Read some stuff
  • Filed two bugs against Zotero (my bibliography tool): One problem in fullscreen mode and one with proxied URLs.
  • Went to a regulars’ table (for the first time after 9 month) and found out that one of them runs a company and they do USB security assessment atm. They are trying to make QEmu emulate a mass storage that returns a good file on the first read and a bad file (i.e. virus) on the second read. Sounded interesting, we’ll keep in touch and exchange details.
  • Right now I’m missing kind of a plan for my work. I haven’t really structured my work or broken it up. So I’m trying to see how many weeks I actually have (I know that I’ll go at least to GUADEC, the annual GNOME conference, for one week. I might even be invited to GNOME.Asia in Taiwan…) and what I could possibly do in that time.
  • I do have a high level idea of what needs to be done, i.e.
    • Patch QEmu to pipe USB communication in and out,
    • write some backend that uses these pipes to communicate with the guest,
    • find a smart algorithm to create/modify fishy USB packets (i.e. try to understand how a webcam communicates and set funny values for resolution on purpose),
    • try to exploit an Operating System (probably best to start off with a self-broken USB driver or application)
  • I’ll try to have a roadmap by the beginning of the next week.

Trying to download from MSDN-AA: Annoying Secure Digital Container

Monday, June 7th, 2010

I thought I’d give Windows technology a try (actually, I just need something to break) and tried to download Microsoft Operating Systems via e-academy.com (MSDN-AA). But instead of an ISO, you get a Portable Executable *facepalm*. Turns out that this binary downloads “Secure Digital Containers” from, i.e. here or here. These SDCs contain the ISO and are, according to this site, encrypted. The key is supposed to be in that downloader binary. However, no tool exists to decrypt those SDC files :-(

I burnt half a day on that. Now going to look for Torrents of the ISOs… Are there official SHA1sums of the ISOs?

Or, dear lazyweb, do you know anybody that reverse engineered the downloader and is able to provide a free tool that unpacks the ISO from the SDC? :-)

Practicum: Virtualised USB Fuzzing

Monday, May 31st, 2010

Alright, I finally decided on my practicum subject. Together with my supervisor, we came up with the following exposé. I either wanted to do that or to do something in Mobile (Phone) OS security.

USB is omnipresent and so far, mostly Operating System behaviour has been exploited, i.e. automatically run an application off a CDROM. USB-Stack, USB-Driver or application security has not yet been in the focus of security research, probably because it is infeasible to create many USB test devices.

If various USB behaviour could be implemented easily and cheaply, a great diversity of maliciously acting USB devices could be tested with little effort.

The goal is to implement a USB fuzzing framework using a virtualisation software that allows to automatically test different USB behaviour to stress-test USB-Stacks, drivers and applications.

While hardware approaches would be possible, a virtual approach using virtualisation software will be taken. That allows any guest Operating System, including Windows and Linux, to be tested, as well as cheap and quick creation of tests and reliable reproduction of the obtained results.

Ideally, this results in exploits for each of the three identified vulnerable layers:

  • USB Stack in the Operating System
  • USB Driver for the attached device (i.e. Webcam)
  • Application using data from the USB device

Thus following questions will be addressed:

  • How secure are USB stacks when it comes to weird devices?
  • How resistant are drivers when specially crafted payload is sent?
  • How good are applications that act upon a new USB device and read its data?

Critical Review of Tesseract

Tuesday, May 4th, 2010

For CA640 we were supposed to pick a paper from International Conference of Software Engineering 2009 (ICSE 2009) and critically review it.

I chose to review Tesseract: Interactive Visual Exploration of Socio-Technical Relationships in Software Development.

You can find the review in PDF here. Its abstract reads:

This critical review of a paper, which presents Tesseract and was handed in for the ICSE 2009, focusses on
strength and weaknesses of the idea behind Tesseract: Visualising and exploring freely available and loosly coupled fragments (mailing lists, bug tracker or commits) of Free Software development.
Tesseract is thus a powerful data miner as well as a GUI to browse the obtained data.

This critique evaluates the usefulness of Tesseract by questioning the fundamental motivation it was built on, the data which it analyses and its general applicability.

Existing gaps in the original research are filled by conducting interviews with relevant developers as well as providing information about the internal structure of a Free Software project.

Tesseract is a program that builds and visualises a social network based on freely available data from a software project such as mailing lists, bug tracker or commits to a software repository. This network can be interactively explored with the Tesseract tool. This tool shows how communication among developers relates to changes in the actual code. The authors used a project under the GNOME umbrella named Rhythmbox to show their data mining and the program in operation. GNOME is a Free/Libre Software Desktop used as default by many Linux distributions including the most popular ones, i.e. Ubuntu and Fedora. To assess Tesseracts usability and usefulness, the authors interviewed people not related to Rhythmbox asking whether Tesseract was usable and provided useful information.

The paper was particularly interesting for me because the authors analysed data from the GNOME project. As I am a member of that development community, I wanted to see how their approach can or cannot increase the quality of the project. Another focus was to help their attempt to improve GNOME by highlighting where they may have gaps in their knowledge of its internals.

During this critique, I will show that some assumptions were made that do not hold for Free/Libre and Open Source Software (FLOSS) in general and for GNOME in particular either because the authors simply did not have the internal knowledge or did not research carefully enough. Also I will show that the used data is not necessarily meaningful and I will attempt to complement the lacking data by presenting the results of interviews I conducted with actual GNOME developers. This will show how to further improve Tesseract by identifying new usage scenarios. Lastly, this text will question the general usefulness of Tesseract for the majority of Free Software projects.

Imaging RAM using Windd, /dev/fmem or QEmu

Friday, April 9th, 2010

While using FireWire to obtain RAM is pretty convenient and powerful, one might still consider using a different method to capture RAM. A reason might be the absence of a FireWire port or driver, or simply the fact that the necessary cable or software is missing. Another more interesting scenario is the analysis of a systems behaviour, i.e. how does the memory differ between a locked and an unlocked workstation.

Windd

Using FireWire is not the only method to get the RAM. If you want to image Windows’ RAM, you could consider running program, i.e. Windd, on the victims machine which simply dumps all memory to the disk. You might have some problems running it though:

Error: InstallDriver cannot start service (Err=0x00000002)
Error: Cannot open \\.\win32dd

This not very helpful error message wants you to move the .sys file to %WINDIR%\SYSTEM32 and search and delete windd references in the Registry.

When you try to use Windd using a normal, non administrator account, you’ll find that elevated privileges are needed to run the executable:

    -> Error: win32dd requires Administrator privileges

If faced with a PC which is logged in with a non administrative account, which is typically found in a business environment, the Windows runas command needs to be used to run Win32dd with the rights of either a local or domain administrator account:

runas /user:Administrator "Win32dd.exe /f c:\images\memorydump"

When using runas you’ll notice that a full path is needed to be specified for creating the image file. Without specifiying a path, Windd saves the RAM image file in to the %WINDIR%\system32 directory instead of the current directory as you would have expected.

The fmem Kernel Module

Although Linux provides a /dev/mem file, one cannot read the physical RAM through it. In order for Linux to expose the RAM via a file, one can load the fmem Kernel module and use dd to obtain the contents of the physical memory address space, e.g. to obtain one gigabyte of memory dd if=/dev/fmem of=memdump bs=1048576 count=1024.
I tried using cat to dump the RAM but found that it read past the end of the physical memory. This is a known bug with fmem which the author notes in the README file provided with the module.

In order to be able to load the module, it needs to be downloaded and compiled, doing a normal untar, make, and run the supplied run.sh script to install, first. These steps are pretty straight forward.

Using QEmu to save RAM

QEmu is a virtualisation solution that allows to dump the RAM of the guest into a file unsing the pmemsave command. I think this deserves attention because it can be used to prepare attacks using the FireWire technique. That technique allows patching the memory on a running (Windows) system which in turn can be used to, say, unlock a password protected workstation. While unlocking has been done for a Windows XP SP2 system, no publicly available tools do that for a later Windows system.

With QEmu, we are able to run a target system, say Windows XP SP3, and get two memory dumps: The first while the machine is locked, and the second right after unlocking. By looking at the difference, we might be able to tell which data has to be modified in what way in order to remotely unlock the machine. This technique can also be used to, say, disable a Firewall, elevate privileges or even inject new processes into the running system. It is noteworthy that this method is Operating System independent for both, the host and the guest, because QEmu is free software which run on many platforms and can itself run many Operating Systems.

Reading RAM using FireWire

Sunday, April 4th, 2010

Recently, I had to obtain the Random Access Memory (RAM) of a Windows XP SP3 system. The RAM is a storage for (program) data but unlike a harddisk it is around a million times faster and volatile. That is, its contents vanishes within a few seconds after the machine is powered off. But as there is data of the running kernel and almost every running program in the RAM, it contains valuable information about the state of a machine, including passwords, running processes, open connections or registry data.

However, manually obtaining the RAM contents usually involves altering the state of the machine, because the system has to either run a special program (and running programs modifies the state) or to load a special FireWire driver (and loading drivers off the disk into memory alters the machines state). Even hibernating the system modifies the machine because files are written, memory might get compressed, etc. It is possible to obtain the contents of the RAM by cooling the chips down and quickly putting them into a system which keeps refreshing the data so that it can be read with an own system. This method, however, requires a lot of preparation, skill and fortune because every second matters. But even if you manage to save the RAM, you might get into trouble because the examined system will still have a CPU cache which might keep the system up and running, potentially noticing the loss of RAM and changing contents of the disk (i.e. erasing). Since a Windows (Vista) Kernel is around 9.9MiB in size it would not necessarily fit into a 2MiB cache which modern CPUs have, but a Linux (2.6.29) Kernel can be 1.7MiB in size which would fit perfectly. Other, smaller, Kernels such as L4 or QNX exist.

I, however, went with the FireWire method just because I thought it’s fun to snarf other machines memory using just a cable :)

FireWire was invented in 1995 by Apple for high-speed data transmission. By design, it is able to read and write directly to the host machines memory contents. This feature can be exploited to dump the machines memory.

However, to dump Windows’ memory via FireWire, one needs to convince Windows to be eligible to do so by pretending to be, i.e. a proprietary and expensive audio player called “iPod”.

By using existing tools it is relatively easy to dump Windows’ memory.
One needs to download and build pythonraw1394 and the necessary dependencies.
Then, the proper tools, which basically configure the Linux host to be an iPod and dump the victims machine’s memory must be run.
Following script should do all the necessary steps and finally save a 2GB memory dump in a temporary directory.
It is known to work on an Ubuntu 9.10 Linux system.

#!/bin/bash
 
DIR=/tmp/$RANDOM
PYTHONRAW=http://www.storm.net.nz/static/files/pythonraw1394-1.0.tar.gz
LOCALPORT=0
REMOTEPORT=1
NODE=0
 
mkdir -p $DIR &amp;&amp; cd $DIR &amp;&amp;
  wget --continue -O- $PYTHONRAW | tar xvf - &amp;&amp;
  cd pythonraw1394/ &amp;&amp;
  sudo apt-get install -y libraw1394 libraw1394-dev swig python-dev build-essential &amp;&amp;
  sed -i 's/python2\.3/python2\.6/g' Makefile &amp;&amp;
  make &amp;&amp;
  sudo modprobe raw1394 &amp;&amp;
  sudo chgrp $USER /dev/raw1934 &amp;&amp;
  ./businfo &amp;&amp;
  ./romtool -g $LOCALPORT $DIR/localport.csr &amp;&amp;
  ./romtool -s $LOCALPORT ipod.csr &amp;&amp;
  ./1394memimage $REMOTEPORT $NODE $DIR/memdump 0 2G &amp;&amp;
  echo Success, please read the memory at $DIR/memdump || echo Failure

(I’ve just finished packaging that up for Ubuntu)

As for mitigation, the best would be to have no FireWire ports ;-) But it’d be stupid thing to rip off your FireWire ports or putting lots of glue into it, because FireWire is a nice technology that you want to use for your external harddrives, cameras, networking, etc. So simply deactivate the driver if you don’t need it! A plugged in device can thus not make use of the functionality. For Linux, rmmod ohci1394 should be sufficient. To make this permanent, you might want to add “blacklist ohci1394” to your /etc/modprobe.d/blacklist. If you then want to use some FireWire device, simply modprobe ohci1394.

By using the above mentioned script, we successfully obtained the contents of a Windows XP SP3 machine in a temporary directory.
In our case, it took around 500 seconds to capture 1024 MiB RAM. Interestingly enough, when reading more RAM than installed in the victims machine, the program puts 0xffs in the dump file. We rebooted the machine from Windows into Linux and read the RAM. Hence, reading RAM from a machine running Linux (2.6.31) works fine. We found it interesting that we still were able to read memory of the Windows system which we have shutdown properly. So Windows left artefacts which we were able read.

Note that the machine whose RAM we read ran a Linux Kernel which did not make use of the most recent FireWire stack, simply because it has not been officially released yet. It will be interesting to see, how and under which circumstances the new FireWire stack, called Juju, allows the RAM to be read and written.

For completeness, we also tried reading the RAM of a Laptop running MacOS and it worked equally well.

muelli@xbox:/tmp/pythonraw1394$ ionice -c 3 ./1394memimage 0 1 /tmp/windows.mem 0-1G
1394memimage v1.0 Adam Boileau, 2006.
Init firewire, port 0 node 1
Reading 0x3fd00000 (1045504KiB) at 2027 KiB/s...
1073741824 bytes read
Elapsed time 517.51 seconds
Writing metadata and hashes...
muelli@xbox:/tmp/pythonraw1394$ volatility ident -f windows.mem
              Image Name: windows.mem
              Image Type: Service Pack 3
                 VM Type: nopae
                     DTB: 0x39000
                Datetime: Mon Mar 22 19:06:42 2010
muelli@xbox:/tmp/pythonraw1394$

It might be interesting for future research to remotely change Windows’ memory to, say, unlock a password protected workstation, change configuration of a firewall or even inject new processes. Although we consider it to be very interesting to build a tiny appliance that does the memory dump of the victims machine, we could not find anything on the Internet. Given that products on the forensic market are pretty expensive, building such a machine might be very rewarding.