This situation is odd, and after hours of google-fu and a discussion with work peers, I still have no answer. I am hoping y'all can help a gal out.
I had to image one SSD (256 GB) and one USB drive (16 GB). I use a Tableau Forensic Bridge (model T356789ui) attached to a forensic laptop via USB. First, I attached the 256 GB to the bridge using an M.2 adapter. Powered on bridge, drive letter H assigned. I then imaged with Encase Endpoint Investigator. This image went well, the hashes verified, all good.
I turned off the bridge, removed the SSD adapter, and plugged the USB directly into the USB blocking slot on the bridge, then powered it back on. Once again it was assigned drive letter H. I had to copy the contents of this USB off for review, which I did via windows Explorer drag and drop, then I began imaging the USB using FTK Imager.
The image was taking forever when it should have taken minutes, which piqued my interest. When the image finished, it was over 100 segments, and was @180 GB in size. I added the image in Encase and took a look at it. After the USB's sectors ended, the remainder of the image was from the 256 GB SSD I'd imaged earlier.Â
The best I can figure, the data from the 256 GB drive was in RAM, presuming it would be written there in the process of imaging. Which is great. But how/why was this added to the 16 GB image?Â
If anyone has any ideas of how this might have happened, I'd love to know. And yes, we will be re-verifying our write blockers post haste 😉 Thanks!
The best I can figure, the data from the 256 GB drive was in RAM
Does your laptop really have 256GB of RAM? This would seem unlikely.
More likely is user error. e.g. you were looking at the E01 files from the SSD when you thought you were looking at the USB drive E01 files. Or the destination folder used for both images was the same and they partially overwrote each other.
Otherwise maybe a flaw in the Tableau T356789iu and it failed to notice you swapped devices and still reported the large SSD connected as H: when in fact it had been disconnected. One would have thought that reading would fail after 16GB in this case, but who knows what shenanigans they doing to the USB protocol to prevent writing. Or maybe FTK failed to notice the read error and keep writing the same random memory buffer for 164GB.
Â
Â