Forensic Practical Exercise #3 - SOLVED

Humpty Dumpty sat on a wall,
Humpty Dumpty had a great fall.
All the king's horses and all the king's men
Couldn't put Humpty together again.

This practical exercise is very much like Humpty Dumpty. It's a simple scenario, a simple JPG file fragmented in unallocated space. The complex part is that its in 35 pieces (fragmented) and they are not necessarily in order, and the FAT table is completely gone :(.

Well, all the kings men couldn't put Humpty Dumpty back together again, but Daniel Walton from e.law Asia Pacific Pty Ltd (elaw.com.au) in Australia was able to put this highly fragmented, unusual JPG image back together and solve the puzzle. If this had been a real case, he would have been paid a large amount of money for doing almost the impossible. Great job Daniel!!

Here are his notes:

-----------------------------------------------------------------------------------------------------------------
I have recovered  your number on the jpg.

983456 294001 991201

Have attached the recovered .JPG

##Extra Credit:
##Can you hypothesize as to what happened to make the file "disappear"?

It seems that the file was formatted by the mac pc.

###Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
[a]  media descriptor byte
Now the media descriptor byte at the beginning of the FAT on the image signifies a floppy disk.( 0xf0)
re http://support.microsoft.com/kb/140418
Byte   Capacity   Media Size and Type
F0     2.88 MB    3.5-inch, 2-sided, 36-sector
F0     1.44 MB    3.5-inch, 2-sided, 18-sector
F8     -----      Fixed disk

on my usb drives it's 0xf8
now that is true for both partitions.

[b] two partitions.
Most usb drives only have 1 partition as windows will not display both partitions on a USB drive.
The file was on the second partition , which wouldn't be visible on the pc if the first partition was formatted to a FAT or NTFS filesystem.

So the first partition must of not had a  FAT or NTFS filesystem or the partition was  been deleted.

The evidence had the following two partitions.
The first partition was formatted by macos.  ("BSD  4.4" , FAT16)
The second partition had been formatted by windows. ("MSWIN4.1" , FAT32)

With this setup the second partition will not be accessible under windows.

For windows to mount the second partition the first partition must (a) not have a  FAT or NTFS filesystem or (b) the partition must been deleted.
I would assume the first partition originally was created but wasn't formatted when it was put in the MAC.

Not having a MAC I couldn't test it's behavour with partitions and USB sticks.
I know Linux will happily see all partitions on a USB stick.

Unless the first partition wasn't originally formatted , in which case that could be why the file wasn't immediately viewable on the mac and was viewable on the pc.

The partition table is EFI , which is the default format mac's make.

[c] File fragmentation.
The file was extremely fragmented.
the end of the file (footer) was stored before the beginning of the file. (header)
Not a normal situation , shows extreme fragmentation or unusual circumstances.

###  Provide the MD5 of the recovered file.
Can't do that as I have removed all of the section which has a header of 0xFFE2.
I couldn't find any info regarding that part of a jpg which would help me to find the missing parts.

After finding the header and footer if  searched for 0xff00 to find the image data.

My method was to use a hex editor and combine the parts manually.

I used encase to find the pictures header.
Then tried data carving it with "revit" which didn't find anything.

So researched the JFIF file format and found out what I could about the format and the headers in the file.
Searched for the most important headers and found the following.
FFD8 , FFE0 , FFE1 , FFE2 , FFDB , FFC0 , FFDA & FFD9
Exported all chunks with the above headers.

Found that JFIF files use byte stuffing and 0xFF00 is used to represent 0xFF , so searched for all blocks containing 0xFF00.

The size of the FFE2 section was fairly large and I couldn't easily find any details about it's format , so removed it.
(used the following two bytes after the header as the section size. (big endian))

Removed any sectors which contained 0xFF followed by a byte which's value is under C0 but still keeping all sectors which contain 0xFF00. (so keeping 0xFF00 and 0xFFC0 and above)

Connected sections FFD8 , FFE0 , FFE1 , FFDB , FFC0 , FFDA together.

Then appended first 4 found sectors containing 0xFF00 . ( Hadn't found the rest of them at that stage)
The resulting JPG wasn't quite correct , so changed the order until it displayed correctly.
This gave me the first two rows of numbers and half the HDD picture.

I search further and found all the other sectors with 0xFF00 .
Luckily I had started from the beginning as they were all in order and then appended them one by one until I ended up with the correct image.
Appended the footer when I had run out of data.

I had been hoping that I might of been able to find part of the original FAT table so then I could figure out the order of the sectors, but didn't

It was not an easy puzzle.
Was a good challenge !!
---------------------------------------------------------------------------------------------------------------------------

Here is the recovered JPG:

The file was fragmented severely across the second partition. Here is the order of the pieces notated in physical sector numbers :

427586, 427587, 427588, 427589, 427590, 427591, 427592, 427593, 427594, 427330, 426497, 428505, 428434, 428433, 427750, 427749, 427751, 427712, 427713, 428685, 428686,  426442, 426443, 426718, 428457, 426858, 426859, 426878, 426879, 426172, 426188, 426208, 426228, 426246, 427202.

Here is the true scenario:
This flash drive was partitioned and formatted using a MAC. The default was to use a GUID partition table. This caused two partitions to be created. The first partition is used as the GUID partitioning config and the second is actually the usable one.  When used on a MAC, there is no problem and just one partition is seen (the second one). When inserted into a Windows XP machine, the OS says the flash disk needs to be formatted and when you choose "yes" to format, it only formats the first partition (The one containing the GUID partition information) which is only 200MB in size. So in this case, I had a flash device that was 4gb, but the actual reported size in Windows was 200MB. I then deleted the second partition after "laying" down the fragmented JPG.  I manually assigned each piece to each sector using the diskmap tool by Tim Coakley (http://www.simplecarver.com/software.php?cat=All).  This tool allowed me to created the highly unusual, but not impossible, fragmentation and disorder among all the JPG pieces. I then reformatted the second partition using the MAC.

I admit that it is not often that you see the beginning of a file *after* middle parts or even the end piece of a file, especially in a FAT file system, but I have to honestly say that I have seen this situation on real evidence before.

To summarize, it's a simple JPG image with a text layer containing the 18 digit account number. I broke the account number into three parts, six digits each and placed the first part at the top, the second in the middle and the last part at the bottom, so if you started to recover the JPG you could start to see the account number, but not all of it until you got all the pieces (yes, it was evil). If you put the first 23 pieces together, you will get a partial image with the first portion of the account number, then you have to put the remaining pieces in order to get the rest.

I was very surprised and pleased at the amount of emails and responses I received asking questions and providing comments about the practical. It indicated to me that there are a lot of people that enjoy doing these puzzles/practical, so I intend on creating some more and posting them shortly.

Thanks to all that participated and congratulations to DANIEL WALTON!!!!

Forensic Review of Windows 7 - Part V - Bitlocker

BitLocker Full Volume Encryption (FVE) is included in some versions of Windows 7 and it has changed a little compared to the version included with Windows Vista. There are (6) six versions of Windows 7 available:

• Starter
• Home Basic
• Home Premium
• Professional
• Enterprise (volume licensing)
• Ultimate

The Starter version provides the minimal amount of features and each version above that adds additional features. Like in Windows Vista, BitLocker is only available in the Enterprise and Ultimate versions of Windows 7. It seems at first glance, Microsoft has enhanced the Bitlocker capability with "BitLocker to go", an extention of BitLocker designed for removable drives. Here are the BitLocker hardware requirements directly from the built in help:

When you look at the BitLocker options from the control panel you may notice some new options:

Removable devices are now treated differently than internel hard disks and are listed below under the heading "BitLocker to go". When you encrypt a removable device, you are presented with a screen that lets you set your own password as well as other authentication methods. This is a change fromt he way Vista handles removable devices and the fact that the user can set the pasword.

Once you enter a password the drive is encrypted, but in a different way than using Bitlocker on removables in Windows Vista. With Windows 7, BitLocker to Go is used and the contents of the flash drive are encrypted into a file container, then an application is placed on the removable device, letting you access the entrypted container from other computers, including non-Windows 7 computers. If you look at the removable device in WIndows explorer or via forensic software, you will see several files:

Normally, I get nervous when I see "autorun.inf" on any removable drive. But in this case if you don't have the autorun feature disabled in the registry (your should!), then the "BitLockerToGo.exe" application is started. Once the application starts, it will then ask for the password that was set.

Once the password is entered, the contents of the encrypted container is displayed and you can copy files from the device:

The BitLockerToGo Reader only allows a non-Windows 7 computer from *viewing* and copying files from the flash device. You cannot add files onto the device using the BitLocker Reader program. However, if you insert the removable device into a different Windows 7 computer with BitLocker enabled, you can access and add files as long as you present the correct password or smartcard.

From a forensic tool, the removable device will look like this:

The COV file is the container file that actually contains the encrypted data. The example above was created on a 4GB flash device.

For internal hard drives, the process is very similar to Windows Vista. You can enable BitLocker and it will create a second small partition that is used for the initial boot process. The main partition is then completely encrypted (not a container like BitLocker To Go). From a forensic tool, an encrypted volume will look like this:

The "C" volume is the boot partition and is not encrypted and the "D" volume is the actual encrypted volume. It is important to note that the above drive letters are assigned by EnCase and are not the same as what would be seen on a live Windows machine with BitLocker enabled. In Windows Vista, the second partition was usually labelled "S". In Windows 7, it does not have a drive label by default. The boot sector of the encrypted volume looks like this:

Gpedit.msc can be used to configure several new options with BitLocker:

This last screen shows how to use BitLocker without a TPM chip. Just enable the "Require additional authentication methods at startup" and check the "Allow BitLocker without a compatible TPM" checkbox.

 The current version of EnCase (6.15.0.82) does not support decryption of a BitLocker volume created with Windows 7 with the EDS module as it does with Microsoft Vista.

Windows 7 Forensics - Part IV - Thumbcache_*.db

Windows 7 creates small thumbnail images of graphic files the same way previous version of Windows does, nothing new here. It stores the thumbnails in the same location as in Windows Vista:

C:\Users\%username%\AppData\Local\Microsoft\Windows\Explorer

There are files named Thumbcache_32.db, Thumbcache_96.db, Thumbcache_256.db & Thumbcache_1024.db which correspond to the thumbnails stored for that specific user account and size.

Currently, the latest release of EnCase (6.15.0.82) does *not* parse these files correctly. The structure has slightly changed and therefore if you try and view the contents of any of the "thumbcache" files, EnCase will mount them without error, but they will appear empty. You can however, use the File Finder module to carve JPG images out of the *.db files.

If anyone is using any other tools and can confirm they handle these new Windows 7 thumbcache files correctly, please post the name in the comments so everyone can benefit and have a tool until EnCase incorporates this support.

Forensic Practical Exercise #3

So I figured many of you may be on vacation and would like a little puzzle to work on during your free time ;)

Scenario:
Your company has been contacted by a very wealthy and prominent business. They have one simple request. They would like you to do some data recovery and recover one simple file. The President of the company explains that he has a USB flash device that contained one simple file and that when he gave it to the company accountant (who uses a MAC), the drive suddenly became unreadable. The President advises you that the file contains the account number of a very important bank account and that he needs that 18 digit account number. Nothing else matters to him.

The file is *very* important and he is willing to pay you whatever fee you demand if you are able to recover the file exactly as it was.

Your mission, if you choose to accept it, is to recover the file and be able to tell the President (me) the account number (via email, please don't spoil it and post it in the comments, send to lance(at)forensickb.com).

Extra Credit:
Can you hypothesize as to what happened to make the file "disappear"?
Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
Provide the MD5 of the recovered file.

I will provide an exact explanation of what was done to the device and file to those who submit answers so you can compare it with what you see. 

There is no encryption or hidden elements to this problem. This is a classic puzzle. For this scenario, I will be the "President" who lost the data and has contacted you. Feel free to "interview me" and ask any further information that you feel necessary, via the comment section (so everyone can benefit).

Good Luck!

Download Here (7.5MB)

Forensic Review of Windows 7 - Part III

This post is a New Year's present from Troy Larson. Troy emailed me a presentation a few days ago that he and Harlan Carvey did a few months back that outlines many of the changes with Vista and Windows 7. With his permission, I am posting the PPT, converted to PDF for everyone to benefit.

Thanks Troy and Happy New Year to everyone!

Download Here

Forensic review of Windows 7 - Part II - File system

Windows 7 supports the same file systems that Windows Vista supports, i.e. FAT, NTFS & exFAT. Internally, Windows 7 uses the same underlying file system as Windows Vista, NTFS version 3.1. Windows 7 continues to utilize the transactional filesystem database, located in the \$Extend\$RmMetadata folder.

Windows 7 continues to not update the last accessed timestamp unless other timestamps (written) are triggered. This is a registry setting that has been available since Windows 2000, but not enabled by default until Vista.

The exFAT filesystem used in Windows 7 is the same as the version used in Windows Vista and is designed for removable drives. The latest version of EnCase supports the exFAT file system and will display the exFAT volume contents similiar to this example:

When formatting external drives and flash devices, Windows 7 will completely WIPE the contents of the volume UNLESS the "QUICK FORMAT" option is selected, regardless of whether NTFS, FAT or exFAT is used. When the "QUICK FORMAT" option is selected, the prior data remains in unallocated space of the newly created volume and can be carved.

Forensic review of Windows 7 - Part I

Over the next few weeks, I will be documenting and posting some basic information about Windows 7 from a forensic perspective. I know many of you may have already encountered a Windows 7 box or have been exploring it yourself. Please feel free to post comments with whatever little forensic nuggets you have found useful.

Initially looking at a Windows 7 image, it closely resembles a Windows Vista installation (no surprise there). There are a few small differences and changes which I will document with additional posts.

Starting off simple, here is a view of a clean Windows 7 install.

Take note there are two separate partitions. During a clean install where the disk does not contain any pre-existing partitions, the Windows 7 installation process creates two partitions, even though you specify one partition. The installation process warns you that an additional partition may be created and in fact a 100MB "hidden" partition is created. There is a little trickery you can do to avoid the 100MB partition, but it’s not intuitive and it is likely a typical user will not know how to avoid it from being created, so you are likely to see two separate partitions, one 100MB and the main partition which by default is the remainder of the physical disk. The second partition is important because it will likely skew any link files you review. EnCase assigns drive letters in chronological order as they are encountered in the partition table, so the hidden partition gets the "C" volume letter, but really it’s a hidden partition and does not get a letter assignment. The main partition gets a "D" assignment, but really it is "C". The contents of any shortcut files will point to "C", which in EnCase in "D".

If the disk has a partition scheme already defined (i.e. it has an older version of windows or it was partitioned prior to starting the installation) then it continues to just use the one defined partition or whatever partitions were defined prior to starting the installation process.

A view of the typical default folders. Looks very "Vista-ish"

A view of a user's profile:

Internet History folders:

For the most part, if you have done an exam on a Vista machine, you will feel right at home with a Windows 7 image and should have no problem finding the common locations for artifacts.

Export x Number of bytes around selected search hits - categorized by keyword hit

Updated - December 15, 2009 - Third version now available below

This EnScript is an update to the previous post here.

Changes & updates in this version:

1. Now includes the MD5 hash of the file the hit is located in (internal and unallocated files are excluded).

2. Keyword column now shows the hit text as well as the keyword. This is in case you used a GREP expression, it will show the expression and the hit.

3. The AFTER count now starts at the end of the keyword hit instead of the the beginning of the keyword hit.

4. The red highlighted keyword hit should now be accurate and only show the exact characters in the keyword hit.

There are now three versions of this EnScript available.

The first version is from the original EnScript that creates one "Proximity Report" with all the hits you selected from the search hits pane.

The second version is an adaptation from the original based on a reader's request. This second version creates one proximity report for each unique keyword hit. This version was created to easily facilitate redaction of certain hits.

This third version creates one proximity report per keyword. i.e. if you have five different keywords that you have selected in the search hit pane, then five different folders are created and in each foler is one report containing all the hits for that keyword.
Download here - updated original version
Download here - updated adapted version
Download here - updated third version

EnScript to create thumbnails of selected video files

This EnScript was designed to take all selected (blue checked) video files (avi, mp4, 3gp, etc.) in the case and to automatically create thumbnail pictures for each video. In order to do this, a program named “Video Thumbnails Maker” is required. This is a free program, but in order to use it in the method described below, you need to give a donation of $25.00 or more to the author of the program (I have no affiliation with the author, I use this program because its the only program that works from the command-line and works reliably, just make sure you have all the appropriate codecs loaded).

Once you give a donation, a reg key is sent via email that enables the program to be used from the command line (Platinum level). It is this feature that is required in order to integrate it with an EnScript. The program can be downloaded from http://www.suu-design.com and can be used for free via the GUI and you can manually convert videos using the GUI but you will not be able to use it as the described below until you register it and receive the activation code, which enables the command-line features.   

 

The “Video Thumbnails Maker” program supports many of the different video types, but I have found AVI to be the most reliable video type that seems to work 100% of the time.

 

To use this EnScript, simply select any video files you wish to make thumbnails of:

 

Then run the EnScript named “Make Thumbnails of selected video files”. The EnScript will create a root folder named “Video Thumbnails” in the default export folder specified in your case. Inside this folder, the EnScript will create a sub folder for each video file that you selected (The hash value is appended to avoid a collision of two files named the same but from different paths):

Inside each subfolder that is named after the video that was exported, the original video and all the thumbnail photos will be present. In addition, there will be a text file named “Video_Header.txt” that contains all the video metadata, name, path, hash, created date, written date. This information can be copied into an external report as the header information describing the video, then show all the thumbnails.

You can see that the thumbnails are all named after the original video, along with a timestamp of when in the video the thumbnail was created. In the example above, a thumbnail was created every second as that is what I have set in my EnCase.vtm file.  You can then quickly scan the images in Windows Explorer thumbnail view to see which picture contain valuable images and which you can delete. In the same folder is a text file with the video metadata that can be quickly inserted into an external report:

The “Video Thumbnail Maker” program  has many different options that you can set and then save those settings to a “preset” file. When you install the “Video Thumbnail Maker” program, there is a subfolder created under the program folder of “C:\Program Files\Video Thumbnails Maker” named “Presets”:

 

The five “Base_Presets_x.vtm” are installed when you install the program the first time. In order for the EnScript to work with this program, you must create a preset file named “EnCase.vtm” with the settings you want to use when creating the thumbnail pictures. Here is an example of my settings as I set them in the program GUI and then saved them to the “EnCase.vtm” preset:

 

This last option screen is where you can set the time sequence for your thumbnails. You can see above that I have the “Specific Time” option selected and the box below says “2 secs”, this means that regardless of how long the video is, this program will create a JPG thumbnail picture every two seconds until the end of the video.

At the top of this last screen you can see the “export” option. This is where you can set all the options you want to use with the program and the export them to a file named “EnCase.vtm” in the c:\Program Files\Video Thumbnail Maker\Preset\” folder. Whatever you save into that preset file are the options that the EnScript will use when creating your thumbnails. Some common mistakes:

1.   Make sure on the Environment screen, in the "output" section,  you do not select the “Save thumbnails to your folder” option. By default the program will place the thumbnails in the same folder where the video file is found, which is that subfolder that the EnScript automatically creates.

2.   When trying to create thumbnails of video files other than “AVI”, I have had to change the “Video Rendering” option on the Environment page between “Engine 1” and some of the other options. “AVI” seems to work great with “Engine 1”, but sometimes .3GP, MP4 and others fail with that option, so changing that option to “Engine 2” or “Extreme” usually fixes the failure.

Once you set all your options and save them to the EnCase.vmt file, you will not need to reconfigure the program unless you want to change some of the settings.

One valuable use for this EnScript is to export out any videos and then quickly scan the thumbnail images in Windows Explorer to see if it contains any images of interest. 

Download Here

EnScript to find Limewire download remnants.

This EnScript was written for a reader who requested an EnScript to search for the common "URN:SHA1:{Sha1_base32 hash} associated with Limewire downloads. When run, the EnScript will search SELECTED files for that tag. If found, it will read the SHA1_base32 value that immediately follows the tag and then compute a SHA1_base32 hash for all the files that have matching extensions to those you specify. If a file with the same hash is found, it is bookmarked as a matching file.

Once completed, check the bookmark folder for two different folders. One contains any "URN:SHA1" tags found in the selected files, and the second one is each file that matches a found SHA1 value

Download Here

EnScript to display the number of search hits per file.

A reader asked if I could write an EnScript to calculate how many search hits were in each individual file, instead of the total number of search hits that EnCase displays.

Below is an EnScript that will calculate the number of unique files with each selected search hit, as well as how many hits in each file. To use, conduct your search, then select the search hits you want to include in the report and then run.

Once you run the EnScript, it will automatically open Microsoft Excel (required) and populate three columns, Search Expression+(unique count), Full Path, and hits per file.

Download Here

EnScript to create LEF with files based on extension

I wrote this EnScript for myself to essentially create a separate Logical Evidence File with all the user generated files to simplify review. It is a modification of the EnScript here that exports files based on extension.

To use, simply run the EnScript and it will prompt you for a list of extensions, by default most of the common user generated extensions are already included, but you can add or remove extensions from the list.

Once run, it will grab every file that has an extension in the list you provided and then create a LEF with just those files, maintaining their original paths and metadata. The files are placed in the LEF in a folder corresponding to their extension, making review easier. If you check the first box, the LEF will automatically be loade dinto EnCase after its created. The second one causes all compund files to be automatically mounted. Office files, Zips, Thumbs.db, etc. will all be mounted to reveal their contents and additional metadata.

As a bonus I also created a folder in the LEF called high ASCII filenames which will contain any files/folders that are named not using the low ASCII character set. This means it will find and categorize all the foreign language files that do not use the standard Roman alphabet.

Download Here

EnScript to export x bytes around search hits - UPDATED

A reader asked if I would modify my original EnScript here so that instead of exporting one HTML file with all the exported search hits, that it would export one HTML for each search hit. He was dealing with 50,000+ search hits and the EnScript was creating one huge HTML file and it would not load in a browser.

Therefore, I have modified the original EnScript to create one HTML file for every search hit and also place them into categorized folders based on the keyword.


Download Here

EnScript to obtain connected USB devices from System Restore Points (XP)

A reader requested that I modify my original USB information EnScript to work with the snapshot copies of the SYSTEM registry hives that are saved in the System Volume Information folder by the System Restore service in windows XP.

I have modified the original EnScript to only parse the registry hives found in the system Volume Information folder. This is a seperate EnScript and does not parse the active registry hives, only the ones in the System Volume Information Folder.

Download Here

EnScript to decode Yahoo chats in unallocated - UPDATED

A few days ago I posted an EnScript to decode Yahoo chat data in unallocated. You can find the original post here.

I have updated the EnScript to bookmark the data and put the decoded chat data in the comment of the bookmark.

I have also updated the pop-up window that displays when invalid data is encountered.

Download Here

EnScript to decode Yahoo chats in unallocated

Awhile back I created an EnScript to search for keywords that may appear in encrypted yahoo chat logs in unallocated. You can read about that EnScript here.

After creating that EnScript, I created a second one to parse the encrypted chat logs that you may find in unallocated. The following EnScript can be used to decode the chats that you may find in unallocated.

Before running the Enscript, click the cursor on the first character of the UNIX time stamp of the found Yahoo log data in unallocated. The structure of the Yahoo log files are date, type, user, size, message, the a dword null (see below). Once you click the cursor on the first byte of the UNIX timestamp, then run the EnScript and you will need to provide the local Yahoo user name, as this is used as the XOR key.

Here is a screenshot of some yahoo logs in unallocated as well as their structure. Take note where the cursor is placed (solid blue) before running the EnScript.

The cursor is placed on the first byte of the UNIX timestamp and then run the EnScript. It will continue to parse all the messages found until the data structure is no longer valid. After the highlighted data blocks in the picture above, you can see four null bytes, then another UNIX timestamp. The EnScript will continue parsing all the messages as long as it encounters this structure and/or the data values in the TYPE field and USER field contain valid values.

Download Here

EnScript to search unallocated for built-in File Signatures

This EnScript started as a kind of test EnScript for something else, but I thought others may find it useful.

By default, EnCase is installed with several hundred file signatures preconfigured in the File Signature tab. This EnScript uses those and any additional signatures that you may add and searches unallocated space for any that you select (blue check). So if you select all of them, then it will search unallocated for all of them. If you only select the signatures in the graphics folder, then only those will be searched. Any file signatures that are found are catagorized and bookmarked into a bookmark folder.



When you start the EnScript a simple window asks if you want to search on the cluster boundary or sector boundary. Normally, cluster boundary (default) is the best and fastest choice, since all the signatures should be found only on cluster boundaries. If you want to override this option and search on byte boundaries, then check the box. Checking the box will be much slower (about 8 times slower) since it will check the beginning of every sector instead of just the beginning of every cluster.

Once the EnScript is done, it will create a folder in the bookmark tree and then a sub folder for every file signature that you searched for and was found in unallocated.



Benchmark: A search for all included file signatures took 3.5 hours with 40gb of Unallocated space and having the checkbox selected (searching *every* sector).

A search for all included file signatures took 1.5 hours with 40gb of Unallocated space and having the checkbox unselected (searching *every* cluster).

Download Here

EnScript to Catagorize all files by their extension and then provide a count

Several months ago I did an EnScript to count up all the file extensions and then provide a summary of all the extensions and how many files with each extension. You can find that EnScript here.

This EnScript is similar but it makes a bookmark folder for every file extension and then bookmarks each file into the respective file extension folder for quick review.



The number next to the file extension is the number of files that match that extension. You could use this to quickly look at common file extension types or to identify what file extension types are prevalent on a specific system. Depending on how many files you have in your evidence, this may take several minutes to generate (~5 mins for 100,000 files).

Download Here

EnScript to find and bookmark foreign language files & folders

This EnScript was designed to recurse all the evidence and check the name of every file and folder. If the filename or foldername contains an ascii character higher than decimal 127, then it is bookmarked. This catches most languages that do not use the standard roman alphabet.

Run the Enscript and it will display a message if any files/folders are found and they are placed into a bookmark folder.



In the example below, it detected a few files with Thai characters and a few documents with latin characters that are not part of the roman alphabet. The EnScript will also detect other languages such as Arabic, Japanese, Chinese, etc.



Download Here

EnScript to alert you if there is data in the unused disk area of a physical device

This EnScript was designed to quickly scan the sectors classified as "Unused Disk Area" & "Volume Slack" for any data. If any data is found in these areas, then a bookmark of that sector is created and at the end of the EnScript a warning message will be displayed indicating that data was found in this area.

Data in this area is generally not a problem as long as you search and process all objects on the physical device. This is just a quick way to indicate if there is data and a way to quickly review what data exists in that area without having to scroll sector to sector.

Simply run the EnScript and it will check the "Unused Disk Area" of all the physical devices and then display a warning message if data was found. A bookmark is made of every sector that contains data in Unused or Volume Slack. You can then view the bookmark tab and quickly scroll through the bookmarks looking for recognizable data.





Download Here