issue about windows kernel File IO

[Saturn35]

First of all, thank you for your nice work. When I was testing the provided sample driver and test program, it worked well.
I encountered an issue while using it. Currently, I'm fuzzing the Windows kernel, but the attack surface can only accept a single file input and cannot use buffer-type inputs. Therefore, I attempted to create a file within the agent module. Although the file creation was successful, it seems that the driver is unable to access this file.

I have tried various approaches, such as creating the file, computing its hash, and making a copy of the payload file that was preloaded during the "make provision_driver" stage. However, the test results indicate that only the original payload file can be accessed by the kernel.

For example, during the "make provision_driver" stage, I preplaced the "payload_00" file in the bin\driver directory. So when executing the following statement:

kafl debug --purge  --memory 4096 --input seed/payload_01  --action single

After the launch of kafland QEMU, in the agent, the payload_buffer obtained from HYPERCALL_KAFL_GET_PAYLOAD is written to the payload_01 file. At this point, I calculated the MD5 hash of “payload_00” and “payload_01” file, and the results displayed by hprintf were the same. Subsequently, the agent executed two statements.

func("payload_01");//Newly Create
func("payload_00");//Old

The result shows that in the first statement, the kernel cannot access the payload_01 file, but it can access the payload_00 file. (This means that the two statements with the same function and file should crash in the first statement, but the test result crashes after the execution of the second statement.)

I'm wondering if there are any limitations regarding the internals of the virtual machine that I haven't grasped yet. Thank you for your response.Many thanks!

[Saturn35]

@IngyuTae I'm afraid I haven't figured it out yet😶.And I still don't understand why,as far as I know,computing md5 hash or reading file content to determine file consistency involves Windows kernel IO operations, but in reality, the test results show that seemingly identical files can lead to different result, as shown above. Currently, I haven't found a way to debug the kernel with this fuzzing tool. Do you have any ideas?