Hacking Forensics#1: Recovering Deleted Files

####  THIS IS A MUST READ. TRUST ME...  ####
 ===================================================

======== RECOVERING DELETED FILES OFF USED MEDIA =========

============ USING COMMAND LINE IN UBUNTU =============

===================================================

***DISCLAIMER: The information and techniques used in this tutorial are for education purposes only. They are to help you understand a forensic analysis on a hard drive using Linux. I am not responsible for what You may or may not do with any images or files you recover using the techniques provided in this tutorial. More importantly, I am not responsible for any damages you may cause on your hard drive due to improper use of the Linux "dd" command. Try this at your own risk... and read everything before you begin. Thank you, and ENJOY! ****************

-------------------------------------------------- INTRO ----------------------------------------------------------------

   
     I Know this is a LONG read, and maybe you don't have time to read it all right now... but this is the first Legit HACKING tutorial I have made and with it comes endless opportunity... I guarantee you will have fun with this tutorial and you will be quite surprised as to what you find...

     Perhaps you had some important files on a flash drive and accidentally deleted the folder the files were in because you thought it was empty. Perhaps you just formatted your computer like you regularly do every other month, but this time you realized you forgot to back up your files. Or perhaps you bought a phone off of Craigslist or eBay and the seller gave you their old SD card (and they deleted all the files off of SD card and formatted the phone before giving it to you). Whatever the case may be, unless the file was deleted with tools designed to do a Full and Proper delete... odds are nearly ALL the files that were on the phone can be recovered... here is how! ==

--------------------- DETERMINE YOUR DRIVE'S PATH WITH FDISK ----------------------

     Ok, so you want to do some forensic analysis on an image file of a hard
drive (.img), maybe a virtual hard drive (.vdk, in virtual box at least), a physical
disc or CD/DVD(.iso,.bin, etc etc), or any other file that represents the contents of a device or storage container. Well the first step, is to actually Create that container... Your hard drive is NOT already just one file ready to be poked and prodded. Linux has a useful tool for cloning drives and saving them as a single .img file, and this command is called "dd"... dd is a common Unix program whose primary purpose is the low-level copying and conversion of raw data.

First, determine where the drive is located in Ubuntu...
     In Ubuntu, every storage container is located at /dev/sd[LETTER][NUMBER]
where /dev/sda and /dev/sdb (when the Letters are different) are completely different drives (maybe two different drives on two different SATA connections in your computer, or maybe one drive IN your computer and one small 2GB flash drive plugged into the back of your computer)... and where /dev/sdc1 and /dev/sdc2 (same letter, different Numbers) are two different Partitions on the SAME physical storage container, such as Ubuntu on sdc1, and Windows XP on sdc2. Or maybe just Linux on sdc1 and the Swap partition that Linux uses for storing page tables outside of RAM in sdc2.
Either way... to see all the devices and any of their sub-partitions, type:

$>sudo fdisk -l

Which produces output like...

[SPOILER]
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c5b3a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      180170  1447213056   83  Linux
/dev/sda2          180170      182402    17923073    5  Extended
/dev/sda5          180170      182402    17923072   82  Linux swap / Solaris

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x182f182e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        9728    78140128+   7  HPFS/NTFS

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009ca9a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1      119370   958836736   83  Linux
/dev/sdc2          119370      121602    17923073    5  Extended
/dev/sdc5          119370      121602    17923072   82  Linux swap / Solaris

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4509da2d

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      121602   976760536    7  HPFS/NTFS

Disk /dev/sde: 1967 MB, 1967128576 bytes
57 heads, 56 sectors/track, 1203 cylinders
Units = cylinders of 3192 * 512 = 1634304 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1        1204     1920955+   6  FAT16
[/SPOILER]

     By looking at the size where it says "Disk /dev/sd[ABCD][1234]: ##### MB/GB", you can determine which path relates to your device, mine is /dev/sde1 for this example.


---------------------------------- CREATING A .img FILE USING dd --------------------------------------

Now clone the device to a file with "dd"... type:

$>sudo dd if=/dev/sde1 of=./My_SD_Card_Image.img

     Where "if"/"of" stand for Input File and Output File respectively... and where you put the path to YOUR drive you want to recover in place of where I put "/dev/sde1"... This will take a while and will be extremely large... I am pretty sure it will be as large as the drive you are cloning... so Do Not attempt to clone your primary drive ON your primary drive... you might end up in the twilight zone with balls growing off your face or something... idk...
This will create a file named, in my case, "My_SD_Card_Image.img" in whatever directory you were in when you executed the previous "dd" command.

****Note: Remember where you created that file so you can type the path out in the next command. Or you can simply run all commands in the terminal from the directory you started in, this way everything will always just be refered to by the file name with no path before it since it is in your current working directory. ****


****MORE IMPORTANT NOTE: Do NOT... I repeat Do NOT get the "if=" and "of=" mixed up and switched... this can Potentially cause you to make a copy of some small flash drive or SD card or whatnot and have it OVERWRITE YOUR ENTIRE HARD DRIVE, or whatever was in the path you put in the "of=" part of the "dd" command. Double check yourself on those parameters before executing the "dd" command. (As long as you don't have some sort of /dev/sd[ABCD] as the parameter for "of", which you Never should anyways, you will be fine.)*********

----------------------------- INSTALLING AND USING FOREMOST ---------------------------------

     Now you have your image file. Hooray! Almost there! Now download a nifty little light weight program called "foremost". If you want to read about it or want to download it from the author's website, go to: http://foremost.sourceforge.net/.
Otherwise, it is in the Ubuntu repository and you can get it by typing:

$>sudo apt-get install foremost

     Ok, now Foremost is installed... go ahead and "man"(manual) foremost to see all of its commands and how it is supposed to be used etc etc... (man foremost)...
After typing "man foremost", certain flags should have caught your eye as to how to run this program to get the best results... Some of the Flags are:

-T = Timestamp the directory they are saved in so you can run it again in the future and it won't just rewrite over your old directory (will save in new one based off new time)
-v = verbose mode. Causes more information of the current state of the program to be displayed on the screen.
-t = type. Specify the type of files you're going to attempt to recover. If no -t parameter is give, the program looks for ALL types of files by Default.
-i = file (i = image). This is the flag you would give before specifying your image name, or the path to your image if it isn't in your current working directory.
-o = output directory. If "-T" isn't given, you must use "-o /directory/" to specify an output folder to save all of these recovered files into.

So, assuming you want to ONLY look for JPEG files to recover, your final command should look something like this:

$>sudo foremost -v -T -t jpg -i 2GB_SD.img

     A folder named something like "output_DAY_MONTH_#DAY-TIME-YEAR" should be created in whatever directory you were in when you ran the foremost command. Then, the terminal should spew out data looking like:

File: 2GB_SD.img
Start: Thu May  5 13:52:39 2011
Length: 1 GB (1967128576 bytes)

Num      Name (bs=512)         Size      File Offset     Comment

0:      00002433.jpg          71 KB         1245696      
1:      00002689.jpg          86 KB         1376768      
2:      00002881.jpg          50 KB         1475072
    .
    .
    .
    .
    .
8144:    01860033.jpg           30 KB       952336896     
8145:    01860097.jpg           20 KB       952369664     
8146:    01860161.jpg           35 KB       952402432     
8147:    01860289.jpg           42 KB       952467968     
8148:    01860417.jpg           35 KB       952533504     
8149:    01860545.jpg           44 KB       952599040     
**********|
Finish: Thu May  5 13:44:49 2011

8150 FILES EXTRACTED
    
jpg:= 8150
------------------------------------------------------------------

Foremost finished at Thu May  5 13:44:49 2011

     Now you should have a folder, with another folder inside it named "jpg" full of JPEG files that were recovered from the 2GB SD card (or whatever you took an image of)... in my case I recovered 8,150 JPEG files. While this may seem like a lot of pictures, keep in mind that MANY of them are duplicates... the same picture often times comes up like 9 or 10 times. Also, ANY picture you EVER viewed for whatever reason, even small thumbnails that you see but don't click on, is stored to memory at some point in time. Therefore all images from surfing the web countless numbers of time over and over have all built up and lots of them are still intact just sitting in an area of memory that isn't frequently accessed for whatever reason. That is the main reason that you can recover sooooo many pictures

     I find that the best way to sift through all the pictures is to have your "view" tab set to "Icons", instead of "List" or "Compact". This way you can just scroll through all the thumbnails and look for anything of interest... Hope you all enjoyed this post... the first "real" hacking tutorial... Happy Hunting!

------------------------------- MEMORY MANAGEMENT EXPLAINED ----------------------------

Wondering why some pictures come up repeatedly? Read on...

     Ok, so you download a picture from a website. That picture first gets stored somewhere in the browsers memory or cache (possibly a temporary files folder such as /temp/), before you even decide you want to keep it on your phone. THEN you decide you want to save it to your phone. The picture is then copied to which ever folder, and subsequent memory location, your pictures are stored in/at. Now, whenever you VIEW that picture it MAY be moved to a different address on the SD card which is the address for files currently being used (This is usually NOT the case... usually it would be loaded into your phones RAM for quicker access, however just like certain apps, such as Apps2SD, save Apps to your SD card, others may keep files in a specific area of the SD card as they run in order to not hog all of the phones RAM.) Then, if you go to send that picture to someone with an emailing App or your SMS app, the picture may get moved to another location as well... perhaps it gets moved to wherever your SMS app stores all the messages. You could argure that it just POINTS to the memory location of the picture and doesnt actually copy it... and maybe in some phones this is true (certainly makes sense). However, on Android phones and the iPhone if I send my friend a picture, and then delete that picture from my Gallery/My Photos and go back to my SMS messages and click the picture I just sent, it will open back up full screen just fine... Proving it is, yet again, somewhere else in memory. And you get the idea... this is why a particular picture may show up 10,20, sometimes like 50 times...

     You will be surprised what you are able to recover... memory management works in mysterious ways... you may find that the picture you deleted just a week ago is no where to be found (or maybe like 1/5 of it was recovered 2 or 3 times), but some picture that you took on your OLD Phone like 4 years ago is still perfectly in tact and is all over the phones memory in Several places... I could explain why this happens in depth... but it is beyond the scope of this tutorial and plus I have already written a novel lol...

------------------------------- DELETING FILES THE REAL WAY --------------------------------------

     So, you might be asking "But 123loaded, I deleted my files, why are they still there?!?"... good question. Your hard drive, or any media storage device that relies on zeros and ones to store data, is broken down into blocks of memory. These blocks vary in size, but the typical block size is roughly 512KB. When you tell your computer to "delete" a file that takes up 16 blocks (an 8MB file in this case), rather than go through and set ALL the bits to '0' or '1', the computer simply sets a flag in each block of memory to say "This block consist of garbage data, it Can be over written". Put more simply, there is one Bit (a 0 or 1), that is designated the "Write" bit. If it is set to '1', writing on that block of data is allowed, if it is set to '0', writing is Not allowed.

     To save time, modern operating systems do not actually delete what you ask it to delete. Instead, the delete operation just switches All "Write" bits to '1' throughout all blocks of memory associated with the specific file or files to be deleted. Therefore the computer does not recognize those blocks of data as having any information, and it ignore those blocks of data as if they're empty... however, ALL the data is still in tact and on the hard drive... someone just needs the right tools to search the drive while ignoring the bit that controls whether the data is relevant or not (as seen in above tutorial).

     A REAL deletion will go through EACH AND EVERY BIT of data and set it to all 0/1s... this can be accomplished in Windows with a program called CCleaner, or a few other good ones that guarantee your files cannot be recovered once you have chosen to wipe them. I think the next tutorial I do will be how to use CCleaner in Windows, and how to also permenantly delete files in Ubuntu so you are protected from someone on craigslist purchasing your old phone and SD card and turning you and your girlfriend into Original Content... Until next time, be careful who you sell used SD cards/flash drives/hard drives to, or even who you lend them to...

Enjoy... You are welcome =)
123loaded, making sure you are Also... Reloaded.