Anti-Forensics via DD (Blazingly Faster than the MAN page)
Disclaimer: Currently deployed to Afghanistan and therefore incapable of downloading the newest Backtrack
Rig:
Toshiba Netbook 32-bit
3 Partition (Logical) 500GB HD
-sda1 --> BT4 r2 (ext2)
-sda2 --> Ubuntu (ext3) (Natty) Original release (8..... I believe) (Can't update, whatever...)
-sda3 --> Windows 7 (NTFS) (don't remember my service pack, not really important for this context)
Over the past 2 weeks I have been playing with different implementations on the usage of DD. I began this when I came across an article somewhere on the net regarding shred/sdelete and its ineffectiveness at wiping data; sadly I don't remember the link or I would post it. However, I decided to do a file backup on my laptop, and came across the fact that I saved the webpage. It is as follows.
This illustrates the problem with "srm". To follow you'll need "sleuthkit" and "secure-delete".
Create a file called data. "ls -Fhli" shows the inode numbers on the left.
Code:
private@host:~$ echo "this is data, data, data" > data
private@host:~$ cat data
this is data, data, data
private@host:~$ ls -Fhli
total 16K
802821 -rw-rw---- 1 private private 25 2008-02-26 11:54 data
802824 drwxrwx--- 2 private private 4.0K 2008-02-26 11:43 docs/
802827 drwxrwx--- 2 private private 4.0K 2008-02-26 11:43 etc/
802818 drwxrwx--- 2 private private 4.0K 2008-02-26 11:43 files/
Now, using Sleuthkit's "istat" command with the inode from "data". At the bottom, istat shows the allocated blocks. "/dev/hda6" is my /home partition, run "df" to find your own device.
Code:
private@host:~$ istat /dev/hda6 802821
inode: 802821
Allocated
Group: 49
Generation Id: 1770472290
uid / gid: 1001 / 1001
mode: -rw-rw----
size: 25
num of links: 1
Inode Times:
Accessed: Tue Feb 26 11:54:47 2008
File Modified: Tue Feb 26 11:54:38 2008
Inode Modified: Tue Feb 26 11:54:38 2008
Direct Blocks:
1619968
Code:
Next, we run "dd". "bs=4096" refers to the block size. "skip=1619968" refers to the direct block (given by istat).
private@host:~$ dd if=/dev/hda6 bs=4096 skip=1619968 | xxd | less
0000000: 7468 6973 2069 7320 6461 7461 2c20 6461 this is data, da
0000010: 7461 2c20 6461 7461 0a00 0000 0000 0000 ta, data........
0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
...
We run "srm data" to "securely" delete the file 'data'. A subsequent call to 'istat' shows the file is unallocated. Is the file 'data' gone?
Code:
private@host:~$ srm data
private@host:~$ istat /dev/hda6 802821
inode: 802821
Not Allocated
Group: 49
Generation Id: 1770472290
uid / gid: 1001 / 1001
mode: -rw-rw----
size: 0
num of links: 0
Inode Times:
Accessed: Tue Feb 26 11:54:47 2008
File Modified: Tue Feb 26 12:03:44 2008
Inode Modified: Tue Feb 26 12:03:44 2008
Deleted: Tue Feb 26 12:03:44 2008
Direct Blocks:
Look below. The data was supposedly cleared. However, running 'dd' again, on the same block as before, shows the data still lingers. 'srm' hasn't cleared the block.
Code:
private@host:~$ dd if=/dev/hda6 bs=4096 skip=1619968 | xxd | less
0000000: 7468 6973 2069 7320 6461 7461 2c20 6461 this is data, da
0000010: 7461 2c20 6461 7461 0a00 0000 0000 0000 ta, data........
0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
...
To clear the block you need to run 'sfill' or use 'dd' with if=/dev/zero or if=/dev/urandom to fill up the filesystem.
I then tried my own method using dd as root; and it worked.
The above experience really got me into thinking how quickly DD could overwrite freespace on a device, and if it was "cross-platform" enough for me in the sense of different file sytem architectures (ext2, ext3, ext4, NTFS, etc....). So, I did what any good true hacker would do and I started experimenting on my own, not just taking the articles on the net at face value. About 3 nights ago I happened to be booted into Ubuntu when I decided to try an implementation of DD using a method that translated the /dev/zero output to all 1s
All of my commands are issued as root
My commands are as follows:
Code:
mkdir mt
mount /dev/sda1 mt
cd mt
dd if=/dev/zero count=1 | tr '\0' '\49' > foo
Good link for ascii reference is: http://web.cs.mun.ca/~michael/c/ascii-table.html
This made me a file 512 bytes in size (512 is the default byte-size unless specified otherwise with bs=) that was filled with 1s for characters. A subsequent: "hexdump -C < foo" confirm the output of 1s. At this point I started trying various implementations of bs & count combinations to come up wih the quickest method for filling a certain device. I made the following observations.
All these were done on different partitions than the operating system in which i tested it. ie.... I filled /dev/sda2 while operating from /dev/sda1, and /dev/sda1 while operating /dev/sda2, /dev/sda3 was windows so i just choose the ubuntu to wipe from.
To see the current speed and progress of a dd operation you simple need to: "ps aux | grep dd", then note the process ID, then issue "kill -USR1 <pid>. This will make a progress dump on the screen doing the DD. The average speed for writing to ext2 & ext3 was found to be around: 22MB/second. The average speed for writing to my NTFS partition averaged out around 5MB a second, it started strong around 20MB a second, but averaged out to the 5 after roughly 1GB of writing.
It was when I happened to have missed a keystroke that the thought for the whole article came up! I was in ubuntu (/dev/sda2) and i had mounted (/dev/sda1) to my home directory ie (mount /dev/sda1 ~/mt)
I then changed to the mt directory (/dev/sda1) and started typing, but I was careless and I typed: "dd if=dev/zero | tr '\0' '\49' > foo". I then issued my kill -USR1 command to see how the progress was coming along and it was at a whopping 48MB/sec! Couldn't believe it...., So, I killed the original process and tried to figure out what had happened. In looking at my syntax I noticed that I did not include a "/" in front of the dev for the if= option. I was now using the (/dev/sda1) partitions /dev/zero file to write to foo.
So, here are some questions I have regarding my experience I hope the community can chime in on:
1) I wonder if anyone else has used dev/zero vs /dev/zero before.
2) Why is if=dev/zero double the speed of if=/dev/zero (Something bout it not being the active O/S?)
3) Help me to improve the following syntax please; the goal of which being able to background DD command that uses pipes and issue kill -USR1 to a variable versus parsing the running processes.
- Example 1:
Code:
dd if=/dev/zero of=foo & pid=$!
the user is then able to type and see the results
- Example 2:
Code:
dd if=/dev/zero of=foo | tr '\0' '\123' > foo & $pid=$!
The problem here is that it issues the pid to the tr command and not dd, I've tried various implementations placing the ampersand right after dd and such, but it all fails......And yes, I am aware that I could simple issue a test expr to make the value of $pid=$pid-1 so to speak, but I would like to learn to proper syntax so that I can understand why it doesnt work. The goal is to background DD so that I dont have to open another screen, while at the same time piping DDs output to a customized command so that I can make it something other than a "null" filled file.
V/r,
Snafu
Pffbt..
Quote:
I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me.. Or thinks I'm a smart ass..
