Corning Community College CSCS1730 UNIX/Linux Fundamentals ~~TOC~~ ======Project: UNIX DATA RECOVERY (udr1)====== =====Errata===== Typos and bug fixes: * (DATESTAMP) =====Objective===== 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. =====Backstory===== 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! =====Background===== 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. =====Obtain the file===== 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). =====Process===== 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. =====Useful tools===== 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. =====Partition Access===== 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 ====Partition Layout==== A partition is defined in 16 bytes (the classic PC layout allows for four primary partitions). The byte layout is as follows: ^ Byte ^ Description | | 0 | Boot Indicator (0x80 indicates it is set bootable) | | 1 | Starting CHS values (you can ignore for this project) | | 2 | ::: | | 3 | ::: | | 4 | Partition Type ID | | 5 | Ending CHS values (you can ignore for this project) | | 6 | ::: | | 7 | ::: | | 8 | Starting Sector (little endian format) | | 9 | ::: | | 10 | ::: | | 11 | ::: | | 12 | Partition Size (in Sectors) | | 13 | ::: | | 14 | ::: | | 15 | ::: | ====Partition Types==== 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 =====Submission===== 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? ====Submit==== 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$