Link to the NIST research on dd isues

I've written a couple of simple overviews of the issues surrounding dd and the seeming lost sectors when bad blocks are encountered. I neglected in my previous posts to include a link to the research by NIST at http://dfrws.org/2007/proceedings/p13-lyle.pdf.

Speaking to both Drew Fahey and Barry Grundy the feeling is that there is no reason to overreact, virtually every tool we use has some flaw or another, however further research is needed to be clear about the issue and how to circumvent it.

I'm off to present at the ACPO conference tomorrow and I'm sure the subject will come up, I'll post any interesting comments.

Norway

I'm teaching this week at the National Police University in Norway and have met some very interesting and talented investigators from various services. What is very interesting is the almost total lack of organised defense experts. It is quite fascinating that most cases with computer evidence rely almost totally upon the prosecution expert with no counter from an alternative position.

As I do both prosecution and defense work I can see the pros and cons from both sides but although I do not doubt the integrity of the officers here I do believe that a sound defense requires experts giving testimony from both sides. Even though with the best will in the world the reports should be the same, we both look at the same data, we all know that things get missed and some issues and elements can be explained in more ways than one.

It is does seem that some officers are now beginning to leave the service and set up on their own so I suppose we will begin to see that change. In the UK, of course, we have many defense experts and although one has to wonder about the competence and even integrity of one or two, at least a defendant can be assured of a second set of eyes on the data. Dont get me started on the need for industry control, I can go on all day. Doesn't mean I know how to solve the problem though!

I guess setting up in Norway could be a good thing for someone?

Linux dd issues part 2

I spoke in the last few posts about the issues with dd both in Windows and Linux. Having recommended in a previous post that you use dd_rescue with the -d flag added to enable direct disk access I have since found that when running it from the Helix distro it appears to work but instead creates a 0 byte file. I can't get my head around why it would do this.

However, following more research it appears that using GNU-dd in Linux you can enable the iflag=direct argument. This seems to enable O_DIRECT disk access and avoid the seeming buffering issues. Testing this against a drive with no errors it acquired the drive as expected and provided the right hash, so at least it doesn't mess things up.

Interestingly I emailed Barry Grundy about it and he had been following the same line of research and testing. Both of us are away from our labs for a week or so and will not be able to test against a drive with bad sectors until then but I will post again.

If you wish to try it the syntax is simple:-

dd if=/dev/(drive) of = (where you save it) conv=noerror iflag=direct

If you get any interesting results please don't hesitate to contact me.

...and FAU-dd issues

Having just posted about DCFLDD, my good friend Jim also pointed out that I had ignored the issues with FAU-dd from George Garner. Helix uses this dd version on the Windows side, specifically because it supports the \\.\PhysicalMemory device to grab RAM. It has been noted that even if the block size is set to 512b FAU-dd still copies data at 4096b to increase speed. however, if it encounters a bad block it will skip 4096b.

The latest version from George steps back from 4096b to 512b when a bad block is found to minimize lost data but unfortunately support for \\.\PhysicalMemory was removed in that version. This is only an issue if bad blocks are found. Removing the noerror switch will stop dd if errors are found and enable you to use a different tool if you are concerned about this. (do not remove the noerror switch when imaging RAM, it will stop almost immediately)

Also, to get around this, FTK imager is installed on the Windows side and there are no reported problems of this type with that tool. However, running from a GUI will have a greater footprint on a live system.

DCFLDD problems

A number of concerns have been raised recently about certain linux dd implementations such as DCFLDD. You can read about it at http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=2557 and http://tech.groups.yahoo.com/group/ForensicAnalysis/message/82

In simple terms the problems revolve around how dd treats a bad sector. With the noerror flag set one would hope that dd would jump the bad sector, zero it and move on. However it would seem that a number of sectors are being missed when a bad block is found. Research by Barry Grundy and others indicates that this is due to the way the Linux kernel buffers data coming from the device being imaged. The buffering is a good thing as it speeds things up but it also would seem to enable the skipping of good sectors when a bad one is encountered.

This affects one of my favourite tools, Helix. Helix uses the DCFLDD tool as a basis for the Adepto GUI on the Linux side. In the meantime if you are using Helix you can make use of dd_rescue, making sure that the -d flag is set which enables direct disk access to the device. If you were planning to image the disk sda to an attached drive sdb1 this would look something like:-

dd_rescue -d -v /dev/sda /media/sdb1/image.dd

The release of Helix Pro later this year will deal with issue.

SMTP woes

I've recently enjoyed a holiday in France and frighteningly one of the first questions I asked my Brother who booked the house was about Internet availability. He had already asked and Wifi was available in the house. It meant my hands could stop shaking with the stress of possibly being disconnected for 2 weeks. Well in reality my Vodafone dongle would have taken a hammering.

We rocked up to the house (beautiful place by the way) and 20 minutes after unpacking the cars there were 2 MacBook Pros glowing silently on the dining room table. In fact we had 3 notebooks between us as I had also taken my Asus EEE as mentioned in the previous post. Sad eh, but even my wife doesn't moan anymore as long as emails are answered, blogs are written etc at appropriate times.

In fact the laptops came in useful on a number of occasions, looking up the weather, finding a local Kart track, finding a good restaurant and route finding to a Chateaux. Even the parents and in-laws were on board.

Later that day a number of emails arrived but as I've found with a number of ISP's my normal SMTP details were blocked. There are a bunch of ways around this but for your information I used http://whatismyip.com to get the IP address assigned to the router, next I did a look up on SamSpade to find out who owned the IP. This turned out to be France Telecom i.e. Orange, a quick Google search found the details smtp.orange.fr which then worked perfectly with no authentication.

If you travel alot there is a paid option of www.smtp.com, for about $10 a month for 50 emails a day you can send emails through any ISP without the hassle of changing details.

You can of course just switch to webmail but I like my Mac Mail.

As an aside I cracked the WEP code on the house's router in 4 minutes 37 seconds - AAAAAAAAAAAAAFFFFFFFFFFFFF. I love my EEE!

EEE'up its good

A number of us have been working on the new Asus EEE PC 900. If you haven't heard of it, its a small form PC which is still very useable. The new 900 has a 20 gig solid state HD and larger screen than its predecessor. (I've got the black version which I think looks nicer than the 'ipod'esque white one).

The rather cool element to the EEE is the in-built Atheros WIFI chipset which supports monitor mode and packet injection. I'm not going to write a detailed explanation about why this is a good thing but any user of Aircrack-ng, Kismet or other such tools will be delighted.

The default OS is a Xandros Linux environment which is quite cool for day to day browsing use, however you are able to boot from the internal SD slot. With a little fiddling you can install Backtrack on an SD card, make it bootable (check the readme on the Backtrack download) and just by holding down the ESC key at boot time, fire up a full Backtrack environment. I managed to get up and working in about 10 minutes and even had a USB Railink Wifi adapter up and working too. Its tiny size makes it perfect for Wifi activities when out and about and at around £300 quid it would be rude not to!