edu(b)log

A note for those of you taking Computer Architecture, Forensics, or Programming Languages now...

The notes from last semester are available in chronological order at my backup site. Click on the category link on the right-hand side to view notes from that class only. Saves you from having to read bottom-up…

Final Exam Review

The exam will be on WebCT. It must be completed by next Wednesday and once you start it you must finish within three hours.

FAT File System

FAT 12 used 3 nibble numbers which were hard to deal with. You move away from that with FAT 16, although the basics of FAT 12 and 16 are the same. With 12 and 16, you have a fixed size root directory.

With FAT 32, the root directory is out in the data area and may grow as it needs to (so it may be fragmented, etc. though it'll start in cluster 2).

Directories

What does a directory look like? It's a bunch of 32-byte records, and each record represents either what we'd consider to be a DOS directory entry (file or directory) or a long file name. It contains all of the information you need about the file except for the long file name. The LFN is an add-on/hack that Microsoft came up with. LFNs came along in FAT 16 and backtracked into FAT 12 with what we call the vFAT. Entries in vFAT are identified with an invalid flag byte.

A normal directory entry contains the short name, file size, starting cluster, and temporal information (time/date stamps). When we're looking at that information it will be all collected together in the 32 byte directory. The only missing element is the long file name.

Each directory entry points to a starting cluster and to a place in the FAT where the cluster chain for the rest of the file is located.

What kind of non-numerical numbers do you find in the FAT? End-of-file (EOF) and bad block markers are common.

What marks the cluster as being available? A zero (0) in the cluster chain shows that the cluster is available for the OS to choose to save a new file.

File Deletion

When you delete a file, the short file name entry is marked with a 0xE5, and the cluster chain is zeroed out. The clusters themselves are not wiped on normal file deletion. That gives us a good chance to recover the files. All of the information needed to locate the file is still in the directory, but it is hidden to the user.

The only time you normally have problems is when a deleted file is fragmented.

The Boot Sector

The information about the file system, including cluster size, sector size, etc. is located in the boot sector.

Some Issues

File Slack: For a four-cluster sector and a very, very small file, it could have file slack in the following form:

Also, when you start to get up to 32k clusters, small files start to take up 32k when they only need a few hundred bytes. Over a whole disk you can have a lot of waste and inefficiency because of this.

NTFS

In NTFS, you'll still have a boot sector with cluster sizes and other fundamental information about the file system. Some of the stuff in the FAT model that's "fudged" gets pulled apart.

Windows 2000 put the Master File Table at the front of the drive, with a mirror file in the middle of the drive with only the first directory containing critical information.

The Bitmap is used to determine allocation/unallocation of clusters.

Deleting Files on NTFS

You go into the Master File Table, find the cluster markings, and unallocate them. The operating system maintains a pointer to the first available slot. The second that you decide to create a new directory or new file, that's the slot that will be assigned. Stuff that has entries high up in the table, that record will be written over very quickly.

The Master File Table

The idea behind the Master File Table (it started out as 32 entries and then jumped to 64 and on up as long as it's full and needs more space) is that the system reserves a chunk of space in which the master file table lives and it won't likely outgrow the reserved space. All directories are non-resident and may be fragmented.

NTFS uses a first-available allocation strategy, and deletions before where the first-available pointer is will change the first-available pointer to point to the deleted file's space on the drive.

Linux, Unix File Systems

Linux defaults to EXT3, but it also uses EXT2 and RIZR? Linux will mount NTFS volumes read-only. The kernels are not yet stable in terms of writing to NTFS (there are some beta programs out there that do it but they can hose the system if they screw up).

EXT3 is a journaling file system, where EXT2 does not do journaling. Journaling keeps track of the major steps taken during the last sessions with a file. That way if the system crashes, you can boot back up to the last known good configuration and recover to the point of the crash. The EXT2 and 3 file systems are based on UFS (Unix File System). UFS is much more complicated than EXT2 and 3. UFS gets to be archaic because it was designed for smaller systems.

UFS is designed to be both fast and reliable, and to be very efficient with small files. Home systems tend to have a lot of small files (~10-12 clusters).

Important Data Structures

Copies of them are stored throughout the system. Just like the MFT is mirrored in the middle of the drive on NTFS, important data structures are copied and scattered throughout the system. The whole files are mirrored, too — not just the first little part of them.

The boot record in Linux is called a Superblock. Linux divides the drive up into block groups and you'll frequently find a copy of the Superblock at the beginning of these block groups. Linux installations use sparse by default, which only puts the copies at the beginning of selected block groups.

On EXT3 drives, changes made to Superblocks are recorded in the journal (so you may find 150 Superblocks in the journal!).

The idea that we're trying to move away from is the amount of drive head movement there is. That's because the information associated with a file isn't stored near the file. You have to go through the global data structure (in NTFS, it's the MFT). In Linux, there is a chunk of information for each block group. It keeps the information in the files local so that head movement is minimized.

Linux also distributes information fairly evenly across the drive (it doesn't use a first-come-first-serve file allocation method).

Partitions still exist in Linux, but now when we have a partition we may lay a file system down on it. That file system will likely be EXT2 or EXT3.

Files may be actual files or hard links, and it's impossible to tell which is which (i.e. two files may point to the same data). There is a counter that keeps track of the number of files that point to a certain piece of data. You will only know whether more than one file points to data by looking into the Inode information.

There are three categories of optional features these file systems may have:

• Compatible Features — existence of a journal. You can mount an EXT3 as an EXT2 (just ignore the journal). A compatible feature will say "this is a feature I can ignore if I have to, but I can still mount and access the files on this system."
• Incompatible Features — e.g. Compression. You might not be able to mount it if you do not understand the compression. These features will disallow the File System from being moutned.
• Read-Only compatible — Under these circumstances you can mount a system read-only but you can't write to it. The type of thing you would find here is large file support. Certain kinds of large file support is read-only compatible (read and understand but not write). Directory structures are not required to be sorted. If you were to mount one that had sorted directories and you tried to write but you didn't know how to use sorted directories, you would mess up some stuff!

Superblocks

The first data structure we should be concered with is the Superblock (analogous to the Boot Record). It is located 1024 bytes from the beginning of the drive. Unlike the boot record, there is no boot code in the Superblock. In the 1024 bytes before the Superblock contains the boot code. Its contents are basic size and configuration information. You'll find copies of it at the beginning of many (if not all) of the block groups.

The Superblock has a signature, which you can search for and find candidate 1024 byte blocks in case the first one got corrupted. Copies of the Superblock arent' all updated at the same time. On top of that, they contain information about which block group they're in so they won't have the same hash value. You must find them by signature and location.

What do we need to know about a block if it's a collection of sectors? How many sectors are in there?? In a 1.44 floppy, there's one sector per cluster and in a 720k floppy there are 2. So it affects your computation there just as it does here. The typical block sizes that you'll find are 1024, 24GB, 4096.

• The total number of blocks in the whole file system…
• the number of blocks per block group…
• the number of reserved blocks preceding the first block group…
• the total number of inodes in the system…
• number of inodes per block group…
• and number of sectors per block are all located in the Superblock.

There is more information in the Superblock, but these are the most important pieces of data for now.

0xEF53 is in bytes 56 and 57. This is on page 405 in the white text book.

The block bitmap manages just the blocks in the Block Group. The Inode Bitmap manages the allocation status of the inodes in the table. The group descriptor contains information describes the group just like the superblock describes the drive (how many free blocks are in the group, how many inodes are free, where the block and inode bitmaps start, etc). If you delete a file in a busy block and it doesn't free up enough information to make the block less than average on the busy scale, that block won't be overwritten for a long time (with some exceptions, of course).

Inodes

The first issue about inodes is one you'd probably expect: they're all the same size. The size is be defined in the superblock. One inode will be allocated to each file and/or directory. Everything has at least one primary inode. Each inode has a number. No two inodes will have the same number as another (they're numbered sequentially down the drive).

In the first group, inodes 1-10 are reserved. The first non-reserved inode will typically point to the superblock. #2 out of the reserved inodes points to the root directory. Inode #1 keeps track of bad blocks. This used to be an interesting place to hide stuff because imaging tools ignored the bad inode group. Bad guys can make inodes in the bad inode block point to good blocks and the tools didn't pick up on this. Now, tools check to see if bad blocks are really bad. If you're on EXT3, inode #8 points to the journal. It's easy to ignore #8 if you want to.

Each inode is the same size and also has the same break-down (fields). It is possible for extended attributes to be set, and if that's the case they'll be stored outside the inode. There will have to be a flag set to show that there are extended attributes. Inside the inode you'll find:

• File size
• Ownership indicator (like GUID number) *Can find the owner in the password file… See Password Data, below.
• Temporal information like MAC (Modify, Access, Change — NOT create!) times and deletion time. *See Time Data below.
• Mode field — typically contains stuff like the file type or link type, if applicable
• Basic permissions — in typical *nix systems, users are members of groups. You can set Read, Write, Execute access for a particular User, Group, and All Users. There are user and group owners, which may have different permissions.
• Link Count — the number of directory entries identifying this inode as the head node for a file. Only hard links affect the link count.

Password Data

The password information is in /etc/passwd. Ownership in an inode doesn't necessarily reflect the fact that the user created the file or even knows it's there because there's a change ownership function you can use to change the ownership of a file.

You may go to the passwd file and there's nothing there. The ID number may not have a user associated with it. Somebody probably went to the web and pulled down a tarball and opened it and the files had ownership associated with them for users on another system.

Time Data

Access (A) time indicates the time the file was last accessed. Last Modify (M) time is the last time the file content was modified. Last Changed (C) time is the last time the metadata was changed. There's also a deletion time.

Notice that there are no file names in the inodes. One of the reasons is that file names may be allowed to be dynamic linked and there's no room in the inodes for dynamic links. You can't go outside the inode like you can with a non-resident entry in an MFT record. You won't see dynamic things in the inode.

Directory entries are located close to their data. Hopefully, if a directory is in a group, the files will be in the group as well.

Inode Types

In addition to the above, "primary" or "direct" Inodes have 12 direct pointers to content blocks. They will have 1 indirect pointer, 1 double indirect pointer, and 1 triple indirect pointer.

Indirect pointers are pointing to 12 other inodes. A double indirect points to an inode that points to 12 other inodes. By the time you get out to the triple (which points to 12 doubles), you have 12⁴ blocks being pointed to.

A fairly simplistic and incomplete version of this:

Files are typically grouped in the same group with a parent directory. This prevents having to move the read head a lot. If it is a new directory, you use that "search for a less used group" function and the file/directory is put there.

With the move command, the data doesn't actually move. The old directory entry is killed and a new one is created.

File Deletion under EXT2/3

When you delete a file, the inode status is set to zero. If a process has a hold of the file, it doesn't unallocate the inode. It breaks the link between the directory entry and the inode. Now you have a file without a parent (an orphan). There's an inode orphan list in the Superblock. When you reboot the computer, the orphans will be unallocated. If you catch it before the reboot, nothing's gone.

There's a difference between EXT2 and EXT3 in terms of unallocating an inode. In EXT3, the file size is set to 0 and the data pointers are wiped. If you recover the inode, you'll have a heck of a time finding the content blocks because the pointers are wiped. EXT2 doesn't wipe the pointers or the file size (similar to FAT).

M, C, and D time are updated to reflect the time of deletion. If the deletion is due to a Move, the A time will be updated as well. If you move a file to another volume, the M time is changed to reflect that.

Directory Entries

Regular Expressions, Recycle Bins

Regular Expressions

Regular expressions are useful in locating patterned data on a drive (not exactly a keyword search, but more like looking for credit card numbers or social security numbers based on a pattern.

Each tool has its own notation. AccessData uses a search engine called DT Search and enCase has a different search with a different set of conventions. AccessData wants a \d for a decimal digit, while enCase wants a pound (#) sign. Square brackets can be used in any regular expression to put items in a set.

FTK Regular Expressions

.                matches anything
\w               matches words (string)
\d               matches decimal digits
\x               represents a HEX character
\s               matches space or tab characters
\l or \u         matches lowercase or uppercase

Some additional Unix regular expressions are listed here.

Group expressions together by putting them in parentheses. The pattern of four digits \d\d\d\d and a pattern of a '-' or ' ' can be combined within '( and )'

((\d\d\d\d)[\- ])

The above will return patterns of four digits followed by a hyphen or a space.

((\d\d\d\d)[\- ]){3}

The above will return matches that occur three times.

((\d\d\d\d)[\- ]){3,5}

Will return patterns matching between three and five repetitions of a pattern.

Note that the hyphen OR space match is there because at the end of a credit card number there isn't an extra hyphen (there is a space instead). There can be false positives with this… You build expressions in such a way that you will get some false positives, but if you get too precise the regular expressions get too long and too difficult to decipher.

\<       Start after non-word character
\>       End after a non-word character
?        Match 1 or 0 preceding instances
|        This | That

Some Examples

Seven digit phone number:

\d\d\d\-\d\d\d\d

A better way to do a seven-digit phone number:

(\d){3}\-(\d){4}

Phone number with international dialing option:

/(^(\+?\-? *[0-9]+)([,0-9 ]*)([0-9 ])*$)|(^ *$)/

Credit Card:

/^((4\d{3})|(5[1-5]\d{2})|(6011))-?\d ...
... {4}-?\d{4}-?\d{4}|3[4,7]\d{13}$/

FTK stores the regular expressions in a text file. So the live search tab gets its regular expressions list from a text file that you can edit with Notepad.

The Recycle Bin

Functionality is straightforward. It was developed as a way to throw things away without really losing them because they didn't really mean to throw it away.

Similar to regular file deletion, the OS makes the file invisible to the original directory but it won't zero out the cluster chain. It adds a directory entry to the Recycle Bin directory and renames the file. If you delete John.jpg, you'll now have a df000010.jpg in the trash can that is associated with the name John.jpg and the path f:/My Pictures/Yadda/Yadda/John.jpg.

From a forensics perspective, it is obvious that stuff gets into the trash can because the user put it there. On Windows Me/9x machines, the trash can is a community dump. All accounts on a machine share a single trash can. This is a big security problem because you can have something you don't want someone else to see and in the community trash can anybody with an account on the machine can get to it.

On later Windows boxes, you can tell which trash can is whose by looking in the SAM file.

INFO2 Structure

• "Deleted" file path
• "Deleted" file index number
• "Deleted" file drive location
• "Deleted" file date and time
• "Deleted" file physical size

The recycle bin tracks only user deleted files. It does not track stuff that the OS deletes, such as temporary Internet files and deleting things with a shift-click.

The trash can doesn't hold stuff deleted from removable media or networks. The time stamps will be "machine active time bias" relative.

FAT vs. NTFS Recycle Bins

FAT: 280 byte INFO2 records and all users on the machine can access files
NTFS: 800 byte INFO2 records and the bin is user-specific based on SID.

The recycle bin has its own Master File Table record for deleted files. FTK is able to show that a file has been removed from the bin and all of the INFO2 data for removed files.

When an item is removed from the file, it's not possible to tell whether it was deleted from the bin or moved back out of the bin. Both actions have the same result as far as the Recycle Bin is concerned.

The date an item is moved into the recycle bin is a potentially powerful piece of evidence, and that informaiton is stored in the INFO2 data in the trash can.

E-Mail

The Beginnings… We started with ARPAnet, a precursor to the Internet. It was a DoD project but it was not related to the military. It was to allow researchers to communicate more effectively. It was to facilitate research wings of the federal government communicating with major research institutions. Implementation began in the late 1960s and it was difficult to set up the infrastructure to allow computers to communicate with one another.

E-mail began in 1971 through the work of Ray Tomlinson, who wrote a SNDMSG protocol that would allow someone to leave messages for another person on the same comoputer. It was essentially appending messages to a text file.

The first e-mail was sent betwen two computers that were in the same word. The messages was "QWERTYUIOP". E-mails are just pieces of text, but obviously with attachments they are much larger text messages (any file that is non-textual is converted to text and is translated from that text on the other end). Remember that text characters are seven bits of an eight bit byte (the eighth bit cannot be trusted because of certain e-mail servers which change it to a zero because of a parity check).

E-Mail Clients are used to read e-mail (e.g. Eudora, Outlook, Pegasus). Each does four things: Display headers, select a message to read, create new messages, add attachments. Malboxes are usually on the local machine, but they may also be on the server.

Webmail (e.g. Hotmail, gmail, Earthlink) is when the e-mail appears on a web browser instead of in an e-mail client. Mailboxes are usually on the server. HTML artifacts may be recoverable on the local box (e.g. Hotmail header pages).

A simple e-mail server will have a list of accounts identified by user and a text file for each user. A user composes a message and hits "send". Jim's e-mail client connects to the server. The server will format the message with from, to, subject, time stamps, and message body. The server then appends the formatted message to the recipient's text file. The recipient uses his own e-mail client, logs onto the server, the client requests a copy of the text file, the copy is saved on the local machine, and the server (optionally) resets the text file to empty.

Sending Mail

When you send an email message, your email program connects to your Internet service provider's mail server. This is typically a Simple Mail Transfer Protocol (SMTP) server, the type of server responsible for sending email.

Your message might be broken into smaller pieces, or packets, before it begins its journey. These smaller packets can travel more quickly from server to server and are reassembled when they reach their destination.

Sorting the Mail

In the same way that postal mail is sorted first by ZIP code, email messages are sorted by domain. For the email address feedback@allbusiness.com, for example, the domain is the "allbusiness" portion. The domain identifies where the message needs to go.

Each domain name maps to a unique Web address, called an Internet protocol (IP) address, which is a string of numbers that servers use to route messages. These relationships are stored in the Domain Name Registry. When the SMTP server receives a message, it looks at the domain and checks the registry to determine what IP address to send the message to. Once it determines the proper server, the SMTP server sends the email message on its way.

Delivering the Mail

Depending on where the destination server is, the original SMTP server may not actually make the final handoff; it may pass the message to another server. That server identifies the domain and passes the message to another server. This process is repeated, the message getting closer and closer to its destination, until the correct server is reached.

The server that receives mail is generally a post office protocol (POP) server. ISPs set up user mailboxes on POP servers. Usernames are like post office box numbers, and passwords act as keys that open the correct box. Once a message reaches the appropriate domain server, it is channeled into the right POP account and stored until the user logs in and checks for mail. In other words, this is how the feedback@allbusiness.com address is differentiated from the service@allbusiness.com address.

When the recipient tells their email program to check for new mail, the email program connects to the ISP's POP server, looks in the user's mailbox and retrieves any mail that's waiting. The message's journey is complete — and all this might have happened in a matter of seconds.

The SMTP Server

The POP3 Server

In the simplest implementations of POP3, the server really does maintain a collection of text files -- one for each e-mail account. When a message arrives, the POP3 server simply appends it to the bottom of the recipient's file!
When you check your e-mail, your e-mail client connects to the POP3 server using port 110. The POP3 server requires an account name and a password. Once you have logged in, the POP3 server opens your text file and allows you to access it. Like the SMTP server, the POP3 server understands a very simple set of text commands. Here are the most common commands:

• USER - enter your user ID
• PASS - enter your password
• QUIT - quit the POP3 server
• LIST - list the messages and their size
• RETR - retrieve a message, pass it a message number
• DELE - delete a message, pass it a message number
• TOP - show the top x lines of a message, pass it a message number and the number of lines

Your e-mail client connects to the POP3 server and issues a series of commands to bring copies of your e-mail messages to your local machine. Generally, it will then delete the messages from the server (unless you've told the e-mail client not to).

Oh come on, seriously… Just go to How Stuff Works because that's where he got all the stuff for his slides anyway!

Alternate Data Streams, Encrypted File Systems, etc.

Data Run

Omnixray: Data Run Example for NTFS file system. (Read more here).

Alternate Data Streams

Creating an Alternate Data Stream by merging two programs together. The following takes to programs in directory g:\three\ and merges them into one.

C> g:\three\notepad.exe>g:\three\calc.exe:notepad.exe
G:\three> start calc.exe

If you run calc.exe, it looks and acts normally (including its appearance in the task manager and process list). If you run notepad.exe with

G:\three> notepad.exe

in Windows 2000, you'll only see calc.exe in the process/applications lists. This allows users to hide executables. In Windows XP, it shows up as Untitled.exe. This is dangerous because viruses can run undetected, etc. Most versions of Norton don't look for this type of hole.

Calc.exe had the following attributes:

Size: 91408
Created: Oct 28 2005
Modified: Dec 7, 1999
Accessed: Nov 8, 2005

Remember that we now have something named calc.exe:notepad.exe. Nothing with that name shows up in the Master File Table, but there are two instances of calc.exe. One of them has two data streams now. This one has a modified date of Nov 8 now, but the filename attribute has not changed. Not sure about the other calc.exe; it's size zero (possibly from a syntax error). As far as properties are concerned, there is no record of the connection between the two programs. Free space on the drive has been reduced by 51kb, but the file size of calc.exe has not changed.

In a master file table, the table starts at a certain size. When there are enough files to cause the table to grow, it grows at the bottom. When files are deleted, new files can write over them before more is added to the bottom. So, items at the bottom of the MFT may "hang around" for a long time after they are deleted.

The Sequence Number is basically the number of times that a particular MFT slot has been used.

Windows 2000 looking at an NTFS volume will not build a thumbs.db file; instead it adds the thumbnails as alternate data streams to the existing pictures.

Encrypted File System

When you do encryption, you pipe an original file and a key into a process and the process outputs an encrypted file. For effective encryption, it's usually an intricate process, but it could be something as simple as a bit mask. You then need the key (and process) on the other side to get the original file back. That's called a symmetric encryption algorithm.

1001 ← file
1101 ← key
----
1011 ← output

1011 ← encrypted file
1101 ← key
----
1001 ← original file

In another method (asymmetric) you may use two different algorithms and two different keys. Asymmetric algorithms are much harder to crack, but also much slower to execute. PGP is assymetric. You have two keys — one public and one private. Someone sends a message that is "for your eyes only". They encrypt it with your public key and only your private key can unlock it. The sender also has two keys — public and private — and she encrypts it with her private key and your public key. In this case, Cathy's public key can decrypt the message so you know it came from her.

On the Encrypted File System, data is encrypted with the File Encryption Key. Each encrypt occurrence generates new FEK (with a symmetric key, which is fast for large volumes of data). FEK is encrypted with the user's Public Key. Each encrypted file contains a $EFS stream (record attribute in NTFS — logged utility stream). In the $EFS attribute is the encrypted FEK. If there is an invoked recovery agent (another account somewhere) then it also encrypts the FEK with the recovery agent's public key. So, the FEK stream will contain two encryptions of the FEK (one by your public key and one by the recovery agent's key). Whoever knows the right private key can get the file back.

If you can get the master key, you can decode the private key, you can decode the FEK and then you can decode the file. On the other hand, if you logon as the recovery agent, that allows you to generate the correct master agent for the recovery agent's private key which also allows you to get to the data.

At the end of the day, if you've got the drive, all you need is the logon (and some time and patience) to get at the files.

With Windows 2000, there is always a recovery agent, which may be a local administrator or a network administrator. You crack the SAM file like we did last class. The recovery agent is optional in Windows XP Pro. Both will support multiple recovery agents.

If you can't break the SAM file (and you have lots of time), you can let FTK do a dictionary and then brute force attack to figure out the password. You can do a distributed network attack (costs extra) that will crack passwords incredibly fast.

You can't encrypt system files! They are needed at boot time. Anything under system root won't be touched, and thumbs.db files will not be encrypted either.

Practical 2 and An Investigation with FTK

Practical 2

On October 19, Mr. Squeak E. Wheel copied a folder from a desktop to the laptop computer of a known pimp in the Orlando area. On October 20, Mr. E. Wheel gave the diskette to his handler. On October 21st, the diskette was examined by the handler, Sgt. James Lee to see if there was any valuable information. He printed one document and nine pictures. The document contained nine street names associated with nine real names. The nine pictures were named the street names, respectively. All of these people appeared to be underage. However, none of them can be located to verify their ages. After printing the document/pictures, the diskette was entered into evidence.

Mr. E. Wheel believes that the Orlando pimp is involved in a child sex ring. You may use getflop, putflop, Microsoft Word, DiskEdit, and FTK for one file (thumbs.db). There are some problems with the diskette.

A hole on the floppy was taped with a piece of duct tape. The write-protect tab is in the unlocked position. So you have two pieces of physical evidence to note: a piece of duct tape over the hole and the disk in write-enabled position.

The disk image will be in a Zip file on WebCT with a copy of the Practical Two scenario.

New! Official Practical 2 Scenario

The following is quoted from the assignment document, in case you can't find it:

On Oct 19, 2005, Squeak Ewheel copied a folder to floppy from Desktop of a laptop computer that was in the possession of James Leonard Frence, a known pimp in the Orlando area.

On Oct 20, 2005, Squeak Ewheel gave the diskette to his handler, Sgt. James Lee.

On Oct 21, 2005, the diskette was examined by Sgt. James Lee to determine if it contained any information of value to him. He made a directory listing, printed one document file and 9 pictures. The printed document named 9 people via street name and real name. The pictures were labeled with the street names of the people listed, all of whom appeared to be underage. None of these people can be located at this time to actually verify their ages. At least one must be verified as actually underage in order to get a warrant for the laptop computer.

The diskette was placed in the evidence locker by Sgt. Lee on Oct 21 after his preliminary exam and he went home for his daughter's 16th birthday party.

Sgt. Lee is the only person, other than Squeak Ewheel, in the chain of custody for this diskette.

Mr. Ewheel claims that James Leonard Frence and his significant other Miranda Ducky are heavily involved in a child sex ring. Sgt. Lee believes that the information on the diskette may provide valuable leads in the case. Sgt. Lee is only basically computer literate and is not certified to perform a complete computer forensic exam.

Needed: any additional information you can shed on this investigation.

You may use putflop, getflop, md5, diskedit, Microsoft word, metadataassistant, a jpg viewer, and you may use FTK, but only to view the thumbs.db file.

A Scenario, Just for Class

Note: This scenario was used for an IACIS re-certification and may contain copyrighted material.

Background

June 9 — Bobbi Phillips was found beaten to death. His DOB is 9/25/1983. The first officer on the scene arrived at 8:50am after a 911 call was placed from the residence by a roommate. The roommate, Gill Davis, was born on 4/2/1980. There were four boys living together in a house; the other two roommates are Lowell Mackavoy (1/21/1985) and William Johansen (11/11/1984). All four were college friends and roommates. They were scheduled to take a trip on 6/7/2005 and return on 6/9/2005. Bobbi Phillips decided to remain home because of work. He worked nights on a production line. He was last seen alive on the morning of 6/7/2005 by the other three roommates (before they left) as well as by a UPS driver who delivered a package and had it signed by Mr. Phillips. The driver also remembers seeing the other three boys driving away. The computer in the house was shared by all four boys but Mr. Phillips used it the most (for chatting online). His password was 'secret' and his login was 'Dr Doolittle'.

The Scene

The body was on the floor in the living room next to a computer desk and the computer case was heavily spattered with blood. The computer was on when the officer arrived. The digital clocks in the house were blinking 12:00. Note: a storm passed through the morning before and may have knocked out power the night before. The roommates noticed several items missing from the house.

Information from Officer

After the body was removed, the officer proceeded to examine the computer system. He noted MS Windows® was running, chat software was running, and messages were being received. It was also noted that the time showing in the lower right-hand corner of the screen was accurate according to the time on his cell phone. He was later directed to stop the examination and send the computer for forensic investigation. Not having the necessary equipment or experience, a local technician was called in to make a copy of the drive.

The computer was turned off at 9:30am. The cover from the system was removed and it was noted that there was one 80GB hard drive attached. A brand new (NTFS) 120GB drive was connected to the system as a secondary master and the computer was rebooted with a boot disk. The following command was issued:

A: ghost.exe

The ghost file was created with compression at 9:35am and the ghost image files were burned to a DVD for analysis.

Suspects

Two male suspects were found with the stolen merchandise. They claimed to have purchased the items from an unknown individual.

Purpose of Investigation

The forensic technician is called in to try to determine the time of death. The defense has obtained a copy of the DVD and is raising the question: If the ghost file was created at 9:35am, why doesn't it say 9:35 on the DVD?

We are able to assume that we have all of the necessary warrants, etc. needed to conduct this investigation. We have to pin down the time of death and what's going on with the DVD.

What's Going On With The DVD?

Time

DOS gets its time from the CMOS clock. We need to know if the Windows® clock is in agreement with the CMOS clock. DOS doesn't care about time zone. We know that the time was correct in Illinois at 9:30am but we need to know whether the CMOS clock was set to the SAMe time zone or if Windows® was correcting it.

Check it by reading the Windows time on a similar machine (with the correct Windows® version), rebooting with the DOS boot disk, and seeing what time it says. Or we can reboot it into CMOS and see what it says there.

File System

DOS doesn't see NTFS drives. You need to see if ghost can even write to an NTFS drive. You may need to check with the technician to see what version of ghost he was running to see if what was documented is actually possible. It turns out that it will allow you to write an image to an NTFS volume. Remember that NTFS drives use GMT, not Local time! The GMT gets adjusted for and displayed according to time zone settings.

DOS Time Zone Adjustment

There is a variable TZ in DOS which stands for Time Zone and it is set to +6. Ghost assumes that the computer is in the Central Time Zone and it doesn't care whether it's on Daylight Savings Time. So the clock could be an hour off. This accounts for an hour discrepancy, but there is a two hour discrepancy so where did the extra hour come from?

There was an adjustment made for daylight savings time when the disk was made and Ghost didn't make an adjustment for daylight savings time. It was 9:30 and there should have been a 5 hour adjustment. There was a 6 hour adjustment made and when an OS (with the capability for DST adjustment) interprets a disk, it automatically adjusts for Daylight Savings Time, which may add another hour to the discrepancy.

The Image

None of our forensic software reads a ghost image, so we need to use a version of Ghost to blow the image down to a new disk and image it to create a set of files we can work with.

Time of Death Investigation

We should create a new case with FTK. There is an NTFS volume on it so we know it's not a Windows® 9x/Me box.

Anomalies

There is the question of how the computer was running when the power failed. Computers can be set to reboot upon a power failure, but is it rebooted into a password-protected profile? Windows® can automatically login to a password protected account so we'd want to know if it requires a password at log-on. The victim may have been alive when the power failed or all of these things may have been settings on the computer.

On Windows® 9x/Me boxes there are two primary data files: System.dat and User.dat. These contain the basic information on system shutdown and startup. This box is running Windows 2000 or later so there will be SAM, System, Software, and Security registry files. For each user, there will be an NTUser.dat file. We need to look at two right now to find the Syskey number (in the System file) in order to extract the encrypted passwords from the SAM file, which stores the user account information. Log-on passwords are encrypted in the SAM file. If you can extract the syskey from the System file, you can use it to crack the SAM file. In Explore view (in FTK), go to WINDOWS → System32 → Config. Config will house the SAM and System files. Export those two files out.

Password Recovery

Run Password Recovery Toolkit. Within PRT, there is an Add Syskey(s) option under the Tools menu. Browse and find the System file. It will extract the Syskey from the System file automatically. You can also import the word list (exported from FTK), and setting up Biographical Information specific to the case will also help (can include DOB, pets' names, etc.). Drag and drop the SAM file into the Password Recovery window and wait for a response. The system password is determined to be 'secret', and the administrator password is the same as that of the Dr Doolittle account.

Additional Registry Information

Using AccessData Registry Viewer, you can find Mounted Devices in the System file to see what external and internal hardware was associated with the machine. In the software system file, you find the profiles list. The one ending in 500 is the Admin account. The others are associated with individual users, of which there are four. It's imperative to figure out what folder belongs to what account. The following is recovered:

...1003 — Pluto
...1004 — Axel
...1005 — BillyRay
...1006 — Mr. Robinson
...500  — Administrator

We are interested in Mr. Robinson because it was under this account that data was last written. We determine that Mr. Robinson is Dr. Doolittle, our victim.

Using Registry Viewer, we can also find out the Time Zone in the active system file, which in this case was set to Pacific Standard Time. The ActiveTimeBias will indicate whether Daylight Savings Time was used and what offset was applied to the system clock. We set our time/date to view the data the same way the user of the computer saw them. We have to set our computer to Pacific in order to see what was really Central time.

I'm tired of taking notes at this point, but you get the gist. Take a look at the mIRC chat logs and you should be able to tell when the outgoing messages stopped and possibly what their content was. Verify the veracity of the time/date stamps on the chat logs and you have yourself an approximate time of death.

System Files

Link: The FAT Filesystem: FAT

OmniXray

The following information references OmniXray, a disk editor utility that is a good replacement for DiskEdit for NTFS volumes. The screenshots came from the OmniXray website (click each to enlarge).

The first screen gives information from the boot sector such as bytes per sector, number of clusters, sectors per cluster, serial number, etc.

You can view sectors in hex view kind of like in DiskEdit. It does not, however, allow you to look at a single byte.

Study page 380 to learn the important offsets. At offset 48 you'll find the starting cluster address of the master file record. At offset 56, you get the starting cluster of the mirror of the master file table. The master file table is the most important component in the NTFS file system. The mirror is typically in the middle of the drive.

Everything Is A File

System Files have names beginning with $:

• $MFT, $MFTMirr
• $LogFile, $Volume
• $AttrDef
• . (dot — contains root directory)
• $Bitmap (indicates whether a cluster is available with a 1 or a 0), $Boot, $BadClus
• $Secure, $Upcase, $Extend

The above are the first 12 entries in the Master File Table. Microsoft reserves the first 16 entries.

Partition Layout

© Microsoft

• Boot sector
• MFT Zone
  • Approximately 12.5% of available space
  • Prevents MFT from fragmenting

$MFT File

• This file is the heart of NTFS
• Every file and directory has at least one associated MFT entry
• There is even an entry for $MFT since it is a file — entry 0
• Entries are uniform in size, usually 1024 bytes

Reserved MFT Slots

Microsoft reserves the first 16 entries for system files but only uses 12 at this time. Refer to the bottom of this page for more information.

Entry  File      Entry  File
 0     $MFT       1     $MFTMirr
 2     $LogFile   3     $Volume
 4     $AttrDef   5     . (dot)
 6     $Bitmap    7     $Boot
 8     $BadClus   9     $Secure
 10    $Upcase    11    $Extend

$MFTMirr

• Stored near the middle of the partition
• Contains a backup of at least the first four entries of the MFT

MFT Records

• Size stored in $Boot but usually 1024 bytes
• First 42 bytes contain 12 fields
• 0-11: signature, usually FILE or BAAD
• Flag: indicates if entry is being used, or a directory
• Remaining 982 bytes are unstructured but divided into "attributes"

$LogFile

• This is a journal that records metadata transactions
• Improves reliability of the file system
• Contains two major areas: the restart area and the logging area
• Idea is to write down what you are going to do before doing it

The . (dot) file

This contains the root directory. It's the only system file that does not start with a $.

$Bitmap

Keeps track of the allocation status of each cluster. This is separate from the cluster chaining which was combined with the FAT model.

$BOOT file

First sector of the partition. Sometimes referred to as the boot record (not the MBR that holds the partition table). Holds fundamental file system information starting with the signature. Contains size of MFT entries and Index entries, sector and cluster size, partition size, drive serial number. Backup copy exists usually in the final sector (after the end of the data area) of the volume.

MFT Entry Attribute Concepts

Most file systems exist to read and write file content. NTFS exists to read and write attributes, one of which happens to contain file content. Each type attribute contains a different type of data. Each attribute has a header and content.

MFT Entry Layout

Header is generic and standard to all attributes. Identifies the type of attribute (number), size of attribute, name of attribute (UTF-16), Flags (compressed, encrypted, resident, non-resident, etc.) Content is specific to the attribute and can be any size, can be resident or non-resident.

Resident Data

Stored in the MFT entry.

Non-Resident Data

Stored in cluster runs as it is in FAT. The run is documented in the MFT entry with a starting address and the run length (contiguous). Fragmented files have multiple runs.

A run list may have fragmented pieces of files out of order, not along a best-fit model. Typically it jumps forward, though. It might move backward if it hits the end of a drive.

Some Attribute Types

16 or 0x10 - $STANDARD_INFORMATION

• Flags
  
• MAC times
  
• Owner and Security ID

There is a complete list of attributes in the text book.

BIOS parameter block (BPB) and Extended BPB fields

From Microsoft.com: How NTFS Works

The table BPB and Extended BPB Fields on NTFS Volumes describes the fields in the BPB and the extended BPB on NTFS volumes. The fields starting at 0x0B, 0x0D, 0x15, 0x18, 0x1A, and 0x1C match those on FAT16 and FAT32 volumes. The sample values correspond to the data in this example.

BPB and Extended BPB Fields on NTFS Volumes

Byte Offset	Field Length	Sample Value	Field Name and Definition
0x0B	2 bytes	00 02	Bytes Per Sector. The size of a hardware sector. For most disks used in the United States, the value of this field is 512.
0x0D	1 byte	08	Sectors Per Cluster.The number of sectors in a cluster.
0x0E	2 bytes	00 00	Reserved Sectors. Always 0 because NTFS places the boot sector at the beginning of the partition. If the value is not 0, NTFS fails to mount the volume.
0x10	3 bytes	00 00 00	Value must be 0 or NTFS fails to mount the volume.
0x13	2 bytes	00 00	Value must be 0 or NTFS fails to mount the volume.
0x15	1 byte	F8	Media Descriptor. Provides information about the media being used. A value of F8 indicates a hard disk and F0 indicates a high-density 3.5-inch floppy disk. Media descriptor entries are a legacy of MS-DOS FAT16 disks and are not used in Windows Server 2003.
0x16	2 bytes	00 00	Value must be 0 or NTFS fails to mount the volume.
0x18	2 bytes	3F 00	Not used or checked by NTFS.
0x1A	2 bytes	FF 00	Not used or checked by NTFS.
0x1C	4 bytes	3F 00 00 00	Not used or checked by NTFS.
0x20	4 bytes	00 00 00 00	The value must be 0 or NTFS fails to mount the volume.
0x24	4 bytes	80 00 80 00	Not used or checked by NTFS.
0x28	8 bytes	1C 91 11 01 00 00 00 00	Total Sectors. The total number of sectors on the hard disk.
0x30	8 bytes	00 00 04 00 00 00 00 00	Logical Cluster Number for the File $MFT. Identifies the location of the MFT by using its logical cluster number.
0x38	8 bytes	11 19 11 00 00 00 00 00	Logical Cluster Number for the File $MFTMirr. Identifies the location of the mirrored copy of the MFT by using its logical cluster number.
0x40	1 byte	F6	Clusters Per MFT Record. The size of each record. NTFS creates a file record for each file and a folder record for each folder that is created on an NTFS volume. Files and folders smaller than this size are contained within the MFT. If this number is positive (up to 7F), then it represents clusters per MFT record. If the number is negative (80 to FF), then the size of the file record is 2 raised to the absolute value of this number.
0x41	3 bytes	00 00 00	Not used by NTFS.
0x44	1 byte	01	Clusters Per Index Buffer. The size of each index buffer, which is used to allocate space for directories. If this number is positive (up to 7F), then it represents clusters per MFT record. If the number is negative (80 to FF), then the size of the file record is 2 raised to the absolute value of this number.
0x45	3 bytes	00 00 00	Not used by NTFS.
0x48	8 bytes	3A B2 7B 82 CD 7B 82 14	Volume Serial Number. The volume’s serial number.
0x50	4 bytes	00 00 00 00	Not used by NTFS.

FTK Modules

Time and Date Forensic Issues

• Where do we find them?
• What form are they in?
• What do they signify/
• How do we view them appropriately?
• What actions change them or don't change them?

After a boot-up, the hardware clock and the software clock may start to differ because the software clock "ticks" every time an interrupt occurs. Some computers are also synced off of an external source such as an atomic clock or the national time standard.

If you reset the clock on your computer, it won't change a time stamp downloaded from a server. A lot of Internet pages keep track of when the site was visited. Before the page is downloaded to your computer, there is frequently a time stamp added as a comment at the bottom of the page (invisible to the user).

You have to be very careful when you're looking at time and date stamps on CDs and DVDs. You may have the option to use the original time/date stamp, the time that the CD was burned, or set a particular time/date for yourself. It is possible to look at the header and find out when the CD was supposedly burned. If they're all identical, it's highly likely that they chose to use the time of burn or set their own time and date stamp.

Time and Date on the FAT file system

In the FAT File System, directory entries do contain some time and date information about the files. You will also always find the last modified time/date. Depending on the OS, you might find the create time/date and the last access date. Depending on the OS, you might also be able to extract a time and date stamp from a volume serial number. The month and day combination are converted to hex and the year is converted to hex and the two are added together. This is assuming that you are using an OS (Windows® 95, Windows® 98, Windows® Me) that follows this format.

You can tell whether a floppy disk was formatted by a particular OS by looking at the end of the boot sector. If it was formatted under the 9x/Me group you'll see a DOS 4.1 reference and if it was formatted XP/2000 you'd see an NT Loader reference there. You can't always rely on that being there because Windows® put the information there when it formatted the disk but it never used the information again. There may have been a session key or session ID written over it.

Last Modify Time/Date

• One time/date stamp included in the old DOS world
• May still encounter files that only have that stamp if any old DOS programs are still installed and usable on the system (e.g. old Word Perfect word processors)
• This stamp is unchanged by moving and/or copying a file to a new location, even across volume boundaries
• It is usually set by the application that is associated with the file type (i.e. when a word processor saves a document)

Usually an application that is smart enough to know whether you changed the file will be smart enough to update the time/date stamp. If it's smart enough to know that you did not update it, it may also be smart enough not to update the time/date stamp when you save it.

Testing the Last Modify Time/Date

• Was set when I first created a .doc file
• Was changed when I edited the file and did a save
• Was not changed when I opened the doc, made no changes and did a save
• Was not changed when I did a copy or move
• Was changed when I opened the document, made no changes and did a save-as under a new name
• Was not changed by a copy-paste on same volume

Create Time/Date

• Set by Windows® knowledgeable programs when they create files (save-as the first time) in a particular location
• Not changed by a drag-drop into another folder on the same volume since this is interpreted as a move
• Changed on the new copy when drag-drop across volume boundary since this is interpreted as a copy unless you just do a move, in which case it will carry the old time/date with it

After you do a save-as, the metadata will indicate that the new file is a copy but the create date will not change. So then you have two files on the same computer that appear to be created at the exact same time down to the millisecond.

Access Date

• Date only — no room for time
• Usually updated to current date when the file is accessed by Windows® knowledgeable programs
• Updated simply by checking the file properties

Thumb Files

Thumbs files appear in Windows® Me, 2000, XP, and 2003. The files are placed into thumbs.db, a hidden file. When files are deleted from the original location, the thumbs.db file is still there. You don't see that file unless you have taken the action to show hidden files. Windows® 2000 and 2003 can encrypt folders with ease. The thumbs file is not, however, encrypted. If you delete the thumbs.db file, you'll get an OS error that says the system may no longer work correctly and most people will leave the file there.

If Windows® 2000 looks at a FAT volume, it will build a thumbs.db file. If it looks at an NTFS file it does not build thumbs.db; instead it generates alternate data streams. The default for Windows® systems is to build the thumbs file, but in more recent versions, you can turn that feature off.

The thumbnails are always generated as JPEGs, however they store the filename with extension of the original graphic that they are associated with (it may be a bitmap, etc).

In Windows® Me and older, the thumbs.db file includes the drive letter, the path, and the file name (with a date stamp). Windows® XP and later include the filename without the path.

More prolific graphics use means Microsoft wanted optimal performance. Thumbnail viewing was born in Windows® Me. To accelerate thumbnail viewing in a folder, a mini database of graphic images is created called thumbs.db.

As long as someone leaves the folder open long enough, thumbs will be generated for all photos in a folder. That means that just because they are in the thumbs.db file doesn't mean someone saw the file.

Download What Format. You can drag files in and What Format will identify the file type by its internal information.

Other thumbnails that will appear are PowerPoint presentations (the first slide), the first page of an HTML document, etc.

Metadata

In FTK, metadata is stored in OLE Subitems. FTK parses the information in an HTML format so it is easy to includde in your report.

Link Files

You may be able to tell from link files (*.lnk or *.url) that there are additional drives or sources of information that are no longer attached to the computer or have otherwise been moved. Target Machine Addressing indicates that there is another computer on the network to which that computer is linked.

Spool files (*.spl) are temporary files that are created when you print a document. In Windows®, you print from Word® to the spool file, and Windows® will send the spool file EMF graphics to the printer and delete the spool file when the printer is done. The spool file has every page in the document as a little picture.

URL shortcuts will typically link to web pages while LNK files will link to local or network files. Recent documents (Start → Documents in Windows®) are all LNK files.

When you look at a LNK file in FTK or EnCase you will see a network path, file size, time and date stamps, and file attributes. You can also carve the graphics files from the spool files with these applications.

Time/Date and Forensic Tools

Time & Date Issues

When you get a time and date stamp that looks like:

05-06-05 06:04:09

you don't know what format it follows. It could be Day-Month-Year or Month-Day-Year or another combination.

Local Time depends on where you are. The world is divided me into time zones. US includes Eastern, Central, Mountain, Pacific, Alasa, Hawaii.

Local time also depends on where you care. May be subject to Daylight Savings. Start-stop may vary year to year at the whim of the politicians. In 1977 we stayed on daylight savings all year because of an energy crisis. Some states (Indiana, Arizona) do not participate in daylight savings time.

You may need to identify the time zone and make adjustments in your forensic software to correctly interpret the time and date stamps.

At best, time/date stamps make weak evidence because they are manipulated easily.

International Time is independent of where you are and does not use daylight savings time. International time is known as:

• UTC (Coordinated Universal Time)
• UT (Universal Time)
• GMT (Greenwich Mean Time)

Time Formats

Some sort of human-readable formats such as an ascii string format

• mmddyyyy hh:mm:ss label (UTC, EST, GMT)
• ddmmyyyy hh:mm:ss (European)
• Use am-pm or 24 military time?
• Use yy or yyyy for year?

What does 05-06-04 05:06:04 represent?

The reason COBOL used a 2-digit year was because they were written on punch cards and didn't want to waste two extra columns for the first two digits of a four-digit year.

Storing Time References

• Need to agree on a non-ambiguous format
• Computers usually store time as the number of seconds (or other unit of time) after some reference point in time, sometimes called an epoch
• Second, millisecond, microsecond precision
• Computers reference several epochs
  • Network: 1 Jan 1900 00:00:00 GMT
  • Unix: 1 Jan 1970 00:00:00 GMT (neg allowed)
  • DOS: 1 Jan 1980 00:00:00 Local Time (neg allowed)
  • Many Windows boxes are set to Redmond time

Why is time important?

• You may automatically replace older documents with newer ones.
• Browsers displaying outdated pages as if they were new (Browser cache management).
• Monitoring billing of clients

From a forensics perspective, we are typically investigating an event (who-what-when-where-how).

CMOS Clock is battery operated. It keeps track of time when the computer is off (depends on the OS installed). Critical issue:

• Store local time (DOS)
• Store UTC time (Unix)
• Dual boot system?

What about time zone information? DOS may use an environment variable in autoexec.bat. Set:

TZ=EST+5

or

TZ=CST+6

Other operating systems store something in their operating system knowledge base, if you will, that will inform them about the difference between the clock and either local time or UTC. Typically you will see a time down in the toolbar if you are running a GUI, and that may or may not be the time stored in the CMOS clock. Windows displays what's in the CMOS clock.

ISO 9660 (CD File System)

ISO 9660 is the most common file system for data CDs and many DVDs. The Joliet extension of ISO 9660 is for Windows and the Rock Ridge system is for Linux.

Files: Directory structure is almost like DOS

• The root directory has . and .. entries
• No limit to the size of the root directory
• Depth of directory nesting is limited to 8 levels (Joliet extension relieves this limitation)
• Permits longer file names but not if used on a DOS system
• Char set is cap letters, digits, and underscores
• ISO permits a file with an extensionbut not a name
• DOS permits a file with a name but no extension
• Directories on a CD-ROM are always sorted alphabetically by the name

If you use Nero to burn a CD, when you drag new files over to the burn folder you will see that it will automatically sort.

CDFS-2

Each sector contains 2048 bytes (optional but universal). The first 16 sectors (sectors 0-15) are empty (all 0 in the DOS world). Sector 16 starts the volume descriptor area. Two are common with DOS and each occupies one sector. The first volume descriptor is the primary.

Primary Volume Descriptor: In addition to other things, it contains a root directory record, an application identifier (Nero, EZ CD Creator, etc.), and date/time of volume creation.

Date/Time Fields

• 4 bytes — year as 4 ASCII digits
• 2 bytes — month as 2 ASCII digits 1-12
• 2 bytes — day as 2 ASCII digits 1-31
• 2 bytes — hour as 2 ASCII digits 0-23
• 2 bytes — minute as 2 ASCII digits 0-59
• 2 bytes — seconds as 2 ASCII digits 0-59
• 2 bytes — .00 seconds as 2 ASCII digits 0-99
• Offset from GMT

Directories

Each directory record represents a file or directory:

• Byte 1: R=length of record in bytes (even)
• Byte 2: 0 (num sectors in an extended attribute)
• Next 8: num of first sector of file or dir data
• Next 8: file size in bytes (double endian double word)
• Next 7: file date

File Date Format (in hex):

• 1 byte — number of years since 1900
• 1 byte — month, 1=jan 12=dec
• 1 byte — day in the range 1-31…

Extensions:

It's not necessarily true that if you burn something on Unix (Rock Ridge) that you will be able to read it on Windows (Joliet), and vise-versa.

Forensic Tools

Imager is the tool you would use to make images of volumes. Imager can be downloaded from FTK's website and used without the dongle. The EnCase image files usually have better compression.

If you're in a Windows® environment, you need to use a write-blocking device or a medium that can be write-protected with a switch (e.g. floppies, some thumb drives). There is also software (NCFS Software Write-Block XP available at http://www.ncfs.org/fleet/block/index.htm) that can edit the registry and write-protect all attached USB devices.

PRTK is the Password Recovery Toolkit (demo available from AccessData). There is also the AccessData Registry Viewer (demo available from their website).

Password recovery tools use a combination of brute-force and dictionary attacks. PRTK will index your drive and when you do searches, you search the index instead of the drive and results point right to the place the file is located on the hard drive. Once the drive is indexed, you can export the index as a word list to use in a dictionary attack. You may also use information collected in interviews with a suspect or in your forensic investigation (e.g. passwords found in the Windows® registry) to use as a dictionary for password recovery tools. PRTK will do a dictionary attack with the dictionaries you specify and if that fails it will try brute force.

With Imager, you can create an image of a file, a folder, a logical drive (partition) or a physical drive. If you create a logical image of a folder, you will get an error that says it will not have metadata or sector data usually found on partitions. Then you will be asked whether you want to create a Raw (dd), SMART, or E01 image. You can also convert one image type to another.

You don't install FTK Imager; you just run it. So with the right support files you can save the application on a thumb drive and actually run the program from that drive instead of your boot disk. This allows you to suck the registry off a running system (or other files Windows® won't usually let you touch).

AccessData Forensic Toolkit (FTK)

FTK is AccessData's version of EnCase. EnCase can interpret times correctly by entering the time in the application. FTK requires you to reset your system clock to match the suspect's clock in order to process time and date data correctly. This is also important because NTFS volumes use universal time. FAT volumes use local time and the forensic application needs to know the correct time reference to use.

Under the Explore tab, you have the ability to explore the directory (structured items) hierarchy, view all files within a directory, list all descendants of a directory, and view a preview of an item. This is also where you can view the MD5 hash and other relevant data about a file.

Under the Graphics tab, you can preview all of the pictures in a folder or on a drive (including all descendents of a particular folder). You can mark images in thumbnail view to be included in your report.

Under the E-Mail tab, the left-hand box will list all of the e-mail boxes, the messages within a box, and the contents of each message (along with attachments). FTK's e-mail capabilities are historically better than enCase's e-mail support.

Under the Search tab, you have a search pane, a results pane, and an expansion of the search results. Note that FTK doesn't index image (picture) files. It can also do regular expression searches for patterns (e.g. credit card patterns). FTK saves your old regular expression searches so that you can reuse them later. You can add more regular expression searches to the text file and they will be available for further searches. FTK comes with some built-in regular expressions to start you off. You may search in Hex if you want, too. You can extend your search with stemming (kill, killer, killing), phonic (kill, pill), synonyms, fuzzy (lazy, lazie, other misspellings), and more features. You may also narrow your search by time/date, etc. These searches make use of the index list. You may bookmark search hits (with file position) for use in your reports.

A lot of times, when you view a list of images in thumbnail view, the system automatically creates a thumbs database file that is a system file. Most of the time the thumbs.db file is still there when the other files are deleted because the OS will give an error that it is a system file so people won't delete it.

Under the Bookmark tab, you can view a list of all files you have bookmarked. You can generate a report from items that have been bookmarked with thumbnails, file paths, and a ton of other optional information. The report is generated as an HTML document that can be burned to CD as an auto-start CD that can be sent to an investigator or prosecutor. The recipient must have the correct software to run files included on the disk (i.e. they must have Microsoft Word to view .doc files).

Neither EnCase nor FTK will automatically restore deleted files, but they will let you know that there is a file that matches your search description and that it has been deleted. If the file hasn't been overwritten it will show you the context of your search result and the location of the file so that you can restore it.

AccessData's Registry Viewer lets you view a lot of important data including Internet Explorer data you can't get from IE like typed URLs (not stuff you stumbled upon — stuff you actually typed in). You can view recent files in chronological order of most to least recent, version info for installed software and attached hardware, etc. The Internet Explorer data also includes decrypted passwords, which you can add to the dictionary for a dictionary password attack. Note: The Registry Viewer demo won't show you the encrypted data, which includes this password information.

Basic Computer Forensics Procedure

Scenario

A young woman is found unconscious in Central Park. She has no purse and no identification. She was wearing cargo pants and inside one of her pockets was a diskette. We are going to get the diskette and do a forensic exam on it to see what we can recover, including who she is, who she is associated with, and anything else of use. We know nothing but that she has a blunt force trauma to the head.

Officers found the diskette in the pocket and they called you to the scene. You begin the chain of custody. You must create a chain of custody piece of paper, on which you will record information about where the disk was found and everything you did with it. When you get it to the evidence locker, it has to be signed over to whomever will be placing it in the locker.

Next, you become the examiner, who will go to the evidence locker and check out the diskette. You will obviously have to open the bag and do a physical exam of the diskette (making a note of any markings visible from the outside). You can assume it has been physically fingerprinted first so you no longer have to handle it with a latex glove. Make a note of the position of the Write-Protect tab (if the seizure guy has already dealt with that and made sure the tab was in the open or closed position don't worry about it). Unless you're going to process it in your disk drive, you may want to stick a little wire tie or piece of string through the hole so nobody can write to the disk. Make a forensic copy of the disk.

Making a forensic copy (this assumes that your disk drive works properly)…

1. Validate the Write Protection feature of the drive — check a clean disk by write-protecting it and make an MD5 hash before and after you try to write to the disk. If they match, you're okay. Put the general procedure for this in the back of your report. Of course you'll validate write protection on a disk other than the one with evidence on it!
2. "Fingerprint" the write-protected evidence disk (record the MD5 hash of the disk).
3. Make the image file (using GetFlop).
4. "Fingerprint" the write-protected evidence disk again and compare post-processing and pre-processing.
5. Make a working forensic copy.
   1. Take a piece of media and pseudo-sterilize (full format) it. In a lab you would do a full sterilization, but we don't have that tool so a full format will do for our purposes. This step is kind of moot because you're going to write over the whole 2880 sectors anyway, but we're still going to do it. We normally going through the sterilization process each time because often the media don't match up (two 80GB drives might format out to different sizes).
   2. Copy image file to target.
   3. "Fingerprint" write-protected target.
   4. Compare this "fingerprint" with the original to make sure that it is a true forensic copy. Document all of this in the report.
6. At this point, you can do a preliminary examination by looking at a directory listing, etc. This won't show you any hidden files, so you could just jump in and begin your exam on it.
   1. Take a look at the boot record so that you can determine the file system, the actual capacity of the disk (1.44mb or 720kb for a floppy), cluster size, volume name, etc. DiskEdit will not bring you into the boot record; it brings you into the root directory.
   2. If you can find a nice way to do it, if you can grab a picture of the root directory and insert it into your report. With this particular diskette, there will be an Invalid Directory Entry error. Ignore the fact that they are causing DiskEdit to give an error.
   3. If the long filename seems to have some value and you want to associate it with the short file name, go ahead and use the corrent letter — just put a note in the report that you did that.
   4. You're going to have to un-write-protect the FORENSIC COPY in order to make the changes to recover the deleted files, so your resulting MD5 hash will NOT match the original and that's okay.
7. Describe the recovery process as briefly as possible in the body of the report and at more length in an appendix.
8. There are some instances where it is helpful to root around the file with DiskEdit, but if you have some files on the disk that are Word documents, spreadsheets, JPEGs, etc, you should use a viewer.

You'll need to come up with a way of marking the working copy, and initial it so that it is obvious you are the one who made it.

There are two different things you'll typically find within a file. One is what you would normally associate with the content of the file. There is typically more than that there. If there is a JPEG picture, there may be some information in there like when the picture was taken, what kind of camera took the photo, what program modified it, etc. Word Documents record information like the author, what computer the file was created on, etc. This is metadata, which is separate than the time and date stamp on the file. One way to get at the metadata is with DiskEdit. If it's a Word file that came from your computer, it will probably have some information in there that identifies you, your computer, a last printed date, a time when it was last saved, etc. An easier way is to use Metadata Assistant Demo (download from WebCT).

For Assignment 1: Download Practical 1 - 05 from WebCT, which is the WinImage copy of the file with the accompanying scenario (described above).

Another way to look at a Word document's metadata is to go directly through Word. This will change the last accessed time so make sure it's write-protected.

Creating a RAM disk

type a:config.sys
rem - - load memory management programs
device = A:\himem.sys
device = A:\emm386.exe NOEMS HIGHSCAN
dos = high.umb

rem - - install device drivers
devicehigh A:\ramdrive.sys 4096 /e

rem - - set up the command processor - 480 byte environment
shell = A:\command.com /e:480

E:\>

The following tools are on a disk that can be downloaded from WebCT:

md5

This calculates the MD5 hash of a floppy disk.

Do you want optional output to a text file? (Y/N): y

Enter name of temporary file: f1-md5.txt

Track: 01...

MD5 hash calculated at 07:29:51pm (EDT) on Tuesday, 09/27/2005

Floppy diskette volume serial number: 0000 Hex

MD5 hash: 9926 5B06 ...

getflop

This creates an image of a floppy disk.

Place source diskette in drive A: then hit any key
Enter name of temporary file: f1-image

Copying track: 01...

Diskette copied to file successfully.

putflop

This copies the image file down.

putflop f1-image

Place target diskette in drive A: and hit Enter
Track: 01...

Diskette copied from file successfully.

Would you like to make another copy? (Y/N): n

Do you want the file f1-image deleted? (Y/N): n

FYI: When you zero out (format) a floppy once and then do it again, the two could have a different MD5 checksum because there is a different volume serial number (based on the time and date of the format).

To do a real sterilization in Linux, you can do a dd with the input file as null, and it will write all zeros to the disk.

For this project, you will need to use the tools above and the Metadata tool. The most important part is the report. Your findings should be located at the beginning of the report, more details are included in the body of the report, and procedures, etc. are located in the appendices. Scott prefers one big Word file, so put everything into a single Word document before submitting it. Put together an executive summary with the most significant findings, but include everything in the body of the report because something that seems insignificant may turn out to have value later in the case.

Review

What are the three things that happen when you create a file in a FAT system?

1. A directory entry is created (file date, file size, short file name, starting cluster, additional entries for long file names, time and date stamps).
2. The correct number of available clusters are chained together.
3. The file gets written to those clusters. Those clusters are out in the data area somewhere.

What are the two things that happen when that file is deleted?

1. First character in the file is changed to sigma (0xE5).
2. The cluster chain is zeroed out.

When directories are deleted, the enclosed files' cluster chain is zeroed out, but the filenames are not changed because the parent directory is no longer visible.

Examining Partitions, Long File Names

I was not present in Computer Forensics on Tuesday, September 20. If anyone took notes on Tuesday, please post them in the comments section on this page so that they may fill in the blanks that I have here. From what I was able to get out of Dr. Leeson, we looked at partition tables (I presume that he also discussed disks that had been repartitioned to hide information in previous locations on the disk, but I could be wrong).

Wikipedia of course has a lot of information on partition tables, along with a list of partition utilities including fdisk, Microsoft DiskPart, and Norton PartitionMagic.

Long filename recovery was also discussed.

Another student, J.B., e-mailed me the following information as well:

He mostly went over his slides which had things like "anatomy of a floppy disk", CMOS, BIOS, and other things he's talked about in the past. The one new thing he talked about was how to recover a directory structure manually in disk edit...

The process was simple:

First search memory for ".. " or "5e 5e 20 20" in hex at offset 32. If you recall the .. is the parent directory information. Once you have the locations for all the directories you can go to those sectors in directory view and find all the information you need to recover the tree structure.

He also mentioned starting to oragnize apenicies for our first assignments. He said things like "how to recover a file," "what is FAT32?," "anatomy of a hard disk," and a glossary are all things we should start compiling.