Hi,
I use Encase to extract the NTUSER, System and Software hives (files) into my forensics workstation but surprisingly I find they are empty? What I mean is that files look about the right size e.g. 27MB, 5MB etc but when their contents it's just full of 00000's, zeros (in Encase or outside of it). The same goes for the System file, and the NTUSER.dat files…
There are .sav and .log files, these do actually contain something (minimal) but they takes a few seconds to review their contents.
The system was Windows XP and this doesn't make any sense. The image was taken when the machine was powered off, hard drive removed and connected to my write blocker - so I know I have imaged the exact contents of the drive. So why are these registry files full of zeros?
Any help is much appreciated.
TJ.
If you can't believe your eyes, pick another tool to check.
[edit sorry, I now see that you say 'in Encase and outside of it' so I assume you did use another tool to check - is that a correct assumption?]
yes that's right. I did use another tool, I mounted the image using FTK imager and looked at the files. I also tried ProDiscover, but got the same results.
Have you tried to mount the registry files within Encase? Right click on the ntuser.dat file, then click on "View File Structure". This will virtually mount the registry file and you can search through the various key.
Another way is if you are using Version 6 is to use the File Mounter Enscript and create a logical evidence file (LO1) of the registry files you wish to search. This is my preferred method as you are able to add the logical evidence file as part of the case. This enables a faster load time of you case instead of keeping a virtually mounted file open.
Try to export the files out of FTK Imager and see if they can be looked at in an outside hex editor. May want to run reg ripper on them - which is a parser, but a test to see if it outputs something and if another tool is just acting wacky. You go back in to the restore points to pull other hives?
Hex editor on the files? Extract them straight from the drive and copy them some place and either use hexedit if you are in a Linux / OS X environment or Winhex. I really love Winhex. If you find you have all zero's from there, then that is certainly note-worthy and worth some investigation time…
-L0ft
I use Encase to extract the NTUSER, System and Software hives (files) into my forensics workstation but surprisingly I find they are empty? What I mean is that files look about the right size e.g. 27MB, 5MB etc but when their contents it's just full of 00000's, zeros (in Encase or outside of it). The same goes for the System file, and the NTUSER.dat files…
Not even a 'regf'?
If you haven't already, run a chkdsk or equivalent on the file system to ensure it is sound. Until you know it is, you can't trust the data you get.
I seem to remember that registry is kept in memory for most of the time, and flushed to disk only at certain points in time. If the system was shut down the hard way at the wrong time, the file may have been garbled.
So check file time stamps against shut-down time.
Of course, the files may simply have been overwritten, too.
In that case, it's restore points copies that remain.
A very long shot … are you looking at the right registry files? I'm not quite sure about this, but %SystemRoot% is set up in boot.ini on XP, and that could be located on another volume than the boot.ini file itself.
(Boot volume and system volume are not necessarily identical in Windows.)
That kind of problem can probably be identified by creating a virtual machine, and booting it. If the registry is corrupted, you'll get error messages identified the files. But if you have that kind of issue, you need to ensure that the drives are in the right order – no idea how you ensure that the drive gets the same 'multi(0)disk(0)rdisk(0)partition(1)' specification if the disk you are booting from happens to be rdisk(1).)
(Added I was probably going to far there – as far as I can make out, the drive stays the same, while partitions may change – so I should have said 'partition(2) instead of rdisk(1), and in that case the order of drives doesn't matter. That problem pops up in other contexts. )
To be honest, I've seen similar problems with 000000's… When this happens, than that means the file itself is corrupted and can't be recovered. I worked on a few image files that had similar problem.
Once you use Hex Editor and see that the File says is, say, 5MB, but you see 000000's in the Hex Editor than, the file is corrupted, there's no way to rebuilt this.
Just what Athulin says, it could have been overwritten, that's why you need something, a tool that prevents overwrites. I think that FTK has a feature that prevents Overwrites…
Are you using DD image capture? This is pure, Bits for Bits copy.. Otherwise, the problem your seeing 0000's might be from overwrite in Windows… The best way to do it is in DOS using Knoppix Live CD.