Hawkeye Research console

!analyze does not guess the target. It needs clues: which process, and which addresses in that process you treat as high-risk.

Lab ships HawkHotTargets.dll (under plugins\). The built-in plugin stages a detection target: it opens Notepad titled Hawkeye Lab target -- do not close, then hands Hawkeye that PID and two fixed addresses — the PE header of notepad.exe, and the PE header of ntdll.dll in that process.

You can replace it with your own plugin. The sample is samples\HawkHotTargets in the Community repo. A game security engineer, for example, writes the code that tells Hawkeye the game process PID and the sensitive addresses in that process's memory. Hawkeye takes those clues and runs automated detection for suspicious behavior.

↑ Contents

Community is the research console. Lab is the same foundation, already set up as a working case. The plugin in step 1 supplies the clues. One built-in run simulates the behavior, detects it, and writes an analysis report — that is how a newcomer first sees what Lab can do.

Before you run this on your machine, follow Community Driver setup and make sure the status bar reads Driver OK. Type !analyze -load -run -demo. The demo uses Notepad as the target. Lab stages high-risk behavior against it — a cross-process read, a planted page, and the rest of that run — a close simulation of a live system.

When that run finishes, Lab writes a PDF. ANALYSIS comes first; DETECTION is the evidence appendix. The cover is marked DEMO or LIVE.

On your machine the file is saved under reports\.

↑ Contents

Lab uses the same host environment as Community: test signing, an Administrator console, and a loaded driver. See Community Driver setup and confirm Driver OK on the status bar before any Lab detection or !analyze run.

Those steps are documented once — on the Community page. When the driver is loaded, start the Lab edition.

↑ Contents

Lab ships the same bench as Community. Symbol context starts with !probe — attach to a process or the kernel, then search many names together.

The illustrated walkthrough is on the Community page: step 2 — !probe.

↑ Contents

!etw samples which instruction pointers ran in a short window — process, thread, or the whole system. Lab pairs it with active-page and instruction-decode work (step 14).

See the Community walkthrough: step 3 — !etw.

↑ Contents

!cross_rw watches a target PID for cross-process access — ReadProcessMemory and the like. The window is short. The scan is threads currently on the CPU, across the system; then it reports who was in that process.

That is a bench question, not a verdict. It shows up around a game process, a build you are testing, or any software you run: is something else reading it.

!cross_rw_sim stages that access on a background thread so you can see the detector fire. Run either command with no arguments for usage. Pair them on the same PID; !cross_rw_sim -stop ends the sim.

↑ Contents

Cross-process access is not one technique. !cross_rw covers attach-based reads such as ReadProcessMemory. !phys_read covers another: MmCopyMemory with MM_COPY_MEMORY_PHYSICAL — a physical-memory read of a process address.

-pid is the process being read. -va is the virtual address inside it. Both sides of the pair take the same two flags.

!phys_read_sim stages the same MmCopyMemory (MM_COPY_MEMORY_PHYSICAL) read so you can see the detector fire. Run either command with no arguments for usage. Pair them on the same PID and VA.

↑ Contents

Physical-memory access is not one technique either. !phys_read covers MmCopyMemory (MM_COPY_MEMORY_PHYSICAL). !map_io covers another: a kernel map of a process address through MmMapIoSpace.

Two cache modes. -cache:0 is MmNonCached. -cache:1 is MmCached. -pid is the process being mapped. -va is the virtual address inside it. Both sides of the pair take the same three flags.

Detection is probabilistic; default is a short scan, -strong widens it. Run more than once to confirm. !map_io_sim stages each mode: map, then unmap, no read. Run either command with no arguments for usage. Pair them on the same PID, VA, and cache.

↑ Contents

Finding the code body of malware, or of software that should not be there, is slow if you walk the address space by hand. !active_pages samples a very short window and records the pages that were active in that process virtual address space.

-pid is the target. -pid:4 is the kernel. -rx:0 is RWX pages. -rx:1 is RX pages. -pid:all walks busy processes for RWX (not PID 4); capture costs more CPU. User-mode hits can be checked against VAD protection.

!active_pages_sim stages an active page in user-mode (-pid above 4) or in the kernel (-pid:4). One sim at a time; -stop when you are done. Pair the detector on the same PID with -rx:. Run either command with no arguments for usage.

-lab_miflag36 is experimental: Windows 11 MiFlags research. It is not part of the detector.

↑ Contents

Some windows are kept out of capture along the DisplayAffinity path: SetWindowDisplayAffinity, or win32kfull!ChangeWindowTreeProtection. !hidden_windows detects that behavior.

Detection needs -init first, once. After that, !hidden_windows with no flags runs the scan. Run with no arguments before -init for usage.

!hidden_windows_sim hides Hawkeye's own main window so you can see the same class of behavior. -enable:1 hides it from capture; -enable:0 shows it again.

↑ Contents

Hiding a window (DisplayAffinity) is one technique. Hiding a Visual is another: fuse a Visual in-process or across processes, keep it out of capture, and bind it to any process window.

!hidden_visuals detects Visuals that are hidden from capture. It needs dwmcore.dll symbols; if they are missing, the console gives the !sym line.

!hidden_visuals_sim creates a Visual locally (a red overlay) and hides it from capture. -enable:1 stages it; -enable:0 restores.

↑ Contents

Classic injection sits in user-mode mappings. A newer technique places executable code in the kernel region of the target process's address space, still reachable from user mode. Ordinary user-mode injection checks do not cover that region. !ukexec scans for those pages.

-pid scans one process. -busy scans busy processes (higher CPU at capture). Use one of these, not both.

!ukexec_sim plants one user-accessible page in that kernel region for a user-mode PID (not PID 4). One sim at a time; -stop when you are done, or when the process exits. Run either command with no arguments for usage.

↑ Contents

Malware that injects into a legitimate process often starts a thread there, then hides that process or thread so the usual lists do not show it. !hidden_process looks for that: what is running, compared with what the system reports.

The scan is system-wide. -run starts it. Run with no arguments for usage. There is no simulator for this command.

↑ Contents

Much modern malware reaches another process's memory through PTE remap paired with INVLPG, not only through familiar cross-process APIs. That makes instruction recognition on the pages that actually ran more important, not less.

Hawkeye decodes active memory and ETW RIP samples into an instruction report: counts for invlpg, virtualization opcodes, control-register moves, MSRs, and related classes, with a risk line when a pattern stands out. Pair it with !active_pages to find hot pages and with !etw to see where the CPU ran in a short window. Together they narrow a large address space down to a few high-risk code pages quickly.

Lab can stage a kernel page full of synthetic high-risk instructions. Run !active_pages_sim -run -pid:4, then detect with !active_pages -pid:4 -rx:0. Open the page in the Memory viewer — see Community Memory for ReadMemory and the console stats line. Lab also lets you edit bytes at a chosen VA in that viewer (hex edit after read) when you need to patch test data by hand.

↑ Contents

!analyze runs automated detection and writes an analysis report from clues you supply. You must provide those clues first. Write a plugin per the contract, or set the target PID and sensitive addresses yourself.

The built-in example uses Notepad and fixed addresses inside that process as the target and clues, then runs simulation and detection. That walkthrough shows what Hawkeye can do and where its limits are — not a live incident.

In -demo mode, Hawkeye actively stages sensitive behavior, then detects it. In -live mode it does not simulate anything; it detects only on the clues you gave. That is the setup for real work. Each dimension in the PDF comes from the behavior-signature library — the check itself plus the Assessment that explains the finding.

Default plugin: plugins\HawkHotTargets.dll (demo and live). Your own DLL: !analyze -plugin:plugins\MyGame.dll -load. Must export HawkHotTargetsQuery. See samples\HawkHotTargets. Run !analyze with no arguments in the console for full usage.

↑ Contents