Before i can get into any of these tools that analyze the files and data units in a filesystem, i unfortunately have to give a brief introduction on the NTFS file systems. If you already have an understanding of the NTFS file system, by all means skim right down to the tools section. If i were to just show how to use a particular tool without giving any background information, it really doesn't explain anything, and this blog would be less than 2 pages long. For the sake of brevity, i'm only going to discuss the NTFS file system, and how it applies to my image. (Sorry for the lame format. I don't know how else to import my Page documents from OSX. I'm also noticing typos that i'm going to have to change at a later time. Sorry. Happy hunting.)
 |
| The USN number is stored in the $STANDARD_INFORMATION attribute of the file that is being modified. The USN corresponds to the byte offset in the $UsrJrnl, where all the change journals are stored and organized by their USN number. |
 |
Provided by,Digital Forensics and Cyber Crime: Third International ICST Conference,ICDF2C 2011, Dublin, Ireland, October 26-28, 2011 |
1) Master File Table: Each NTFS partition has a Master File Table. The MFT contains the details of all files on the volume and thus it is the first port of call for evidence regarding the presence of files, the relevant dates and times of files, file sizes and identifications as well as their storage locations on the volume. (Sammes & Jenkinson, Forensics Computing, 2nd ed. 2007.)
MFT is the heart and soul of an NTFS file system. Somewhat comparable to FAT32's File allocation table in its job description, but with more features and precision. MFT is an indexing table that has multiple entries aka records inside of it that keep track of the metadata and attributes that are associated with a file or directory, and even the volumes themselves have metadata associated with them. So for every file that you have existing on your computer, that file has at least one MFT Entry aka MFT Record, inside the Master File Table. Let's get into how these entries work.
2) MFT Entry: These entries are 1024 kilobytes long, and are created to keep track of the file it's connected with out on the volume. The first 42 bytes of the MFT entry is the header, which contains 12 fields of data. In the beginning of all MFT entry headers is a string signature "FILE", which you can see in plain text in the ASCII column of a hex header. All entries begin with this magic signature. After that, a header includes information for allocation statuses, what the used bytes are in the MFT, etc.. Then the remaining 982 bytes is filled with attributes and possible slack space (where rootkits and malware could possibly reside).
Each one of the 1024 kb MFT entries is given a record number. This MFT record number is also stored inside the MFT header. Inside the master file table, the first 1024 kb entry starts with record number 0 (which is the $MFT entry), and the record numbering consecutively continues on with each entry (0,1,2,3,4...).
2) Metafiles: The $Volume file i just mentioned, is called a metafile. In Brian Carrier's book, he refers to them as "file system metadata files", just to make the distinction between metadata that exists for an entire file system, as apposed to metadata that exists for a single file or directory. There are 16 (records 0-15) of these file system metadata files, which are just like every other MFT Entry, just specifically assigned for keeping track of the entire file systems metadata. They are reserved by default in the Master File Table. They begin with a "$" and 1024 kb in size. After these 16 entries, i believe there are 18 more entries that NTFS reserves for the $extend directories. To sum up from Carriers text, "Entries 0 to 15 are reserved and set to an allocated state even if they are not being used, and 16 to 23 are not typically allocated. MFT entries for user files start at entry 24."
4) MFT Entry Addressing: Every file in a volume has an MFT entry, that much we already know. But these MFT entry addresses and locations within the Master File Table need to be kept track of and their allocation status to a file also needs to be recorded. There are to values that exist inside the MFT entry itself that tells us what record number it is in the MFT, and whether it is allocated to a file, and if so, how many times it has been reused to allocate files that have been deleted in the past.
a) The first value is known as a file record number aka file reference address number aka MFT record number, which is a 48 bit value (6 bytes). The first MFT entry in the table is $MFT, and its file record number equates to 0.
b) The second value in the MFT entry is a 16 bit sequence number that is incremented when the entry is deleted and reallocated, (when a file on volume is deleted, the sequence number is marked as unused, but when allocated again, increments from its previous number, 0 to1, or 1 to 2). These values are also helpful when determining is a file is an orphan file, or in other words, a file who parent directory has been deleted, but the file itself is still allocated.
The MFT entry file record number (48 bit) and sequence number (16) bit) are combined to form a 64-bit Unique file ID known as a file reference address. This file reference address is more like a matching scheme between a file in a volume, and its possible connecting MFT entry. NTFS stores the file’s MFT file reference so that it can directly access the file’s MFT record when it reads and writes to the file or directory at a later time. These "file references" are used whenever a structure needs to refer to a record in the MFT.
5) Attributes: An MFT entry is comprised of attributes. Attributes are files that exists to contain data that pertains to a file or directory. There are attributes that are designated for a file's name, date and time stamps, security identifiers, and there is even an attribute that specifically contains the contents of a file. In addition to a number, each attribute type has a name, and it has all capital letters and starts with "$." Each attribute is given a unique ID number called the Type ID, (there are also unique ID's for other attributes, so don't confuse with this ID). You can see the list of attributes that i've listed in my diagram in the beginning of this blog, and see that each attribute is given this ID type. *Remember not all of these different types of attribute will exist for every file.
All attributes have two primary parts:
- the header that indicates what type of attribute it is, its size, and its name.
- The content, is data that is associated with that attribute.
- $STANDARD_INFORMATION
- $FILE_NAME
- $SECURITY_DESCRIPTOR
- $DATA
To make things clear, attributes exist inside an MFT entry. If attributes to a file cannot fit within one mft entry, than NTFS puts the rest of the attributes out on disk, but while these excess attributes are put out on disk, they will also have their own newly created MFT entry. The original MFT entry in all of this runaround, is called the base file record.
Entry headers and attribute headers:
 |
| File system forensic analysis. Carrier, 2005 |
When file attributes are resident within an MFT entry (Each MFT entry won't always look like this):
 | |
|
When an attribute is too big to be resident, a cluster number is put in the attribute header to allocate with data runs:  |
Dione: A Flexible Disk Monitoring and Analysis Framework. Jennifer Mankin and David Kaeli, 2012.
|
NTFS Indexing
My final discussion involves the "indexing" technology within NTFS. This is pretty much a technology that is implemented with the assistance of two metafiles, $INDEX_ROOT & $INDEX_ALLOCATION. Why is this important? Well aside from the MFT, we've got all the files and directories out on our volume, so how do we keep them organized and keep them well maintained when changes are applied to them? B+ treeing is the primary terminology for indexing. NTFS uses indexes for security descriptors, object identifiers, repairs points, owner identifiers, directory entries, and other utilities.
With this NTFS B+ tree data structuring, you have a parent file, and below it can be many children files. (I'm going to be doing some over simplifying). There are root parent nodes, then there are children files that exist within the directory, and can become a node themselves, and branch off into more children.
So where are these entries and how are they structured? Well when you create a file, it receives its own MFT entry, that much we already know. Within each entry, there are two attributes called the $INDEX_ROOT & $INDEX_ALLOCATION attributes that are created when placing files within a directory as resident or non-resident. Both of these attributes are also called and represented by the value "$I30", which are stored outside of the MFT in what are called INDX buffers. When parsing through your data, you will find these "$I30" flags, that indicate this is an attribute that is containing an index directory with alphanumeric attributes listed inside. $I30 contains a list of files, and each file is referenced back to the Index attributes such as $INDEX_ROOT & $INDEX_ALLOCATION attributes.
Alright, so let me try and break this down from the beginning. When a file is created, it is given an MFT record, and a list of attributes, including attributes that are linked to them for indexing, in order to keep sufficient organization. Those two attributes are the $INDEX_ROOT & $INDEX_ALLOCATION attributes, and the former is for resident entries, and the ladder is for non-resident. When non-resident, the $INDEX_ROOT attribute creates and points to an $INDEX_ALLOCATION attribute. And inside of these $INDEX_ALLOCATION attributes are a collection of index records, that contain index entries. The index entries consist of a header then a body. The body contains a copied record of the $FILE_NAME attribute that exists for the file that is in a directory. So these entries fill up index records, until it's 4096 byte size limit is reached, then a new index record is created for the rest of the index entries.
The $INDEX_ALLOCATION attribute points to these INDX files (4096 bytes in size). Think of these index attributes as like mini MFT tables that assigns record numbers to index records, and each index entry is used for keeping track of the name of a file, and where in a directory it is/was located. When you parse through data you will find these INDX buffer data spaces with a signature of INDX in its file record, just like finding "FILE" in a file record of an MFT entry that you come across. One thing i forgot to mention, there is also a $BITMAP attribute header that also exists inside of the index records for marking what has been deleted.
When you have a raw image of a drive, the first thing you probably want to analyze is the boot sector. There are indicators inside of this sector that will give you insight into how the rest of the drive is constructed. When you you want to know what OS you're working with, the location of directories, the sizes of sectors and clusters, and the location of the $Mftmirr $DATA attribute location, this is where you first investigate. (Well technically there isn't any byte value by itself that signifies what Windows OS you're looking at. If you're doing by hand, it's more of a calculated conclusion). But of course you can run strings search to locate in ascii any identifying titles.
The boot sector (MBR) really is the starting point of an investigation. When manually analyzing an image, you can't find anything else inside the volume without first analyzing the MBR. Here is where you will find out the cluster and sector sizes, the starting and ending sectors of the MFT, partition type, active partitions, and the size of the partitions that are in the drive. With Autopsy you can look at each individual data unit, and analyze in Hex what type of permanent data there is.
Autopsy
Since my first post already explained how to install autopsy, i'm not going to go over that here.
For those of you have already installed them, Autopsy needs to know where it is getting its evidence from. By default, you will create what is called "Evidence_Locker", and this is where you'll place your images to be analyzed by Autopsy. Well, this doesn't really work great for someone like me at the moment, simply because I'm running a VM and i can't place a 300 gb file inside my 20 gb VM space. One solution to this dilemma, is to change the location in which Autopsy looks for its evidence. In other words, good bye evidence_locker. My image is located on an external hard drive: (/media/digitalresidue/My_Passport/1NTFS_image/ntfscopy.img.001). (Yes i added a few underscores from my last posts. Spaces in pathnames don't play well, especially with Autopsy.) So as you can see in the command above, this is where my image is located, so i'm going to redirect Autopsy into thinking its evidence folder is located in the 1NTFS_image folder while excluding the image ntfscopy.img.001 at the end. The command to redirect the evidence location for Autopsy is as follows: (autopsy -d /media/digitalresidue/My_Passport/1NTFS_image). This assigns a new evidence location, while automatically running Autopsy, and has it listening on port 9999. See down below:
From here you copy and paste that url into your VM's browser, connect as a host to Autopsy's server, and begin filling out the requirements that allow them to connect to your directory where your image is stored. There are plenty sites out there that already have the beginning setup steps of how to run Autopsy. I really don't want to screen shot every step of the way. But one thing to keep in mind, if you have an image with a .001 or .002 extension (as you'll see with split imaging with FTK), you need to subtract those extension numbers, and replace them with the Asterix '*' wildcard when Autopsy asks, "what is the file path to your image?" See down below:
From here, clock on next and go through the necessary steps to have Autopsy connected to your image. Click on the "data unit search" tab in the top right, so we can look at sector one of our image:
Light grey box = (offsets 1BE-1FD (decimal 446-509)), these are FOUR 16 byte entries, each of which are representing a partition in your drive. As you can see, we are working with the first entry.
Red box = (offset 446) 80h indicates an "active partition", whereas 00h indicates non-active.
Blue box = (offsets 447-449) Starting sector address for our MFT represented in CHS values.
Purple box = (offset 450) 07h is an indicator for an NTFS volume.
Yellow box = (offset 451-453) the ending sector address of our partition represented in CHS values.
Green box = (offsets 454-457) another representation of our partitions starting sector, this time in LBA values.
Orange box = (offsets 458-462) tells us how many sector are inside of our partition.
Black box = ending signature of a sector.
I don't want to go over all of these byte values, since i really need to wrap this blog post up. So, in my opinion, I find it particularly important to go over how we locate the first sector address of our active partition, since this is where all of our important data begins, and it is somewhat of a tricky process in converting a three byte CHS address to a physical sectors location. If you need to know more about what CHS addressing is, I highly recommend looking at Daniel Starman's website.
Down below is the process in which you convert the three bytes at offset 447-449, (bytes 20, 21, 00), to a CHS address, then in turn convert that CHS address into a physical sector address:
The starting sector of our partition from the CHS values is 2048. We can confirm this will some TSK tools, but we can also look at offsets 454-457, and see the LBA byte representation of the first sector address and see that it matches our CHS value. In the green box we have in little endian (0x 00 08 00 00), which we translate into big endian, which then becomes (x0 00 00 08 00), which when converted into decimal becomes an LBA address 2048.
Lets see if this data is correct by using Autopsy the same way we did to find the MBR at data unit 0, but this time i want to look at data unit 2048. My suspenses will be confirm if i see in the ASCII column an "NTFS" signature. Fingers crossed:
Aha! There is my volume boot sector at sector 2048! Here's what's inside those highlighted bytes:
Green: Jump instruction.
Orange: OEM ID.
Cyan: BIOS parameter block BPB. This is a very important structure. It contains a lot of information pertinent to file system analysis. At offset 0x0B (decimal 11) you'll see a byte value that represents how many bytes per sector there is, 0200 = 512 bytes per sector. Followed by offset 0x0D (decimal 13), you'll see a byte value that represents how many sectors per cluster there is, 0x08 = (decimal 8 which means 512 x 8 = 4096 bytes in a cluster. There is also byte values that tells us the LCN of the MFT, plus how many kilobytes are assigned to each MFT entry.
Red underline: Bootstrap code.
Magenta: End of sector signature.
So to wrap things up a bit, i want to quickly recap. When manually analyzing an image, you start with locating and analyzing the MBR, then locating and analyzing NTFS boot sector, then analyzing the BPB to locate the logical cluster number for the Master File table, then the rest is up to you. There is also the reverse technique of finding files in the volume first, allocated or unallocated, and using its filename or Object ID number to try and match it back to what MFT entry it was allocated to.
TSK
For some general information about an NTFS filesystems layout, the fsstat tool analyzes the type of file system that is on the drive, and gives you some basic feedback, including information about the attributes that are inside. This basic information also includes data about MFT entry sizes, starting clusters, number of clusters and sector ranges, etc. When using this tool, you'll need to enter in a few switches, unlike with mmls. With fsstat you will need to indicate which offset to start looking at with the -o switch, while also indicating what file system you're working with with the -f switch. Here is the output from this tool:
digitalresidue@ubuntu:/media/digitalresidue/My_Passport/1NTFS_image$ fsstat -o 2048 -f ntfs ntfscopy.img.001
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 9CA8B871A8B84B90
OEM Name: NTFS
Volume Name: System Reserved
Version: Windows XP
METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 8533
First Cluster of MFT Mirror: 2
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 256
Root Directory: 5
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 25598
Total Sector Range: 0 - 204798
$AttrDef Attribute Values:
$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident
$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident
$FILE_NAME (48) Size: 68-578 Flags: Resident,Index
$OBJECT_ID (64) Size: 0-256 Flags: Resident
$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident
$VOLUME_NAME (96) Size: 2-256 Flags: Resident
$VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident
$DATA (128) Size: No Limit Flags:
$INDEX_ROOT (144) Size: No Limit Flags: Resident
$INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident
$BITMAP (176) Size: No Limit Flags: Non-resident
$REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident
$EA_INFORMATION (208) Size: 8-8 Flags: Resident
$EA (224) Size: 0-65536 Flags:
$LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident
digitalresidue@ubuntu:/media/digitalresidue/My Passport/1NTFS image$
You can see the attributes with there ID number listed, then their byte size range, and then whether they are resident or non resident. It's nice that this gives us general information about our attributes and MFT sizing information, but this doesn't really give me much information to go forward in an investigation.
**One thing to point out with fsstat. I've seen from other peoples output, fsstat will show a list of what clusters are allocated and being used. Here it did not. Again, output with these tools are very OS sensitive.
Moving on to our new tool, fls you can say is TSK's "heavy lifter". It is one of the primary tools you will be using when investigating a drive with TSK. (I sadly did not get as much output as i had hope working with this image, particularly i couldn't see file paths, but still one of the most useful tools). You can search a specific directory with this tool, or an entire drive with fls when given the proper parameters. It searches for deleted and/or allocated files, does a dir of directories to show you what files are inside. fls needs to be ran in conjunction with other arguments like -d to display deleted entries, -p to display a files full path , -u display undeleted entries, etc. But by itself it only lists the primary files listed in your root directory. So if you simply ran the command against your image (fls -o 2048 -f ntfs ntfscopy.img.001), the results will be some metafiles that have r/r & d/d values that represent allocation statuses, and three numbers to the right of them. The first number represents an MFT record number, second is the attributes ID number (Most of these references are the 128 $DATA attribute), and third is when an MFT entry has more than one $DATA attribute, and the number is representing which $DATA attribute it is.
 |
When you want to get more specific than just some metafile entries as output, you can take one of the MFT record numbers and place it at the end of your fls command ex: fls -o 2048 -f ntfs ntfscopy.img.001 11, this will you you file listings that exist inside the $Extend metafile.
Or you can recursively scan the entire drive for deleted files with the -r and -d arguments. (I tried running a command such as fls -o 2048 -f ntfs -rd ntfscopy.img.001, and it simply didn't work. I know Autopsy and TSK work with different results according to each OS, and results generally work better for Linux than they do for NTFS. Maybe there are some people out there who have had some setbacks when working with an NTFS image with TSK's fls that would like to comment on it's possible irrisponsiveness to an NTFS dd image. Either way, for the sake of continuing this investigation, i found an NTFS dd image on the web that is small in size, that does give some better results. I took the same steps as i did before with my last image, then ran a scan of the root directory with fls -f ntfs -o 128 dfr_08_ntfs.dd:  You can see each metadata address (ex: $Attrdef's is 4) and you can see some metafiles and .txt files that have a file "type" represented as either - / r, which stands for "unknown" file type, or r / r which stands for a file that is allocated i believe. If you want to know what these type values, visit a sleuth man page. I believe the Asterix represents that these text files are unallocated, or in other words in a deleted state. There is one allocated file call fill.txt. I'm trying to run a few arguments with fls, such as -p -r -d, and there doesn't seem to be giving me any additional information provided when i apply them. There are timestamps when i run the -l argument, and i could use the -m argument to setup these times into a body file for creating a timeline report, but i'm not going to do that right now. To now get some basic feedback information regarding each one of these entries, we will use the istat. You'll simply have to specify which entry you want to examine by specifying its metadata address at the end of the command. For example, unallocated file Rukbat.txt has an metadata address of 64, so to view with istat we type: istat -f ntfs -o 128 dfr_08_ntfs.dd 64. It's output is as follows: 
So as we can see, the Rukbat.txt file has an mft entry number 65, and is unallocated. When we see a file that is unallocated with istat output, remember that this mft entry 64 could very well be reallocated to a new file. When you want to verify if an MFT record number is associated with a filename, you will use icat to verify if it is so. (We will do this later).
The filename attribute is located in MFT 5 which is the root directory where you'll find file names located, plus a file name record out in the volume. The sizes in the istat output are in bytes, and the attributes at the bottom show whether they are resident or non-resident with a size next to it in kilobytes. At the top of the output you'll see the word Sequence has a number 4 next to it. This means that this is the 4th file to occupy this MFT entry.
Now, if you look at the bottom of the output, you will see a bunch of numbers, 958376 958377 958378 etc. This is the cluster run that shows you each cluster address that is allocated to this file. Since this is an unallocated file, these clusters very well may be allocated to a knew file.
icat is a very useful tool that is used to extract the data units that are associated with a file. All you have to do is supply the metadata record number at the end of the command, and it will list the contents of the associated data units that exist for that record number. You can also use the -s argument to extract slack space that may exist in those data units, where possible previously existing files may reside. You either process the results with the > command to a newly created file, then run the file command against that newly created file to see its output, or process the results to the STDOUT, with the xxd tool. Which is what i'll be using. Oh ya, i forgot to mention. When you want to carve out the data units for an entry record, you need to know the size of the file first. So first thing, you look at your output from fsstat to see how many bytes are in a cluster, which is generally 4096, then you look and see how many cluster runs your file takes up in the istat output, which had 16 cluster addresses allocated to it, which equates to 65536 bytes total. So when you carve with the xxd tool specify bs=4096 count=16. So the common will look like this: icat -f ntfs -o 128 dfr_08_ntfs.dd 64 | bs=4096 count=16 | xxd. Aaaaaaaand of course i didn't get results. It just refreshed to my root user directory, which usually means it wasn't an incorrect command. I don't know. Maybe someone has tried this method before and could explain a possible mistake i made. Either way, TSK will still show results for entry 64, i'm just not sure if it's a carving of the actual size of the file. So just use icat -f ntfs -o 128 dfr_08_ntfs.dd | xxd, and results down below:
0000000: 0a44 4652 0a46 696c 6520 5275 6b62 6174 .DFR.File Rukbat
0000010: 2e74 7874 2070 6174 6820 726f 6f74 0a00 .txt path root..
0000020: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000030: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000040: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000050: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000060: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000070: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000080: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000090: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000a0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000b0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000c0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000d0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000e0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00000f0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000100: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000110: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000120: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000130: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000140: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000150: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000160: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000170: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000180: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
0000190: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001a0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001b0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001c0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001d0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001e0: 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b 2b2b ++++++++++++++++
00001f0: 2b2b 2b0a 5275 6b62 6174 2e74 7874 0a00 +++.Rukbat.txt..
0000200: 0a44 4652 0a42 6c6f 636b 2030 3030 3031 .DFR.Block 00001
0000210: 2053 6567 6d65 6e74 2030 3031 2066 696c Segment 001 fil
0000220: 6520 5275 6b62 6174 2e74 7874 2070 6174 e Rukbat.txt pat
0000230: 6820 726f 6f74 0a00 2b2b 2b2b 2b2b 2b2b h root..++++++++
Ok, come to find out, you didn't need to specify with bs= count=. icat carved the appropriate size with the xxd tool. And the results above are just a shortened version of my output, because the output was 15 times longer than this. And i'm really not sure what 2b2b stands for. Maybe that's the output that comes up when you try and carve an entry that is unallocated? Possibly. I'm sorry if the end of this blog got a little bit unorganized. I just really need to finish up this post.
|
