Air Force One wrote:Number one: are there any descriptions about hardening log file? What those 2 hexadecimal numbers at the beginning of every line means?
The only documentation is the VirtualBox source code, which is available at the VirtualBox download sites. Each line of the
VBoxHardening.log file begins with the process ID and the thread ID of the thread creating the log message. Don't ask me why they are displayed in hex.
Air Force One wrote:Next question: I couldn't find the STATUS_HEAP_CORRUPTION anywhere in those logs, which file and line is it?
VBoxHardening.log file from VBox_host_logs_install_25092022 wrote:2988.5f4: supR3HardNtChildWaitFor[2]: Quitting: ExitCode=0xc0000374 (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 217414 ms, the end);
764.ef8: supR3HardNtChildWaitFor[1]: Quitting: ExitCode=0xc0000374 (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 218462 ms, the end);
The exit code can be found in the last log message. The Microsoft documentation can be found in
2.3.1 NTSTATUS Values.
Air Force One wrote:Then: what do you mean by software, which patches something? In which lines I can see this?
VBoxHardening.log file from VBox_host_logs_install_25092022 wrote:764.ef8: kernel32.dll: Differences in section #2 (.rdata) between file and memory:
[...]
764.ef8: Restored 0x2000 bytes of original file content at 00007ffe82c61000
This is one of several examples, which you can find near the beginning of the
VBoxHardening.log file. The log messages indicate that parts of the contents of
kernel32.dll as seen inside the memory space of the VirtualBoxVM process are different from the corresponding parts of the file on disk. This means that some software has modified those parts of
kernel32.dll in memory. VirtualBox tries to revert those modifications, and only continues to run the VM if it is successful in doing that. If the other software doesn't expect that to happen, all sort of consequences can arise.
One type of software often seen modifying Windows core DLLs is so-called security software, which behaves just like malware in this respect. That's one of the reasons why neither Microsoft nor security experts like 3rd-party AV software.
Regarding your theory of relating the patching to host OS updates, note that all your
VBoxHardening.log files show the same modifications.
The exceptions in your latest
VBox.log files took place in the VMSVGA FIFO thread, so they are most probably related to the graphics implementation.