Magicrescue to the rescue

I've been running magic rescue on this machine since 9:00 am. It's currently 11:15 am and I have recovered 453 office documents and it is still not done scanning. Apparently, I should have used shred before I installed over Windows XP. None the less, it's recovering a lot of data, but, not the HPA hidden files yet.

Update: 1:52pm and it's still running. We're at 570 files and 336M. I might as well let it keep running. But, I'm going to try changing the options next time around. I'll probably tinker with the default block size, as well as create a recipe file for a gif image. It's picking up every type of Microsoft Office document...sigh...

To be continued...

Update: Well it has finished scanning! Yay! I wish I would have timed it, as I am not sure when it finished Friday night or Saturday morning. The problem now is sifting through all the 1073 files recovered. Only 207 of which are Word docs. If I was thinking, before I deleted the files from HPA space, I would have noted the file size. Oh well, now I'm manually checking to see if the files were recovered. I'm also going to unhide the HPA partition and just run magic rescue just on that partition. We will see if that makes a difference.

Happy Dance!

Preparation
Well, I'm actually getting somewhere with the HPA project now. I had to do a fresh Debian 5.0.3 install, as recovery wasn't working from my latest error. Although, this was inevitable as I didn't have the drive partitioned correctly. Or, as the HPA project needed. So, here is a look at the drive.


#>sfdisk -luS

Disk /dev/hda: 3648 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/hda1 63 16064 16002 83 Linux
/dev/hda2 16065 1975994 1959930 82 Linux swap / Solaris
/dev/hda3 * 1975995 52757459 50781465 83 Linux
/dev/hda4 52757460 58605119 5847660 83 Linux

The /dev/hda4 partition needs to be mounted manually. Which, is probably the way it would be if I were actually hiding data. A red flag would be raised instantly if /etc/fstab contained a partition that was inaccessible. So, I created a partition at the end of the disk, placed a couple images in it, now it's time to hide the partition.

HPA designation!
I have found a great new way to bomb your machine! Just run

#> ./setmax --delta 52757460 /dev/hda

Then try to do something simple like, oh, I don't know, browse the web. Slowly but surely the load on your machine will rise and lock everything up. It's kind of like a slow fork bomb, a la :(){:|:&};:. (Possible suggestion for a red team member at CDC?) It was actually kind of fun to watch the load slowly rise until it halted. Anyway, here's what went wrong. The instructions I have been following to hide data with HPA has an error. (http://niiconsulting.com/checkmate/2006/09/15/hiding-data-with-hpahost-protected-area-in-linux/) The instructions inform you to run, ./setmax --delta D /dev/hda, where D is the starting sector number you want to hide data. (or just designate HPA) I was running ./setmax --delta 52757460 /dev/hda and bombing my system. Thankfully a hard reboot and a restart fixed everything. The D does not indicate the sector number to start HPA space, it is the number of sectors *minus* the end-of-disk. Thank you code comments! So, essentially, I was trying to hide 27GB worth of space on a 30GB drive, when I wanted to hide 3GB.

Here is the command that worked to hide the data:

#>./setmax --delta 5847660 /dev/hda

And to unhide:

#>./setmax --delta 0 /dev/hda

SleuthKit has a handy tool that will detect HPA protected areas called disk_stat. When the partition was hidden disk_stat gave the following output:

#> disk_stat /dev/hda
Maximum Disk Sector: 58605119
Maximum User Sector: 52757459

** HPA Detected (Sectors 52757460 - 58605119) **

And when the data was visible:

#> disk_stat /dev/hda
Maximum Disk Sector: 58605119
Maximum User Sector: 58605119

I also tried to mount /dev/hda4 while hidden and received an error. Very cool!

Well now that the hide/unhide is possible I need to take it up a notch. I'm thinking. Delete the 2 pictures, rehide the partition, and see what I can find with magicrescue. That's on the agenda for today!

Reading and attempting to do other things...

Interesting discussion on crimes in the next chapter of Digital Evidence and Computer Crime. The motives for criminal behavior never change and the laws remain the same. Technologies just open up different avenues for carrying out these crimes. I had a rant all ready here about legislation, net neutrality and John McCain but I will save that for another day.

Enough with current events, on to the HPA disaster I've created! It's funny how quickly the rust appears when you haven't used Linux in a while. Ignorance is bliss in the Windows/Apple world, but I digress. I've installed debian on a junky laptop from work, then needed to resize and create a new partition. The rust is already showing as this should have been taken care of during the initial install. The process took me way longer than it needed to and still may need to be fixed. My next step is using a little script to mark the partition as HPA space, drop data in it, cover it with some dirt and we're done! The only problem is now I am receiving a boot error:

BUG: soft lockup - CPU#0 stuck for 61s! [ipw2200/0:1415]

So, I'll see what I can do otherwise another fresh install may be in order. Which, may not be a bad thing. Did I mention that this was a junky laptop?

Unfortunately, along the way I read the last chapter of the book first. By that I mean that I spoiled the ending by reading about Sleuth Kit. I am attempting to see if hiding data in HPA designated space can be found using different forensic tools. Apparently, Sleuth Kit has no problem finding such data. Now, if I can only get to the point where I can hide the data then I will attempt to find it again.

Again, to be continued...

Since we last spoke...

Well, since the last time I posed, my time has been spent looking at better applications for doing forensic analysis. I have read a couple articles on The Coroner's Toolkit, (http://www.sans.org/reading_room/whitepapers/incident/the_coroners_toolkit_in_depth_651?show=651.php&cat=incident, http://www.giac.org/certified_professionals/practicals/gsec/0325.php). Since some of the data recovered, described in my last post, was corrupted using Lazarus piqued my interest. Now, I have TCT installed on a machine at work, yet have not yet tried to use it.

My next goal is to use a technique for hiding data on the disk, then to see if TCT or the Sleuth Kit can find it. Oh, and by the way, I found the Sleuth Kit at some point and am eager to try it out! The information hiding technique is Hiding Data with HPA. I need to gain a better understanding of how to hide data as well as how to use my tools. As the saying goes, the carpenter is only as good as his tools.

To be continued...

Actual physical evidence!

I have a hard drive that needs data extracted off of it. Here's the situation, there was a folder on this hard disk that somehow was deleted. My job, if I choose to accept it, is to get that data back. (Note: I chose to accept it.)

Going into the situation I expected a hard drive containing a Windows XP directory structure, one user, missing a folder on the desktop. That guess wasn't very close. The drive was NTFS formatted, but that was the extent of my correct assumptions. The drive was possibly a second disk in a workstation being used as a backup drive. There were 2 folders on the drive. A third folder was deleted and needed to be restored along with all recoverable contents.

Since I was working off of a copy of the original disk, I simply popped the drive in the external enclosure and began perusing. The two applications I used are Recuva, and Restoration. Both applications work very well, but each has it's own nuisances. For instance, Recuva can only restore files to the original location on the disk. There was no option to restore files in a different location. So, I decided to try Restoration, which had that functionality. If there was a competition between the two applications, the score would be Restoration 1 and Recuva 0. However, Restoration has a more cumbersome restoration process. Recuva allows a user to select multiple files to restore, where Restoration does not. So, restoring a large number of files is not ideal with Restoration. The score is now Restoration 1 and Recuva 1.

One thing I found very interesting is the inablity of either application to find the actual name of the folder I am attempting to restore. I am able to recover data from the disk with both applications. Yet, since the originating folder was deleted, and possibly over written, both applications cannot pick up the originating folder name. When Recuva finds a file it displays the location to which it will be restored. Since the folder no longer exists, there is a '?' in it's place. What I assumed, was that everything on the disk that would be restored to the '?' location, was data that needed to be restored. There was close to 5 Gig total on the disk that could have been restored. Only 2 Gig was located in the indicated folder.

This was a great learning experience. In the process I found a fantastic article on file carving with a hex editor. I was hoping to use some file carving techniques on this project. Yet, the file types were unknown, leaving me to do some further investigating before restoring any data.

A couple items I would like to continue to explore:

- Whether or not the Folder Name can be discovered off of the disks' inodes.

- How to search for data when someone is really trying to hide it. (Guess that means I have to learn how the hiding process works first.)