SNAP Server Data Recovery Of A Single File

Recovering a single file from a SNAP OS

As we know SNAP Appliance used a proprietary Unix File System (UFS) handler in order to run there Network Attached Storage (NAS) product. This particular OS ran a Berkley Software Distribution (BSD) flavor of UFS. Although there are many similarities to the original file system, there are also enough changes to make file recovery extremely difficult. In the following paragraphs, and articles we will explore the arithmetic and methodology of recovering a single file from a UFS volume.

In order to recover the file we must use the on-disk data structures that give the OS its road map to the file name, inode, and finally data block placement. Normally I would start with the coarsest data structure, but in order to facilitate an understanding of the file hierarchy I will start from the smallest granularity. That data structure being the directory entry.

To illustrate the data elements and their use I chose a PDF file for recovery. The file name is “2003STEP.PDF”. Using you favorite sector editor, do a scan and search for the file name that you want to recover. The tool I use is a wonderful product called “WinHex”. Figure A is a capture of my sector search.

Figure A

There are many elements in a directory entry structure; however there are actually five key elements.

1. File Name: This is the actual name of the directory/file. In Figure A this is defined as “2003STEP.PDF”
2. File Name length: This data element is self explanatory as it defines the length of the name. In Figure A the name length is defined as 0x0C, or 12 in decimal.
3. File Type: In this case we are only concerned about two types. First 0×04 which is a directory entry and 0×08, which is a standard file name entry. In Figure A this file entry is regular file name.
4. Record length: This defines the entire length of this particular directory/file name record. In variable length records there is always a record length. In Figure A you can see the record length is 0×00000028 in hex, or 40 in decimal.
5. Inode number: The name, and name length are important, however the inode number holds the key to the data block placement. In Figure A this is defined as 0x000F7E01, or 1015297 in decimal.

Next installment I will describe the ‘cylinder group’ data structure and how we can use that to find our inode element.