Windows Internals / Zig Tooling

what it is

A collection of small, focused Zig programs that exercise the Win32 API directly — no frameworks, no runtime abstractions between the code and the operating system.

problem / objective

Security research on Windows requires understanding what the OS actually does below the layer most languages hide. The objective: build working knowledge of dynamic library loading, module resolution, PE structure, and GDI rendering by implementing each piece by hand.

environment

• Windows host, Zig toolchain
• Direct Win32 API calls via Zig's C interop — no wrapper libraries
• Debuggers and Sysinternals for observing what the API calls actually do

architecture / design

Each experiment is a single-purpose program built to answer one question about platform behavior — kept deliberately small so the mechanism under study is the whole program, not a side effect of a larger codebase.

technical implementation

• Dynamic loading — manual LoadLibrary/GetProcAddress usage and observation of the module resolution order
• PE/loader behavior — inspecting how the loader maps images, resolves imports, and handles relocations
• GDI rendering — drawing directly against the GDI API to understand the graphics/device-context model
• Zig↔Win32 interop — extern declarations, calling conventions, and wide-string handling at the ABI boundary

security considerations / methodology

All experiments are platform-behavior probes — they observe documented API behavior rather than exploit anything. The same knowledge applies in both directions: writing tooling, and recognizing what anomalous loading or rendering behavior looks like.

interesting problems encountered

• Zig↔C interop friction: wide strings, calling conventions, and getting extern declarations exactly right
• Cases where observed loader behavior differed from what the documentation implies — resolved by tracing with a debugger instead of reading docs

what i built

• A set of working experiment binaries, each isolating one platform mechanism
• Notes connecting observed behavior to the security research work — how loading and resolution actually work is prerequisite knowledge for both offense and detection

results

Working, minimal demonstrations of each mechanism studied.

evidence

$ zig win32 experiment — module handles and MessageBoxA resolved at runtime (GetModuleHandleA / LoadLibraryA / GetProcAddress); no static user32 import

what i learned / next steps

Comfort operating at the Win32 API layer without framework support. Next: expanding into additional loader and process-internals areas that feed the security research.