Write-blocker issues?

  • We encourage our users to use Real Names to build a real community, friendships and networking opportunities.

    [more information]

Status
This thread has been solved! Go to solution…

zulu4

New Member
Dec 1, 2018
3
Ratings
1
1
#1
Anyone ever have a write-blocker that somehow altered data in transit coming from the source drive? I was copying some data using a write-blocker and noticed when I hashed the copied files, they didn’t have the same hash values as I was told the files were meant to have. I thought perhaps the write-blocker was faulty in not protecting the source, but when I swapped it out with another write-blocker, and did the copying process again, the copied files now had the correct hash value. I tested copying the files a number of times with the ‘faulty’ write-blocker, and every time I got different hash values on copied files. Seems very weird to me. Any thoughts what could cause this?
 

kalinko

New Member
Oct 27, 2018
4
Ratings
4
3
Germany
#2
Hey there,

what write blocker did you use? And on what OS and Filesystem did you do the task?
And did you just copy the files with OS tools? Or do you create an image with e.g. FTK Imager or Guymager.


First I would check if the source files are really not altered, this means I would hash the source files before I copy them and after i copied them. Both times the source files, not the copied versions of the files. IF the hash values are identical, the source is not altered, the write blocker seems to do its job.

Second comes your test (if I understood it correctly), you already did it. You know that the copied files are not identical to the source files, you just need the first test to check which version changed -> source or copy.

If only the copied versions changed, my question above is important, did you just copy the files or did you create an image? If just copied, your used OS could be the source of error/change or your way how you created the hash values. So my third question -> how did you create the hash values?
And fourth: When you have hash values per file -> what files have a changed hash value?

The most time a saw a behaviour like the one you have explained here, the write blocker didn't work correctly and allowed changes to the source, most time from the OS. E. g. indexing stuff made automatically be the OS based on NTFS file systems.

Until now I didn't see that a write blocker itself changed any data copied. But I learn/see new stuff every day ;)
 

twicesafe

Administrator
Staff member
Sep 4, 2018
84
Ratings
20
8
Vancouver, Canada
www.computerforensicsworld.com
Twitter
Forensic_Notes
#3
First thing I would do it check the firmware of the Write-blocker. I have seen weird behavior with older write-blockers that didn't have updated firmware. Not sure if it has something to do with the solid-state memory drives, but a good reason to keep them always up to date.

If that doesn't work, perhaps a faulty write-blocker.

Was it ever properly tested before? Before using any hardware or software in DFIR, you should test each item to ensure it is working as intended.

Hopefully, this helps.
 

zulu4

New Member
Dec 1, 2018
3
Ratings
1
1
#4
Thanks kalinko & twicesafe for your responses. And sorry, I probably didn't do the best job describing the issue. I won't name the write-blocker, I don't want suggest the product is faulty, when there is a good chance user-error is to blame. But I was using Windows 10 to copy files from a portable HDD to my host computer.

First I would check if the source files are really not altered, this means I would hash the source files before I copy them and after i copied them. Both times the source files, not the copied versions of the files. IF the hash values are identical, the source is not altered, the write blocker seems to do its job.
Actually, I did do this. And yes the hash of the source files and the hash of the copied files were identical. So, in that sense the write-block did do it's job and actually I likely would have never noticed the problem if not for the fact that I was also provided the hash values by the person who had placed the files originally on the portable HDD. And this is when I realized that my hash values were not matching what they had provided.

I initially thought the data perhaps had been altered on the portable HDD. But then I connected the drive to a different write-blocker and hashed the source files again, this time I got same hash values as what I had been provided.

So, the files had never changed on the source drive. But when the drive was access and the files were hashed via the 1st write-blocker, it did not provide the correct hash values. And actually not all of the files had a changed hash value from what was expected. Only the larger files (multiple GBs in size vs smaller MB files) had the issue.

On that note, I realize I named this thread incorrectly, as the issue is not about the data being altered in transit, but I guess how the data was possibly viewed thru the write-blocker? (I'll edit this thread name.)

Twicesafe, didn't think of that either, i'll check the firmware when I'm back at work. Thanks.
 
Status
This thread has been solved! Go to solution…

About us

  • Our community began in 2004. Since this time, we have grown to have over 29,000+ members within the DFIR & Cyber Security community.

    We are happy to announce that this forum is now under new ownership with the goal to once again become the main Digital Forensics Forum on the internet for DFIR, OSINT and Cyber Security.

    If you can think of ways to help us improve, please let us know.

    We pride ourselves on offering unbiased, critical discussion among people of all different backgrounds.

    We are working every day to make sure our community is one of the best.

Quick Navigation

User Menu