JTAG and a Pattern Locked ZTE x500

The other day I was handed a pattern locked ZTE x500 Android based cell phone using the Metro PCS wireless network.  Since I have not JTAG’ed one of these devices before, I didn’t know if this device was even supported.  I reviewed my various JTAG devices and discovered this specific phone was not directly supported.  I headed over to PhoneScoop (http://www.phonescoop.com/phones/phone.php?p=3368) to learn the device specifications.  According to PhoneScoop, this device has a 600 MHz Qualcomm MSM7627 processor.  Sweet, RIFF and some other tools support this processor/controller.  Now I just need to find the Test Access Points (TAPS).

I Googled the device looking for the phone’s pinouts.  Nothing.  I have the ‘JTAG Finder’ (http://www.jtagfinder.com/x/), but I haven’t had the best luck with it. 

The next step was to take the device apart.  After removing the back cover and backing, I was presented the this.  Well at least the TAPS are easy to find.

Upon closer inspection of the QR code next to the TAPS, I could see the QR code sticker was covering up some writing.  I removed the QR code and couldn’t believe what I found.

All the TAPS are labeled!!  Well that just simplified my life.  I soldered my wires according to the labeled TAPS, hooked up my power supply, micro USB cable, selected Qualcomm MSM7xx in RIFF, and was easily able to download the NAND.

Using the Python scripts discussed in previous posts, I was able to get the swipe pattern.

So why is this note worthy???  I have never seen a phone’s TAPS labeled like this!  I wish LG would do this.  

JTAG and a PIN locked Samsung SPH-M820

In this post I will talk about my experience with a pin locked Samsung SPH-M820 (AKA: Samsung Galaxy Prevail / Precedent) on the Boost Mobile wireless network.  According to Phone Scoop (www.phonescoop.com), this cell phone is also available from TracFone.  Per the User Manual, this phone supports a numeric 4 to 16 digit personal identification number (PIN) code.

 

Ok, the device wants me to enter a PIN number.  I don’t have it.  I connected the device to a computer and typed ‘adb devices’ in a terminal window.  The computer did not recognize the phone.  USB Debugging may not be turned on or the manufacturer has disabled the USB port.  If the display field below the ‘List of devices attached’ is all question marks (??????????????) where the device’s serial number should be listed, you have a driver issue that needs to corrected.  However, in my case, the ‘List of devices attached’ field was blank.  No question marks.  Nothing.  Since the computer could not communicate with the cell phone, USB Debugging is not turned on.  One trick I learned; when I plug in the USB cable into the phone (and the other end of the USB cable is already plugged into the computer) I watch the top Status Bar on the phone.  If USB Debugging is turned on, a message will usually flash in the Status bar indicating USB Debugging is turned on.  If no USB Debugging message is displayed, there is a good chance USB Debugging is turned off, which is the default setting.

Since the Samsung SPH-M820 phone is supported by my RIFF box, I decided I would attempt to JTAG the device, download the NAND, and run the Recover Android Pin python3 script from CCL Forensics against the NAND dump.

I disassembled the phone and located the JTAG Test Access Port (TAP).  I used a fiberglass pen (http://www.amazon.com/Scratch-Brush-Fiberglass-Colors-vary/dp/B0019V18D2/ref=sr_1_1?ie=UTF8&qid=1337799235&sr=8-1) to clean off any accumulated residue off the TAP.

 

If you read my previous post, you saw first hand that my soldering skillz need some work.  A good friend offered the following JTAG TAP soldering tips: bring the solder iron to highest heat; use a fine solder tip; place the solder iron tip on the TAP and hold for 3-4 secs; bring solder wire to the TAP and brush up to the solder tip; let it melt and ball up; remove the solder wire; remove the solder iron; you should be left with a nice ball of solder on the TAP; now add a little solder to the end of the wire; now when you solder, you are just trying to melt the solder ball on the TAP and the little bit of solder on the end of the wire, not the TAP itself.  Excellent advice.

Once I located the pinout for this phone, I was able to solder the correct wires to the TAP.  Since I prepped the TAP earlier, the actual wire soldering process took less than a half hour.

I connected the JTAG wires to my RIFF Box.  Next, I connected the USB cable from the RIFF Box to the phone’s printed circuit board (PCB).  I applied power to the PCB using my power supply; connected the RIFF Box to the computer via USB; then launched the JTAG Management software.

I was having a heck of a time getting the software to connect to the phone.  When I  powered on the phone, the power supply Amp meter readout started at 0.06 amps, then quickly climbed to 0.15 amps.  The phone / software never connected when the Amp meter read 0.15 amps.  After several attempts, I was able to get the software to communicate to the phone.  I had to time it just right, when the Amp meter read 0.06 amps.  Any other amp meter reading and the phone / software would not communicate with each other.

  

Once the memory dump process began, it took about an hour to complete.

I ran the Recover Android Pin python3 script against my NAND dump.

The recovered PIN is 0805. 

I put the phone back together, cleaning up my solder mess.  It looks almost like new…

I powered up the phone and typed in the recovered PIN number.

SWEET!!  Now I just need to turn on USB Debugging and Stay Awake.  After that, I can use whatever cell phone forensic software available (commercial or open source) to download the contents of this phone.

Questions, comments, soldering recommendations????

JTAG and HTC EVO 4G

I came across a cell phone the other day that had the Android pattern lock.  This was a HTC EVO 4G, which is using the Sprint wireless network.

In order to gain access to the pattern locked device, I thought I would root the device.  I checked to see if USB debugging was turned on by attempting to connect to the device using Adb.exe.  It wasn’t..damn.  Not too many options available at this point. 

I had been reading up on the JTAG process from various posts.  The actual soldering / JTAG process seemed to be the most difficult part of the process.  I was only able to successfully complete this task after a good friend helped me get a clear picture of the overall process.

I bought my RIFF Box and assorted jigs from GSM Server.  Yes, the parts came from Hong Kong.   http://gsmserver.com/shop/gsm/riff_box_jtag.php

I purchased additional cell phone disassembly tools from Amazon.com and soldering equipment from my local MarVac Electronics store.  I am ready to do this!!..so I thought.

Prior to soldering the wires to the HTC’s printed circuit board (PCB) test access port (TAP), I took apart other junk cell phones and attempted to hone my soldering skills.  After ruining a couple of junk cell phone PCB’s along with some successful soldering attempts, I decided ‘I got this’.

My next course of self instruction was to watch a couple of HTC EVO 4G disassembly videos on YouTube.  After watching about two or three 5 minute disassembly videos, I thought this is going to be a piece of cake!!

I was able to successfully disassemble the HTC EVO 4G down to the PCB.

 

If your soldering skillz need some work (like mine), this can be a long process.  You  need to connect/solder specific wires from the RIFF Box to the HTC’s JTAG TAP.  This requires you to obtain documentation of the HTC’s JTAG pinout.  Luckily, since RIFF Box supports the HTC EVO 4G (AKA: HTC Supersonic), the pinout diagram is included in the RIFF JTAG Management software. After a couple of hours, I was done soldering.  YES!!

Now to connect all the parts so I can dump the HTC PCB’s NAND.  I provided power to the HTC PCB using a Mastech Single-Output DC Power Supply, model# HY3003D.  I connected my JTAG wiring from the HTC PCB to the RIFF Box.  I next connected a USB cable from the computer to the microUSB slot on the HTC PCB.  I connected the RIFF Box to the computer via USB and launched my RIFF JTAG software manager.  I next turned on the HTC PCB.  I knew the device was running because the Amp meter on my power supply was registered about a .10 amp draw.

With the RIFF JTAG software manager up and running, I selected the HTC Supersonic phone from the supported phone drop down menu.  Next I selected the DCC Read/Write tab, then selected ‘Read Memory’.  For all my hard work, I was presented with an error message that basically said the software was not talking to the phone.  To make a long story short, after about an hour of trying to figure out what I did wrong, I discovered I soldered a wire to the wrong HTC PCB JTAG TAP.  I attempted to de-solder the one wire.  In the process, I de-soldered two adjacent wires.  Great!!!! Another hour passed before I once again had all the wires soldered in their correct location.  This time I was able to connect to the device and download the NAND.  The one gigabyte download to over an hour to complete.  Yah, the download crashed once or twice..Ok, a total of five times.  But I was able to continue each time from where the process previously left off.

Using the Python3 GenerateAndroidGestureRainbowTable.py script from CCL Forensics (http://www.ccl-forensics.com/), I created the SHA1 rainbow table of hash values for pattern locks from 3 to 9 positions.  The python script creates a rainbow table,  storing the SHA1 hash values in a SQLite database.  This might be a great time to take a break while the database is being created.  The process took about 30 minutes to complete.  

Once the script was finished, I was left with a SQLite database called ‘AndroidLockScreenRainbow.sqlite’. The SQLite database should be around  130MB in size.

My next step was to use the Android_GestureFinder.py python script from CCL Forensics.  Basically this script will parse my HTC EVO NAND dump for the SHA1 pattern lock hash value.  Once a hash value is located, the script will compare this hash value with the hash values stored in the AndroidLockScreenRainbow.sqlite database.  When a SHA1 hash value match is located, the script will present you with the offset where the hash value was located within the NAND dump, the actual SHA1 hash value, and the pattern associated with the hash value.  NOTE TO SELF:  Make sure the Android_GestureFinder.py and the AndroidLockScreenRainbow.sqlite are in the same directory.  If all goes well, you should get something like this…   

Ok, so the pattern lock is 0, 3, 4, 1, 6  What does that mean?

Picture it this way:

I re-assembled the cell phone after de-soldering all my little wires.  The device powered up and presented me with the ‘Draw pattern to unlock’.  Drawing the above pattern, I was able to unlock the HTC EVO 4G.  I immediately went into the Development settings and turned on USB Debugging, and Stay Awake.

From here, I can use whatever cell phone forensic software I have to download (physical or logical) the contents of the cell phone.

Hmmm.  My next project just arrived.  A PIN locked Samsung SPH-M820 cell phone on the Boost Mobile network…..  

Me and Windows FE (Forensic Environment) Part 1

Wow…It has been a long time since my last post…

I was asked to present a Creating a Windows FE boot disk segment to our local HTCIA chapter.  In Part 1, I will go through the steps I used to create a Windows FE bootable CD.  With luck, and maybe not so large a gap, Part 2 will go into documenting the use of certain applications within your newly created Windows FE environment.

First some background on Windows FE.  An excellent source on the beginnings of Windows FE and build tutorials can be found on Brett Shavers blog: http://winfe.wordpress.com/2010/05/28/windows-fe/.  I also highly recommend downloading (and reading) Brett’s Users Guide to WinFE.  During your read, you will be directed to http://reboot.pro for current tools to create your Windows FE bootable CD.

For my project/presentation, I downloaded the following items:
1. WinBuilder (version 082) http://reboot.pro/files/file/4-winbuilder/
2. The WinFE script v2.2 (Public Release) for WinBuilder.  I used v2.2 because I am familiar with this script, but as you can see by the link, public release v3.0 is available. http://reboot.pro/files/file/113-winfe-win7pe-sex64x86-v3-publicreleasescript/
2a. After I completed the training but before I was able to complete this post, and still wanting to make the Ultimate WinFE build, I added an additional script.  I have included Colin’s Write Protect Script (wp.script).  It can be downloaded here: https://www.box.com/s/065664cc60bd6bd51464
3. FTK Imager from AccessData http://accessdata.com/support/adownloads.  I actually didn’t download it, I had version FTK Imager 3.0.0.1443 already installed on my machine.
4. VMWare Player, version 4.0.2. http://www.vmware.com/. Once installed, I launched VMWare Player to get all the fist time pop-up screens out of the way.
5. ProDiscoverBasic edition (U3 install package) http://www.techpathways.com/DesktopDefault.aspx?tabindex=7&tabid=14  

You will also need a Windows7 install DVD.  A Win7 Recovery DVD might work, but I wouldn't count on it.  Either the x86 bit or x64 bit version will do.

I downloaded WinBuilder.exe, moved it to the root of my c:\ drive, and launched the application.  I first had to select a project to download (bottom center pane) before the left pane populated with options.  I selected the project: win7pe.winbuilder.net/SE.  When the left pane populated, I expanded the Tweaks folder and selected (green check marked) BGInfo.script.  I like to know if the computer is connected to a network, and if it is, what is the device’s IP address and other available computer information.  I next unchecked Languages, keeping the default English.  These are the only changes I made.  As you become more experienced with this product, you can design it the way YOU want.  When I finished with my ‘fine tuning’, I clicked on the ‘Download’ button.

After about 10 minutes, WinBuilder finished downloading the various scripts and launched.  A Window’s pop up informed me WinBuilder was not a trusted application.  I chose to run the application and was presented with this screen.  What you didn’t see was WinBuilder also created a Projects folder on the root of the C drive.

We next need to do some behind the scenes work and copy an expanded ProdiscoverBasic folder (it was downloaded as a zip file) to our C:\Projects\Win7PE_SE\Apps\Portable\Pstart folder.  We will configure the ProDiscover Basic setup later.

Now we need to manually add the WinFE script v2.2 (Public Release) script and the wp.script to WinBuilder.  Navigate to your downloaded scripts and copy the scripts to your C:\Projects\Win7PE_SE\Tweaks folder.  After the copy process is finished, re-launch WinBuilder.exe. and expand the ‘Tweaks’ folder on the left pane.  You should now see, and it should already be green checked, the WinFE (Forensic Environment) and the Write Protect script.  As of this writing, it is important the write protect script is listed last (per the scripts installation instructions).

Ok, now that our WinFE script and Write Protect script is seen by WinBuilder, We need to configure the overall environment. The first item is to select the Boot Manager.  If you have read my recommended reading, you know we need to change the Boot Manger option in the Main Configuration to ‘Standard’.

    

The next change is on the Image Configuration tab.  Since I am NOT using files from the Windows Automated Installation Kit (AIK), I need to instruct WinBuilder to use the WIMMount driver to extract the files from the Windows 7 installation DVD.

Next, expand the ‘Tweaks’ folder.  I checked BGInfo because I want to see various system information displayed on the desktop.  If you didn’t check this when downloading your initial project, you will need to be connected to the Internet when you create your WinFE ISO.  The BGInfo installation files will need to be downloaded from the Internet at the time of compiling.

Clicking on ‘WinFE (Forensic Environment)’ on the left pane populates the right pane with options.  Check ‘Copy Installed FTK Imager from Host Machine’ and navigate to the FTK Imager folder using the ‘Open Folder’ icon.  On my 32-bit Windows Operating System, FTK Imager.exe is located at the following location: C:\Program Files\AccessData\FTK Imager\.  If you are using a 64-bit OS, FTK Imager.exe is located here: C:\Program Files (x86)\AccessData\FTK Imager\.  No other changes are required.



You can click on the ‘WinFE Write Protect Tool’ if you want, but there is nothing to be done here, nor can you make any changes.

Check and Expand ‘Apps’ on the left pane.  Expand ‘Portable’, Check and select ‘PStart and Papps’  We are going to add the ProDiscoverBasic tools to our WinFE project.  On the right pane:  
Add ‘ProDiscoverBasic\Data’ (without the quotes) to the Directory of Apps field.
Add ‘ProDiscoverBasic.exe’ to the Name of exe field.
Check the Start menu box.
Add ‘Forensics’ to the Start menu folder field.
Add ‘ProDiscoverBasic’ to the Name of shortcut field.
Check the ‘Desktop’ box
What you just did was put a ProDiscoverBasic shortcut on the windows desktop in your WinFE environment.

A word of caution.  If you are going to be using a Windows 7 x64-bit install DVD, DO NOT add ProDiscoverBasic to this environment, it will not work in x64-bit builds.

The last thing is to check and expand ‘Virtual Test’ and check VMware Emulation.  This will boot the newly created WinFE ISO in VMWare Player.  This just checks to make sure your build will work.
If you are going to be using a Windows 7 x64-bit install DVD, you will need to make a few more changes to the VMware Emulation configuration settings to make your VMWare session x64 compatible.  Click on the VM ‘More Options’ button. Change the ‘Number of processors’ button to ‘automatic, read from system’.



We are FINALLY getting close to create our WinFE ISO image.  Now we need to point WinBuilder to our Windows 7 install DVD.  Select the ‘Source’ button.



In the Source Directory area, navigate to your Windows 7 install DVD.  If you haven’t put the Win7 install DVD in yet, now would be a good time.  Once that information has been added, click on ‘Play’



If all goes well with your initial settings, you should get something similar to this display.  The process has begun, but this is only half the battle.  For now, just sit back and let the script do its work.  It will take close to 15 minutes to complete.



This next window will pop up.  Don’t let the (Not Responding) fool you.  The program has not crashed.  Just let it run!



Damn…Got an error message.  When I clicked ‘OK’ the process terminated.  Now what?  You need to fix the cause of the error message.  Review the log file to see what caused the error message.



After fixing your error issue, go back to the ‘Main Configuration’ option on the left pane. Click on the ‘Script’ button, right pane in upper left.  Now we need to clear the temporary files.  Click the ‘Clear Temporary Files’ to perform this task.
 


Now you’re ready to try it again.   Click the ‘Play’ button once again and cross your fingers.  If you are presented with a VMWare Player window like this….



CONGRADULATIONS!!!   It works.  You see before you the Write Protect script telling you the 2GB VMWare created hard drive is read only.  If you were using this on a regular computer, all storage media should be listed as read-only.  If the drive is not listed, there might be a driver issue or hardware problem.  When you click ‘Close’, the FE environment will continue to boot up.  Windows drivers will continue to load.  If you get an error at this point, it will be a driver issue.  Its not uncommon on newer machines to get a network device error.  This just means the default drivers within Windows do not support this device.  No problem, unless you need network connectivity.  If you need a working network device are need to add a specific driver for a piece of hardware you will be using, read the documentation, it discusses how to add additional drivers to the WinBuilder WinFE creation process.  When the system has finished booting, you will be presented with your normal Windows GUI desktop.

Ok, now I want to burn my WinFE ISO image to a CD/DVD.  Your newly created ISO image is located in your C:\ISO folder.  Depending on the OS version, you will either have a Win7PE_x86.ISO or Win7PE_x64.ISO or both image files in this folder.  Using your favorite ISO burning software, these are the ISO images files you need to create your Win7 bootable CD\DVD.

I recommend you immediately rename the ISO to Win7FE_x86.ISO (or x64) and move it to a different directory.  If you were to create an additional WinFE ISO images using the same Windows7 install DVD, the newly created ISO file overwrites the old ISO file(without asking permission).

That’s it for now….Enjoy you new WinFE boot disk. 

Don’t forget to do some experimentation and add additional portable apps to your WinFE environment.

Testing My Software Write Blocker!

I was finally able to get a software write blocker installed on my laptop! If you read my previous post, I am using a Windows 7 laptop and was going to install Document-Solutions’ DSi USB Write-Blocker.  This was the only software write blocking application that indicated it was tested, or designed, for the Windows 7 (32 bit and 64 bit) OS. (Note: On 06-20-2011, I learned the ACESLE web site now offers software write blocking for Windows Vista and Windows 7, 32 bit and 64 bit.)

I am also a Helix Pro user.  It would be nice if they would continue to update the product (personal comment).  Oh well…Anyway.  From the Helix Pro. manual is the following validation process.  I used this validation process to test the DSi USB Write Blocker software.  I also added a step, which included accessing the device at the physical level with a hex editor. 

From the Helix Pro. manual: “This process is based on the National Center for Forensic Science (NCFS) 5 step validation process for testing write protection devices (Erickson, 2004). It was originally designed to test the Windows XP SP2 USB software write blocker, but has been adapted to test any hardware and/or software write blockers.
Step #1 – Prepare the media
a) Attach the storage media you will be testing with to your forensic workstation
in write-enabled mode.
b) Wipe the media - validate that this has been successful.
c) Format the media with a file format of your choosing.
d) Copy an amount of data to the media.
e) Delete a selection of this data from the media.
f) On the desktop of your forensic workstation create 3 folders. Call these Step-1, Step-2 and Step-5.
g) Image the media into the Step-1 folder and note the MD5 hash.
Step #2 – Testing the media
a) Remove and then replace the testing media into your forensic workstation.
b) Copy some data to the media.
c) Deleted a selection of this data from the media.
d) Image the media into the Step-2 folder and note the MD5 hash.
e) Validate that this hash value is ''different'' to that produced in Step #1.
Step #3 – Activate the write blocking device
a) Remove the media from your forensic workstation.
b) Attach and/or activate the write protection device.
c) Follow any specific activation procedures for the specific blocker.
Step #4 – Test the write blocking device
a) Insert the media into your forensic workstation.
b) Attempt to copy files onto the media.
c) Attempt to delete files from the media.
d) Attempt to format the media.
Step #5 – Check for any changes to the media
a) Image the media into the Step-3 folder and note the MD5 hash.
b) Validate that this MD5 hash is the ''same'' as the MD5 hash from Step #2.”

My results:

Prepare the media:

Step 1a: I attached a 2GB SanDisk 2GB USB thumb drive device to my laptop. 

Step 1b & 1c: I used the application DiskWipe, downloaded at  http://www.diskwipe.org to sterilize my USB media.  After formatting the USB device, I confirmed the usable partition was zeroed out using a hex editor.

Step 1d:  Four files, totaling 81.2MB, were copied to the newly formatted thumb drive. 

Step 1e:  One file was deleted, leaving three file consuming a total of 28.3MB of storage space on the thumb drive.

Step 1f & 1g: I created the required folders on my desktop and created a forensic copy of the thumb drive using FTK Imager.  The MD5 hash value: 8c494803b54c8a72c67a8ee2aedc7d38.

Testing the media:

Step 2a: The thumb was properly ejected from the laptop. After approximately 15 seconds, the thumb drive was connected to the laptop using a different USB port than before.

Step 2b: Four more files were copied to the thumb drive, for a total of seven files on the thumb drive.  The seven files occupy 41.5MB of storage space on the thumb drive. 

Step 2c: Six files were deleted from the thumb drive.  Currently only one file remains on the thumb drive, occupying 22.4MB of storage space on the thumb drive.

Step 2d: I created a forensic copy of the thumb drive using FTK Imager.  The MD5 hash value: 8a69859fdc18c0d0d0e280a4b44a626d. 

Step 2e: The MD5 hash value in Step 2d is different from the MD5 hash value in Step 1g. 

Activate the write blocking device

Step 3a: I properly ejected the thumb drive from the laptop.

Step 3b and 3c: Having previously installed DSi USB Write Blocker software, I launched the USB write blocking software from Digital Solution, Inc.  I then Enabled the software, which makes Windows Registry changes.

 

Test the write blocking device

Step 4a: The USB thumb drive was again connected to the laptop.

Step 4b: I attempted to copy three files to the USB thumb drive.  I received the following error message during the copy process of the first file.  I continued to receive this error window after several attempts of selecting the ‘Try Again’.  Finally I selected ‘Skip’, only to receive this same error window for the second file I had attempted to copy to the thumb drive.  After selecting ‘Skip’ for the second file, I received this same error message for the third file attempting to being copied to the thumb drive.

Step 4c: I attempted to delete a file from the thumb drive by highlighting the file, then depressing the ‘Delete’ button.  The file was not deleted nor was I presented with an error message.  I next tried to right mouse click on the file, but was not presented with the ‘Delete’ option from the menu.  Finally, I tried to drag the file to the ‘Recycle Bin’.  This also did not deleted the file from the thumb drive.

Step 4d: I attempted to format the thumb drive

but received the following error message.

I was unable to complete the format operation.

Check for any changes to the media

Step 5a & 5b: I re-imaged the device with the USB write blocker software still enabled.  I was presented with the following MD5 hash value: 8a69859fdc18c0d0d0e280a4b44a626d.

I compared this hash value with the results from Step 2d and discovered the two hash values were the same.  This indicates the DSi USB write blocker software worked as designed.  The DSi USB write blocker software prevented disk access during several different types of disk operations.

As indicated earlier, DSi makes Windows Registry changes to prevent disk access at the logical level.  But what about at the physical level?  Does DSi’s changes prevent physical disk access?

I installed and registered a copy of Hex Editor Neo, Professional Edition.  By registering the product(paying for a license), I now am able to use Hex Editor Neo’s physical disk access feature.  The free version of Neo did not offer physical access, just logical access.  I found this true with other hex editors as well.  The demo version of the hex editor only allowed logical access, but paying for a license would allow physical access to the device, if the software supported this feature.

I accessed the USB physical device.  By default, the application opens the physical device as read-only. 

I unchecked the Read-Only box.

I navigated to offset 0x003b8680 and changed this offset from 0x00

to 0xff.  I was able to save my changes, even with the USB write blocker enabled.  I re-imaged the device using FTK Imager.  The MD5 hash was: bd79c8350de71d6f73306a1d0b716c99.

Conclusions:

When the DSi USB Write Blocker software is enabled and I attempted to make changes at the logical level, the DSi USB Write Blocker software prevented the Operating System from accessing the device.

When I accessed the device at the physical level using a hex editor, I was able to make changes to the device without any problems.

The DSi USB Write Blocker operated as designed.  Users of this and other software write blocking products need to remember the registry settings will prevent logical access, but not physical access.

Your comments are always welcome.

Where can I find a cheap ($$$$) write blocker?

I am attempting to use the Windows Operating System as the main OS for my computer forensic needs. However, this particular OS does not offer a safe forensic environment without some assistance.  For this safe forensic environment to occur, I need to have some type of write blocking device (hardware or software) to prevent Windows from ‘touching’ and getting its dirty little finger prints all over my media.

Since this blog is about low cost Windows forensic options, hardware write blockers will not be discussed.  Why…Because they are rather expensive (money wise) and thus do not fit into this blog’s topic.   It is my belief you get what you pay for, so if you find a hardware write blocking device for say…$10.00, well…you get my drift.  And yes, I know, the same can also be said about software write blockers as well.  No matter what product you use, you NEED to validate the product and determine it is operating as designed!

My mobile forensic acquisition machine is a Sony Viao laptop computer with Windows 7 installed (32-bit) and 3GB of RAM.  I have a couple of available USB 2.0 ports and a FireWire 400 port.  I use AccessData’s FTK Imager (http://accessdata.com/support/adownloads) as my acquisition tool.  Its free, I just need to provide AccessData with my email address to download their product.

What software write blocking solutions are out there?  Hmmmm…Back in the day I used a product called ‘WriteBlocker XP (WBXP) Version 6.10’ from the https://acesle.org web site.  This tool was tested by the National Institute of Justice and found to operate as designed.  (http://www.nij.gov/pubs-sum/220222.htm)  However, I no longer have access to this site, and as previously stated, am I using Windows 7, not XP.

I found this white paper on AccessData’s web site (http://accessdata.com/media/en_us/print/papers/wp.USB_Write_Protect.en_us.pdf) discussing how to modify the Windows XP (SP2) Registry to write protect USB devices.  When modifying the Windows Registry, PLEASE be careful.  The paper clearly explains the modification process and even offers a free tool from the National Center of Forensic Science to automate this process.  The NCFS also lists a five step validation process so you can test your handy work.  Even though this is for an XP box, I could modify my Windows 7 Registry and then validate the results, to see if this would be an option.

Another tool brought to my attention is from Document-Solutions, Inc., called DSi USB Write-Blocker (http://document-solutions.biz/downloads/?did=9).  This tool also makes Windows Registry changes, and provides a nice little icon in the System Tray to let the user know when the DSi Write-Blocker is enabled or disabled.  According to the Document Solutions web site, their utility is compatible with the following operating systems.

• Windows XP (w/SP2 and Higher, 32bit & 64bit)
  
• Windows Vista (32bit & 64bit)
  
• Windows 7 (32bit & 64bit)

This tool has potential since it appears to be Windows 7 compatible.

Another tool I was not aware of is from Mid Michigan Computer Forensics Group (http://www.m2cfg.com/usb_writeblock.htm).  The program is called: M2CFG USB WriteBlock. This tool modifies the Windows Registry on a Windows XP (SP2) computer.  There is no mention on the web site if the USB write blocker application has been tested on newer Windows operating systems.  Based on the web site, the M2CFG USB WriteBlock does not initially meet my Windows 7 OS requirements.  Further testing will be needed to see if it is compatible with Windows 7.

Need a USB blocker for the corporate environment?  Check out http://www.netwrix.com/usb_blocker_freeware.html.  Notice I said blocker, not write blocker.  There is a difference.  This application is for the corporate environment.  The free version is for the small office environment.  One of its many uses that I see is the prevention of Intellectual Property theft.  The application will prevent USB devices from being recognized by the OS when plugged into the employee’s computer workstation.  For what I want to do, this is not the application for me, but worth mentioning.

The last software USB write blocker application I am aware of is called Thumbscrew.  This application can be downloaded at http://www.irongeek.com/i.php?page=security/thumbscrew-software-usb-write-blocker.  The author openly warns everyone downloading his application that the program is not 100% forensically sound. This application, like the others, modifies to the Windows Registry to accomplish read-only, or write blocker, status.

Once you have made you selection as to which of the above software write blocking applications you want to try, validate, validate, validate, on a test device BEFORE using the application in the field.

I am going to install and test Document-Solutions’ DSi USB Write-Blocker.  I will let you know how it goes!     

Linux based tools vs Windows based tools

I am not here to discuss the advantages/disadvantages of one OS over the other with regards to computer forensics.  This is more of a competition between friends as to what tools are available in the Linux world and in the Windows world to complete a specific task.  For those of you who are interesting in tools for the Linux OS, please visit my good friend's Linux Sleuthing Blog at: http://linuxsleuthing.blogspot.com/.
The battle has begun!!