Hello Reader,
Are you using Linux as your DFIR environment of choice? Many are and for good reason. Linux makes many things easy thanks to the wide variety of open source DFIR tools available, premade distributions (SIFT, Paladin, DEFT, etc...) and the ability to quickly turn evidence into mountable file systems.
However for all the good there are some Linux internals that might be silently tripping you up. The first is something a lot of us have known for awhile. If you mount a journaled file system that Linux supports (ext3/ext4 are good examples) the underlying driver may replay the journal even if you tell it read only.
In addition to this Maxim Suhanov (@errno_fail) is now showing that write blockers that make a device appear to be writeable and actively suppress errors to make the device appear to be working can lead to a different set of issues. In this case the in memory cache will replay the journal and record other changes unless you pass into dd the direct iflag value to tell to skip the write cache in memory and look at the disk itself. This was a new one to me and very interesting. In fact I initially thought this was something the write blocker was doing wrong and asked for the firmware revision only to realize when thinking about it again that the issue is with the write cache itself.
The write cache is not unique to Linux, all modern operating systems do it. But I didn't think to find a way to bypass when disk imaging and I'm glad Maxim brought it up. Maxim documented this in his Github project for his Linux write blocker kernel module:
If you want to make sure your Linux kernel is really treating a disk read only you can use Maxim's kernel model: https://github.com/msuhanov/Linux-write-blocker#in-memory-modifications
If you want to read the original tweets go here: https://twitter.com/errno_fail/status/1253363615282991105?s=20
Are you using Linux as your DFIR environment of choice? Many are and for good reason. Linux makes many things easy thanks to the wide variety of open source DFIR tools available, premade distributions (SIFT, Paladin, DEFT, etc...) and the ability to quickly turn evidence into mountable file systems.
However for all the good there are some Linux internals that might be silently tripping you up. The first is something a lot of us have known for awhile. If you mount a journaled file system that Linux supports (ext3/ext4 are good examples) the underlying driver may replay the journal even if you tell it read only.
In addition to this Maxim Suhanov (@errno_fail) is now showing that write blockers that make a device appear to be writeable and actively suppress errors to make the device appear to be working can lead to a different set of issues. In this case the in memory cache will replay the journal and record other changes unless you pass into dd the direct iflag value to tell to skip the write cache in memory and look at the disk itself. This was a new one to me and very interesting. In fact I initially thought this was something the write blocker was doing wrong and asked for the firmware revision only to realize when thinking about it again that the issue is with the write cache itself.
The write cache is not unique to Linux, all modern operating systems do it. But I didn't think to find a way to bypass when disk imaging and I'm glad Maxim brought it up. Maxim documented this in his Github project for his Linux write blocker kernel module:
In-memory modifications
Some changes to a mounted file system made by a file system driver can be cached in memory, although they won't reach a physical drive (with the patch enabled and a block device marked as read-only, of course). In this situation, reading a "modified" data block with a userspace program (e.g. dd or md5sum) will result in inconsistency between data received by a userspace program and data actually stored on a drive, i.e. a userspace program will get the bytes from cache (containing modifications from a driver), not from a drive (no modifications here). Unmounting a file system will bring things back to normal.
If you want to make sure your Linux kernel is really treating a disk read only you can use Maxim's kernel model: https://github.com/msuhanov/Linux-write-blocker#in-memory-modifications
If you want to read the original tweets go here: https://twitter.com/errno_fail/status/1253363615282991105?s=20
Post a Comment