Project: UNIX DATA RECOVERY (udr1)

Typos and bug fixes:

• <description> (DATESTAMP)

Use your UNIX skills and tools at hand to enable you to solve a problem in the realm of raw data management and data recovery, this time involving hard drives and partition tables.

It always starts the same way: you torrent a cracked version of a newly released game you've been pining for, neglecting to check for embedded malware. This time it was the pinnacle of human programming achievement- the Mudkip Simulator (move over goat simulator!) Oh, and you were sneaking internet access on the chief meme archivist's main workstation. Whoops.

Turns out this one had a few tricks up its sleeve. Of particular note: partition scrambling. Oh no! All the memes!

After downing two Mr. Pibbs, a Mars bar, and a pack of Necco Wafers (saving the purple ones for last), you sit down to correct your most grievous of oversights. Chiptunes blazing, gaming flash drive at the ready, and extra monitors displaying terminals covering nearly every square decimeter of desk space, you have a hard drive partition map to restore.

Turns out there was at least some redundancy… a backup of the partition table/master boot record for the drive was stored somewhere in the first part of the drive. A little digital forensics and you should be on your way…

You need to recover the partition table, restore the disk to its accessible state, and copy pertinent files onto one of its partitions. Basic file management never seemed so enthralling.

Time to dust off that hexadecimal, sharpen your dd skills, and prepare for offset-calculating awesomeness: udr1 is ready to enhance your day!

Your data, as we experience it today, is organized in units of files (regular files, directory files, special files). Turns out, that is further organized into things called inodes and superblocks, software organizational structures that make up the filesystem, which organizes your data.

Below that, we have the notion of sectors (units of transactions), that are the often de-facto unit of measurement.

So here, below the file system, in fact, what helps establish boundaries for the filesystem that we conveniently use everyday, is another organizational scheme, one that sets boundaries for where our data can reside on media. We call these partitions. And the partitions are laid out in a partition table.

This week's project is located in the udr1/ subdirectory of the UNIX Public Directory.

You need to go there and run a program called prep, by providing it the absolute path to the directory you've made to store your files for the udr1 project.

For example, if you've made a src/unix/projects/udr1/ directory, you can say:

lab46:/var/public/spring2017/unix/udr1$ ./prep /home/$USER/src/unix/projects/udr1
Processing disk.image .........................................
MBR backup is at offset 0xXXXXXX
Process complete. Your file is in '/home/$USER/src/unix/projects/udr1/disk.image'
lab46:/var/public/spring2017/unix/udr1$ 

A couple of things to note:

• the file you need, disk.image will be copied into the directory of your choosing. The directory must exist before you instruct prep to place it there (otherwise you'll get an error).
• You'll get an offset for the “MBR backup”… write this down! You'll need it to progress further. The MBR backup is located in a contiguous region spanning exactly 127 bytes (that's in decimal).

In order to gain access to the drive (in the form of the file called disk.image, which is 5MB in size), you'll need to restore the partition table/Master Boot Record (MBR).

There is a backup stored on the drive… you were informed of its location when you successfully ran prep. Obtain and unravel it.

Once you have it, you'll want to restore it onto the drive; it needs to occupy the first sector on the drive.

Once you have that in place, we can use a hex editor to study the partition table and determine the starting sectors and overall sizes of each partition.

You'll want to extract each partition individually from the disk image so you can better interact with it. You'll need to determine the partition type and ensure a viable filesystem is in place (think back to the puzzle boxes). Ultimately you'll want to be able to view and copy data to/from the various partitions.

To facilitate your efforts, please name each extracted partition files as follows:

• partition #1: udr1.part1.img
• if there's a partition #2: udr1.part2.img
• if there's a partition #3: udr1.part3.img
• if there's a partition #4: udr1.part4.img

As this is a disk image of the chief meme archivist's workstation, you'll also need to do a little file organization to bring things up to spec (and ensure they never realized what happened); specifically, placing all mudkip and reptilian-themed files on the fourth partition.

Finally, reintegrating the changed fourth partition over the old one, so that you can submit the whole restored image, along with a list of command-lines you performed (and other information gathered) to accomplish this task.

You may want to become familiar with the manual pages of the following tools (in addition to tools you've already encountered):

• dd(1) – especially the conv=notrunc option
• bc(1)
• mtools(1)
• hexedit(1)

The aim is for this entire project to be performed on lab46. No external resources/tools are required. Like udr0, this project deals with binary data, something that is likely still throwing many of you for a conceptual loop. The more you play with this, the more it will make sense.

Be sure to ask questions! There are bound to be many.

The partitions are defined in the partition table, located near the end of the first sector of the drive.

Of particular note, you're interested in groups of 16 bytes starting at offset 0x1BE.

You may want to consult a reference of the binary layout of the MBR/partition table. An excellent source of information can be found here:

• http://thestarman.pcministry.com/asm/mbr/PartTables.htm

A partition is defined in 16 bytes (the classic PC layout allows for four primary partitions). The byte layout is as follows:

 0  Empty           24  NEC DOS         81  Minix / old Lin bf  Solaris
 1  FAT12           27  Hidden NTFS Win 82  Linux swap / So c1  DRDOS/sec (FAT-
 2  XENIX root      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  84  OS/2 hidden C:  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux extended  c7  Syrinx
 5  Extended        41  PPC PReP Boot   86  NTFS volume set da  Non-FS data
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility
 8  AIX             4e  QNX4.x 2nd part 8e  Linux LVM       df  BootIt
 9  AIX bootable    4f  QNX4.x 3rd part 93  Amoeba          e1  DOS access
 a  OS/2 Boot Manag 50  OnTrack DM      94  Amoeba BBT      e3  DOS R/O
 b  W95 FAT32       51  OnTrack DM6 Aux 9f  BSD/OS          e4  SpeedStor
 c  W95 FAT32 (LBA) 52  CP/M            a0  IBM Thinkpad hi eb  BeOS fs
 e  W95 FAT16 (LBA) 53  OnTrack DM6 Aux a5  FreeBSD         ee  GPT
 f  W95 Ext'd (LBA) 54  OnTrackDM6      a6  OpenBSD         ef  EFI (FAT-12/16/
10  OPUS            55  EZ-Drive        a7  NeXTSTEP        f0  Linux/PA-RISC b
11  Hidden FAT12    56  Golden Bow      a8  Darwin UFS      f1  SpeedStor
12  Compaq diagnost 5c  Priam Edisk     a9  NetBSD          f4  SpeedStor
14  Hidden FAT16 <3 61  SpeedStor       ab  Darwin boot     f2  DOS secondary
16  Hidden FAT16    63  GNU HURD or Sys af  HFS / HFS+      fb  VMware VMFS
17  Hidden HPFS/NTF 64  Novell Netware  b7  BSDI fs         fc  VMware VMKCORE
18  AST SmartSleep  65  Novell Netware  b8  BSDI swap       fd  Linux raid auto
1b  Hidden W95 FAT3 70  DiskSecure Mult bb  Boot Wizard hid fe  LANstep
1c  Hidden W95 FAT3 75  PC/IX           be  Solaris boot    ff  BBT
1e  Hidden W95 FAT1 80  Old Minix

Successful completion will result in the following criteria being met:

• When all is said and done, you will submit 2 files to me:
  • The final, modified disk.image file, which:
    • has the backup MBR restored to the proper place
    • has the mudkip/reptilian files copied into the fourth partition, and that fourth partition is merged back into the disk image.
  • steps.txt, which contains:
    • a list of command-lines used to accomplish every step of this project from start to finish (excluding the successful run of prep and the successful submit).
    • explanations of the commands, as well as how you derived any numbers used.
    • type ID (in hex as well as descriptive text) of each partition
    • which partition is marked as bootable?
    • total size (in bytes and sectors) of the MBR/partition table region
    • total size of each partition (as defined in the partition table)
    • total formatted size of each filesystem
    • amount of space used in each filesystem (when all is said and done)
    • amount of space free in each filesystem (when all is said and done)
    • the disk label of each partition/filesystem.
    • what file(s) are present in the fourth partition upon copying all mudkip/reptilian-themed files?
    • what file(s) are left out?

Please submit as follows:

lab46:~/src/unix/udr1$ submit unix udr1 disk.image steps.txt
Submitting unix project "udr1":
    -> disk.image(OK) 
    -> steps.txt(OK) 

SUCCESSFULLY SUBMITTED
lab46:~/src/unix/udr1$