My end goal was to…
- "mount" a EnCase EWF disk image using libewf/mount_ewf.py
- run log2timeline-sift on the resulting "mounted" image
The first step works fine. But when log2timeline-sift tries to mount the partition I only get the message
"NTFS signature is missing."
I tried to mount the partition manually, but I get the same result. I believe that log2timeline-sift just tries to run the "mount" command anyway, so that didn't surprise me.
It's entirely possible that this machine didn't get a clean shut-down.
mmls can see the partitions in the full disk images fine. fdisk, as well.
So I tried to dd out the NTFS partition and mount it manually, same thing.
Then I used ewfexport to convert the EWF image into a RAW image, and I retried everything above, but with the same result.
I'm able to see the files in this partition in EnCase without a problem, so I know it, at least, is able to overcome whatever the issue is with the "missing NTFS signature."
Any thoughts as to how I can mount this?
Have you looked at the actual volume data to see if the NTFS signature is missing?
Possible fix - recommend you revert to SIFT 2.0 to mount the E01 and then the contained image.
I also consistently received the "NTFS signature is missing" error while using SIFT 2.1. When I ran the mount_ewf.py command to mount the E01 to /mnt/ewf all seemed fine but I was unable to then mount the image. Always got the "NTFS signature is missing" message.
I loaded my old SIFT 2.0 VM and reran the mount_ewf.py command to mount the E01 image residing on an external drive to /mnt/ewf. The mount_ewf.py script worked (as it seemed to in SIFT2.1) and I was able to successfully mount the contained image file using the proper sector offset to the NTFS partition. It works in SIFT 2.0 but not in SIFT 2.1 and I do not know why.
parsonsg,
Did you send Rob Lee an email describing what you did and the error message you received?
Harlan,
Yes. Rob (who is travelling today) thinks the problem may be with libewf version on SIFT 2.1. He asked me to perform a libewf update on the SIFT 2.0 system (from v20100126 to v20110320) to see if the problem persists. I'll email him again and post the results here tomorrow as I won't be able to perform the test until late tonight or tomorrow morning.
Cool. I'm sure that the resolution will be useful to all users of SIFT.
Any thoughts as to how I can mount this?
Even though there seems to be a possible resolution in the offing, I'd recommend identifying what the problem actually is. Myself, I'd begin by assuming the message is correct, and that there was some kind of mixup as to what the correct partition was (what does 'fdisk -l' say, for example), I'd probably try to mount it as a FAT partition just in case.
Then, 'disktype' almost always prints out helpful information for unknown or unrecognized hard drives/volumes. You may have to download it from sourceforge and compile it yourself, but it is worth the trouble when you are in situations like this.
When all such possibilities are exhausted, I'd look for problems in lower layers, such as libewf. If there is a problem, I'd expect previous tests would have indicated it – say, disktype fails to find anything useful, and manual inspection of volume boot record etc. does not show the usual structures.
However, keep in mind that if you are looking at an encrypted disk or volume, you probably need to look elsewhere to establish that. I assume you know that that particular situation is not at hand.
I also had problems with mount_ewf.py on some images… after hours of tests I ended up using xmount and it seems that it works with those images.
Paolo