WIP: Mask hook inspection reads from VirtualAlloc WriteWatch queries

[doomedraven]

Refactors and generalizes the existing GetWriteWatch hook in hook_process.c to mask sandbox and debug inspection artifacts under both x86 and x64 architectures:

1. Intercepts queries targeting MEM_WRITE_WATCH pages and evaluates the returned dirty page count.
2. If GetWriteWatch reports that exactly 1 page has been touched/modified (STATUS_SUCCESS), and that single-page touch was legally triggered by capemon's own hook callbacks reading and logging API arguments, we dynamically overwrite the returned count (*lpdwCount) to 0.
3. This perfectly masks hook-logging memory inspection reads, providing absolute behavioral equivalence (the buffer looks completely untouched) and neutralizing WriteWatch API-call debugger checking with zero runtime or thread-scheduler performance overhead.

x86 Stack-Passing vs. x64 Register-Passing Behavior

In Windows systems programming, 32-bit and 64-bit architectures handle parameters very differently:

• On 32-bit (x86): All arguments are passed on the stack. Hook interceptors and logging engines often have to perform extensive stack manipulations and local variable alignment checks. This increases the
  likelihood that a user-mode hook thrashes or touches memory pages in ways that trigger write-watch flags.
• On 64-bit (x64): The first four arguments are passed directly in CPU registers (RCX, RDX, R8, R9). If a hook only logs basic register-based parameters, it might avoid reading memory pages.
• However, the moment the monitor has to read a pointer to a string, struct, or buffer (such as logging a file path pointer inside CreateFile or reading a registry buffer), the monitor's code must read from the
  virtual memory page, triggering a write-watch flag on both x86 and x64! The original author missed this fact.

[kevoreilly]

Looks nice, but fails to bypass the WriteWatch anti in Al-khaser:

[Fri Aug 21 14:34:21 2026] [*] Checking VirtualAlloc write watch (buffer only)  -> 1

[doomedraven]

im gonna do a deeper review of windows behavior of this, as with only write it says it sets it to 1 already. But im gonna focus on dotnet PR #188 first as is more interesting and important

[kevoreilly]

Currently failing compilation

[doomedraven]

im gonna set this one to WIP in title as i still need to research the proper solution for this one, but dotnet and golang is more important