computer forensics - identifying disk differences — broken mirrors

8/3/2019 Computer Forensics - Identifying Disk Differences — Broken Mirrors

http://slidepdf.com/reader/full/computer-forensics-identifying-disk-differences-broken-mirrors 1/4

Computer Forensics: Identifying DiskDifferences — Broken Mirrors

Posted by Dave Hull on August 12, 2010 – 11:30 amFiled under Computer Forensics, Evidence Analysis, artifact analysis

One Friday afternoon I was greeted by a large package from FedEx. Inside the giant box was supposed to be a hard disk

drive on which I was to conduct digital forensic analysis. Opening the box and removing a few handfuls of packing peanuts

revealed a bubble-wrapped Dell Tower. Obviously, the clients, like most non-computer folks, didn’t know they could remove

the actual hard disk drive from the tower and send those my way.

After grabbing the paperwork for this job, filling out my own chain-of-custody documentation and evidence receipt, I

cracked open the tower and saw the following inside:

Image 1: Double SATA, double fun

This job suddenly got more interesting and possibly less profitable for me. I wondered if the clients knew when they hired

me for the job that the system contained two disks. I disconnected the lower drive from the system, added it to my

evidence inventory as D1 and connected it to my write-blocker and then to the SIFT Workstation.

After gathering the mmls output for the image, I started the imaging process. The output from mmls looked something like

this (actually, it looked nothing like this. I’m not going to expose details of the c lient’s system. For our purposes, this

works):

DOS Partition Table

Offset Sector: 0

Units are in 512-byte sectors

Slot Start End Length Description

00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)

01: ----- 0000000000 0000000062 0000000063 Unallocated

02: 00:00 0000000063 0000210923 0000210861 Dell Utilities FAT (0xde)

03: Meta 0000210924 0007952615 0007741692 Win95 Extended (0x0F)

04: Meta 0000210924 0000210924 0000000001 Extended Table (#1)

05: ----- 0000210924 0000210986 0000000063 Unallocated

06: 01:00 0000210987 0007952615 0007741629 NTFS (0x07)

Based on the interviews with my clients and the information I had about the case, I knew that the NTFS partition would be

the primary focus of my investigation. I started the disk imaging process and went out for a walk-about.

After dc3dd finished imaging and hashing the disk image. I returned D1 to the Dell tower and removed the second hard disk

drive, added it to the evidence inventory as D2 and repeated the process above.

Running mmls on D2 revealed the following information:

DOS Partition Table

Offset Sector: 0

Units are in 512-byte sectors

Slot Start End Length Description

00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)

01: ----- 0000000000 0000000062 0000000063 Unallocated

02: 00:00 0000000063 0000210923 0000210861 Dell Utilities FAT (0xde)

03: Meta 0000210924 0007952615 0007741692 Win95 Extended (0x0F)

04: Meta 0000210924 0000210924 0000000001 Extended Table (#1)

05: ----- 0000210924 0000210986 0000000063 Unallocated

06: 01:00 0000210987 0007952615 0007741629 NTFS (0x07)

Astute readers will note that D2 ′ s partition table matches D1′ s exactly. I breathed a sigh of relief as it appeared that D1

and D2 were a mirrored pair likely running in RAID1 configuration. This meant that I could limit my analysis to a single drive

and probably finish the job on the original time line I’d promised and without losing money on the gig.

Rather than image D2, I took an MD5 hash of it to verify that it matched D1. Sadly, it did not. If the drives were supposed

Search for:

CATEGORIES

artifact analysis

Browser ForensicsCase Leads

Certification and License

Challenge

Computer Forensic Hero

Computer Forensics

Computer Forensics and IRSummit

Digital Forensic Law

Drive Encryption

eDiscovery

Email Investigations

Ethics

Evidence AcquisitionEvidence Analysis

Incident Response

Linux IR

Malware Analysis

Memory Analysis

Mobile Device Forensics

Network Forensics

Registry Analysis

Reporting

Reverse Engineering

Timeline Analysis

Uncategorized

USB Device Analysis

Windows IR

Write Blockers

Computer Forensics: Identifying Disk Differences — Broken Mirrors http://blogs.sans.org/computer-forensics/2010/08/12/computer-fore...

2 di 6 12/08/2010 19.33

http://blogs.sans.org/computer-forensics/2010/08/12/computer-fore




to be a mirrored pair, the synchronization was apparently broken. At this point, I mounted the NTFS partition on the SIFT

workstation and viewed the contents of the root directory and compared them to the contents of the root directory of the

NTFS image I’d collected already. Everything in the root directory was the same, file names, sizes, time stamps,

sub-directory names and so on. My theory that this was a mirrored pair out of sync had some life in it. I started imaging D2

and thought about ways of quickly iso lating differences between the two disks.

My first thought was to run Jesse Kornblum’s ssdeep against the disk images to see how similar they were. I tried this, but

ssdeep complained, “Value too large for defined data type.”

Next I decided to carve out each partition and calculate MD5 hashes and compare them. One by one, the partitions were

carved and their MD5 hashes compared. In the end, each partition’s hash matched except for the NTFS partition.

Knowing that one of the options fo r dc3dd is the hashwindow option, which can be used for piecewise hashing, I decided

to use it to determine how similar the two disks were. Here are the commands I used:

dc3dd if=D1_ntfs.img hash=md5 hashwindow=10M hashlog=D1.hashlog of=/dev/null

dc3dd if=D2_ntfs.img hash=md5 hashwindow=10M hashlog=D2.hashlog of=/dev/null

Note the output file is /dev/null. I didn’t need to create new images, I’d already carved them out. All I wanted from this

operation was to locate which portions of the two disk images were different. The result of running these two commands

was a couple of text files containing MD5 hashes for 10 MB sections of the NTFS partitions. Here’s a sample of the output:

md5 0- 10485760: fdfd6a607ebef09871c3c51140e9eb40

md5 10485760- 20971520: f1c9645dbc14efddc7d8a322685f26eb




...


md5 492830720- 503316480: 00254e8b9cf9c6d3a1f6ba8040cf4782

md5 503316480- 513802240: 348b1f2236220e4ab71e335385cb80femd5 513802240- 524288000: f1c9645dbc14efddc7d8a322685f26eb

...

The first column of output shows us the hashing algorithm that was used, then the starting and ending byte offsets, followed

by the MD5 sum for the bytes in that range. Note that the first 10 MB section of the partition contained data, the next 470

MBs of the partition contained no data, thus the MD5 sums for each 10 MB section were the same until finally, between

470 and 480 MBs, the partition contained something other than nulls, hence the MD5 sums started to vary again.

I was curious to see how different the two sets of hashlogs were. So I ran ssdeep against the first hashlog file and saved

the result, then ran ssdeep against the second hashlog, comparing its result against the first:

ssdeep D1.hashlog > D1.hashlog.ssdeep

ssdeep -m D1.hashlog.ssdeep D2.hashlog

/cases/20100808/D2.hashlog matches D1.hashlog.ssdeep:/cases/20100808/D1.hashlog (88)

The hashlogs from these two partitions are 88% alike according to ssdeep. I now had more evidence that these two

partitions were (at one point in time) a mirrored pair. The next step was to locate the differences between the two

partitions. To do that, I used the diff command:

diff D1.hashlog D2.hashlog

1c1

< md5 0- 10485760: fdfd6a607ebef09871c3c51140e9eb40

---

> md5 0- 10485760: ef9f993a60a6a77114aab999091597ce

48c48

< md5 492830720- 503316480: 00254e8b9cf9c6d3a1f6ba8040cf4782

---

> md5 492830720- 503316480: 547bd7c44930a1911cd6ce6f85b606df

51c51

< md5 524288000- 534773760: 705c8fc001d91cc32919d34d83127df6

---

> md5 524288000- 534773760: 64772837bbb0502f98af41261bb3743e

53c53

< md5 545259520- 555745280: 272594145001e58f0b1dfba6e7a36ce1

---

> md5 545259520- 555745280: 3497c9365449e8339c550b161ea98535

55,56c55,56

< md5 566231040- 576716800: b20266a7591cac2f2cfa9f8375a71761

< md5 576716800- 587202560: f9b18be13c774fa009717101ec495afc

---

> md5 566231040- 576716800: 58638effcded45e272d555def45351f8

> md5 576716800- 587202560: c366890edd98ed67c381adc7c294dfb5

58,61c58,61

< md5 597688320- 608174080: 9a30b16c50fdd1e6b46c621cabde0ecd

< md5 608174080- 618659840: 59f55c57bc15467e1734d8eab837b02c

< md5 618659840- 629145600: cdcb01a465f188cff6e08b5189413f2e

< md5 629145600- 639631360: 7981b144a85149fcac7fce2161d44278

---

> md5 597688320- 608174080: dedffa8e94b137914ae70ee64d02ec5b

> md5 608174080- 618659840: 9261d04130b4802a9ee6cfe50e5b3f2a

> md5 618659840- 629145600: 46f66e9d9711815a521a3429179f3e42

> md5 629145600- 639631360: 5696f83cead6b1fc80bf5b7819535f99

63c63

< md5 650117120- 660602880: 43aadd02600598fab034d091684c9dff

---

> md5 650117120- 660602880: 9d6db2c17acc1c321493bd054510c1d1

190c190

< md5 1981808640- 1992294400: c8a0dc3bcbedc485c3ebfd06087a34d8

---> md5 1981808640- 1992294400: b6a289e4342258a016223eb4400f1c8c

380c380

< md5 TOTAL: a347712cc414e2f7ea23baedd929d620

---

> md5 TOTAL: 2ba46718f54169305073b0bc469bc1e9


3 di 6 12/08/2010 19.33





If you’re anything like me, that may look like mind numbing output. Let’s review a few lines of the output line-by-line. First is

the diff command itself, simple enough, compare D1.hashlog to D2.hashlog. The next line, “1c1 ″ refers to line number one

in each file, the “c” means that line number one in the second file has “changed” compared to the first file. The next several

lines of diff output follow this same format, then we see

55,56c55,56

< md5 566231040- 576716800: b20266a7591cac2f2cfa9f8375a71761

< md5 576716800- 587202560: f9b18be13c774fa009717101ec495afc

---

> md5 566231040- 576716800: 58638effcded45e272d555def45351f8

> md5 576716800- 587202560: c366890edd98ed67c381adc7c294dfb5

This means that lines 55 through 56 of file one have changed in file two, based on this explanation, you can make sense of

the rest of the file. Given diff’s output, we’ve narrowed down the differences between the two ~4 GB fi les to 120 MBs. We

can now narrow in on the differences even more by repeating the process above using a smaller hashwindow and

restricting dc3dd to those sections of the NTFS images where we know the differences reside.

The output in the hashlog files contains byte offsets . When we run dc3dd, we’ll be working with blocks. We can specify our

block size and divide the byte offsets given in diff’s output and drill down to the specific portions of each 10 MB section to

more precisely locate the differences. Here’s an example:

dc3dd bs=512 if=D1_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_

warning: sector size not probed, assuming 512

dc3dd 6.12.3 started at 2010-08-08 21:47:49 -0400

command line: dc3dd bs=512 if=D1_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 h _ _

compiled options: DEFAULT_BLOCKSIZE=32768

sector size: 512 (assumed)

md5 0- 1048576: d5c912a902d74371aa06aafefe21674a

md5 1048576- 2097152: b6d81b360a5672d80c27430f39153e2c

...

dc3dd bs=512 if=D2_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_


dc3dd 6.12.3 started at 2010-08-08 21:50:17 -0400

command line: dc3dd bs=512 if=D2_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 h _ _



md5 0- 1048576: 042a76d72aaf721c2d49246a40d974df

md5 1048576- 2097152: b6d81b360a5672d80c27430f39153e2c

...

I’ve abbreviated the output, but you can see that where previously we knew that there was a difference in the first 10 MBs,

now we know that difference is actually in the first MB. Now we’re getting somewhere. Let’s zoom in on the first MB from

each file and see how we can pinpoint the difference.

dc3dd bs=512 if=D1_ntfs.img of=/dev/null hash=md5 hashwindow=512 count=20 hashlog=D1_1MB

dc3dd bs=512 if=D2_ntfs.img of=/dev/null hash=md5 hashwindow=512 count=20 hashlog=D2_1MB

These dc3dd commands collect the MD5 hashes for every 512 bytes of data for the first 1 MB of each NTFS partition.

Running diff on the two resulting hashlog files, we get the following result:

diff D1_1MB.hashlog D2_1MB.hashlog

17c17

< md5 8192- 8704: 590693b0719f5a66787565fa3d795e05

---

> md5 8192- 8704: dc1196943e31869bbcf12fe86f7d896c

Now we know the difference in the first MB of the NTFS partitions is somewhere between byte offset 8192 and 8704. At

this point, we can easily carve out this section of each file and compare them.

dc3dd if=D1_ntfs.img of=D1_8192-8704.img bs=512 skip=16 count=1 hash=md5


dc3dd 6.12.3 started at 2010-08-08 22:18:22 -0400

command line: dc3dd if=D1_ntfs.img of=D1_8192-8704.img bs=512 skip=16 count=1 hash=md5



md5 TOTAL: 590693b0719f5a66787565fa3d795e05

1+0 sectors in

1+0 sectors out

512 bytes (512) copied (100%), 0.00191684 s, 261 K/s

dc3dd completed at 2010-08-08 22:18:22 -0400

dc3dd if=D2_ntfs.img of=D2_8192-8704.img bs=512 skip=16 count=1 hash=md5


dc3dd 6.12.3 started at 2010-08-08 22:18:42 -0400

command line: dc3dd if=D2_ntfs.img of=D2_8192-8704.img bs=512 skip=16 count=1 hash=md5



md5 TOTAL: dc1196943e31869bbcf12fe86f7d896c

1+0 sectors in

1+0 sectors out

512 bytes (512) copied (100%), 0.00155415 s, 322 K/s

dc3dd completed at 2010-08-08 22:18:42 -0400

Let’s review our dc3dd command above. We s pecify our blocksize (bs) as 512 bytes and we want to s kip to byte offset

8192 and collect a s ingle block. Skip and count both take blocks as arguments so we divide 8192 by 512 and get 16 for

our skip value. Note also that our MD5 sums for each of the 512 byte sections we’ve carved out, match the previous MD5sums.

Now to pinpoint the differences in these 512 byte sections, I run them through xxd, dumping them as hexadecimal files and

then diff those two files:


4 di 6 12/08/2010 19.33





xxd -g1 -u D1_8192-8704.img > D1_8192-8704.img.xxd

xxd -g1 -u D2_8192-8704.img > D2_8192-8704.img.xxd

diff D1_8192-8704.img.xxd D2_8192-8704.img.xxd

1c1

< 0000000: FF FF 00 07 00 00 00 00 7E 37 01 03 00 00 00 00 ........~7......

---

> 0000000: FF FF 00 07 00 00 00 00 FF 3F 00 00 00 00 00 00 .........?......

That’s it, repeat this process and determine if the differences between the two disks are relevant to the case. And of

course, in true SANS fashion, now that you’ve seen the difficult way to do something like this, you should know that the

SIFT Workstation includes vbindiff, which can solve this problem for you and in a much more elegant way, though you may

still run into instances where the files you are working with are too large for vbindiff. Here’s a screen capture of vbindiff

showing the above difference:

Image 2: vbindiff D1_ntfs.img D2_ntfs.img

Dave Hull is an incident responder and forensic investigator for a Fortune 10000 CIRT where he enjoys being the

dumbest person in the room. Over the years he has worn many hats and still dons them from time to time. When he’s not

flipping bits, he enjoys teaching for the SANS Institute.

Digg vote now

Permalink | Comments RSS Feed - Post a comment | Trackback URL.

2 Comments

Andrew HayPosted August 12, 2010 at 1:00 pm | Permalink

Wow, great post. We need more walkthrough’s like this ;)

Ken PryorPosted August 12, 2010 at 4:02 pm | Permalink

I agree with Andrew. What an excellent post! Thanks Dave!KP

Post a Comment

Your email is never published nor shared. Required fields are marked *

Name *

Email *

Website


5 di 6 12/08/2010 19.33



computer forensics - identifying disk differences — broken mirrors

Documents