I’m not sure how I missed it when it came out in 2009, but Peter Norris has put together an absolutely fantastic write up on the internal structures of the Registry. Deep internal knowledge like this is vital when you are finding parts of old registry files in unallocated space, the page file, or memory. For anyone else who has seen this paper, it is hosted here:
Many digital cameras will compress their images into JPEG files, making them much easier to deal with for the average consumer. But, occasionally, you run across those that take their image capturing seriously who will set their cameras to save the files in “RAW Mode”. What that means depends on the model of camera. IrfanView is my preferred tool for viewing most images I run across in cases, and it usually does a great job of supporting even these RAW image formats. But, sometimes you want to get a second opinion…
Microsoft publishes a CODEC Pack that will enable its built-in viewers to also properly display most of the RAW image formats. It is available for download here:
I’m guilty. I’ve been neglecting this blog. I have a really nice write-up as the next good post, and I got distracted by something shiny and haven’t finished it yet. That is coming soon. I’ve also been working on a couple of projects that y’all will find interesting. To properly host those projects, I’ve moved my personal site to a new hosting service and completely redesigned it in the process. Part of that redesign, for the purpose of consolidation, involved installing wordpress there. So, this is your warning order – this site will move off wordpress to my domain as soon as my lazy ass finishes the site. Once that is done, I’m sure I’ll get distracted by something else shiny.
Update 1: The new site is live. I’m not done, but let’s be realistic – I never will be.
Future posts will be at http://blog.taksati.co.cc/
Update 2: The new site is dead. My hosing provider had this rule, in fine print at the bottom of page 15 of the user agreement, that I had to log into cpanel every month or they would delete the site and domain registration due to “inactivity”. So, I’m back to using this blog instead of the one my now nonexistent site. If my boss ever lets me out from under the rock he has buried me under, I will do some more write ups.
I was asked what this Fix-up thing was that I mentioned in my last post.
Fix-ups are used by NTFS to keep track of sectors that are part of specific data structures within the file system. This is done for a variety of reasons: detecting corruption from a failed disk sector, from a failed write, or from the moons of Jupiter not being properly aligned. By tagging all of the sectors that make up a specific structure, NTFS can check to ensure that the sector it just read was read correctly and does indeed belong to the structure it is trying to read. This is accomplished by a coordinated effort from two objects: the Update Sequence Number (USN) and the Update Sequence Array (USA).
The Update Sequence Number (USN) is a uint16 (two byte unsigned integer) that is stored in the header of the structure and in the last two bytes of every sector consumed by the structure. When this number is written into those sector ending positions, it overwrites existing bytes that used to be part of information that we probably cared about, such as file names, date/time stamps, etc. We need a way to store and recover that overwritten data, which brings us to the USA.
The Update Sequence Array (USA) is a series of uint16 (two-byte unsigned integer) entries that contain the last two bytes of each sector consumed by the structure. Any time we read a sector that is part of that structure, we must account for the USN. First we check to see if the last two bytes are the same as the USN from the structure’s header, to see if we read the sector correctly and to ensure the sector that we read is part of the structure we meant to read. Once we are happy with that, we throw it away. Next we need to step through the USA to the entry that corresponds to the sector we are reading, and substitute those two bytes for the last two of the sector we just read.
The types of data structures that we typically find USN and USA for are:
– $MFT FILE Records
– INDX Records for directories and other indexes
– $LogFiles RCRD Records
– $LogFile RSTR Records
This can be especially problematic when searching a drive in a forensics-like “look for this file name anywhere on the system” type keyword search. If there is a fix-up in the middle of the file name, the keyword search won’t find it. Most point-n-click forensics tools (EnCase, FTK, etc) will correct the data when displaying in the pretty tables that are part of the tool, but still can’t account for the USN when it is time to do a keyword search. Also, anyone doing manual parsing of file system, for those that have to deal with damaged media or a corrupt file system, needs to understand this concept.
1) MFT Records are 1024-bytes long. So, each record consumes two sectors. In the FILE Record header, there will be a two-byte USN and a four-byte USA. The USN will be found repeated at the end of each sector, so offset 510-511 and 1022-1023. Depending on what attributes make up the FILE record, there could be important information at offsets 510-511 that could be overwritten.
2) INDX Records that make up directories are 4096-bytes long. If there are more entries than can fit in that amount of space, then a second INDX record, for another 4096-bytes, is used. Each INDX Record will have a two-byte USN and an eight-byte USA. Only the allocated part of the INDX will be written to. So, say we have a directory that contains a lot of files, then all but a few get deleted. The actual size of the INDX will shrink, but it will still be allocated in 4K chunks. There will be records in the slack space towards the bottom of that 4K chunk that will reference files that may or may not still exist. The sectors consumed by that slack space will have a different USN saved at their tails.
I needed to walk a directory index for another script I was working on. I figured, as long as I was there trying to prototype that, I would just dump out the entire Index.
I already have a couple of scripts that do this. One of the major things I noticed when I started working on this that I hadn’t realized before was that there were a couple of serious problems with those other scripts. Most notably, they weren’t applying the fixups from the Update Sequence Array, which caused random corruption in file names and dates. Forensics is not a field where you want errors in dates, so I thought this a big deal.
Like the MFT parser below, this dumps to the console. Blue check the folder of interest and run. It will operate successfully against multiple checked folders, but the output is kinda long and hard to keep straight, so I don’t recommend it.
So, I was having lunch with my good friend Mike. Great guy. If you get a chance, take Mike to lunch. Anyway, we were discussing how EnCase doesn’t really give the user easy access to the MFT and there is some information in there that doesn’t get parsed by EnCase that could be useful to an examiner. So, on a bet, I built an EnScript to parse out the MFT record for all selected (blue checked) files. Mike had to pay for lunch and you get an EnScript.
Currently it just dumps info to the console. Next version will output to a series of sweeping bookmarks.
This is an EnCase EnScript I wrote a few years back. The original design goal was to implement Sysinternals Autoruns.exe inside EnCase so it could be run against dead drives during forensics cases. Sysinternals has since reworked Autoruns.exe so it can work against a dead drive, thus limiting the usefulness of this script. It still comes in handy for certain tasks since it is faster than mounting the drive to run Autoruns.exe.
The output will be in the Console and from there can be cut-n-pasted or saved to a file.
Due to changes in the Registry files, this doesn’t work on Windows 7.