Scan 24 for October 2002 deals with computer forensics
analysis of a recovered floppy disk. The details of this problem can be found here. We were given six
questions to try to answer including one bonus question. In the next section,
the answers to these questions are given. Following that, the process used to
arrive at these answers is described.
The file “Jimmy Jungle.doc” was recovered from the disk image. In it, the supplier is named with his address as
Jimmy Jungle
626 Jungle Ave Apt 2
Jungle, NY 11111
The complete letter can be viewed here.
The file, coverpage.jpg, contains the string “pw=goodtimes” which appears to be a password. The password is required to decrypt and open a zipped file, which is recovered from the disk image.
The file, Scheduled Visits.xls, is recovered from the disk image and indicates that Joe Jacobs also frequents Key, Leetch, Birard, Richter, and Hull high schools. The spreadsheet can be viewed here.
Three files were recovered from the disk image. Each one was hidden or masked using a different method.
The file, Jimmy Jungle.doc, was simply deleted normally from the disk. As such it was easily recovered using commonly available data restoration utilities.
The second file, coverpage.jpg, was obscured by modifying the file’s entry in the root directory. The starting cluster for the entry was multiplied by 10. The actual starting cluster was 42 while the one indicated by the root directory entry was 420; hence, attempts to read the file based on the bogus starting cluster resulted in reading a blank part of the disk image.
The third file, Scheduled Visits.xls, was masked using a three-step process. First the file was encrypted and compressed using a zip utility. Next the name was changed to “Scheduled Visits.exe”. Finally, the file’s entry in the root directory was modified. The advertised size of the file was truncated to 1000 bytes; thus, utilities accessing the file would only read the first 1000 bytes out of a total of 2560 bytes.
See the next section on the Forensic Process.
I believe that the cover page file was created using the Microsoft Paint application that comes with Windows XP. The JPEG header of a test file created using this application is identical to that of the cover page file. ASCII strings embedded in the “Jimmy Jungle.doc” indicate that it was edited using Microsoft Word Version 10.0, which is the version number for Word 2002. I would expect Word 2002 to be loaded on a Windows XP system.
The process I followed in examining the disk image progressed from using simple tools and techniques to arcane analysis.
My analysis platform consisted of an Intel Pentium III, 850 MHz machine running the Microsoft Windows 2000 Professional operating system. Also loaded on the machine are the Microsoft Office 2000 suite of tools and VMware. Using VMware, I configured and networked a virtual machine (VM) running Red Hat Linux 7.3. The data drive on the VM was shared with the host operating system using Samba. This configuration allowed me to simultaneously process the same data using both Linux and Windows tools on the same machine.
The first step was to get the data and verify its authenticity. I downloaded the zip file, image.zip, from the Honeynet web site and set the file permissions (using “chmod”) to allow only reading and not writing. Next, I computed the MD5 checksum under Linux using the “md5sum” command and compared it with the checksum posted on the web page.
My next step was to try to access the data using the standard Linux and Windows tools. Using the Linux command, “unzip”, I unzipped the file and again set the file permissions to allow only reading. Now I had the raw disk image from the floppy disk in a file called image. I mounted the disk image using the following Linux command: “mount ./image ./fd –o loop,ro”. This successfully mounted the disk image. Issuing the mount command without parameters produces a list of mounted file systems and their types. Using this, I determined that the disk format was VFAT (virtual file allocation table). Using “ls -al”, I saw two files on the disk. Next I used “file *” to see what the file types were. The output of file indicated that schedu~1.exe was a zip archive and that “cover page.jpgc” was PC formatted floppy with no file system. Attempts to view the contents of these files using typical user applications met with failure.
The Linux “strings” command can often provide useful information about files. It prints all ASCII strings of a specified minimum length. I applied this command successively to the two files and the disk image. No interesting strings were found in “cover page.jpgc”, but “schedul~1.exe” contained the string “Scheduled Visits.xls”, a useful hint. When I applied strings to the disk image itself, I found several interesting strings. The text content of the letter to Jimmy Jungle was recovered as well as the string “pw=goodtimes”.
Taking the analysis to the next level, I obtained a demonstration copy of R-Undelete from R-tools Technology Inc. R-Undelete is a file recovery tool. Using this tool, I was able to recover the “Jimmy Jungle.doc” file from the disk image. Also, R-Undelete indicated that the disk image used the FAT12 format. No other files were recoverable using this tool. Any other data recovery would require more advanced techniques.
My next step was to dissect the disk image one byte at a time. Through a web search, I found some documents on the structure of the FAT12 format. A paper on the FAT file system can be found here, and a useful tutorial is here. From these documents, I was able to locate within the disk image those structures that describe the data on the disk. A FAT12 disk is laid out as shown below. In the following, I assume the reader is familiar with the FAT file system structure.
The numbers in the figure indicate the starting sector for that section of the disk. A sector has 512 bytes as defined in the initial boot sector on the disk. Using the KHexEdit tool in Linux, I was able to view the raw data values in the disk image. Below is the initial portion of the boot sector.
Boot Sector
0000:0000 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 01
01 00 ë<.MSDOS5.0.....
0000:0010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00
00 00 .à.@.ð..........
0000:0020 00 00 00 00 00 00 29 cf cd b1 c4 4e 4f 20
4e 41 ......)ÏͱÄNO NA
0000:0030 4d 45 20 20 20 20 46 41 54 31 32 20 20 20
33 c9 ME FAT12 3É
0000:0040 8e d1 bc f0 7b 8e d9 b8 00 20 8e c0 fc bd
00 7c .Ѽð{.Ù¸. .Àü½.|
0000:0050 38 4e 24 7d 24 8b c1 99 e8 3c 01 72 1c 83
eb 3a 8N$}$.Á.è<.r..ë:
0000:0060 66 a1 1c 7c 26 66 3b 07 26 8a 57 fc 75 06
80 ca f¡.|&f;.&.Wüu..Ê
Looking first at the boot record, I found the following
Bytes per sector 512
Sectors per cluster 1
Reserved Sectors 1
FAT Count 2
Max Root Dir Entries 224
Total Sectors 2880
Sectors per FAT 9
Volume Serial 3299986895
Volume Name NO NAME
Format FAT12
This information was used to assign the starting sectors in the preceding figure. Next I examined the FAT and the Root Directory using the same tool, KHexEdit. The non-zero portions of the Root Directory and FAT are shown below.
Root Directory
0000:2600 e5 64 00 6f 00 63 00 00 00 ff ff 0f 00 bc
ff ff åd.o.c...ÿÿ..¼ÿÿ
0000:2610 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff
ff ff ÿÿÿÿÿÿÿÿÿÿ..ÿÿÿÿ
0000:2620 e5 4a 00 69 00 6d 00 6d 00 79 00 0f 00 bc
20 00 åJ.i.m.m.y...¼ .
0000:2630 4a 00 75 00 6e 00 67 00 6c 00 00 00 65 00
2e 00 J.u.n.g.l...e...
0000:2640 e5 49 4d 4d 59 4a 7e 31 44 4f 43 20 00 68
38 46 åIMMYJ~1DOC .h8F
0000:2650 2b 2d 2b 2d 00 00 4f 75 8f 2c 02 00 00 50
00 00 +-+-..Ou.,...P..
0000:2660 42 67 00 63 00 20 00 20 00 20 00 0f 00 f4
20 00 Bg.c. . . ...ô .
0000:2670 20 00 20 00 20 00 20 00 20 00 00 00 20 00
20 00 . . . . ... . .
0000:2680 01 63 00 6f 00 76 00 65 00 72 00 0f 00 f4
20 00 .c.o.v.e.r...ô .
0000:2690 70 00 61 00 67 00 65 00 2e 00 00 00 6a 00
70 00 p.a.g.e.....j.p.
0000:26a0 43 4f 56 45 52 50 7e 31 4a 50 47 20 00 6d
4d 46 COVERP~1JPG .mMF
0000:26b0 2b 2d 2b 2d 00 00 da 43 2b 2d a4 01 e1 3c
00 00 +-+-..ÚC+-¤.á<..
0000:26c0 42 69 00 74 00 73 00 2e 00 65 00 0f 00 9e
78 00 Bi.t.s...e....x.
0000:26d0 65 00 20 00 20 00 20 00 20 00 00 00 20 00
20 00 e. . . . ... . .
0000:26e0 01 53 00 63 00 68 00 65 00 64 00 0f 00 9e
75 00 .S.c.h.e.d....u.
0000:26f0 6c 00 65 00 64 00 20 00 56 00 00 00 69 00
73 00 l.e.d. .V...i.s.
0000:2700 53 43 48 45 44 55 7e 31 45 58 45 20 00 53
53 46 SCHEDU~1EXE .SSF
0000:2710 2b 2d 2b 2d 00 00 90 42 b8 2c 49 00 e8 03
00 00 +-+-...B¸,I.è...
0000:2720 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
0000:2730 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
File Allocation Table 1(FAT1)
0000:0200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00
00 00 ðÿÿ.............
0000:0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
0000:0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
0000:0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 2b ...............+
0000:0240 c0 02 2d e0
02 2f 00 03 31 20 03 33 40 03 35 60 À.-à./..1 .3@.5`
0000:0250 03 37 80 03
39 a0 03 3b c0 03 3d e0 03 3f 00 04 .7..9 .;À.=à.?..
0000:0260 41 20 04 43
40 04 45 60 04 47 80 04 ff af 04 4b
A .C@.E`.G..ÿ¯.K
0000:0270 c0 04 4d
f0 ff 00 00 00 00 00 00 00 00 00 00 00 À.Mðÿ...........
0000:0280 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
0000:0290 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ................
Examining the first three entries in the Root Directory reveals the deleted file, Jimmy Jungle.doc. The e5 in the first byte of each of the first three records indicates a deleted file. Each record is 32 bytes long, so a single record uses exactly two lines in the figure. Since the file was deleted, the clusters used by it were released in the FAT by setting them to zero. The starting cluster is 0002, which we see in the FAT is set to zero. This file can be recovered in a number of ways using file recovery utilities or extracting the appropriate sectors from the image and placing them in a new file using the Linux “dd” command.
Now skip down to records 6-8 (at offsets 0x26C0, 0x26E0, 0x2700). These are the entries for the schedu~1.exe file. Records 6 and 7 give the long filename for this file, while record 8 provides the 8.3 filename and information on where the file is stored and how large it is. The size entry shows 0x03E8 (1000) bytes. The starting cluster for the file is 0x49 (73). This cluster entry is at 109 (0x6D) bytes into the FAT. Since the first FAT table starts at 0x0200 bytes into the image, this cluster is located at 0x026D. The FAT is a singly linked list of clusters assigned to files. By following the list of clusters in the FAT for a given file, we can determine the total number of clusters assigned to the file and where they are located on the disk. From the FAT we find that schedu~1.exe has 5 clusters or 2560 bytes assigned to it (yellow highlighted portion); hence, it appears that the size value for this file has been tampered with in the root directory entry. Using the FAT, I determined that sectors 104 to 108, in order, are allocated to schedu~1.exe. Using the following Linux “dd” command, I extracted the file.
dd if=./image of=recovered-schedul~1.exe bs=512 count=5 skip=104
Recall, that the Linux “file” command reported that this file was a zip archive. The recovered file can be opened with WinZip and reveals that it contains one file, “Scheduled Visits.xls”. Attempting to extract the file results in a prompt for a password. The previously identified string “pw=goodtimes” yields the correct password to extract the file.
Next, look at the root directory entry for coverp~1.jpg. The starting cluster is listed as 0x01a4 (420); however, the FAT is completely zero at this location (not shown in the figure); hence, this must not be the correct starting cluster. Look at the FAT. There is a section of assigned clusters that have not been accounted for (turquoise highlighted section). The starting cluster is at offset 0x23F, which corresponds to a cluster value of 42, which is sector 73. Note that the starting cluster of this unidentified file is exactly one-tenth of the advertised starting cluster for the coverp~1.jpg file. Following the linked list in the FAT reveals that sectors 73 through 103 are allocated to this file. Extracting these sectors using “dd” yields the cover page file, which can be viewed here. Applying the Linux “strings” command to this file, yields several strings one of which is “pw=goodtimes”.
All files and data on the disk image have been accounted for. Below is an updated map of the disk image based on our findings. The numbers along the left side represent the starting sector for each section while the numbers on the right are the offset in bytes into the disk image.
To
address the question of which Microsoft application created the cover page
file, we must dig into that file for identifying signs of the program used to
create it. Applying the Linux “strings” command to the file produced
interesting strings but nothing that specifically identified the application
used to create it. I had previously seen the string “Microsoft Word 10.0” in
the “Jimmy Jungle.doc” file. I would expect this version of Word to be loaded
on a Windows XP system; hence, I included Windows XP applications in my search.
I searched the web for documentation on the JPEG format and found a helpful
reference for decoding the header information in the file. You can find it here. The header
for the cover page file is shown below.
Cover
Page File Header
0000:0000 ff d8
ff e0 00 10 4a 46 49 46 00 01 01 01 00
60 ÿØÿà..JFIF.....`
0000:0010 00 60 00 00 ff
db 00 43 00 08 06 06 07 06 05 08 .`..ÿÛ.C........
0000:0020 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c
19 12 ................
0000:0030 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 24 2e
27 20 ........... $.'
0000:0040 22 2c 23 1c 1c 28 37 29 2c 30 31 34 34 34
1f 27 ",#..(7),01444.'
0000:0050 39 3d 38 32 3c 2e 33 34 32 ff db 00 43 01 09 09 9=82<.342ÿÛ.C...
0000:0060 09 0c 0b 0c 18 0d 0d 18 32 21 1c 21 32 32
32 32 ........2!.!2222
0000:0070 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 2222222222222222
0000:0080 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 2222222222222222
0000:0090 32 32 32 32 32 32 32 32 32 32 32 32 32 32 ff c0 22222222222222ÿÀ
0000:00a0 00 11 08 00 c7 00 d0 03 01 22 00 02 11 01
03 11 ....Ç.Ð.."......
0000:00b0 01 ff c4 00
1f 00 00 01 05 01 01 01 01 01 01 00 .ÿÄ.............
0000:00c0 00 00 00 00 00 00 00 01 02 03 04 05 06 07
08 09 ................
0000:00d0 0a 0b ff
c4 00 b5 10 00 02 01 03 03 02 04 03 05 ..ÿÄ.µ..........
0000:00e0 05 04 04 00 00 01 7d 01 02 03 00 04 11 05
12 21 ......}........!
0000:00f0 31 41 06 13 51 61 07 22 71 14 32 81 91 a1
08 23 1A..Qa."q.2..¡.#
0000:0100 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09 0a
16 17 B±Á.RÑð$3br.....
0000:0110 18 19 1a 25 26 27 28 29 2a 34 35 36 37 38
39 3a ...%&'()*456789:
0000:0120 43 44 45 46 47 48 49 4a 53 54 55 56 57 58
59 5a CDEFGHIJSTUVWXYZ
0000:0130 63 64 65 66 67 68 69 6a 73 74 75 76 77 78
79 7a cdefghijstuvwxyz
0000:0140 83 84 85 86 87 88 89 8a 92 93 94 95 96 97
98 99 ................
0000:0150 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4 b5
b6 b7 .¢£¤¥¦§¨©ª²³´µ¶·
0000:0160 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2 d3
d4 d5 ¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕ
0000:0170 d6 d7 d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8 e9
ea f1 ÖרÙÚáâãäåæçèéêñ
0000:0180 f2 f3 f4 f5 f6 f7 f8 f9 fa ff c4 00 1f 01 00 03 òóôõö÷øùúÿÄ.....
0000:0190 01 01 01 01 01 01 01 01 01 00 00 00 00 00
00 01 ................
0000:01a0 02 03 04 05 06 07 08 09 0a 0b ff c4 00 b5 11 00 ..........ÿÄ.µ..
0000:01b0 02 01 02 04 04 03 04 07 05 04 04 00 01 02
77 00 ..............w.
0000:01c0 01 02 03 11 04 05 21 31 06 12 41 51 07 61
71 13 ......!1..AQ.aq.
0000:01d0 22 32 81 08 14 42 91 a1 b1 c1 09 23 33 52
f0 15 "2...B.¡±Á.#3Rð.
0000:01e0 62 72 d1 0a 16 24 34 e1 25 f1 17 18 19 1a
26 27 brÑ..$4á%ñ....&'
0000:01f0 28 29 2a 35 36 37 38 39 3a 43 44 45 46 47
48 49 ()*56789:CDEFGHI
0000:0200 4a 53 54 55 56 57 58 59 5a 63 64 65 66 67
68 69 JSTUVWXYZcdefghi
0000:0210 6a 73 74 75 76 77 78 79 7a 82 83 84 85 86
87 88 jstuvwxyz.......
0000:0220 89 8a 92 93 94 95 96 97 98 99 9a a2 a3 a4
a5 a6 ...........¢£¤¥¦
0000:0230 a7 a8 a9 aa b2 b3 b4 b5 b6 b7 b8 b9 ba c2
c3 c4 §¨©ª²³´µ¶·¸¹ºÂÃÄ
0000:0240 c5 c6 c7 c8 c9 ca d2 d3 d4 d5 d6 d7 d8 d9
da e2 ÅÆÇÈÉÊÒÓÔÕÖרÙÚâ
0000:0250 e3 e4 e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7
f8 f9 ãäåæçèéêòóôõö÷øù
0000:0260 fa ff da
00 0c 03 01 00 02 11 03 11 00 3f 00 f7 úÿÚ..........?.÷
The
highlighted bytes are the markers that identify different sections of the file.
Note that the last marker highlighted FFDA indicates the start of the image
data, so all entries following this marker are dependent on actual image
content.
I
examined this file using the Microsoft Photo Editor application to find the
properties of the file listed below.
Cover
Page File Properties
True
Color (24-bit)
Width:
208 pixels
Height:
199 pixels
Pixel
Density: 96 pixels/inch in both directions
No
transparency
I
created a number of test images using different applications to see which would
default to true color and 96 pixels/inch. I then compared the headers of these
files to that of the cover page. I found that only Microsoft Paint on Windows
XP will produce an identical header to the cover page header (see below). In
particular, the application uses the identical image density (96 pixels/inch)
and quantization table (data following markers FFDB) as the cover page file. No
other application defaulted to these values. Hence, it is highly likely that
the cover page file was created using Microsoft Paint on Windows XP.
MS
Paint on XP Test Image Header
0000:0000 ff d8
ff e0 00 10 4a 46 49 46 00 01 01 01 00
60 ÿØÿà..JFIF.....`
0000:0010 00 60 00 00 ff
db 00 43 00 08 06 06 07 06 05 08 .`..ÿÛ.C........
0000:0020 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c
19 12 ................
0000:0030 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 24 2e
27 20 ........... $.'
0000:0040 22 2c 23 1c 1c 28 37 29 2c 30 31 34 34 34
1f 27 ",#..(7),01444.'
0000:0050 39 3d 38 32 3c 2e 33 34 32 ff db 00 43 01 09 09 9=82<.342ÿÛ.C...
0000:0060 09 0c 0b 0c 18 0d 0d 18 32 21 1c 21 32 32
32 32 ........2!.!2222
0000:0070 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 2222222222222222
0000:0080 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 2222222222222222
0000:0090 32 32 32 32 32 32 32 32 32 32 32 32 32 32 ff c0 22222222222222ÿÀ
0000:00a0 00 11 08 00 c7 00 d0 03 01 22 00 02 11 01
03 11 ....Ç.Ð.."......
0000:00b0 01 ff c4
00 1f 00 00 01 05 01 01 01 01 01 01 00 .ÿÄ.............
0000:00c0 00 00 00 00 00 00 00 01 02 03 04 05 06 07
08 09 ................
0000:00d0 0a 0b ff
c4 00 b5 10 00 02 01 03 03 02 04 03 05 ..ÿÄ.µ..........
0000:00e0 05 04 04 00 00 01 7d 01 02 03 00 04 11 05
12 21 ......}........!
0000:00f0 31 41 06 13 51 61 07 22 71 14 32 81 91 a1
08 23 1A..Qa."q.2..¡.#
0000:0100 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09 0a
16 17 B±Á.RÑð$3br.....
0000:0110 18 19 1a 25 26 27 28 29 2a 34 35 36 37 38
39 3a ...%&'()*456789:
0000:0120 43 44 45 46 47 48 49 4a 53 54 55 56 57 58
59 5a CDEFGHIJSTUVWXYZ
0000:0130 63 64 65 66 67 68 69 6a 73 74 75 76 77 78
79 7a cdefghijstuvwxyz
0000:0140 83 84 85 86 87 88 89 8a 92 93 94 95 96 97
98 99 ................
0000:0150 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4 b5
b6 b7 .¢£¤¥¦§¨©ª²³´µ¶·
0000:0160 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2 d3
d4 d5 ¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕ
0000:0170 d6 d7 d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8 e9
ea f1 ÖרÙÚáâãäåæçèéêñ
0000:0180 f2 f3 f4 f5 f6 f7 f8 f9 fa ff c4 00 1f 01 00 03 òóôõö÷øùúÿÄ.....
0000:0190 01 01 01 01 01 01 01 01 01 00 00 00 00 00
00 01 ................
0000:01a0 02 03 04 05 06 07 08 09 0a 0b ff c4 00 b5 11 00 ..........ÿÄ.µ..
0000:01b0 02 01 02 04 04 03 04 07 05 04 04 00 01 02
77 00 ..............w.
0000:01c0 01 02 03 11 04 05 21 31 06 12 41 51 07 61
71 13 ......!1..AQ.aq.
0000:01d0 22 32 81 08 14 42 91 a1 b1 c1 09 23 33 52
f0 15 "2...B.¡±Á.#3Rð.
0000:01e0 62 72 d1 0a 16 24 34 e1 25 f1 17 18 19 1a
26 27 brÑ..$4á%ñ....&'
0000:01f0 28 29 2a 35 36 37 38 39 3a 43 44 45 46 47
48 49 ()*56789:CDEFGHI
0000:0200 4a 53 54 55 56 57 58 59 5a 63 64 65 66 67
68 69 JSTUVWXYZcdefghi
0000:0210 6a 73 74 75 76 77 78 79 7a 82 83 84 85 86
87 88 jstuvwxyz.......
0000:0220 89 8a 92 93 94 95 96 97 98 99 9a a2 a3 a4
a5 a6 ...........¢£¤¥¦
0000:0230 a7 a8 a9 aa b2 b3 b4 b5 b6 b7 b8 b9 ba c2
c3 c4 §¨©ª²³´µ¶·¸¹ºÂÃÄ
0000:0240 c5 c6 c7 c8 c9 ca d2 d3 d4 d5 d6 d7 d8 d9
da e2 ÅÆÇÈÉÊÒÓÔÕÖרÙÚâ
0000:0250 e3 e4 e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7
f8 f9 ãäåæçèéêòóôõö÷øù
0000:0260 fa ff da
00 0c 03 01 00 02 11 03 11 00 3f 00 f7 úÿÚ..........?.÷
The recovery of information from the disk image required detailed knowledge of the data structures that implement the file system and an ability to examine and extract any data in the disk image. The standard tools included with Windows 2000 Professional and Red Hat Linux were sufficient for this exercise. The process used here is, however, not scalable. For example, a 120GB hard drive loaded with thousands of files would require automated processes to be successful.
By: Dennis Ruck, druck002@butter.toast.net