Track what files and sectors are being read/written during entire boot (Windows) - Page 1
Forum section: electronics / general

author: Georgy.Moshkin
author_rank: Frequent Contributor
timestamp: October 09, 2023, 12:56:08 am
content: Is there any way to track this?What I am trying to achieve: In my program, which is very similar to HEX viewer, I want to highlight bytes that wasreadorwrittenafter last reboot usinggreen/redcolor. This program can have many uses: performance analysis and optimization, malware analysis, bug hunting, etc. Here is how it may look lilke:I thought about1) Using Process Monitor, Process Explorer - good, I can see offset and length, but it will not work until boot is complete. Maybe I can run it a little earlier, e.g. before explorer.exe.Large portion of boot process remains untracked.2) WriteFileEx/ReadFileEx/WriteFile/ReadFile/CreateFile/SetFilePointer/etc. hooks - DIY logger can be a bit faster, but thesame problem with boot.Theoretically, it is possible to write some driver which starts very early.3) NTFS Journaling - I think it should work before boot, but does not provide offset/length, and has a time lag: "The NTFS file system delays updates to the last access time for a file by up to1 hour after the last access."4) Creating virtual machine and track access to virtual disk file using methods 1) and 2). Not convenient for analysis on non-virtual machines (need to convert system to virtual machine, etc.)5) Making stm32-based basic bootable USB and log raw sector access using firmware.Probably method 4 is the easiest way, I can start track some VMDK file before virtual machine starts and log all offset/length pairs. Then I can parse VMDK file and use logs to highlight bytes with red/green colors. What do you think?

author: Halcyon
author_rank: Unknown
timestamp: October 09, 2023, 10:17:24 am
content: I'm sure someone who's clever at writing code that can start shortly after the kernel would be able to advise better than me, but "back in the day" when we seized computers, but wanted to examine them on "real hardware" as a live environment (rather than just imaging the disk and examining them on a forensic workstation), we used a device called a "Shadow" by Voom Technologies (no idea if they are still available). (Also, resist the urge to sing "Voom Shadow" to the tune of Cat Stevens - Moonshadow)Essentially they were a type of forensic write blocker that would sit between the hard disk being examined and the PC it originated from, which you could boot as normal. Reads/writes were captured separately but writes were never written back to the original disk, retaining it as it was when it was seized. It allowed you to capture evidence in a live environment, but also allowed you to "roll back" to the original version, kind of like a hardware-based snapshot.I'm not sure if something like that would be useful to you?

author: Georgy.Moshkin
author_rank: Frequent Contributor
timestamp: October 09, 2023, 04:09:40 pm
content: Any information is useful. Voom shadow is an interesting concept, maybe I can learn something from it. Few years ago I've usedReboot Restore rx, worked pretty good. Currently I think about using virtual machine with process monitor. The only drawback is that drivers will be different.Edit: one more solution is to use some open source disk encryption program and modify it (driver?) to track reads and writes instead of running encryption algorithms.

author: abeyer
author_rank: Frequent Contributor
timestamp: October 09, 2023, 06:40:42 pm
content: I'm not sure how early you care about... but even if you load software as early as possible within your os, you'll still be missing any disk access from bios/uefi/bootloader that run before you even have a kernel.

author: coromonadalix
author_rank: Super Contributor
timestamp: October 12, 2023, 03:28:53 pm
content: yes a 64 bit kernel will lock you out of many things, unless you do some kernel hacking, dll injections etc ...or maybe insert a device in the sata control lines of the drive, for nvme or m2 it's the same thing?if they exist, it must be very expensive