Unlocking a screen locked Android phone / Breaking the Android passcode

Firstly, it’s important to note that every technique comes with some limitation or the other. You will need to figure out which technique would help you depending on the circumstances. Circumventing the passcode may not be always possible. We will take a few scenarios and see how you can take advantage in each case.

There are currently three main types of pass codes supported by Android devices – Pattern lock, PIN and alphanumeric code.

1. Smudge Attack:

This is not specific to any Android device but used generally by forensic analysts where they can deduce the password of a touch screen mobile. The attack depends on the fact that smudges are left behind by the user’s fingers due to repeated swiping across same locations. The pattern lock or any pass code is something that the user will have to swipe every time that he wants to use his mobile. We can infer that the smudges would be heaviest across the same locations and hence under proper lighting and high-resolution pictures we can deduce the code. So during examining any device, forensic analysts usually take care to avoid hand contact with the screen to check for the smudge attack.

(Picture referenced from http://www.elsevierdirect.com site)

2. If USB – debugging is enabled:

If USB debugging in the Android is enabled, then bypassing the lock code can be done in a matter of seconds. Imagine an attacker who wants to get access to his friend’s files and applications on his Android mobile. You can first ask his handset for some false reason, to make a call, for example, and turn on the USB debugging under Settings à Developer Options à USB debugging; and then hand over the mobile back to him. So later, at some convenient time, when you get access to the device, you can exploit it using any of the following ways discussed in this article. Now adb (Android Debugging Bridge) is primarily a command line tool that communicates with the device. ADB is bundled with the Android platform tools. To explain in simple terms, this is what happens when you deal with adb:

• An adb daemon runs as a background process on each Android device.
• When you install Android SDK on your machine, a client is run. The client can be invoked from shell by giving an adb command.
• A server is also run in the background to communicate between the client and adb daemon running on the Android device.

You can use any of the below methods to take advantage of the USB debugging to bypass the screen lock:

Using UnlockAndroid.apk:

Before going ahead with this process you can download the Unlockandroid.apk file from the below location.

URL: http://www.megafileupload.com/en/file/409464/UnlockAndroid-apk.html

1. Connect the device to the machine where Android SDK (including platform tools etc.) is installed.
2. Open command prompt and type cd C:\android-sdk-windows\platform-tools>adb.exe devices
3. The device must be identified by the adb if everything is going fine.
4. Copy the above UnlockAndroid.apk file into C:\android-sdk-windows\platform-tools directory.
5. In the command prompt type, C:\android-sdk-windows\platform-tools>adb.exe and install adb.exe UnlockAndroid.apk. Observe that the application is installed on the device.
6. To start the application just type:

   C:\android-sdk-windows\platform-tools>adb.exe shell am start -n com.rohit.unlock

   /com.rohit.unlock.MainActivity

7. Observe that the screen lock is bypassed now you can access all the application and folders in the mobile phone. Below is a screenshot of the process.

   

Deleting the gesture.key file:

If the Android device is using the pattern lock and it it’s a rooted device, then the process below can be tried to bypass the screen lock.

1. Connect the device to the machine where Android SDK (including platform tools etc.) is installed.
2. Open command prompt and type cd C:\android-sdk-windows\platform-tools>adb.exe devices
3. The device will be identified by the adb if everything is going fine.
4. Connect to adb shell by typing : adb.exe shell
5. The terminal appears giving you access to shell. Now type rm /data/system/gesture.key. This is the file where pattern is stored.
6. Restart the phone and you will still observe that the device is asking for the pattern. You can draw any random pattern and unlock the device.

   Below is the screenshot of the process.

   

Updating the SQLite files:

If the phone is rooted, then by updating the SQLite files you can bypass the screen lock. Here are the details.

cd /data/data/com.android.providers.settings/databases
sqlite settings.db
update system set value=0 where name=’lock_pattern_autolock’;
update system set value=0 where name=’lockscreen.lockedoutpermenantly’;

Cracking the PIN in Android:

We have seen how to bypass the screen lock and how to completely delete or disable the lock screen. But what if we wanted to know the actual PIN so that you can lock/unlock at any time? In Android, the PIN that user enters is stored in /data/system/password.key file. As you might expect, this key is not stored in plain text. It’s first salted using a random string, then the SHA1-hashsum and MD5-hashsum are calculated and concatenated and then the final result is stored. Seems very complicated but not to the modern computing power, as the following code shows:

[plain]
public byte[] passwordToHash(String password)
{ if (password == null)
{ return null;
} String algo = null;
byte[] hashed = null;
try {
byte[] saltedPassword = (password + getSalt()).getBytes();
byte[] sha1 = MessageDigest.getInstance(algo = “SHA-1″).digest(saltedPassword); byte[] md5 = MessageDigest.getInstance(algo = “MD5″).digest(saltedPassword); hashed = (toHex(sha1) + toHex(md5)).getBytes();
} catch (NoSuchAlgorithmException e)
{ Log.w(TAG, “Failed to encode string because of missing algorithm: ” + algo);
} return hashed; }
[/plain]

Since the hash is salted, it’s not possible to use a regular dictionary attack to the get original text. Here are the steps you can follow to try to crack the PIN.

1. Pull out the salt using adb. Salt is stored in the ‘secure’ table from /data/data/com.android.providers.settings/databases/settings.db)
2. Get the password : sha1+md5: (40+32) (stored at /data/system/password.key)

   Ex: 0C4C24508F0D29CF54FFC4DBC5520C3C10496F43313B4D3ADDFF8ACDD5C8DC3CA69CE740

3. Once you have the md5 and the salt, you can brute force using the tools available in market (Ex hashcat) to get password.

Data Extraction in Android:

After having seen different ways to bypass the Android screen lock, now let’s have a look at how to extract the data from an Android phone. You can extract the data of all the files on the system or only those relevant files that you are interested in. But for any form of extraction, it’s important that the device is unlocked or USB-debugging is previously enabled. There are two types of extractions.

Extracting through ADB: As explained earlier, adb is a protocol that helps you to connect to Android device and perform some commands.

Boot Loader Extraction: This can be done when the device is in Boot Loader mode. This takes advantage of the fact that during boot loader mode the Android OS will not be running.

Before extracting the data, it is important to know how the data is stored in the Android device to understand where to look, and what data to pull. Android stores the data mainly in the below four locations:

1. Share Preferences: Data is stored in key-value pairs. Shared preference files are stored in application’s ‘data’ directory in the ‘shared_pref’ folder.
2. Internal Storage: Stores data that is private in device’s internal memory (something like NAND flash).
3. External Storage: Stores data that is public in device’s external memory that might not contain security mechanisms. This data is available under /sdcard directory.
4. SQLite: This is a database that holds structural data. This data is available under /data/data/Package/database.

For example, if you want to analyze the Facebook Android application, here is how you do it. Download and install the Facebook application and sign in. As soon as you install any application in Android, the corresponding application data is stored in /data/data folder. However due to the security restrictions, you cannot access or pull this data unless you have root privileges on the phone. By using adb, let us see what the /data/data folder consists of. As shown in the below fig, a quick ‘ls’ on the /data/data folder gives the below results.

Whether it’s a browser, gallery or contacts, everything is an app in Android. They are the applications that come along with the phone. Application like games, social network apps etc. are the applications installed by the user. But the data belonging to any of these applications will be stored in /data/data folder. So the first step is to identify where your application is.

To see the contents of that application, ‘ls’ into that directory.

As you can see, these are the folders created by the Facebook application on your phone. For instance, the cache folder may consist of images that are cached and stored for faster retrieval during normal browsing. The main area of focus would be the databases folder where the data related to the user would be stored. Here comes the concept of application security. If the application were secure enough, it would take proper steps not to store any of the sensitive data permanently in the databases folder. Let us see what kind of data Facebook stores the when you are currently logged in. You can pull the Android folder into your system using the below command:

C:\android-sdk-windows\platform-tools>adb.exe      pull      /data/data/com.facebook.katana C:\test

The databases folder must be now copied into the ‘test’ folder in your C drive.

In the ‘databases’ folder, you see DB file types which are the SQLite files where the data is stored. To view the data present in them, you can use a browser such as Sqlite browser. Download and install SQLite browser. In the SQLite browser, click on File -> Open Database and select any of those DB files.

This shows you the database structure and helps you to browse the data stored in them. Now log out of the application, and you might notice that the data present in those tables would be deleted by the application.

To learn about additional Android forensic techniques, check out the mobile forensics course (http://www.infosecinstitute.com/courses/mobile-computer-forensics.html) offered by the InfoSec Institute. So to conclude, in this article we have seen how to bypass the Android screen lock under different conditions and how to extract the application data from Android phone.

Introduction & Prerequisites

Apple devices store much more information than you would ever imagine. It is surprisingly accurate as well, with timestamps to the millisecond and even location data that is frighteningly accurate. The main challenge for the user however, is correctly extracting, preserving and analyzing this information which is where awesome dudes like me come into the picture! After several months of studying the iOS architecture and how things work on an Apple device, I am more than happy to provide the community with bite size chunks of information and that is exactly what I am about to start doing with this first post, aimed at Apple forensics.

So, enough blabbering on about the facts and figures, time to get right down to business right? Well, first you gotta have the right equipment and tools, of course. Here is what you’ll need for this tutorial:

• An Apple device – this best works with an iPhone or an iPad but could be a great success on the latest iPod Touch too.
• The device has to be jailbroken – cause it is really easy to do and allows us to do so much more with the devices.
• Cydia package iFile which can be downloaded from many sources on Cydia.
• An extensive EXIF viewer, there are many available however, I prefer this one that is available online.
• Some legs, cause the device ain’t gonna walk up a high street itself now, is it?

That is roughly everything that you’re going to be needing in order to pursue this tutorial. Let’s get to it then!

Foreword

I’ll show you what we did during our research and what procedures we followed to get the end result which is of course a picture with the location data plotted on the map that easily allows you to see your whereabouts at certain times. It should be noted that when we carried out this experiment, we took our iPad and walked down a busy high street in the heart of Glasgow, assuming that the iPad would automatically connect to open WiFi networks itself (which it did). We never at any point connected to a network by ourselves, we only had the Camera application open and were taking pictures intermittently. During the following steps, I’ll breakdown exactly what we did, why and how.

Step 1

Take your device out for a stroll, preferably on a street that you know contains many WiFi hotspots (that is if you have non-cellular device such as an iPad Mini WiFi only model), so if you have an iPhone, you should be good to go anywhere because it is always connected to the Internet via radio towers.

Step 2

Take some pictures, at random times, in random places, of random things. Possibly do it with the same technique that we did – 5 pictures on the way down and 5 pictures on the way back. Notice that when you take a picture using the Camera application, the location data icon shows up on the status bar of your device, as shown below:

Location data active icon in the taskbar.

The actual icon may differ from the one I have above however, it will only pop up right after you take a picture using the Camera application. The icon will always show up when the iPad is requesting the use of location services. This can be changed within the Settings application.

Step 3

Once you have a small collection of photos that you took, you can head back in and start extracting them from the iPad. Now, you can always just sync the photos on iTunes and that’ll move them over or use some 3rd party software to transfer them but how about doing it wirelessly? That’s right. With iFile on a jailbroken device you can easily set up a web server that allows you to transfer content over to your computer.

Open up iFile and navigate to the following path:

/var/mobile/Media/DCIM/100APPLE

You’ll be presented with a screen that looks similar to the one below, of course you could have more or less photos, obviously depending on how trigger happy you are with the Camera application.

The image files contained within the folder mentioned above.

Already you can see information such as the size for each file, timestamps and file names. To initiate a web server connection, touch the wireless icon in the bottom center of the screen. This will yield this screen which shows you what to type into your address bar in a browser.

Connection has been created, use the details to access your device wirelessly.

Step 4

Now open up a browser on your laptop or desktop computer (for the love of god, do not use Internet Explorer) and type up the address that is shown on the device into the address bar. This will establish the connection between your computer and the device, enabling you to transfer files (yes, they go both ways) easily and effortlessly. Once you’ve setup the connection, you’ll be presented with this screen on your computer and a confirmation on your device.

This is what you’ll see on your computer once connection has been setup.

Step 5

You can now navigate to the path shown above on the computer and download the photos that you’ll be working with, precisely those that are located at the bottom of the folder. Just make sure that the date and time match that of when you took your initial photos. To save your photos, simply either right click on one and select Save link as… or click on it and repeat the aforementioned step. Save all your photos into one neat folder on your computer, so you can find them easily when it comes to the next step.

Step 6

This is where it begins to get interesting – with the photos extracted and ready, you can start uploading them onto the online EXIF viewer. Go ahead and open that up and upload the first image using the instructions provided on the website.

Uploading your image to the online EXIF viewer is easy, my gran could do it!

Step 7

Once your image is uploaded and the processing is complete, you’ll be presented with the full page of information. Some of this information is useful, and some is not. Have a wonder about and see how much you can understand cause we really need a few important details for the next bit. Notice on the top of the page there is a section that summarizes all the information that we need – a timestamp, longitude and latitude.

This EXIF viewer does a nifty job summarizing all the stuff we need.

Step 8

Go ahead and copy the latitude and longitude that is shown in brackets, you’ll need it for plotting the final coordinates later on. Now all you need to do is rinse and repeat the steps above for the remaining photos that you took, remembering to copy over the coordinates into a text file.

Once you’re done, you’ll essentially have something that looks like the following image. Let’s hope you haven’t been stalking me and your coordinates are wildly different from mine.

Your final list of coordinates, probably different from mine.

Step 9

It’s time to plot this small selection of coordinates (larger list if you’re a photo fiend) on a map, provided by the good old trustworthy Google Maps. Navigate yourself to this website, which plots lists of coordinates with ease and slap in your list. Guess it’s common sense that you need to press the big green button to get anywhere, eh? You’ll start with something like this:

Pretty straightforward, eh?

And you’ll end up with the final result which is shown below:

The final result!

Conclusion

So, we’ve managed to plot the coordinates of the photos taken with an Apple device – this allows us to further explore just how fascinating technology really is and how quickly it is evolving into something that may soon be beyond our control. Even though this probably won’t hold up by itself in a court of law, it could potentially be part of crucial evidence that can be used to prosecute a suspect. I hope you’ve learned something new from this tutorial and this is just the first of many steps of uncovering what else Apple has in store for us.

For more articles, visit our blog!

We would really appreciate it if you like us on Facebook.

Thanks for reading!

ABSTRACT:  This is a keywords searching tool working on the allocated, unallocated data and the slackspace, using an indexer software and a database storage .

Often during a computer forensics analysis we need to have all the keywords indexed into a database for making many searches on it in a fast way.

We could use strings and grep, for searching the keywords, but we cannot have a database and an engine, then we can’t search them inside many formats, like compressed files, including the ODT, DOCX, XLSX, etc..

So, I tried to solve this problem, first of all we need to extract, what I call “spaces”:

1)      Allocated space;

2)      Unallocated space;

3)      Slackspace;

Then we can run the indexer against these three spaces and we can extract all the keywords inside them.

We must remember that we have two kind of unallocated spaces, the first is all the deleted files and the second is all the files those are not in the deleted set, but they are still on the memory device (hard disk, pendrive, etc.).

For extracting these file we need to use the data carving technique, that consists into the search for the file types by their “magic numbers” (headers and footers), this technique is filesystem-less, so we can gather all files, allocated and unallocated (including the delete files too), so we need to eliminate duplication generated by carving.

The slackspace can be extracted by the TSK (The SleuthKit ) tools and put into a big text file, we have to remember that slackspace is all the file fragments present into the unused cluster space.

Inception

We have to create a directory named, for instance, “diskspace”.

We can mount our disk image file (bitstream, EWF, etc) into a sub-directory of diskspace, e.g. /diskspace/disk and so we can have all the allocated space.

Now, we have to extract all the deleted files including their paths and put them into “/diskspace/deleted”.

We have to run the data carving and put all the results into “/diskspace/carved”, we can use the data carving only on the freespace of the disk and then we must delete the duplicates with the deleted files.

Finally we can extract all the slackspace, if we need it and put it into “/diskspace/slack”.

Now we got:

/diskspace
|_disk
|_deleted
|_carved
|_slack

We only need a “spider” for indexing all these spaces and to collect all the keywords into a database.
For this purpose there is a program in the open source world: RECOLL that indexes a content of a directory and allows various quests. (http://www.lesbonscomptes.com/recoll/)

After the indexing we have all to perform our researches.

All these operations are made by my bash script called KS.sh  http://scripts4cf.sourceforge.net/tools.html

KS – This is a keywords searching tool. sudo bash ks.sh for running it. It mounts a DD image file; It extracts all deleted files; slackspace; It makes a data carving on the freespace only; It indexes all by RECOLL.
You need:
The Sleuthkit (last release)
Photorec
MD5Deep
RECOLL
It stores the index DB and the recoll.conf in the chosen output directory.
NEW file formats added and README.txt for the HowTo expand the search range.
Website:
http://scripts4cf.sourceforge.net/tools.html

This is the bash script code:

#!/bin/bash
#
# KS – by Nanni Bassetti – digitfor@gmail.com – http://www.nannibassetti.com
# release: 2.2
#
# It mounts a DD image file or a block device, it extracts all deleted files,
# it makes a data carving on the unallocated space, the it runs recoll
# changing automatically the variables in recoll.conf.
#
# many thanks to Raul Capriotti, Jean-Francois Dockes, Cristophe Grenier,
# Raffaele Colaianni, Gianni Amato, John Lehr, Alessandro Farina

echo -e “KS 2.2 – by Nanni Bassetti – digitfor@gmail.com – http://www.nannibassetti.com \n”
while :
do
echo -e “\nInsert the image file or the device (absolute path): “
read imm
[[ -f $imm || -b $imm ]] && break
done
while :
do
echo “Insert the output directory (absolute path):”
read outputdir
[[ "${outputdir:0:1}" = / ]] && {
[[ ! -d $outputdir ]] && mkdir $outputdir
break
}
done

(! mmls $imm 2>/dev/null 1>&2) && {
echo “0″
echo “The starting sector is ’0′”
so=0
} || {
mmls $imm
echo -e “\nChoose the starting sector of the partition you need to index”
read so
}

HASHES_FILE=$outpudir/hashes.txt # File output hash
DIR_DELETED=$outputdir/deleted # Deleted File’s Folder
DIR_SLACK=$outputdir/slackspace # Slackspace’s Folder
DIR_FREESPACE=$outputdir/freespace # Carved File’s Folder
BASE_IMG=$(basename $imm) # Basename of the image or device

[[ ! -d $outputdir/$BASE_IMG ]] && mkdir $outputdir/$BASE_IMG

off=$(( $so * 512 ))
mount -t auto -o ro,loop,offset=$off,umask=222 $imm $outputdir/$BASE_IMG >/dev/null 2>&1 && {
echo “Image file mounted in ‘$outputdir/$BASE_IMG’”
}

# recovering the deleted files
echo “recovering the deleted files…”
[[ ! -d $DIR_DELETED ]] && mkdir $DIR_DELETED
tsk_recover -o $so $imm $DIR_DELETED

# extracting slack space, comment if you don’t need it
echo “extracting slack space…”
[[ ! -d $DIR_SLACK ]] && mkdir $DIR_SLACK
blkls -s -o $so $imm > $DIR_SLACK/slackspace.txt

# freespace and carving

[[ ! -d $DIR_FREESPACE ]] && mkdir $DIR_FREESPACE || {
rm -R $DIR_FREESPACE
mkdir $DIR_FREESPACE
}

# using photorec to carve inside the freespace

photorec /d $DIR_FREESPACE/ /cmd $imm fileopt,everything,enable,freespace,search

# taking off duplicates from carving directory
echo “taking off duplicates from carving directory…”
[[ $(ls $DIR_DELETED) ]] && md5deep -r $DIR_DELETED/* > $HASHES_FILE
[[ $(ls $DIR_FREESPACE) ]] && md5deep -r $DIR_FREESPACE/* >> $HASHES_FILE
awk ‘x[$1]++ { FS = ” ” ; print $2 }’ $HASHES_FILE | xargs rm -rf
[[ -f $HASHES_FILE ]] && rm $HASHES_FILE

# RECOLL configuration to have a single recoll.conf and xapiandb for each case examined.
echo “RECOLL is indexing…”
rcldir=$outputdir/recoll
recollconf=/$rcldir/recoll.conf
mkdir -p $rcldir/xapiandb

cat > $recollconf << EOF
topdirs = $outputdir
dbdir = $rcldir/xapiandb
processbeaglequeue = 1
skippedPaths = $rcldir $rcldir/xapiandb
indexallfilenames = 1
textfilemaxmbs = -1 # for indexing txt files greater than 10Mb thanks to Alessandro Farina
usesystemfilecommand = 1
indexstemminglanguages = italian english spanish
EOF

recollindex -c $rcldir -z >/dev/null 2>&1
case $(tty) in
/dev/tty*) echo -e “\nStart on terminal from graphic interface the following command:”
echo -e “recoll -c $rcldir\n”
exit 1
;;
*) recoll -c $rcldir >/dev/null 2>&1 &
exit 0
;;
esac

1- RECOLL in action.

The RECOLL allow the search for keywords also working in compressed files and email attachments in short, once indexed all the content you had to be able to search for keywords or phrases, just as you would with Google.
As all the open source projects I have to thank to the collaboration of some friends  and developers.

Author
Nanni Bassetti, Digital Forensics Expert, C.A.IN.E. Linux forensic distro project manager, founder of CFI – Computer Forensics Italy, mailing list specialized in digital forensics topics, codeveloper of SFDumper and founder of the web site http://scripts4cf.sf.net.
Personal website: http://www.nannibassetti.com – e-mail: digitfor@gmail.com

Let’s consider a scenario:  in this case an armed forces staff member is on patrol. they take a picture of themselves and upload it to a social media. Their personal profile on this site is not secured or has limited access that allows anyone to view their photos. A militant group happens to be doing some research on their “enemy”. They use advanced search on Google then happen use the correct collection of words or phrases, and just happens to find this picture. What could possibly happen?

First off, the basics:

What is a geotag?

The method of geotagging is the addition of geographical data into the meta data of an object, in this case a picture that has been taken by armed services personnel.

A geotag on a photograph from an Iphone, for example, captures the GPS coordinates of the location it was taken using Longitude and Latitude.

Obtaining geotag information

Using free tools that are widely available on the internet it can take seconds to reveal the geotag information. It requires very little effort and absolutely no training. Ideal for militant groups who would want to find this information relatively quickly.

Below is an example and for this example I will be using a picture of the blue ball in snooker, but imagine this photo was a team photo taken in a base on foreign soil.

Here I’m using Evigator’s TAGView software

(available @ http://www.evigator.com/)

1 – Locate the image and open it using the Open Image Icon.

2 – Press Open

3 – The Image will be analysed and you will have a screen similar to below:

4 – Sample data from the analysed picture.

As you can see from the above, highlighted is the geotag data & various information about the device the picture was taken on. Also note the mapped location of where it was taken. To get this information was less than 3 seconds once loaded into the program. 

Security Risks & Repercussions

So what are the security risks? Well, as already pointed out the information could reveal any number of things: barracks, bases, patrol points or even patrol patterns. This information not only puts the staff member who uploads the pictures in danger but their entire deployment group.

Potential death is not the only issue, with profiles being insecure it could lead to that one member being profiled by the militant group, this then leading to potential blackmail, kidnap or endangering family members.

What should the armed forces be doing?

There are many things the armed forces could be doing. The key thing to do is offer the training necessary to remind their staff of the issues of geotags and smart phones. They could put a ban on any personal phones completely. However, some service men and woman would still find a way to take them into active duty.

A one hour basic training session that shows the dangers is all that is needed. The session could cover basic security settings of their social networking profiles and turning off the location services on any of their devices.

A one hour session could be the difference between life and death in most cases during deployment.

This article has been geared towards the idea of militant groups, however its not just militant groups, it could be anyone; stalkers, thieves, even an enraged ex could use these techniques.

Part 2 will be released soon. 

When I refer to embedded systems, I think of specialized devices, sometimes in a larger system or machine. Embedded systems usually have at least one microprocessor with dedicated program, and limited options to extract the information in a sound forensic way. Cell phones, smart phones, tablets, DVD and BluRay players, advanced digital watches, TVs, cars, elevators, and even washers & dryers can have embedded systems.

I would like to suggest a more structured way to represent data collection methods for such systems. As this is a work in progress, I look forward to constructive criticisms that can benefit the forensics community.

The classification is broken down into six methodologies.

1. Manual acquisition
2. Logical acquisition
3. Pseudo-physical acquisition
4. Support-port acquisition
5. Circuit read acquisition
6. Gate read acquisition

Each methodology has their shortcomings and benefits. I categorized these into four areas, and ranked them in a scale of 1 to 10, with one for “least” and 10 “most”.

Destructiveness is the impact on the target device, and how likely that everything is fully functional after data collection.

Technical & Training is the required understanding and education in the area required to attempt the methodology.

Cost is simply the expenses involved with the resources required, such as equipment, tools and consumables, to attempt the methodology.

Forensically Sound, the final measurement, is how likely the original data is modified, knowingly or not.

Acquisition Methodology Comparison

Manual

This is the oldest and least training and equipment required methodology. The examiner takes advantage of the devices display and user interface and a camera to record all relevant information, as much as possible. The target device may record all display and user interface activity, and update system data as normal housekeeping.

Example: Secure cell phone in holding bracket, then using the keypad scroll through all relevant items while taking pictures of the cell phone with an external camera. A commercial product used for this kind of acquisition is Paraben Project-A-Phone.

Logical

Logical acquisition method is where the device’s operating system (OS) is in full control of what can be accessed, and provides the method to transfer the data. The examiner connects the device to a forensic workstation, and using various software packages communicates with the OS on the target device. The OS may record the connection, and communication on the target device, and update system data as normal housekeeping.

Example: Connect cell phone’s external port to USB port, using proprietary cable. Run Software to initiate serial communication with device, and request information from device using proprietary and device specific commands. A software, such as BitPim would be used for this type of acquisition.

Pseudo-Physical

The process of pseudo-physical collection involves forcing program code onto the target device in some way which allows access to most data areas. The code may only provide access and takes advantage of the target device’s OS to provide communication, or is a complete replacement of the OS with just collection functionality. Thereafter, the examiner connects the device to a forensic workstation, and using various software packages communicates with the program code, or the OS on the target device. The OS may record the connection, and communication on the target device, and update system data as normal housekeeping. The forced-on code may also impact the information on the target device.

Although often touted as physical acquisition by almost all vendors, this process is not, in my opinion, truly physical as most forensics examiners expect it to be. Most forensics examiners think “bit-by-bit” when they hear “physical”. In my experience, this is not the case, as unallocated and slack areas of the storage are not collected.

Example: Target device is connected to the forensic workstation with a USB to proprietary serial cable. The target device is placed in Device Firmware Update (UDF) mode. The software on the forensic workstation at this time may load a special program code onto the target device. The code allows the software on the forensic workstation to access most information on the target device. Sometimes the target device’s UDF mode software provides the communication features.

Support-Port

Most mass produced electronic devices have ports for testing the electronics, or for updating firmware on various onboard integrated circuitry. These “ports” can be implemented as user accessible ports such as a USB, RS232 or even some pin and socket connector (Molex), non-user accessible ports including pin headers or insulation-displacement connector, and finally test connection pads that appear on the printed circuit assembly (PCA).

To access these ports, almost all small electronics require disassembly, often voiding the manufacturer’s warranty. Once the device is disassembled, the port must be identified on the PCA, and the specific communication protocol must also be found. Communication is established with the specific storage circuitry, and data is requested. This data is then stored for further analysis.

The most often used protocols are Boundary Scan (often referred to by the standardizing group name Joint Test Action Group [JTAG]), Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI), Enhanced Synchronous Serial Interface (ESSI), Controller Area Network (CAN), Local Interconnect Network (LIN), and Background Debug Mode (BDM).

Example: The target device is disassembled, and test access points (TAP) are located. Leads are soldered or clamped onto the TAP, and connected to a protocol specific universal asynchronous receiver/transmitter (UART). This device in turn is connected to a USB port of the forensic workstation. Specialized software using circuit-specific commands instructs the on-board device to download data from the circuit. The returned data is stored on the forensic workstation. No information is stored or written to the target device besides the temporary instructions.

Circuit Read

For this acquisition methodology, the integrated circuits (IC) such as memory chips are desoldered from the PCA and data is extracted using chip specific pin-out and communication. This is often referred to as “chip-off” process.

There are several critical points with this method, including the possibility to permanently damage the IC during desoldering, dealing with stacked ICs (3D packaging) or monolithic configuration.

In this particular method, the IC is removed, socketed or soldered, and specific signals are sent to extract the data from the specific chip, using specialized software.

Example: The target device is disassembled, and data storage ICs are located. Pin out information, and timing details for communication with the IC is researched. Target device is preheated, and then the specific ICs are desoldered. The ICs are either placed in temporary sockets, or leads are soldered to appropriate pins. The socket or leads are connected to a communication device using proper communication protocol, such as a Transistor-Transistor Logic (TTL), which in turn is connected to the forensics workstation.

Specialized software using IC-specific commands instructs the socket to download data from the IC. The returned data is stored on the forensic workstation. No information is stored or written to the target IC.

Gate Read

This methodology requires both equipment, and chemicals that are usually not found in most digital forensics labs. The process involves the removal of the target IC in similar fashion as the Circuit Read acquisition methodology. Instead of attempting to communicate with the IC through electronic signals, the chip is literally sliced into multiple layers, to expose each original semiconductor lithographic layer, and information is reverse engineered from the layers.

The layers are measured in nanometers (1 x 10-9 m) or a billionth of a meter. Each layer is removed, photographed, and then reverse engineered from the photograph. The process is as much guess work as it is a very high level understanding of IC internals and IC lithography. The process works best with planarized chips. The steps of the process are device depoting or package removal, delayering, imaging, annotation, schematic, organization and finally analysis.

Example: The target device is disassembled, and data storage ICs are located. Pin out information for the IC is researched. Target device is preheated, and then the specific ICs are desoldered. The IC is bathed in chemicals to remove potting, or encasing. At this point, the only remaining items are the leads to a piece of silicon die. The leads are noted and photographed. The die using lapping (or other very precise slicing or abrasion method) removes each layer, and photographed. The layers are stacked in software, and reverse engineered using the shape, color density and interconnection of the layers. This process requires identification amongst other things the N-type, P-type silicon, the gates, power and ground.

Reference:

Rankings are on a scale of 1 to 10, with one for “least” and 10 “most”. Ex. Most destructive would be a 10; Least costly would be a 1.

File and directory timestamps are one of the resources forensic analysts use for determining when something happened, or in what particular order a sequence of events took place. As these timestamps usually are stored in some internal format, additional software is needed to interpret them and translate them into a format an analyst can easily understand. If there are any errors in this step, the result will clearly be less reliable than expected.

My primary purpose this article is to present a simple design of test data suitable for determining if there are errors or problems in how a particular tool performs these operations. I will also some present some test results from applying the tests to different tools.

For the moment, I am concerned only with NTFS file timestamps. NTFS is probably the most common source of timestamps that an analyst will have to deal with, so it is important to ensure that timestamp translation is correct.  Similar tests need to be created and performed for other timestamp formats.

Also, I am ignoring time zone adjustments and daylight savings time: the translation to be examined will cover Universal Coordinated Time (UTC) only.

Background Information

NTFS file timestamps, according to the documentation of the ‘FILETIME’ data structure in the Windows Software Development Toolkit, is a  “64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)”.

Conversion from this internal format to a format more suitable for human interpretation is performed  by the Windows system call FileTimeToSystemTime(), which extracts the year, month, day, hour, minutes, seconds and milliseconds from the timestamp data. On other platforms (e.g. Unix), or in software that is intentionally platform-independent (e.g. Perl or Java) other methods for translation is be  required.

The documentation of FileTimeToSystemTime(), as well as practical tests,  indicate that the FILETIME value to be translated must be 0x7FFFFFFFFFFFFFFF or less.  This corresponds to the time 30828-09-14 02:48:05.4775807.

File timestamps are usually determined by the system clock at the time some file activity was performed. It is, though, also possible to set file time stamps to arbitrary values.  On Vista and later, the system call SetFileInformationByHandle() can be used; on earlier versions of Windows, NtSetInfomationFile() may be used. No special user privileges are required.

These system calls have a similar limitation in that only timestamps less than or equal to 0x7fffffffffffffff will be set.  Additionally, the two timestamp values 0×0 and 0xffffffffffffffff are reserved to modify the operation of the system call in different ways.

The reverse function, SystemTimeToFileTime(), performs the opposite conversion: translating a time expressed as the year, month, day, hours, minutes, seconds, etc into the 64-bit file time stamp. In this case, however, the span of time is restricted to years less than or equal to 30827.

Requirements

 Before any serious testing is done, some kind of baseline requirements need to be established.

1. Tests will be performed mainly by humans, not by computers. The number of test points in each case must not be so large as to overwhelm the tester. A maximum limit around 100 test points seems  reasonable.  Tests designed to be scored by computer would allow for more comprehensive tests, but would also need to be specially adapted to each tool being tested.
2. The currently known time range (0×0 to 0x7FFFFFFFFFFFFFFF)  should be supported. If the translation method does not cover the entire range, it should report out-of-range times clearly and unambiguously.That is, there must be no risk for misinterpretation, either by the analyst or by readers of any tool-produced reports. A total absence of translation is not quite acceptable on its own — it requires special information or training to interpret, and the risk for misinterpretation appears fairly high. A single ‘?’  is better, but if there are multiple reasons why a ‘?’ may be used, additional details should be provided.
3.  The translation of a timestamp must be accurate, within the limits of the chosen representation.We don’t want a timestamp translated into a string become a very different time when translated back again.  The largest difference we tolerate is related to the precision in the display format: if the translation doesn’t report time to a greater precision than a second, the tolerable error is half a second (assuming rounding to nearest second) or up to one second (assuming truncation)  If the precision is milliseconds, then the tolerable error is on the corresponding order.

TEST DESIGN 

Test 1: Coverage

 The first test is a simple coverage test: what period of time is covered by the translation? The baseline is taken to be the full period covered by the system call FileTimeToSystemTime(), i.e. from 1601-01-01 up to 30828-09-14.

The first subtest checks the coverage over the entire baseline. In order to do that, and also keep the number of point tests reasonably small, each millennium is represented by a file, named after the first year of the period, the timestamps of which are set to the extreme timestamps within that millennium. For example, the period 2000-2999 is tested (very roughly, admittedly) by a single file, called ‘02000’, with timestamps representing 2000-01-01 00:00:00.0000000 and 2999-12-31 23:59:59.9999999 as the two extreme values (Tmin and Tmax for the period being tested).

The second subtest makes the same type of test, only it checks each separate century in the period 1600 — 8000. (There is no particular reason for choosing 8000 as the ending year.)

The third subtest makes the same type of test, only it checks each separate year in the period 1601 — 2399. In these tests, Tmin and Tmax are the starting and ending times of each single year.

The fourth subtest examines the behaviour of the translation function at some selected cut-off points in greater detail.

These tests could easily be extended to cover the entire baseline time period, but this makes them less suitable for manual inspection: the number of points to be checked will become unmanageable for ‘manual’ testing.

Test 2: Leap Years

The translation must take leap days into account. This is a small test, though not unimportant.

The tests involve checking the 14-day period ‘around’ February 28th/29th for presence of leap day, as well as discontinuities.

Two leap year tests are provided: ‘simple’ leap years (2004 – year evenly divisible by 4), and ‘exceptional’ leap years (2000 – year even divisible by 400).

Four non-leap tests: three for ‘normal’ non-leap years (2001, 2002, 2003) and one ‘exceptional’ non-leap tear (1900 — year is divisible by 100).

More extensive tests can easily be created, but again the number of required tests would  surpass the limits of about 100 specified in the requirements.

It is not entirely clear if leap days always are/were inserted after February 28th in the UTC calendar: if they are/were inserted after February 23th, additional tests may be required for the case the time stamp translation includes the day of the week. Alternatively, such tests should only be performed in timezones for which this information is known.

Tests 3: Rounding

This group of tests examines how the translation software handles limited precision. For example, assume that we have a timestamp corresponding to the time 00:00:00.6, and that it is translated into textual form that does not provide sub-second precision.  How is the .6 second handled?  Is it chopped off (truncated), producing a time of ’00:00:00′?  Or is it rounded upwards to the nearest second: ’00:00:01′?

In the extreme case, the translated string may end up in another year (or even millennium) than the original timestamp. Consider the timestamp 1999-12-31 23:59:59.6: will the translation say ’1999-12-31 23:59:59′ or will it say ’2000-01-01 00:00:00′? This is not an error in and by itself, but an analyst who does not expect this behaviour may be confused by it.  If he works after an instruction to ‘look for files modified up the end of the year’, there is a small probability that files modified at the very turn of the year may be omitted because they are presented as belonging to the following year. If that is a real problem or not will depend on the actual investigation, and if and how such time limit effects are handled by the analyst.

These tests are split into four subgroups, testing rounding to minutes, seconds, milliseconds and microseconds, respectively.  For each group, two directories corresponding to the main unit are created, one for an even unit, the other for an odd unit. (The ‘rounding to minutes’ test use 2001-01-01 00:00 and 00:01. In each of these directories files are created for the full range of the test (0-60, in the case of minutes), and timestamped according to the Tmin/Tmax convention already mentioned.

If the translation rounds upwards, or round to nearest even or odd unit, this will be possible to identify from this test data. More complex rounding schemes may not be possible to identify.

Tests 4: Sorting

These tests are somewhat related to the rounding test, in that the test examines how the limited precision of a timestamp translation affects sorting a number of timestamps into ascending order.

For example, a translation scheme that only includes minutes but not seconds, and sorts these events by the translation string only will  not clearly produce a sorted order that follows the actual sequence of events.

Take the two file timestamps 00:00:01 (FILE1) and 00:00:31 (FILE2).  If the translation truncates timestamps to minutes, both times will be shown as ’00:00’.  If they are then sorted into ascending order by that string, the analyst cannot decide of FILE1 was timestamped before FILE2 or vice versa.  And if such a sorted list appears in a report, a reader may draw the wrong conclusions from it.

The tests are subdivided into sorting by seconds, milliseconds, microseconds and nanoseconds respectively. Each subtest provides 60, 100 or 10 files with timestamps arranged in four different sorting order. The name of these files have been arranged in an additional order to avoid the situation where files already sorted by file names are not rearranged by a sorting operation.  Finally, the files are created in random order.

The files are named on the following pattern: <nn>_C<nn>_A<nn>_W<nn>_M<nn>, e.g. ’01_C02_A07_W01_M66′.

Each letter indicates a timestamp field (C = created, A = last accessed, W = last written, M = last modified), with <nn> indicating the particular position in the sorted sequence that timestamp is expected to appear in. The initial <nn> adds a fifth sorting order (by name), which allows for the tester to ‘reset’ to a sorting order that is not related to timestamps.

Each timestamp differs only in the corresponding subunit: the files in the ‘sort by seconds’ have timestamps that have the same time, except for the second part, and the ‘sort by nanoseconds’ files differ only in the nanosecond information. (As the timestamp only accommodates 10 separate sub-microsecond values, only 10 files are provided for this test.)

The test consists in sorting each set of files by each of the timestamp fields: if sorting is done by the particular subunit (second, millisecond, etc.) the corresponding part of the file name will appear in sorted order.  Thus, an attempt to sort by creation time in ascending order should produce a sequence in which the C-sequence in the file name also appears in order: C00, C01, C02, … etc, and no other sequence should be the same ascending order.

An implementation with limited precision in the translated string, but that sorts according to the timestamp values will sort perfectly also when sorting by nanoseconds is tested.  If the sort is by the translated string, sorting will be perfect up to that smallest unit (typically seconds), and further attempts to sort by smaller units (milliseconds or microseconds) will not produce a correct order.

If an implementation that sorts by translated string also rounds timestamps, this will have additional effects on the sorting order.

Tests 5: Special tests

In this part, additional timestamps are provided for test.  Some of these cannot be created by the documented system calls, and need to be created by other methods.

0x00FFFFFFFFFFFFFF
0x01FFFFFFFFFFFFFF
0x03FFFFFFFFFFFFFF
…
0x7FFFFFFFFFFFFFFF

These timestamp can be set by the system calls, and may not have been tested by other test.

0×0000000000000000

This timestamp should translate to 1601-01-01 00:00:00.0000000, but it cannot be set by any of the system calls tested.

0×8000000000000000
0xFFFFFFFE00000000
0xFFFFFFFF00000000
0xFFFFFFFFFFFFFFFE
0xFFFFFFFFFFFFFFFF

These timestamps cannot be set by system call, and need to be edited by hand prior to testing.

These values test how the translation mechanism copes with timestamps that produce error messages from the FileTimeToSystemTime() call.

Other tests

TZ & DST — Time zone and daylight saving time adjustments are closely related to timestamp translation, but are notionally performed as a second step, once the UTC translation is finished. For that reason, no such tests are included here: until it is reasonably clear that UTC translation is done correctly, there seems little point in testing additional adjustments.

Leap seconds — The NTFS timestamp convention is based on UTC, but ignores leap seconds, which are included in UTC. For a very strict test that the translation mechanism does not take leap seconds into account, additional tests are required, probably on the same pattern as the tests for leap years, but at a resolution of seconds.

However, if leap seconds have been included in the translation mechanism, it should be visible in the coverage tests, where the dates from 1972 onwards would gradually drift out of synchronization (at the time of writing, 2013, the difference would be 25 seconds).

Day of week — No tests of day-of-week translation are included.

Additional Notes

 A Windows program that creates an NTFS structure corresponding to the tests described has been written, and used to create a NTFS image.  The Special tests directory in this image have been manually altered to contain the timestamps discussed. Both the source code and the image file is (or will very shortly be) available from SourceForge as part of the ‘CompForTest’ project.

It must be stressed that the tests described should not be used to ‘prove’ that some particular timestamp translation works as it should: all the test results can be used for is to show that it doesn’t work as expected.

TEST RESULTS

As the test image was being developed different tools for examination of NTFS timestamps were tried out. Some of the results (such as incomplete coverage) was used to create additional tests.

Below, some of the more interesting test results are described.

It should be noted that there may be additional problems that affect the testing process.  In one tool test (not included here), it was discovered that the tool occasionally did not report the last few files written to a directory. If this kind of problem is present also in other tools, tests results may be incomplete.

Notes on rounding and sorting have been added only if rounding has been detected, or if sorting is done by a different resolution than the translated timestamp.

Autopsy 3.0.4:

Timestamp range:

1970-01-01 00:00:01 –  2106-02-07 06:28:00
1970-01-01 00:00:00.0000000 is translated as ’0000-00-00 00:00:00′

Timestamps outside the specified range are translated as if they were inside the range (e.g. timestamps for some periods in 1673, 1809, 1945, 2149, 2285, etc. are translated as times in 2013. This makes it difficult for an analyst to rely only on this version of Autopsy for accurate time translation.

In the screen dump below, note that the 1965-1969 timestamps are translated as if they were from 2032-2036.

EnCase Forensic 6.19.6:

Timestamp range:

1970-01-01 13:00 — 2038-01-19 03:14:06
1970-01-01 00:00 — 12:00 are translated as ” (empty). The period 12:00 — 13:00 has not been investigated further.

Remaining timestamps outside the specified ranges are also translated as ” (empty).

The screen dump below show  the hours view of the cut-off date 1970-01-01 00:00.The file names indicate the offset from the baseline timestamps, HH+12 indicating an offset of +12 hours to 00:00. It is clear that from HH+13, translation appears to work as expected, but for the first 13 hours (00 — 12), no translation is provided, at least not for these test points.

ProDiscover Basic 6.5.0.0:

Timestamp range:

1970-01-02 — 2038, 2107 — 2174, 2242 — 2310, 2378 — 2399 (all ranges examined)

 Timestamps prior to  1970-01-02, and sometime after 3000, are uniformly translated as 1970-01-01 00:00, making it impossible to determine actual time for these ranges.

Timestamps after 2038, and outside stated range are translated as ‘(unknown)’.

Translation truncates to minutes.

The following screen dump shows both the uniform translation of early timestamps as 1970-01-01, as well as the ‘(unknown)’ and the reappearance of translation in the 2300-period. (The directories have also been timestamped with the minimum and maximum times of the files placed in them.)

WinHex 16.6 SR-4:

Timestamp range:

1601-01-01 00:00:01 — 2286-01-09 23:30:11.
1601:01:01 00:00:00.0000000 and .00000001 are translated as ” (blank).

Timestamps after 2286-01-09 23:30:11 are translated partly as ‘?’, partly as times in the specified range, the latter indicated in red. The cut-off time 30828-09-14 02:48:05 is translated as ” (blank).

Additional Tests

Two additional tests on tools not intended primarily for forensic analysis were also performed: Windows Explorer GUI and PowerShell command line. Neither of these provide for additional time zone adjustment: their use will be governed by the current time configuration of the operating system. In the test below, the computer was reset to UTC time zone prior to testing.

 PowerShell

Timestamp range:

1601-01-01 00:00:00 –  9999-12-31 23:59:59

 Timestamps outside the range are translated as blank.

Sorting is by timestamp binary value.

The command line used for these examination was:

 Get-ChildItem path | Select-Object name,creationtime,lastwritetime

for each directory that was examined. Sorting was tested by using

 Get-ChildItem path | Select-Object name,creationtime,lastwritetime,lastaccesstime | Sort timefield

The image below shows sorting by LastWriteTime and nanoseconds (or more exactly tenths of microseconds).  Note that the Wnn specifications in the file names appear in the correct ascending order :

Windows Explorer GUI:

Timestamp range:

1980-01-01 00:00:00 — 2107-12-31 23:59:57
2107-12-31 23:59:58 and :59 are shown as ” (blank)

  Remaining timestamps outside the range are translated as ” (blank) .

It must be noted that the timestamp range only refers to the times shown in the GUI list.  When the timestamp of an individual file is examined in the file property dialog (see below),  the coverage appears to be full range of years.

Additionally, the translation on at least one system appears to be off by a few seconds, as the end of the time range shows. Additional testing is required to say if this happens also on other Windows platforms.

However, when the file ’119 – SS+59′ is examined by the Properties dialog, the translation is as expected. (A little too late for correction I see that the date format here is in Swedish — I hope it’s clear anyway.)

Interpretation of results

 In terms of coverage, none of the tools presented above is perfect: all are affected by some kind of restriction to the time period they translate correctly. The tools that comes off best are, in order of the time range they support:

PowerShell 1.0  (1601–9999)
Windows Explorer GUI (1980–2107)
EnCase 6.19 (1970–2038)

 Each of these restricts translations to a subset of the full range, and shows remaining timestamps as blank.  PowerShell additionally sorts by the full binary timestamp value, rather than the time string actually shown.

The Windows Explorer GUI also appears to suffer from an two-second error: the last second of a minute, as well as parts of the immediately preceding second are translated as being the following minute.  This affects the result, but as this is not a forensic tool it has been discounted.

The tools that come off worst are:

Autopsy 3.0.4
ProDiscover Basic 6.5.0.0
WinHex 16.6 SR-4

Each of these show unacceptably large errors between all or some file time stamps and their translation. ProDiscover comes off only slightly better in that timestamps up to 1970 are all translated as 1970-01-01, and so can be identified as suspicious, but at the other end of the spectrum, the translation error is still approximately the same as for Autopsy: translations are more than 25000 years out of register. WinHex suffers from similar problems: while it flags several ranges of timestamps as ‘?’, it still translates many timestamps totally wrong.

It should be noted that there are later releases of both Autopsy and ProDiscover Basic that have not been tested.

It should probably also be noted that additional tools have been tested, but that the results are not ‘more interesting’ that those presented here.

How to live with a non-perfect tool?

1. Identify if and to what extent some particular forensic tool suffers from the limitations described above: does it have any documented or otherwise discoverable restrictions on the time period it can translate, and does it indicate out-of-range timestamps clearly and unambiguously, or does it translate more than one timestamp into the same date/time string?
2. Evaluate to what extent any shortcomings can affect the result of an investigation, in general as well as in particular, and also to what extent already existing lab practices mitigate such problems.
3. Devise and implement additional safeguards or mitigating actions in the case where investigations are significantly affected .

These steps could also be important to document in investigation reports.

In daily practice, the range of timestamps is likely to fall within the 1970–2038 range that most tools cover correctly — the remaining problem would be if any outside timestamps appeared in the material, and the extent to which they are recognized as such and handled correctly by the analyst.

The traditional advice, “always use two different tools” turns out to be less than useful here, unless we know the strengths and weaknesses of each of the tools.  If they happen to share the same timestamp range, we may not get significantly more trustworthy information from using both than we get from using only one.

A. Thulin
(anders@thulin.name)

The artefacts discussed in this post are based on Windows 7, however Apple Mac operating systems retain similar data in plists (property lists).

By default data from a user’s Google Drive is stored at C:\Users\USERNAME\Google Drive. In addition to this, there are nuggets of information and data stored on a user’s PC.

If we inspect the following location of the Windows registry we are able to learn a lot more about a particular Google Drive setup on a PC and we are also able to confirm the Google Drive product is indeed installed to that PC, by virtue of this key: 
KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products \227C12A7952F67947BAA66855EDFDEFA\InstallProperties

Within this key we can gather a range of information including when Google Drive was first installed, which is a simple date value in the format YYYYMMDD. In addition to this are version numbers and display names.

As you would expect, there is an entry at HKEY_CURRENT_USER\Software\Google\Drive, but there is little stored here.

Staying within the Windows registry by examining the ‘Run Key’ (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run)  we can confirm if Google Drive is set to autorun on startup, which is the default.

The first registry entry I spoke of in this post
(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\ 227C12A7952F67947BAA66855EDFDEFA\InstallProperties) contains a long string of characters (GUID) and does not actually mention or refer to Google. In my testing I have found the GUID of 227C12A7952F67947BAA66855EDFDEFA is consistent with all Google Drive installations on Windows, therefore searching for this GUID should identify the location of Google Drive data in the registry.

Stepping out of the registry, there is a great deal of data that can be found within the user profile of a user with Google Drive installed in addition to the Google Drive files themselves.

If the path C:\Users\USERNAME\ AppData\Local\Google\Drive exists a few SQLite databases and further settings files can be inspected.

First we have a file called ‘pid’. Inside this file is a number, which is the Windows process ID relating to the Google Drive application. However the really interesting data is within the SQLite database files here.

The smaller of the 2 databases is ‘sync_config.db’ and this amongst other information contains the registered Google Drive account/email address and the location of Google Drive files – which by default is C:\Users\USERNAME\Google Drive.

The larger database is ‘snapshot.db’ and contained within it are several tables holding very valuable information. Each file currently stored and not deleted from Google Drive has corresponding entries in the ‘snapshot.db’ database. These entries detail creation and modification dates in unix epoch format (number of seconds elapsed since midnight (UTC) on 1^st January 1970).

The file names and the link to the files within Google Drive’s web store, which when accessed require the username and password to be provided. Other database entries include a file type, which is referenced by a number instead of the actual file type. There is also an MD5 hash value, which I believe Google use to check for differences in the data during a sync.

If data is deleted from a user’s Google Drive, some interesting things happen. A file deleted from the local Google Drive folder (C:\Users\USERNAME\Google Drive) makes no changes to the ‘snapshot.db’ content, until the Google Drive application is running. Therefore the entry for the deleted file will remain in the database until the Google Drive application is next enabled and synchronised at such time the entry is deleted from the database. Even if this has happened, the information is still potentially retrievable – I have had success recovering these deleted entries from unallocated space.

Deletion of data via the Google Drive web interface is different again. Much like a Windows operating system (or Mac and others for that matter), when you delete a file, it moves to the ‘Bin’ within the Google web interface and remains here until it is restored or further deleted and permanently removed.

As soon as a file is deleted and moved to the ‘Bin’ and a this action is synchronised  with the local installation of Google Drive and the entry for that file in the ‘snapshot.db’ is removed from the database.

Switching back to the web interface, despite the deleted file being in the ‘Bin’ users can still work on the file via the web interface and they can also restore it back as a live file. During such time and actions the revision history is not lost.

Once the file is restored and Google drive is synchronised with a local Google Drive client again the entry for that file is added back to the ‘snapshot.db’ complete with the original metadata and importantly the original creation date.

It is important to highlight that the metadata stored within the ‘snapshot.db’ is by far the most accurate and reliable.

In contrast, the metadata of the physical files stored in Google Drive accessed by a right-click and properties action is unreliable.

Take the scenario outlined previous where we have deleted a file and restored it back the creation date shown on the Windows properties will be the date the file was synchronised back from Google Drive. The ‘snapshot.db’ however shows the true creation date, which is when the file was first created before the actions of delete and restore.

We know that the presence of a Google Drive has the potential to assist and our eDiscovery and forensic work provided there is a solid understanding of how it operates and how the data can be captured and interrogated.

What are the practicalities and considerations when working with such data? In my first post I highlighted the need to understand Google Drive data and that native Google file types are little more than placeholders to file content stored within Google Drive servers.

What one also needs to appreciate is the importance of the structured databases generated by Google Drive. It is this structured data where we can recover a host of information about the files within Google Drive – the true metadata if you will.

In terms of approach – because Google Drive can be accessed via the Internet is it essential that in forensic and eDiscovery matters one considers both securing and isolating access to such data immediately. This should include removing network connectivity from computers and/or mobile devices to disable further synchronisations of the data. If this was not done and an individual deleted data from the Google web interface, these changes would occur on computers and/or mobile devices.

One should also revisit the point that an individual can in theory delete permanently data from Google Drive via the web interface. As a result that data must be secured quickly and where possible a legal hold put in place to prevent such data being deleted. You  cannot afford to wait or ignore this issue and should try whenever possible to collect data from Google Drive immediately (unless it is not considered to be within scope).

The presence of Google Drive placeholders on computers and/or mobile devices mean there is further work to do in terms of data capture and this work must be performed via the web interface. The Google Drive web interface allows users to download any file or a collection of files locally in a variety of different formats.

One should endeavour to download such data in as close to native format as possible for example a gdoc file as a docx file.

There are several issues to consider when downloading data direct from Google Drive’s web interface including:

1. the question of gaining access with the username and password
2. jurisdictional considerations,
3. the potential for loss of metadata.

As a consequence best practice will be to capture and preserve both Google Drive files AND the Google drive structured databases so as to give as full a picture as possible.

Make sure you keep an eye on the Millnet blog for further updates.

For a number of years Google have offered online solutions for creating, editing and publishing a range of files including Word and Excel. More recently this service has linked into Google Drive, which offers more functionality, but also allows users to synchronise data across various devices. An individual with a Google Drive account is allocated 5Gb of free data storage and can obtain further storage at a cost.

Google Drive supports many of the file types and formats we work with every day including docx, xlsx and pptx. However, any user who creates a new file for example a word processing file via the Google drive website will by default generate a file with an extension of .gdoc (.gslides for a presentation and .gsheet for a spreadsheet). These file types are Google formatted files and are synchronised across all devices running Google Drive.

Running Google drive on a standard Windows PC, by default creates a folder within the user profile. On a Windows 7 PC the Google drive data is stored in the following path C:\Users\USERNAME\Google Drive. Google drive will quite robustly deal with maintaining and synchronising the data as changes are made and a successful synchronisation of the data is indicated by a small green tick and an out of date synchronisation by blue arrows, as shown below.

By virtue of the gdoc file being created on a PC during the synchronisation process it generates and maintains its own metadata on the PC. By right clicking on the gdoc file and viewing properties you see the usual dates and times (created, modified and accessed).

As you would expect the created date reflects the time the file was first created and successfully synchronised on the PC.

The important point to note is if a file is created via the Google website at 1200 on 1^st January 2013, but the PC with Google drive installed is not connected to the internet until 1630 on 10^th January 2013, then the creation date of the gdoc file on the PC will show 1630 on 10^th January 2013 – because this was the when the PC sync’d with the Google Drive website. The modification and accessed dates update as you would expect, with the same limitations associated with the created date.

The valuable metadata is stored on the Google drive servers, however this presents us with a challenge:

1. how do we gain access to the account?
2. and how do we get the metadata out?

One important piece of metadata maintained by Google is the revision history.

The revision history is a cross between “track changes” and a backup solution, where Google “snapshots” the data when changes are made and so as to permit users to jump back to any version of the file, prior to those changes having been made, at the click of a button.

This means that it is possible to see what a document looked like several days ago after a number of changes to the content have been made. This is fantastic information, however it is not readily available to download or capture in an offline form.

Instead, this data can only be captured by communicating with the Google Drive using its own coding API. This is tricky and a challenge, nevertheless with the appropriate programming skills the revision history data can be captured.

If we take a deeper look at the gdoc file which is created on a PC we notice it is tiny and only 1Kb in size. The reason for this is because the content of the actual file is not stored on your PC. The gdoc file is nothing more than a pointer to the data on the Google Drive Server.

If we look inside the gdoc file it contains a URL which itself is a unique reference to the data on the Google Drive systems and only those with appropriate account credentials can view the data. This is true of gslides  and gsheet files also.

There are important considerations when dealing with Google formatted data including documents, spreadsheets and presentations.

• First; forensically imaging PCs with Google Drive installed and Google formatted files stored on the PC is an incomplete exercise because, although the PC holds pointers to data held on the Google server, it does not hold the actual data.
• Second, there is a huge amount of valuable information stored on Google drive about files, in particular the revision history. Where Google Drive is in use, efforts should be made to harvest this data with a view to building, if necessary, a more detailed picture of the evolution of the file.

For clarity, I should add that files in a non-Google format that are stored in a user’s Google Drive are synchronised and stored in full on users PCs: they do not adopt the same pointer system that is utilised by Google formatted files.

Keep an eye on our blog page for future posts relating to this topic

Hard drives are built in a way so that they never return unreliable data. This means that if a hard drive cannot guarantee 100 percent accuracy of the data requested, it will simply return an error and will never give away any data at all.

This article explains how bad sector recovery actually works and why it needs to be done with great caution.

Understanding Bad Sectors

General causes of bad sector formation are physical or magnetic corruption. Physical corruption is easy to understand—it occurs when there is physical damage done to the media surface. Magnetic corruption occurs when a hard drive miswrites data to a wrong location. While the latter may seem to be less damaging, it is actually as dangerous as physical damage, as miswritten data may damage not only adjacent sectors but also servo sectors.

Regardless of the cause of damage, there are several possible outcomes:

• Address Mark field corruption
• Data corruption
• ECC field corruption
• Servo sector corruption
• Or any combination of these

What is common in all these types of corruption is that your operating system or normal data recovery tools cannot read the data from those sectors anymore.

Let’s find out exactly what happens when a tool tries to read a sector that has one of the above-mentioned problems.

Address Mark corruption

When Address Mark is corrupted, the hard drive simply cannot find the requested sector. The data might still be intact, but there is no way for the hard drive to locate it without the proper ID. Some modern hard drives do not actually use sector ID or Address Mark in the sector itself; instead, this information is encoded in the preceding servo sector.

Data corruption

To verify data integrity, a hard drive will always validate it with the error checking and correction algorithm using the ECC code written after the data field (see above diagram). When data is corrupted, the hard drive will try to recover it with the same ECC algorithm. If correction succeeds, the drive will return the sector data and will not report any error. However, if correction fails, the drive will only return an error and no data, even if the data is partially intact.

ECC field corruption

Although this is rare, the ECC code can also get corrupted. In this case, the drive reads perfectly good data from the sector and checks its integrity against the ECC code. The check fails due to the bad ECC code, and the drive returns an error and no data at all, because there is no way to verify data integrity.

Servo sector corruption

There are up to a few hundred servo sectors on a single track. Servo sectors contain positioning information that allows the hard drive to fine-tune the exact position of the head so that it stays precisely on track. They also contain the ID of the track itself.

Servo sectors are used for head positioning in the same way a GPS receiver uses satellites—to exactly determine the current location. When a servo sector is damaged, the hard drive can no longer ensure that the data sectors following the servo sector are the ones it is looking for and will abort any read attempt of the corresponding sectors.

How Bad Sector Recovery Works

Once again, hard drives are built to never return data that did not pass integrity checks.

However, it is possible to send a special command to the hard drive that specifically instructs it to disable error checking and correction algorithms while reading data. The command is called Read Long and was introduced into ATA/ATAPI standard since its first release back in 1994. It allowed reading the raw data + ECC field from a sector and returning it to the host PC as is, without any error checking or correction attempt. The command was dropped from the ATA/ATAPI-4 standard in 1998; however, most hard drive manufacturers kept supporting it.

Later on, when hard drives became larger in capacity and LBA48 was introduced to accommodate drives larger than 128 GiB, the command was officially revived in a SMART extension called SMART Command Transport or SCT.

Obviously, since the drive does not have to verify the integrity of data when the data is requested via the Read Long command, it would return the data even if it is inconsistent (or, in other words, the sector is “Bad”). Hence, this command quickly became standard in bad sector recovery.

There is also another approach which is based on the fact that some hard drives leave some data in the buffer when a bad sector is encountered. However, our tests have shown that chances of getting any valid data this way are exactly zero.

Debunking Bad Sector Recovery

So to “recover” data from a bad sector, one would simply need to issue the Read Long command instead of the “normal” Read Sectors command. That is really it! It is so simple any software developer who is familiar with hard drives can do it. And sure enough, more and more data recovery tools now come with a Bad Sector Recovery option. In fact, it has come to the point where if a tool does not have a bad sector recovery feature, it automatically falls into a second-grade category.

Error checking and correction algorithms were implemented for a reason, which is data integrity. When a hard drive reads a sector with the Read Long command, it disables these algorithms and hence there is no way to prove that you get valid data. Instead, you get something, which may or may not resemble your customer’s data.

Tests in our lab had shown that, in reality, by using this approach, you will get much more random bytes than anything else. Yes, there are cases where this approach allows recovering original data from a sector, but these cases are extremely rare in real data recovery scenarios, and even then, only a part of the recovered sector will contain valid data.

Even when we got some data off the damaged sector, what exactly should we do with its other (garbled) part? And how exactly do we tell which part of the sector has real data in it and which is just random bytes? Nobody is going to manually go through all the sectors in a HEX editor and judge which bit is valid and which is not. Even if someone did, there is no way to guarantee that what they see is valid data.

And this is where the real problem starts.

Dangers of Read Long approach

Imagine a forensic investigator recovering data off a suspect’s drive while the drive has some bad sectors on it. To get more data off the drive, the investigator enabled Bad Sector Recovery option in his data acquisition tool. In the end, his tool happily reported that all the sectors were successfully copied, so he began extracting data from the obtained copy.

While looking for clues, he found a file that had social security numbers in it. He then used these numbers in one way or another for his investigation.

What he did not know is that one of the sectors that contained these numbers was recovered via the Read Long command, and some bits were flipped (which is very common for this approach). So instead of 777-677-766, he got 776-676-677, causing him and other people a whole lot of unnecessary trouble.

Another example: when recovering a damaged file system, even slightly altered data in an MFT record can mislead the file recovery algorithm and in the end do much more harm than if there was no data copied at all in that sector.

Once again, an error checking and correction algorithm is in place for a great reason. There is absolutely no magic in bad sector recovery; it is impossible to recover something that just isn’t there.

There are tools that claim better bad sector recovery because they utilize a statistical approach, an algorithm where the tool reads the bad sector a number of times and then reconstructs the “original” sector by locating the bits that occur most often in the sector. While these tools claim this approach could improve the outcome, there is no evidence to back up the validity of such claims. Furthermore, rereading the same spot many times while the hard drive is failing is a good way to cause permanent damage to the media or heads.

To summarize, if you are after valid data, avoid using any bad sector recovery algorithms. These algorithms will never offer data integrity no matter how complex their implementation is. And when you absolutely must recover data from bad sectors, make sure you use a tool that properly accounts for these recovered sectors, marking the files containing such sectors. This way, the operator has the ability to disregard such “unreliable” files and manually verify file integrity if it is an important one.

Dmitry Postrigan is the founder and CEO of Atola Technology, a Canadian company that makes high-end data recovery and forensic equipment.

Windows is the most used operating system worldwide. I have met a lot of IT guys in my country and also other computer elites. My discovery was that 90 percent of them use Windows. I felt maybe that was just in my country, then I decided to contact some friends from UK, USA, India, and Pakistan, and they said the same about the wide use of Windows OS in their countries. However, the case was a bit different for that of the guy in the USA and I also noticed that a lot of my friends there use the MAC OS X. This doesn’t change the fact that Windows is still more used worldwide and because of this, hackers and intruders have had a lot more time to study Windows and create a lot of malware for it. The popular Windows OS has been tagged the most vulnerable OS. Now there is a new Windows OS. The question is: Is it vulnerable as well?

This article focuses on the new version of Windows. Windows 8 was released on October 26, 2012. It was designed to work perfectly on a touch screen. The interface is so catchy!!

As a computer lover, I follow a page on Facebook named “computer freaks.”

Recently, this picture was posted, showing that in the timeline of the Microsoft Windows operating system they have always had a good OS, then a bad OS, and then a good one again. Kind of like an arithmetic progression with a common difference of one among the good Windows operating system. Because of this, I decided to do an analysis on this Windows 8 edition of Microsoft Windows to see what will really make it bad or “SHIT,” as the picture puts it.

I began to do research on Windows 8 and I discovered that three patches have already been released for Microsoft’s new operating system. This reminds me of when Vista was released, there were so many patches that they just had to make a better version of Windows OS (Windows 7). I’ve used Windows 7 for a long time and I’ve also met some Windows 7 power users that can testify that it is a good one from Microsoft. However, I still think Windows XP stands a higher ranking when we focus on system stability.

Speaking more fully of malware, one of Microsoft’s major objectives is to reduce the risk of their OS being infected by malware. As a result, several measures have been taken to reduce the chances of malware infection in Windows 8. Jason Garms of Microsoft has provided some tips on how to keep your PC free from malware in the link below:

http://blogs.msdn.com/b/b8/archive/2011/09/15/protecting-you-from-malware.aspx

Windows 8 has proven to be less vulnerable to malware, because the Windows Defender that comes with it is very active with good heuristics for detecting malwares. Even with all the new security, the common saying still remains true: there is no total security and therefore you cannot be totally secure from malware on Windows 8 but the risk of being affected by malware is just reduced. Windows 8 got better in a lot of ways to the point that their error page had a transformation.

This doesn’t have to do with malware, but one thing I still don’t like about the Windows OS is the inability to retain commands on the console (command prompt) after the cmd is closed and reopened. For those who work more on the console, you can imagine using a lot of very long commands and then, simply because you mistakenly closed this console session, when you open another, all those commands are gone and you need to retype them. This is unlike the terminal (console) in Linux.

I read and heard from different sources that Windows 8 was secure but I am a big time skeptic, so I had to prove it to myself. To be sure of the fact that Windows 8 is not so vulnerable to malware, I had to start by creating a proRAT Trojan server with my Windows 7 machine and then I sent it to my Windows 8. I have tried this Trojan several times and I’m no novice with it. I used it often in the days when I loved threatening schoolmates in the network, and I still have a good handle on it. As soon as I sent the server file to the Windows 8 OS with an external drive, Windows Defender deleted it. This was really amazing. I don’t have any third-party AV installed and my computer could react that way with malware. I had even seen some Windows 7 OS with third-party AVs that will not detect the server file due to poor heuristics. However, one third-party AV you can rely on to some extent is Norton with its bloodhound heuristics. The image below is what I got when I put my Trojan server on Windows 8:

The image below contains the hexadecimal of the Trojan server that was used

Windows 8 is indisputably the most secure Microsoft Windows, but we cannot still match its malware detection with MAC OS X. I realized that the Windows 8 defender that protects us from malware is the popular Microsoft Security Essentials. It’s good the way they saved us the cost of buying Microsoft Security Essentials separately.

There are interesting testimonies everywhere about Windows 8 and its safe usage and security but this doesn’t make it impeccable. Although I’ve not personally found any faults in Windows 8, from my research I discovered that the new Windows version that was released already had its first security patch on November 13, 2012, which was just a few weeks after it was released.

Also, not that I’m very sure about this, but I came across an article that said the Bitdefender company had tested some malware on Windows 8 and one piece of malware had its way with Windows 8. This particular malware is capable of creating backdoors that allow hackers to remotely control the computer of the host and also to steal gaming credentials and a lot more.

However, the company used malware collected over the last six months, which is not ideal, because the test sample won’t include every threat and also because every antivirus product misses some software nastiness, giving a greater chance to the attacker.

Bitdefender also tested the malware by fetching a copy of the malicious code from an internal FTP server and executing it to see how far the malware progresses–as opposed to visiting a booby-trapped web page that attempts to compromise the PC, which is a more common method of infection. In theory, there should be little difference, but this methodology bypasses Windows Defender’s SmartScreen, which filters out phishing attacks and malware downloads when using Internet Explorer.

Well, this is not an issue to make you reconsider using Windows 8, because a lot of antivirus vendors are just trying to find a fault in the Windows Defender (built-in Microsoft Security Essentials) in order to provide a chance for their own AVs.

Another test I tried is the backdoor. I installed WAMP server in Windows 8 on my VMware and I tried to upload a backdoor shell onto it from my host operating system. I kept trying this but to no avail. Then I tried to manually drop the shell into the guest Windows 8 OS server directory. It turned out while cleaning up the file that I received a message notifying me that malware was detected and could not be accessed.

I know c99, c100, GNY, and r57 shells are very well-known and restricted by a lot of anti-malware programs. Because of this, I tried to use a WSO shell, but it was still functionless.

Left to me, I will say that Windows 8 is like a means to put an end to a hacker’s invasion on web servers. Probably, if most webservers on Linux OS are moved to Windows 8, the hackers would have a lesser chance to upload backdoor shells to damage our web contents.

Since some of the antivirus companies have predicted future security shortcomings on the secure Windows 8, we also have to be prepared to keep our PCs protected.
I will start by providing you with good software for analyzing Windows executable files. With this software, you can check to see if there is anything attached with an executable application you want to run on your computer. It is called PEid, which identifies “portable executables.”

Download with the MediaFire link: http://www.mediafire.com/?f2yu4wzbrq3bp2a

If it happens an attacker successfully finds way to drop his malware on your PC, you can also remove it manually from your computer, but you must be very careful because there are some malwares with anti-tracing features that can make your OS crash the moment you detect them.

So to find them, you will go to your registry and follow the given registry keys to check for these malwares:
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Currentversion\explorer\Usershell folders
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrenVersion\RunServicesOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\VMM32Files
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\VxD

The reason for locating the malware yourself is because of polymorphic malwares. These are malwares that make it impossible for antivirus and firewalls to detect them.
Some of the malwares can make themselves run at your system startup by replicating themselves to the following:

Config.sys (a system32 folder)

Autoexec.bat (rootdrive)

System.ini (Windows folder)

Before using the registry keys to locate the files, you may consider disconnecting yourself from the network where it’s likely an attacker is using the malware to attack you.

After locating any suspicious file in the registry keys, you can double-click the file to find its path, as the image below shows:

As a regular Windows user, you should know we can’t delete files that are working in the background, so we need to check for this file in the task manager processes and stop it.

That’s not malicious software, but it’s the exact file I examined in the registry. If it were malicious, I would just click the “End Process” button to put an end to its work. Now you can go back to the directory you were given by the registry and delete the file. After this, you will need to restart your PC if you know the malicious software has not caused much damage to your computer. If it has eaten some of your system files up, you may need to upgrade your Windows OS by using an installation CD to go through the installation process again. This way your files remain intact in a folder, “WindowsOld,” in your C: directory.

I have given a link to download the PEid. Now I will show you a little way to make use of this software in examining your executable files.

When you unpack the rar file I gave in the link, you will see an interface like the one below:

Do not mind the Windows Explorer look of my own software, it’s just a skinpack. On your PC, the three blue dots should be minimize, maximize, and close button. To check details about a particular exe file, you can select the file in the first option of the PEid GUI.

Now to check the active processes that may include the malware, you can click “Task Viewer,” which gives you a result like the task manager does. When you select any task, it will show every file attached to the process and working with it. PEid is a really good solution for malware detection.

Windows 8 Defender uses the colors green, yellow, and red to show its security level. To make your Windows 8 more secure from malwares, I will advise that you should update Windows Defender as often as possible, as you would any third-party antivirus if you really want to stay secure.

Sometimes malware will be placed in software that you already have on your PC. For instance, suppose you downloaded a game that was functioning properly before it started malfunctioning. It is advisable to do an md5 checksum on downloaded files so when it gets suspicious, you can do a checksum again to compare with the previous test and then you will be able to say if it has been tampered with. You can download software for checking your md5 on Windows here:

http://www.4shared.com/zip/qsq6WC8O/NetTools4574.html

Joseph Orekoya is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that has trained over 15,000 people including popular CEH and CCNA certification courses.

References

http://www.pcworld.com/article/2013807/windows-8-already-getting-security-patches.html

http://blogs.msdn.com/b/b8/archive/2011/09/15/protecting-you-from-malware.aspx

http://www.anandtech.com/show/4822/windows-8-malware-protection-detailed

http://windows.microsoft.com/en-US/windows-8/windows-defender#1TC=t1

http://www.theregister.co.uk/2012/06/21/win8_security/

http://propellerheadforensics.files.wordpress.com/2012/05/thomson_windows-8-forensic-guide2.pdf

Documents identified by computer forensic investigations in civil litigation typically require review and analysis by attorneys to determine if the uncovered evidence could support causes of action such as breach of contract, breach of fiduciary duty, misappropriation of trade secrets, tortious interference, or unfair competition.  In addition, bit-for-bit forensic imaging of workstations is also commonly used as an efficient method to quickly gather evidence for further disposition in general commercial litigation matters.  For example, instead of relying upon individual custodians to self-select and copy their own files, forensic images of workstations can be accurately filtered down to exclude system files, which only a computer can understand, and identify files which humans do use such as Microsoft Word, Excel, PowerPoint, Adobe PDF files and email.  In any of the above situations, be it a trade secrets type matter or a general commercial litigation case, litigants are always highly sensitive to the potential costs associated with attorney review.

Now that Microsoft Windows 8 workstations are available for sale and will likely be purchased for use by corporate buyers, civil cases involving the identification and analysis of emails from such machines is a certainty.  Recently, excellent computer forensic research on Windows 8 performed by Josh Brunty, Assistant Professor of Digital Forensics at Marshall University revealed that “In addition to Web cache and cookies, user contacts synced from various social media accounts such as Twitter, Facebook, and even e-mail clients such as MS Hotmail are cached with the (sic Windows 8) operating system”  (source:  http://www.dfinews.com/article/microsoft-windows-8-forensic-first-look?page=0,3).  Building on Professor Brunty’s scholarship, I set out to determine the extent, amount, and file formats email communications exist on a Windows 8 machine.  In addition, a goal was to identify any potential issues for processing locally stored communications for attorneys review in the discovery phase of civil litigation.

As you will see, the format in which Windows 8 stores email locally does in fact present potentially significant challenges to cost effective discovery in both trades secret type matters as well as general commercial litigation cases.  Fear not as my conclusion offers some potential solutions as well as other important considerations.  I have written this article in detailed steps so that others might more easily duplicate my results.

Testing

My testing was performed on the Release Preview version of Windows 8, so I will be upgrading the subject workstation to the current retail version, re-running my tests and reporting the results in a later publication.

1.  Subject Workstation “Laptop”

• Manufacturer:  Dell Latitude D430
• Specifications:  Intel Core 2 CPU U7600 @ 1.20GHz / 2.00GB Installed RAM /
• OS:  Windows 8 Release Preview / Product ID:  00137-11009-99904-AA587
• HARD DRIVE:  SAMSUNG HS122JC ATA Device / Capacity 114,472 MB

2.  Windows 8 Installation

The Dell Laptop originally came with Windows XP Professional installed, but I replaced XP with Windows 8 Release Preview (“W8”) using an installation DVD burned from the W8 .ISO file provided by Microsoft’s website.

3.  Windows 8 Preparation

I created a single user account called “User” with a password of “password”.  After the W8 initiation phase ended, I was presented with the new “tile” interface, which is much more akin to an iPhone, iPad, Android metaphor.  Unfortunately, my Dell laptop did not enjoy a touch screen that would have allowed me to take more advantage of the tiles.  Even on this older machine, the built in track pad and other mouse controls all worked perfectly out of the box, so I was able to proceed with installing various communication applications.

A.  Connecting the Windows 8 laptop to web based accounts

On W8’s default new tile screen, there are three key tiles I began with; “People”, “Messaging” and “Mail”.  Within the “People” tab, I connected my contacts to my Microsoft, Facebook, LinkedIn and Google accounts.  Connecting to these external accounts brought in a flurry of contact profile pictures, email addresses, phone numbers, physical addresses, company name, job title and website from LinkedIn.  Interestingly, my own record, “Me”, did not import a profile picture from any of my online accounts, leaving a generic silhouette tile.  Perhaps LinkedIn, Gmail and Facebook are excluded from choosing my local Windows 8 profile by Microsoft.  I do not have a profile picture associated with my Microsoft Live account, which might be the cause of the missing profile picture.

Below is the end-user view under the Windows 8 “Mail” tile showing imported emails from my Google Gmail account:

• Inbox: 34
• Drafts:  0
• Sent items:  15
• Outbox:  0
• Junk:  0
• Deleted items:  22
• [Gmail] / All Mail:  34
• [Gmail] / Spam:  0
• [Gmail] / Starred:  2
• [Gmail] / FORENSIC:  1
• [Gmail] / Receipts:  0
• [Gmail] / Scarab:  2
• [Gmail] / Travel:  0

4.  End User Installed Applications

I installed the following four applications on the laptop:

A.  Programs recorded by the Control Panel:

1.  Adobe Flash Player 11 Plugin ver. 11.4.402.287

2.  Google Chrome ver. 23.0.1271.64

3.  Mozilla Firefox ver. 16.0.2 (x86 en-US)

B.  Programs listed under Windows 8’s “Store” tile:

1.  Tweetro (I did not link to any Twitter account)

2.  Xbox Live Games (using Microsoft account user name “larry_lieb@yahoo.com”)

Using the Chrome browser, I logged into my Google account and installed “Gmail Offline” to see what effect this add-on would have.  After installing “Gmail Offline”, the Chrome icon now appears in the system tray by default when viewing the Desktop.  I then logged in to a newly created Yahoo account, which I called “larry.lieb@yahoo.com”.  I sent and received several emails both two and from my Yahoo/Gmail accounts.  While logged into my Yahoo.com email account, I imported contacts from my LinkedIn account.  Now that I had created multiple sources of email and instant message correspondences, I set about imaging the laptop.

5.  Forensic Imaging

I used Forward Discovery’s Raptor 2.5 (http://forwarddiscovery.com/Raptor) installed to a USB flash drive from the Raptor 2.5 .ISO file using Pendrivelinux.com’s free USB Linux tool.  I changed the boot order to USB drive first which then caused the laptop to boot the Raptor 2.5 operating system instead of Windows 8.

Within Raptor 2.5, I used the Raptor Toolbox to first mount a previously wiped and formatted external Toshiba hard drive, which was connected to the laptop via a USB cable.  The total imaging and image verification process took close to eleven hours due to the slow USB connection.  The internal Samsung hard drive uses a ZIF zero insertion force connector, so although I may have been able to achieve a faster imaging time using my Tableau ZIF to IDE tool (http://www.tableau.com/index.php?pageid=products&model=TDA5-ZIF), I was loathe to tempt equipment failure as Tableau states, “ZIF connectors are not very robust and they are typically rated for only 20 insertion/removal cycles.”  In addition, the Tableau kit only comes factory direct with Toshiba and Hitachi cables, which would not work with the Samsung drive.

6.  Indexing

Using Passmark’s OSForensics ver. 1.2 Build 1003 (64 Bit) on my Digital Intelligence µFred forensic station (http://www.digitalintelligence.com/products/ufred/), I created an index of the Windows 8 files contained within the Raptor 2.5 created Encase evidence files.  OSForensics was able to create an index of the entire contents in around one hour.

Under OSForensics’ “File Name Search” tab, I ran searches for common email file types.  Out of 142,712 total items searched, OSForensics identified:

A.  2,204 items using the search string “*.eml”

B.  0 items using the search string “*.msg”

C.  0 items using the search string “*.pst”

D.  0 items using the search string “*.mbox”

Using OSForensics “Create Signature” tab, I was able to run and export a  Hash value and file list report for the folder “1:\Users\User\AppData\Local\Packages\”.

7.  .EML files

Using AccessData’s FTK Imager 3.1.1.8, I exported the contents of the folder path, “Users\User\AppData\Local\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Indexed\LiveComm\larry_lieb@yahoo.com\”.

I noticed that there are two interesting folders that might warrant different treatment for electronic discovery projects:

A.  Location of folder storing .EML files containing email communication:

OSForensics found 264 .EML files under the “Mail” folder path:

“microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Indexed\LiveComm\larry_lieb@yahoo.com\120510-2203\Mail\”

B.  Location of folder storing .EML files containing contacts:

OSForensics found 1,939 .EML files under the “People” folder path:

“microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Indexed\LiveComm\larry_lieb@yahoo.com\120510-2203\People\”

 C.  Location of folder storing my “User” .EML contact file:

OSForensics found 1 .EML files under the “microsoft.windowsphotos \..\People\Me” folder path that contains my “User” profile:

“Users\User\AppData\Local\Packages\microsoft.windowsphotos_8wekyb3d8bbwe\LocalState\Indexed\LiveComm\larry_lieb@yahoo.com\120510-2203\People\Me”

Conclusion

In electronic discovery projects that utilize forensic imaging tools to capture workstation hard drives, it is common for data filtering to be requested such as D-NIST’ing, file type, key word, date range and de-duplication.  Often times, a file type “inclusion” list will be used to identify “user files” for further processing such as Microsoft Word, Excel, Powerpoint, Adobe PDF, and common email file types such as .PST, .MSG., and .EML.  Files found in the forensic image(s) will be exported for further processing and review by attorneys.

One of the challenges attorneys face in electronic discovery is reasonably keeping costs low by avoiding human review of obviously non-relevant files.  However, as Windows 8 appears to be storing contacts from LinkedIn, Gmail, and other sources as .EML files, it is apparent that using file type filtering inclusion lists with .EML as an “include” choice, will bring in many potentially non-relevant files.

If an attorney is billing at a rate of $200/hour, and can review fifty documents per hour, then the 1,938 “contact” .EML files alone would require 38.78 hours of attorney review time at a cost to the client of $7,756.00.  Therefore, it may make sense for all parties to stipulate that .EML files from the “People” folder be excluded from processing and review unless the hard drive custodian’s contact list is potentially relevant to the underlying matter.

In some cases, litigants do not or cannot pay for outside vendor electronic discovery processing fees and will direct their counsel to simply produce their electronically stored information.  I advise against this practice as the potential for producing privileged or protected information exists with this approach.  A requesting party may also object to the costs de facto shifted to them with this approach.  Nonetheless best practices and economic reality do not always mesh.  Parties that wish to take this “no attorney review prior to production” approach with evidence gathered from Windows 8 machines may risk over producing the “contact” EML files to their opponent and should consider the risks associated with not allowing a professional to apply filters to their collection upfront.

Companies that are planning on purchasing and implementing Windows 8 workstations may want to consider altering their IT policies to prevent employees from linking to personal Gmail, LinkedIn and other web based identities to prevent personal communication from being stored locally.  I am uncertain if such an option is available within the administrative portion of the Windows 8 operating system, or if employee handbooks and training alone might be available to stop employees from bringing their home to work.

From an ease of trade secrets type computer forensic investigation standpoint, having a suspected former employee’s Gmail communication locally and readily available is excellent; certainly this ease of access is preferable to sending a subpoena to Google to retrieve similar information.  However, from this author’s personal experience, general commercial litigation type cases in general vastly outnumber cases involving traditional computer forensic issues.  Perhaps companies who take steps to proactively prevent Windows 8 machines in the corporate environment from caching their employee’s personal communication locally may experience significantly less expensive discovery costs in the long run.

Acknowledgments

1.  Josh Brunty, Assistant Professor of Digital Forensics at Marshall University     
2.  David Knutson and Tim Doris of Duff & Phelps for their sage opinions on Linux live CD versus ZIF connector to a hardware write-protection device acquisition approaches.
3.    Patrick Murphy and Raechel Marshall of Quarles & Brady for their insight into document production risks.

About

Larry Lieb, ACE, CCA

CIO

Scarab Consulting  (http://www.ConsultScarab.com)

LINK TO PDF:  Windows 8 Computer Forensics and Ediscovery Considerations

Official Secrets Act warning sign on quayside at Crouch Corner, Foulness, Essex (Photo credit: Wikipedia)

I had an opportunity this week to be on the receiving end of an acceptable use policy (AUP) – something that I should experience each and every time I work for a new client on their hardware, but something that isn’t often the case and thus is a bit of a novelty to me. It was accompanied by a form that required completion before I would be issued my user ID & laptop, so without further ado, as did my fellow conscripts¹, I signed the form and returned it without so much as glancing through the AUP. Now, as a person who has written a dozen or more AUP, I had a pretty good idea of that which was contained within – to whit nothing of any interest what so ever, but I’d just signed over my acceptance of it’s terms and conditions without so much as a backwards glance. And this is the real issue with most policy and procedures, they are written by people who have little desire to educate or even get the user to genuinely accept the restrictions made on their life, but who write policy and procedure to cover their own, and the company’s, arse ( ass – for our American readers ). This is what has been fed down as doctrine from the dawn of time ( look at the 10 Commandments – after “Thou shalt not kill” – “Honour thy father and thy mother” ? Clearly an arse/ass covering exercise if ever I saw one ! ) – but actually this shouldn’t be what our policies should be about.

A policy should be an educational document, something that informs the reader of what they should do, why they should do it and what will happen if they don’t. Anything more than about 2 sides of A4 written in current legalese is going to destroy the minds of 99% of the people who read it – the other 1% probably write policies for a living, and read it as a matter of professional interest ( like I did, eventually, with the one that I was given ! ) Given that often staff have as much understanding of the topics at hand as children do when being told to behave, is it really unsurprising that the effectiveness of policy set like this that dissimilar to handing a six year old a twenty page policy about sweets before bedtime or a teenager a tome regarding drinking, smoking and curfew times ? I’m not suggesting that you should treat your staff like children ( although in some cases you might think that this may not be that bad a suggestion ), but how about a simple document that outlines more simply the things that you actually _care_ about ?²

The other week, the children and I had seen the first episode of Arrow ( Sky 1 in the UK, The CW in the US ) based on the DC comic book character “Green Arrow” – before the second episode, when my other ( better ) half joined us we had a short family competition, judged by Mrs.B – we each had to describe the previous episode to bring her up to speed in as few words as possible. I didn’t win, although I was pleased with my entry – but to summarise a full episode of a program – even one as well scripted as Arrow – in the winning twelve words that my son managed is an achievement. I’m proposing a variation on this game to drop an AUP down to a reasonable length – I’m bound by a confidentiality agreement, so I’m not going to reproduce the particular AUP that I’ve just agreed to, although I will say that it is one of the better ones that I’ve been party to, and is a mere 6 sheets or 12 sides of A4 ( although with copious use of title, back and blank pages, change control and other administrative blurb leaving 8 pages of actual text, however my opinion is that we should be able to drop this to two pages ( in the same font size³ ) without losing a single iota of meaning⁴. Here’s my stab at it.


Hi. Welcome to Organisation.

We take Information Security and the use of our systems very seriously – to this end, there are a few things that we’d really like you to agree to do when using any of the company computer systems.

Please choose a good password, a mix of letters and numbers, both lower and upper case are good. Remembering a good password can be difficult, but as a help, you might like to try using a consonant vowel consonant sequence to make it pronounceable – bogdotfan – and then add a number – bogdotfan25 and then mix it up with some upper case – bOgDotfAn25. Please do change the password when requested by the system, and do use a completely new one each and every time. Do protect the password – it is part of what identifies you on the system, and, when it is entered any and all action taken when using it will be assumed to be yours.

Do turn your laptop off when you are in transit – the encryption doesn’t work if the device has been left on or in standby.

Please help us to reduce the risk of malware or data loss by using only officially issued, encrypted USB devices in your company laptop or desktop.

Do respect privacy – be it personal, company or client. Do think about the data that you are using, what it should be used for, and who should see it. If you are at any time unsure – do ask – there is no punishment for asking. Do familiarise yourself with any relevant legislation to the data that you are handling, be it the Data Protection Act or the Official Secrets Act – these are Acts of Government and must be complied with.

Do use the computer and informations systems as you require to do your job, please, also, feel free to use them sensibly for personal use during breaks through the day. We ask that you maintain your usage, browsing and e-mail content to remain within the realms of both the inoffensive and the legal – if your Granny wouldn’t approve, neither will we.

Do use all of the software that we have licenses for, if there is something that you need to do your job that we’ve not supplied – do put in a request for it, we want to enable you. Do wait for us to install it though, we want to keep you and us above board and legal. ( This includes OpenSource software too please ).

We have access controls and lock down various parts of the network where there is sensitive data, do request access if you need to get to something that you’re not able to reach.

Do clear your desk at the end of the day or if you are going away from it. Do lock your screen too.

Do let us know if anything goes wrong, you lose anything that shouldn’t have been lost or if you see anything at all untoward – we do monitor things ( including you ) – but the chances are that you would notice things before we do – that quick response could make all the difference.

We really hope that you enjoy working here – there may be specific instructions for systems that you work on, these will be provided to you when you get your access. Other than that, please sign here to acknowledge that you understood and agree to do everything above.

Ok, so that’s 565 words – less than a single A4 page. I get that it could be refined and polished – but then it did only take me 10 minutes to paraphrase the 8 pages that it was before, with some added advice ( around the passwords ) and including, I think, the meaning of pretty much everything else. It’s a little flippant, but I hope that you might take my point on board – nobody is going to read a 40 page AUP, the number of people that will read a 8 page one is limited – 1 page, maybe 2 and you stand a chance – arguing enforceability is a lot harder when it is made really straightforward and easy to understand – and there is no excuse for even the shortest attention span of employee not getting it.

Give readability a chance !

[ Update: I noticed an oversight on this AUP - have a look here for a correction and a bit more besides ! ]

1. Not really conscripts, new hires, fresh meat, what ever you like to call us …
2. I know that there are lawyers out there reading this going round the bend with fear at the lack of arse/ass coverage, but actually consider the possibility that there might be less incidents overall – good news for you as well as for us in Security …
3. That works out to 20 words per line for 40 lines per page, or 800 words.
4. Incidentally, I would recommend that this is an excellent intellectual exercise for any of the documents, reports or, possibly most important of all, your PowerPoint presentations.

Forensic Analysis of Windows 7 Jump Lists

Abstract

The release of Microsoft Windows 7 introduced a new feature known as Jump Lists which present the user with links to recently accessed files grouped on a per application basis.  The records maintained by the feature have the potential to provide the forensic computing examiner with a rich source of evidence during examinations of computers running the Microsoft Windows 7 Operating System.  This paper explores the type and level of information recorded by the Jump List feature, the structure of those records and the user actions which result in them being updated.

Introduction

The content of this article is based upon an MSc Thesis submitted by the author to Cranfield University in February 2012 but has been supplemented with observations and findings from analysis of Jump List files in actual investigations.

The article focuses primarily on artefacts relating to file accesses and although additional Jump List data relating to the use of individual programs has no focus in this paper, some work in this area has been conducted by Barnett (undated).

The Jump List feature provides the user with a graphical interface associated with each installed application which lists files that have been previously accessed by that application.  An example of that interface is shown at Fig. 1.

Fig. 1 – Example of Jump List associated with Microsoft Paint.

As indicated in Fig. 1, it is also possible for a user to ‘pin’ items in order to retain them on a list.

The feature is enabled as standard and the default setting is to show the 10 most recently accessed files per application, although it is possible to adjust that figure to a maximum of 60.

Configuration changes can be achieved by a right mouse click on the Windows Logo button > Properties which reveals a dialog box similar to that shown at Fig. 2 which can be used to enable/disable the Jump List feature.

Fig. 2 – Example of Windows 7 ‘Taskbar and Start Menu Properties’ Dialog box.

The number of items to be displayed on a Jump List can be adjusted through clicking of the ‘Customize…’ button which reveals a second dialog box, similar to that shown at Fig. 3

Fig. 3 – Example of Windows 7 ‘Customize Start Menu’ Dialog Box.

Background Information

During the initial stages of the original project research was conducted in an attempt to identify what was already known about the topic of Jump Lists.

Whilst it was found that information available in the public domain was limited, some useful material was identified:

1. Torres (2011) indicates that records of the items pinned to the Taskbar are stored in the directory ‘C:\Users\%username%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar’.
2. AccessData’s Registry Quick Find Chart (2010) indicated that details of applications that have been pinned to the Taskbar are also recorded in the Windows Registry values ‘Favorites’ and ‘FavoritesResolve’ at ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband’ and that details of applications subsequently removed are retained within those Registry values.
3. Larson (undated) explains that details of accessed files are held within structured storage (Compound Binary) files which themselves are stored within the user’s profile at the location ‘%systemdrive%\Users\%username%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations’ and notes the following:
   1. The files are named with 16 hexadecimal digits, known as the AppID followed by the file extension ‘automaticDestinations-ms’.
   2. The AppID can be set by the application or by the OS at application runtime. (MSDN, 2011).
      1. A list of known AppIDs can be found at http://www.forensicswiki.org/wiki/List_of_Jump_List_IDs
   3. The majority of records within the Compound Binary file are named with a hexadecimal numeric value and are structured in accordance with the shortcut (link) file specification.
   4. A further entry entitled ‘DestList’, is also present and although this element is structured, there is little information available relating to that structure or the information contained within these elements although it was clear that they do not follow the Shortcut specification.
4. Carvey (2011) details a small proportion of the structure, including a 64 bit ’FILETIME’ object and indicates that there are further byte sequences present within the ‘DestList’.
5. The specifications for both Compound Binary (MSDN, 2010 (a)) and Shortcut files (MSDN, 2010 (b)) are documented online and a number of tools are available to extract the individual elements from Compound Binary files, for example SSView (http://www.mitec.cz/ssv.html), OffVis (http://download.microsoft.com/download/1/2/7/127ba59a-4fe1-4acd-ba47-513ceef85a85/OffVis.zip) and JumpLister (http://www.woanware.co.uk/?page_id=266), however, none of these tools will fully parse the ‘DestList’ element within a Jump List file.
6. Ard (2007) states that Jump Lists record the number of times that a file is opened.
7. Li (2011) reports that the number of items to be shown on a Jump List is stored within the Registry value ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_JumpListItems’.

Experimental Setup and Program.

All experimentation was conducted in a virtual environment.  Based upon available resources at the time of the research, this was achieved using VMWare Workstation 7.1.3 and a retail copy of Windows 7 Ultimate (x64) with no Service Packs.

The virtual machine was created with two attached virtual disks formatted with the NTFS file system; the first to hold the Operating System and the second to store a series of specimen text, picture, music and video files.

The date and time settings of the virtual machine and all clones made from it were deliberately maintained in British Summer Time (GMT+1) in order to assist in how dates and times are recorded by Jump Lists.

The experiments that were conducted were designed to address specific points with a view to understanding the full structure of the records maintained by Jump Lists and were broken down into specific objectives.

Identify initial Jump List data. 

The first stage in this process was to carry out a fresh installation of Windows 7.  The virtualisation software was used to capture a snapshot at the completion of the installation, a second after an account was created and a third after being presented with the option to apply a password or not.  Finally the process was allowed to complete by logging the newly created user on for the first time after which the VM was shut down without accessing any files.

This experiment was carried out twice; once where a password was applied and once without.

All further experimentation was based upon clones of the VM where a password was applied to the user account and various tests were conducted to change the configuration of the feature and update the records maintained by it.

Modify configuration settings.

This was achieved by accessing the ‘Customize Start Menu’ dialog box as depicted in Fig. 3 and changing the default values to 15 (for number of programs) and 20 (for number of recent Jump List items).

The next step was to use the ‘regedit’ application to access the Registry key identified by Li (2011) before changing the data of the value ‘Start_JumpListItems’ to 25 (0×19) before closing regedit and accessing the relevant dialog box again to note the displayed values.

Finally, the ‘Use Default Settings’ button was used to return both displayed values to 10.

Open files.

A number of the sample files held on the second virtual hard disk were opened using applications included with Windows 7; Notepad and WordPad for text, Windows Photo Viewer and Paint for picture files, Windows Media Player and Windows Media Centre for video, sound and pictures.

Pin and Unpin items to a Jump List, Taskbar and Start Menu.

One entry each from the Jump Lists for Notepad and Paint were pinned to their respective lists.

The picture viewing program Irfanview (http://download.cnet.com/IrfanView/3000-2192_4-10021962.html?part=dl-IrfanView&subj=dl&tag=button) and the productivity suite Microsoft Office 2007 were then installed using the default installation locations, before shortcuts to Irfanview, Microsoft Word, Notepad and Paint were pinned to the Taskbar and Start Menu.

Irfanview and Microsoft Word were used to open two picture files and two Microsoft Word documents respectively.  One entry from each of the displayed Jump Lists was pinned to the list; one from the Taskbar list and the other from the Start Menu List.

Irfanview was then unpinned from the Taskbar and Start Menu and uninstalled using the relevant link found in the programs listing presented on the Start Menu.

Microsoft Office 2007 was uninstalled via the Windows Control Panel without unpinning Microsoft Word from either the Taskbar or Start Menu.

Delete Jump List data.

A number of methods of deleting the entries from a Jump List were tested;

1. Manually selecting each entry through a right mouse click > ‘Remove from this list’ option.
2. Deselecting the option to ‘Store and display recently opened items in the Start menu and the taskbar’ from the ‘Taskbar and Start Menu Properties’ dialog box (see Fig. 2).
3. Navigating to the ‘AutomaticDestinations’ directory and deleting the Compound Binary Files through Windows Explorer.
4. From a command prompt with the command ‘del C:\Users\Win7x64JL\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\* /Q’.

Establish the order of file accesses.

This experiment consisted of three steps;

1. Open a series of files in a known order
2. Pin a selection of Jump List items in a known order
3. Open all of the files again in a known order.

Identify pinned entries.

No additional experimentation was required for this step as previous experiments had already included the action of pinning individual entries to various Jump Lists.

Determine how often a file has been accessed.

Although it had previously been noted by Ard (2007) that Jump Lists record the number of times that a file has been opened, no information was identified to indicate whether other types of file access are also counted.  The experimentation at this stage was intended to address this knowledge deficit.

Due to time constraints associated with the original project, all further experimentation focused on the use of the applications Notepad and Microsoft Paint.

A number of steps were taken to investigate this aspect of Jump Lists;

1. Two sample files (one picture and one text) were opened a total of five times each by navigating to them through Windows Explorer and a double left mouse click.
2. The various context menu options (with and without the use of the Shift key) available for picture and text files were each used to perform a function, i.e Print.
3. Shortcut files were created on the Desktop and used to open sample files.
4. The various options within the application toolbars were each used to perform a function.
5. Entries appearing in the Jump List were used to re-open files and the additional options available through a right mouse click on an entry were also selected in turn.
6. Sample files were opened from the Command Prompt with commands such as ‘notepad D:\somefile.txt’.

Identify whether the date/time of file access is recorded.

It has been noted previously at Section 2 above that Carvey (2011) identified the presence of a ‘FILETIME’ object within the structure of an entry recorded in the ‘DestList’ element of a Jump List, although the purpose of this value was unknown.  Analysis of changes to these byte sequences was performed on the various Jump List files which had been generated and updated as a result of the experiments conducted in order to determine the purpose of that object.

Establish any differences in how file accesses are recorded.

The various Jump List files generated throughout the testing phase were analysed in an effort to identify any differences in the way that certain actions are recorded.

Delete, move and rename Jump List target  files.

Experimentation was conducted to investigate the impact of these types of user actions on the records within a Jump List.  The experiments involved opening a number of sample files to generate an entry in a Jump List before testing the following actions;

1. Moving the target within the same volume.
2. Moving the target to a different volume.
3. Deleting the target to the Recycle Bin.
4. Deleting the target to the Recycle Bin and then deleting it from that location.
5. Deleting the target, but bypassing the Recycle Bin by use of the Shift key.
6. Renaming the target file on the original volume.

Install a known application to a non-default location.

The purpose of this experiment was to identify any differences in the value of the AppID generated by Windows 7 by installing an application to a non-standard location.

In this case, this was achieved by installing the program Irfanview to the path ‘C:\Irfanview’ instead of the default ‘C:\Program Files(x86)\Irfanview‘.  Following the installation two sample picture files were opened.

Results and Observations

This Section provides a summary of the experimental results and observations made.  For ease of reference the information is grouped into areas of interest.

Data present at first login.

The areas of the folder structure and the Windows Registry that are used to store data relevant to Jump Lists are created within a user account at the point that account first logs in.

A fresh install of Windows 7 resulted in the applications ‘Internet Explorer’, ‘Windows Explorer’ and ‘Windows Media Player’ being automatically pinned to the Taskbar without any user interaction as shown in Fig. 4 below.

Fig. 4 – Screen capture of Windows 7 Start Menu and Taskbar at first login

The directory ‘C:\Users\%username%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar’ was found to contain three shortcut (.lnk) files relating to those three applications.

References to those pinned applications were also found in the Windows Registry values ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband\Favorites and FavoritesResolve’.

The Windows Registry value ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_JumpListItems’ did not exist at this stage.

It was found that irrespective of whether the system was configured to show hidden files and folders or not, the ‘AutomaticDestinations’ directory could not be seen when attempting to navigate to it through Windows Explorer.

If, however, the full path was typed into the address bar, then the contents of the directory could be seen.  Navigating to it from a Command Prompt had no such problems.  Further analysis using forensic software did not show the ‘AutomaticDestinations’ directory to have the ‘Hidden’ attribute set.

One Jump List, named ‘1b4dd67f29cb1962.automaticDestinations–ms’ exists within the ‘AutomaticDestinations’ directory at first login which contains four entries relating to the ‘Libraries’ available through Windows Explorer.

Jump List Configuration Settings

Changing the number of Jump List items to display using the ‘Customize Start Menu’ dialog box resulted in the creation of the Registry value ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_JumpListItems’.

Similarly, changing the number of recent programs to display resulted in the creation of a value named ‘Start_MinMFU’ in the same Registry key.

After deselecting the option to ‘Store and display recently opened items in the Start menu and the taskbar’ from the ‘Taskbar and Start Menu Properties’ dialog box, a new value entitled ‘Start_TrackDocs’ was created within the same Registry key.  Additional experimentation identified that the data in this value is either ‘0’ when the feature is disabled or ‘1’ when enabled.

None of these values were present at first login.

Using regedit to alter the date in the Registry values resulted in immediate updates to the respective checkboxes in the ‘Customize Start Menu’ dialog box.

The installation path of a program is taken into account by the OS when AppIDs are automatically generated.

Whilst it was found that uninstalling a program removed traces of items pinned to the Start Menu and Taskbar, it was also found that Jump Lists relating to that application remained intact.

Accessing files

There are numerous options available to a user in respect of file manipulation through Windows Explorer, context menus, application file menus and Jump Lists themselves.

Testing revealed that providing a period of at least 30 seconds elapsed between repeated instances of opening the same file, a counter in the ‘DestList’ entry would increment by 1.

Accessing files in a serial manner, i.e. one after the other, resulted in entries being made in the Jump List irrespective of the amount of time elapsed between each access.

The FILETIME object only changed when a user action caused the entry access counter incremented.

The only actions that were found to cause such updates to the FILETIME object and the access counter were those that resulted in the content of the target file being made available to the user, i.e. displaying a picture file on screen or printing it.

Table 1 below shows only the various user actions which resulted in an update to the access count of a Jump List.  It should be noted that the options ‘From Scanner or camera’ and Send in Email’ present in the file menu associated with Paint were not tested

Analysis of Jump List files in relation to live case work has shown that some applications including the Microsoft Office suite, Windows Explorer and Windows Media Player may record non whole numbers in the access count.  The reason for this difference has not been identified and experimentation has failed to identify a method to replicate the issue.

Serial	Action	Result	Remarks
1	Cut and Paste to new Fixed Disk NTFS volume	Opened.  File path amended to new location.
2	Cut and Paste to Removable Drive NTFS volume		‘Yes’ removes the entry from the list.  ‘No’ leaves it in the list.
3	Cut and Paste to same Fixed Disk NTFS volume	Opened.  File path amended to new location.
4	Right Mouse click > Delete (Sent to Recycle Bin)		‘Restore’ returns the file to original location, but does not open it. ‘Delete’ removes entry from list but leaves the file intact in the Recycle Bin
5	Right Mouse click > Delete > Delete from Recycle Bin	As Serial 2 result.
6	Shift key + Delete key (Bypass Recycle Bin)	As Serial 2 result.
7	Rename	Opened.  File path amended to new name.

Table 2 – Results of renaming, moving or deleting files

Order of Access

The list is presented on screen to the user and stored in the ‘DestList’ element in reverse order, i.e. the first entry at the bottom and the most recent at the top,  with each subsequent entry being appended to the list above the preceding entry.

Within the ‘Recent’ section of a Jump List, subsequent accesses to target files results in placing the entry for the most recently accessed at the top of that section when the list is presented on screen to the user and within the ‘DestList’ element.

The ordering of presentation of items pinned to a Jump List differed, with the sequence reflecting the order in which they were pinned, i.e. the first at the top of the section and the last at the bottom.

It was also found that when an entry is pinned, the data relating to it in the ‘DestList’ became static and was not re–ordered as further accesses occurred.  This was also true within the list presented to the user on screen, i.e. the entries were not re–ordered.

Pinning/Unpinning Items

Individual files can be pinned to the Jump List and/or the Start Menu, but not to the Taskbar.

At the point the first item is pinned to the Start Menu a new sub-directory named ‘StartMenu’ is created within ‘C:\Users\%username%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\’ which is used to store a shortcut (.lnk) file relating to that item.

Unpinning the item from the Start Menu results in the shortcut (.lnk) file being removed from the ‘StartMenu’ sub-directory.

Unpinning all items from the Start Menu leaves the ‘StartMenu’ sub-directory intact.

When an program is pinned to the Start Menu or the Taskbar a shortcut (.lnk) file is created and stored in the relevant sub-directory of ‘C:\Users\%username%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\’ .

A record of items pinned to the Taskbar is also added to the data in the values ‘Favorites’ and ‘FavoritesResolve’ within the Windows Registry key ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband’.  If those shortcut files are removed from the respective locations, either manually or during an application uninstallation process, the corresponding traces within the folder structure and Windows Registry are also removed, but any Jump Lists generated from the use of that program remain intact.

The testing conducted showed that the total number of items pinned to a Jump List is recorded in the header of the ‘DestList’,  with a hexadecimal count beginning at ‘0×01 0×00 0×00 0×00′

Pinning an entry to a Jump List results in an update to a 4 byte sequence in the ‘DestList’ record which acts as a counter and changes from the default value of ‘0xFF 0xFF 0xFF 0xFF’ to a hexadecimal numeric value. The count begins at hexadecimal ‘0×00 0×00 0×00 0×00’, i.e. 3 pinned entries will result in count values of ‘0×00 0×00 0×00 0×00’, ‘0×01 0×00 0×00 0×00’ and ‘0×02 0×00 0×00 0×00’.

The changes to the ‘DestList’ header (at offset 8) and an entry (at offset 280 in this example) which occurred as a result of pinning a single entry to a Jump List are shown at Fig. 6 below:

Fig. 6 – Changes to ‘DestList’ element of Paint Jump List after pinning a single entry

Deleting Jump List Files

Input at the Command Prompt of ‘del C:\Users\Win7x64JL\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\* /Q’ resulted in the entire contents of the ‘AutomaticDestinations’ directory being deleted, irrespective of the pinned status of any element within the lists.

By navigating to the ‘AutomaticDestinations’ folder, it was possible to select and delete all of the Compound Binary Files it contained, regardless of the pinned status of the entries.

By expanding the Jump List and manually deleting the entries by using the ‘Remove from this list’ option, the following was noted:

1. A pinned entry could not be deleted until after it had been unpinned.
2. When the last remaining entry was removed from the list, the entire Jump List file was removed from the ‘AutomaticDestinations’ directory.

The action of removing an entry via a Jump List caused changes to the header of the ‘DestList’ element, as depicted in Fig. 7 below which provides further insight into the structure of that part of the element.

Before deletion – 2 entries in list

After deletion – 1 entry in list

Fig. 7 – Changes to ‘DestList’ element after removing an entry via the Jump List

After deselecting the option to ‘Store and display recently opened items in the Start menu and the taskbar’ from the ‘Taskbar and Start Menu Properties’ dialog box the following was noted:

1. All Jump List files which contained no pinned elements were removed from the ‘AutomaticDestinations’ directory.
2. For those Jump Lists which did contain pinned items, all other entries were removed from the list, leaving only records relating to the pinned elements.
3. The Jump List binary files can be extracted from the ‘AutomaticDestinations’ directory on a running machine without changing the data they contain.

‘DestList’ Structure

As a result of background research and the experimentation conducted, it was possible to identify the majority of the ‘DestList’ structure, however, it was found that the purpose of certain areas of the ‘DestList’ structure remained unknown.

It appeared that the first 8 bytes of an entry were some kind of hash of the entry data. Minimal experimentation was conducted whereby a single byte in each of the identified byte sequences in the entry was amended in a hex editor.  As a result the following observations were made:

1. Any change in the entry data between the start of the unidentified 8 byte value and the last byte before the file path data would result in any entries in the list after the altered one not appearing in the Jump List displayed on screen.
2. Changing the file path had no effect and the correct target file was opened when the entry in the list was clicked.  In addition, the Jump List was re–written to amend the file path to show once again the correct information.
3. These findings tended to support the theory that the first 8 bytes of an entry is some kind of hash.

The full structure of the ‘DestList’ element is presented in Table 3 (header) and Table 4 (entry) below:

Summary

1. Configuration settings can be retrieved from the Windows Registry
   1. ntuser.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_JumpListItems
      1. Number of items to display on Jump List
      2. Default value of 10
      3. Maximum value of 60
   2. ntuser.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ Start_TrackDocs
      1. Status of feature
      2. Switched on by default
      3. If present the feature has been turned off at some point (0 = Jump Lists off. 1 = Jump Lists on)
   3. Only present if default values\state changed
2. Jump List data stored in Compound Binary files at %systemdrive%\Users\%username%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations
   1. Can be shortened to %AppData%\MicrosoftAppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations
   2. Most entries in Compound Binary files are named with a hexadecimal numeric value
      1. Structured as link files
   3. DestList records the order of access
3. Not all applications use Jump Lists to record file accesses.
4. The individual entries in the ‘DestList’ element of a Jump List contain a wealth of information regarding the target files to which they relate including:
   1. The Entry ID number, which can be used to ascertain the order in which the entries were added to the list and therefore the order in which files were first accessed.
   2. A count of file accesses which result in the contents being presented to the user.
      1. Different applications may record this information in different ways.
   3. The date and time (in GMT) of the last recorded access for each entry.
   4. A flag to indicate whether the file has been pinned to the list and, if it has, the order in which it was pinned.
   5. The full path of the target file.
5. It is possible to identify if entries have been deleted from a list through:
   1. Disparity between the number of entries in the list as recorded in the ‘DestList’ header and the last issued Entry ID.
   2. Values missing from the numerical sequence used to name the individual entries.

_____________________________________________________________________________

References

AccessData (2010) Registry Quick Find Chart. [online] Available at: http://accessdata.com/media/en_us/print/papers/Registry_Quick_Find_Chart_9–27–10.pdf [Accessed: 21 Jul 2011].

Ard, C. (2007) Introduction to Windows 7. [online] Available at: http://info.publicintelligence.net/WIN7–TWO–Hour–Talk.pdf [Accessed: 17 Feb 2011].

Barnett, A. (n.d.) The Forensic Value of the Windows 7 Jump List. [online] Available at: http://www.alexbarnett.com/jumplistforensics.pdf [Accessed: 13 Sep 2011].

Carvey, H. ((a) 2011) Jump List DestList Structure. Windows Incident Response, [blog] 28 Jun 2011, Available at: http://windowsir.blogspot.com/2011/06/meetup–tools–and–other–stuff.html [Accessed: 8 Sep 2011].

Larson, T. (n.d.) Forensic Examination of Windows 7 Jump Lists. [online] Available at: http://www.slideshare.net/ctin/windows–7–forensics–jump–listsrv3public [Accessed: 7 Jun 2011].

Li, N. (2011) Change the Number of Recent Items Displayed in Windows 7 Jump List. [online] Available at: http://blogs.technet.com/b/win7/archive/2011/05/10/change–the–number–of–recent–items–displayed–in–windows–7–jump–list.aspx [Accessed: 21 Jul 2011].

MSDN (2010) (a) [MS–CFB]: Compound File Binary File Format. [online] Available at: http://msdn.microsoft.com/en–us/library/dd942138.aspx [Accessed: 26 Feb 2011].

MSDN (2010) (b) [MS–SHLLINK]: Shell Link (.LNK) Binary File Format. [online] Available at: http://msdn.microsoft.com/en–us/library/dd871305(PROT.10).aspx [Accessed: 17 Feb 11].

MSDN (2011) Application User Model IDs (AppUserModelIDs). [online] Available at: http://msdn.microsoft.com/en–us/library/dd378459(v=vs.85).aspx [Accessed: 26 Jul 2011].

Torres, A. (2011) Revealing Intent with Windows 7 Artifacts. Computer Enterprise and Investigations Conference.

Rob Lyness is a member of the British Army Royal Military Police, who has specialised as a forensic computer examiner since February 2007.

He began the MSc with Cranfield University in February 2009 and graduated in July 2012.

He was awarded the prize for the highest scoring project with his thesis ‘An Assessment of the Forensic Value of Windows 7 Jump Lists’.

Rob welcomes any questions regarding the content of this article.  Please feel free to PM.

Abstract

Solid State drives (SSD) introduced dramatic changes to the principles of computer
forensics. Forensic acquisition of computers equipped with SSD storage is very different
of how we used to acquire PCs using traditional magnetic media. Instead of predictable
and highly possible recovery of information the suspect attempted to destroy, we
are entering the muddy waters of stochastic forensics where nothing can be assumed
as a given.

Download article in PDF format

Stochastic Forensics

The way today’s SSD drives operate allows little space for positive assumptions.
With SSD drives, the only thing we can assume is that an investigator can access
existing information stored on the disk. Deleted files and data the suspect attempted
to destroy (by e.g. formatting the disk – even in “Quick Format” mode) may be lost
forever in a matter of minutes [1]. And even if the computer is powered off immediately
after a destructive command has been issued (e.g. in a few minutes after the Quick
Format), there is no easy way to prevent the disk from destroying the data once
the power is back on. The situation is somewhat of a paradox, reminding of Schrödinger’s
cat: one will never know if the cat is alive before opening the box [2].

Schrödinger’s cat, image from Wikipedia

The golden age of forensics is going to end. “Given the pace of development in
SSD memory and controller technology, and the increasingly proliferation of manufacturers,
drives, and firmware versions, it will probably never be possible to remove or narrow
this new grey area within the forensic and legal domain,” the scientists, from Australia’s
Murdoch University, wrote. “It seems possible that the golden age for forensic recovery
and analysis of deleted data and deleted metadata may now be ending.” [1]

Cannot Delete

The way SSD drives are constructed imposes several design limitations. Existing
types of flash memory allow for a limited number of write operations before wearing
off. Modern SSD drives employ smart wear leveling techniques [3] that, instead of
re-using existing blocks of memory, will write to a different block when data stored
in a certain block is being modified. This in turn will leave blocks containing
potentially sensitive information scattered all over the memory chip.

To further increase effective lifespan and improve wear leveling on SSD drives,
many manufacturers install chips that can hold up to 25 percent more data than their
advertised capacities [4]. This extra capacity is not addressable by means of the
operating system, or by any other reasonable means (e.g. without using custom hardware
to access the flash chips directly). This as well makes the content on SSD drives
impossible to wipe as securely as required by some government and military standards
via traditional means.

To mitigate this issue, some SSD manufacturers implemented an extension to the
ATA ANSI specification to enable secure destruction of information stored on all
flash chips [5]. The ATA Secure Erase (SE) command, when implemented correctly [4],
wipes the entire contents of the drive at a hardware level.

In general, software secure wipe tools that would overwrite information stored
on a hard drive with cryptographically secure random data in several passes. The
problem with these software tools is their inability to address and, therefore,
access the entire storage capacity of the SSD drive (including system, reserved
and remapped areas).

As opposed to software-based tools, the ATA Secure Erase command instructs built-in
SSD controller supporting the command to electronically erase all blocks on all
flash chips of the drive. Effectively, erased SSD drives are cleaned completely,
with all blocks being completely empty and available for immediate write (additional
erase cycles will not be required before writing information to wiped blocks). Effectively,
the SE command restores the SSD to factory defaults and write performance. When
properly implemented [4] [13], the SE command will result in complete wipe of all
storage regions of the SSD drive including any reserved, system and service areas.

An example of properly implemented secure erase is found in Intel self-encrypting
SSD drives. According to Intel [13], “Executing a SECURE ERASE function, such as
that found in the Intel® SSD Toolbox, will cause the Intel SSD 320 Series drives
to generate a new internal encryption key.” This will instantly render unusable
all the encrypted user data stored on an Intel 320 Series SSD (and other devices
supporting hardware-level full-disk encryption).

Cannot Recover

The inability to reliably recover erased information is another side of the same
coin. The use of wear leveling will cause extensive use of the drive’s storage capacity,
making use of previously unoccupied blocks of data at the time each write operation
commences. Even repeat writes to the same file (e.g. the page file) will cause the
entire content of the SSD drive to become “dirty”, leading to severe decrease in
performance with write speeds being much slower than usual. This occurs because
flash technology used in SSD drives requires blocks to be erased before the controller
can perform a write operation on them. This property is unique to storage devices
based on the flash technology, and is very different from how traditional magnetic
types of media handle write requests.

As the process of erasing previously occupied blocks tends to be much slower
compared to reading and writing, SSD drives full of “dirty” blocks will require
significant time to write even a single block of data as no empty (erased) blocks
exist. This lead SSD manufacturers to design a process performing garbage collection,
erasing “dirty” blocks in background and making them available for fast write operations
again.

The issue with garbage collection is that neither the drives nor their controllers
know exactly which blocks are actually occupied by files or system structures of
the operating system, and which blocks are no longer used and are just “dirty”.
While the controller could mark blocks that were remapped to another blocks as a
part of a wear leveling process, this information would only slow down the process
of the drive being filled up with “dirty” blocks during normal use of the drive
that typically involves creating, writing, modifying and deleting files.

In order to mitigate this issue, SSD designers developed an interface allowing
the operating system (e.g. Windows, Linux, Mac OS X etc.) to inform the controller
that certain blocks are no longer in use via the TRIM command [6]. This allows the
internal garbage collector to electronically erase the content of these blocks,
preparing them for future write operations.

Blocks of data processed by garbage collector are physically erased. Information
from such blocks cannot be recovered even with the use of expensive custom hardware.
Forensic researchers named this process as “self-corrosion” [7] [12].

SSD Self-Corrosion

Today’s SSDs self-destroy court evidence through the process that can be called
“self corrosion”. Garbage collection running as a background process in most modern
SSDs will permanently erase data marked for deletion, making it gone forever in
a matter of minutes after the data has been marked for deletion. It is not possible
to prevent garbage collection by moving the disk to another PC or attaching it to
a write blocking device. The only way to prevent self-corrosion is physically detaching
the disk controller from flash memory chips storing the data, and then accessing
the chips directly via custom hardware [see "Hardware for SSD Forensics"].

TRIM: Myths and Reality

A common misconception is that discarded blocks of an SSD drive are immediately
erased. This is not usually the case. Instead, the way the TRIM command operates
is considering the contents of discarded blocks as indeterminate (the “don’t care”
state) until the moment these blocks are physically erased by a separate background
process, the garbage collector. In other words, the TRIM command does not erase
the content of discarded blocks by itself. Instead, it adds them to a queue of pending
blocks for being cleared by the garbage collector.

TRIM, image from
http://www.corsair.com/us/blog/how-to-check-that-trim-is-active/

Exceptions

The “cannot recover” rule does not apply if the TRIM command has not been issued,
or if TRIM is not supported by any link of the chain. If this is the case, information
from SSD drives can be recovered in pretty much the same way as from a traditional
hard drive [8][9].

The TRIM protocol will be disabled, or is not supported altogether, if at least
one of the following conditions is met:

• Old SSD drivesOlder SSD drives do not support the TRIM command. For example, Intel started
  manufacturing TRIM-enabled SSD drives with drive lithography of 34nm (G2); their
  50nm SSDs do not have TRIM support. [10]
• Old versions of WindowsIn Windows Vista and earlier versions, the TRIM protocol is not supported, and
  the TRIM command is not issued.Possible exception: TRIM-like performance can be enabled via
  certain third-party solutions (e.g. Intel SSD Optimizer, a part of
  Intel SSD Toolbox).
• Old versions of MacOS XMac OS X started supporting the TRIM command for Apple supplied SSD drives since
  version 10.6.8. Older builds of Mac OS X do not support TRIM. In addition, user-installed
  SSD drives not supplied by Apple itself are excluded from TRIM support.
• (Windows) File systems other than NTFSAt this time, only NTFS-formatted partitions receive full TRIM support in Windows.
  Volumes formatted with FAT, FAT32 or other file systems are excluded.
• External drives, USB enclosures and Network Attached StorageThe TRIM command is fully supported over the SATA interface, including the eSATA
  extension, as well as SCSI via the UNMAP command. If an SSD drive is used in
  a USB enclosure or installed in certain types of NAS storage, the TRIM command
  will not be communicated via the unsupported interface.
• PCI-Express SSDsInterestingly, the TRIM command is not natively supported by any version
  of Windows for high-performance SSD drives occupying the PCI Express slot.Possible exception: TRIM-like performance can be enabled via
  certain third-party solutions (e.g. Intel SSD Optimizer, a part of Intel SSD
  Toolbox).
• RAIDAs of this writing, the TRIM command is generally not supported over RAID configurations
  (with few very rare exceptions) [10]. SSD drives working as part of a RAID array
  can be analyzed.
• Logical corruptionSurprisingly, SSD drives with corrupted system areas (damaged partition tables,
  skewed file systems etc.) are easier to recover than healthy ones. The TRIM
  command is not issued over corrupted areas [11], because files are not properly
  deleted; they simply become invisible or inaccessible to the operating systems.
  Many commercially available data recovery tools (e.g. Intel® Solid-State Drive
  Toolbox with Intel® SSD Optimizer, OCZ SSD Toolbox) can reliably extract information
  from logically corrupted SSD drives.
• Encrypted volumesSomewhat counter-intuitively, information deleted from certain types of encrypted
  volumes (some configurations of BitLocker, TrueCrypt, PGP and other containers.)
  may be easier to recover as it may not be affected by the TRIM command. Files
  deleted from such encrypted volumes stored on an SSD drive can be recovered
  (unless they were specifically wiped by the user) if the investigator knows
  either the original password or binary decryption keys for the volume.

Encrypted Volumes

Encrypted volumes and SSD drives don’t play well together due to the wear leveling
and performance issues described above. In many configurations, the crypto containers
will encrypt the entire space on the drive, including free space. This turns every
write on that disk into a re-write, which significantly slows down write performance
on SSDs. The manufacturers of crypto containers recognized the issue and introduced
ways (such us various configurations and advanced options) to mitigate the issue
by releasing unused space back to the SSD controller, which in turn weakens overall
security (as free unencrypted sectors are easy to tell).

If an encrypted volume of a fixed size is created, the default behavior is also
to encrypt the entire content of a file representing the encrypted volume, which
disables the effect of the TRIM command for the contents of the encrypted volume.

A dedicated research is required to investigate these options. At this time one
thing is clear: in many configurations, including default ones, files deleted from
encrypted volumes will not be affected by the TRIM command. Which brings us to the
question of the correct acquisition of PCs with encrypted volumes.

Forensic Acquisition: The Right Way to Do

The right way to acquire a PC with a crypto container can be described with the
following sentence: “If it’s running, don’t turn it off. If it’s off, don’t turn
it on.” Indeed, the original decryption keys are cached in the computer’s memory,
and can be extracted from a Live RAM dump obtained from a running computer by performing
a FireWire attack. These keys can be also contained in page files and hibernation
files. Tools such as Elcomsoft Forensic Disk Decryptor can extract decryption files
from memory dumps and page/hibernation files, decrypting the content of encrypted
volumes.

Hardware for SSD Forensics

At this time, most forensic researches involving the investigation of SSD drives
are still performed on dedicated but still regular computers. SSD drives are either
attached directly to the computer’s SATA interface or connected via a write blocking
device of the same type that is also used to investigate magnetic hard drives. While
write blockers do prevent user-induced modifications to the data stored on the SSD
drive, they have nothing to do with the operation of the TRIM command and the disk’s
internal garbage collector. It is essential to realize that an SSD drive connected
via a write blocking device will continue performing background garbage collection,
possibly destroying the last remnants of deleted information from the disk.

Preventing the operation of internal garbage collection is only possible by physically
disconnecting the built-in controller from actual flash chips, and accessing information
stored in the chips directly. At this time, this method is far from being popular
as it requires special skills and custom hardware.

SSD controller and flash memory blocks, image taken from

Custom Hardware: The Future of SSD Forensics?

By physically detaching the controller and using custom hardware to read information
directly from the flash ships, investigators could extract traces of destroyed information
that could be stored in various areas of the flash chips.

Custom SSD recovery hardware [4]

A group of scientists from University of California [4] designed an FPGA-based
device providing direct access to flash chips of the SSD drive while bypassing the
controller. The researchers estimated the cost of their prototype as $1000, while
their estimate for building production units using microcontrollers instead of FPGA’s
was as little as $200.

Is this the future of SSD forensics? While custom devices such as those built
by Californian researchers may help forensic specialists extract some extra traces
from certain SSD drives, other researchers suggest that most information is lost
from an SSD drive in just a few counted minutes after the user deletes a file or
issues a quick format command. The need to maintain custom hardware as well as the
need of having specially trained staff for using this method will only make it justified
for very few select cases.

Conclusion

SSD forensics is different. SSDs self-destroy court evidence, making it difficult
to extract deleted files and destroyed information (e.g. from formatted disks) close
to impossible. However, the correct acquisition technique may result in acquiring
the original binary decryption keys, allowing investigators to access information
stored in encrypted volumes, which may provide access to more information than available
in unencrypted areas of SSD drives. In addition, numerous exceptions exist that
effectively prevent mechanisms causing evidence self-corruption on SSD drives. Currently,
SSD drives used in NAS devices, participating in RAID configurations, and connected
as external devices via USB and FireWire are excepted from evidence self-corruption.
Old versions of Windows, Mac OS and Linux do not support SSD’s garbage collection
mechanisms, and are also exceptions.

The playfield is changing very fast. What’s true today may no longer apply tomorrow.
We’ll keep an eye on what’s happening in the industry, releasing an updated report
in a few months.

About the Authors

Yuri Gubanovis a renowned computer forensics expert. He is a frequent speaker at industry-known conferences such as EuroForensics, CEIC, China Forensic Conference, FT-Day, ICDDF, TechnoForensics and others. Yuri is the Founder and CEO of Belkasoft. Besides, Yuri is an author of f-interviews.com, a blog where he takes interviews with key persons in digital forensics and security domain.You can reach Yuri Gubanov at yug@belkasoft.com or add him to your LinkedIn network at http://linkedin.com/in/yurigubanov

Oleg Afonin is an independent expert and consultant in computer forensics. You can reach Oleg at aoleg@voicecallcentral.com

Literature

[1] Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?
http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf

[2] http://en.wikipedia.org/wiki/Schr%C3%B6dinger’s_cat

[3] Wear Leveling http://en.wikipedia.org/wiki/Wear_leveling

[4] Reliably Erasing Data From Flash-Based Solid State Drives
http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf

[5] SSD Data Wiping: Sanitize or Secure Erase SSDs?
http://www.kingston.com/us/community/articletype/articleview/articleid/202/ssd-data-wiping-sanitize-or-secure-erase-ssds.aspx

[6] TRIM http://en.wikipedia.org/wiki/TRIM

[7] Modern SSDs self-destroy court evidence
http://www.ssdfreaks.com/content/612/modern-ssds-self-destroy-court-evidence

[8] Retrieving Digital Evidence: Methods, Techniques and Issues
http://forensic.belkasoft.com/en/retrieving-digital-evidence-methods-techniques-and-issues

[9] Belkasoft Evidence Center 2012 Help: Carving
http://forensic.belkasoft.com/en/bec/en/Carving.asp

[10] Intel SSD, TRIM support
http://www.intel.com/support/ssdc/hpssd/sb/CS-031846.htm

[11] Recovering Information from SSD Drives: Myths and Reality
http://hetmanrecovery.com/recovery_news/vosstanovlenie-informacii-s-ssd-nakopit.htm

I remember how excited I was to test TIM (Tableau IMager) on a multi core system and see it outperform the competition.  It was just as exciting as finding out about Access Data’s FTK Imager CLI.  It was not about the performance improvement (since there was none) but the OS support and the ability to encrypt images using a certificate.

It’s been working great, but in the latest version something has changed.  Using version 3.1.1 to acquire an image on Windows 7 Professional 32/64 bit worked as advertised.

C:\temp\ftkimager>ftkimager.exe \\.\physicaldrive1 c:\temp\usb –e01 –outcert C:\temp\pub.cer
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Creating image…
Image creation complete.

The image was opened in FTK Imager 3.0.1 using the private key and the given password and FTK Imager was happy to comply.  Of course, the question can come up to verify the image in the tool that created it.  Surprisingly, the newest version of the software gave an error message and refused to take the private key with the password that worked just fine in GUI.

C:\temp\ftkimager>ftkimager.exe c:\temp\usb.e01 –verify  –incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Error setting up decryption: DecryptWithPrivateKey: Cert encrypted and password failed: c:\temp\pri.pfx
** AD Decryption setup failed.

This seemed to be odd since new version of software supposed to fix problems and not break what was working just fine.  The natural thing was to think that it must have been the command line options I used, the spelling of words, or the spaces.  Then, the private key and password were blamed.  Then, in a final attempt, I wanted to see if the previous version was able to access the image and verify it.  It worked.  It felt grate to verify that I do know how to spell and remembered my password correctly.  The image was not lost and a lesson was learned about the value of tool testing.

C:\FTK ImagerCLI 2.9.0_Win32>ftkimager.exe c:\temp\usb.E01 –verify –incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v2.9 CLI (May 11 2010)
Copyright 2006-2010 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Verifying image…
Image verification complete.
[MD5]
 Computed hash: 08d27c2233aee57c95ddecb0386e1e6f
 Image hash:    08d27c2233aee57c95ddecb0386e1e6f
 Report hash:   08d27c2233aee57c95ddecb0386e1e6f
 Verify result: Match
[SHA1]
 Computed hash: 38e1d87975594abd14608960e2236737619f08db
 Image hash:    38e1d87975594abd14608960e2236737619f08db
 Report hash:   38e1d87975594abd14608960e2236737619f08db
 Verify result: Match

Problems like this must be treated as a valuable lesson that no books and training classes can relay.  Know your tools and you should treat every update with caution.  Maybe there is a good reason for projects like NIST’s Computer Forensics Tool Testing (CFTT) Project.  It would have been an interesting feeling to find out that you couldn’t decrypt an encrypted evidence file.  There is no substitute for risk management and methodological problem solving.  I do hope that AccessData will remedy this issue and will not create another “teachable moment” in future releases.

P.S. It still does not make sense why the User Manual PDF file does not show the — ( double dashes ) that are required for the options to work.  It’s been like that since the first release.