kvc.pl :: principal software engineer·MASM x64 & armasm64·C++23/C11 freestanding·reverse engineering·applied mathematics

Marek Wesołowski (WESMAR)

Principal Software Engineer — MASM x64 & armasm64 · C++23 · Systems & Application Development · Reverse Engineering & Binary Analysis · Ring-0 Kernel Drivers · NT Internals · DSE & SecureBoot Bypass · PP/PPL Manipulation · Forensic Tooling · Applied Mathematics & Optimisation · Windows · Linux · OSX · Android

Marek Wesołowski
ASMCC++ NT KernelEFI/UEFIPPLDSEBYOVDHVCI IRP FilteringSyscallsTrampoline HooksBoot Integrity REForensicsSteganographyCryptography UndervoltingPlundervoltFirmware Math Optimization LinuxAndroid + KernelPatch

I build systems and application software in modern C++ (C++23), C, and Assembly — from reverse engineering and binary analysis, through kernel-mode development, down to the firmware layer beneath the operating system. The same craft covers applied mathematics and algorithm optimisation, among them a chess engine.

The work follows a problem across the whole privilege stack rather than staying at one layer. At the firmware level, before the operating system loads: UEFI undervolting driven through model-specific registers, BIOS setting and NVRAM variable manipulation, a read/write NTFS driver, and a UEFI application that patches the SYSTEM hive in RAM at ExitBootServices. In the kernel (Ring 0): DSE and HVCI control, KASLR-aware offset resolution, and signed-driver I/O routed beneath the Filter Manager. In user space (Ring 3): TrustedInstaller token chains, Windows Defender control over WMI, and hardware management down to Lenovo battery charge thresholds through the platform driver. Much of it is hand-written assembly — x86, x64 and AArch64 — where a compiler’s output is not good enough and the instructions have to be placed by hand.

Core Capabilities

Kernel Engineering

Windows internals, driver behavior, and security boundary analysis in modern hardened systems.

Research Tooling

Custom low-level frameworks built for reproducible tests, structured validation, and operational clarity.

System Security

Mitigation assessment across boot flow, trust chain transitions, and protected process mechanics.

Selected Engineering Work

NTFS Driver for UEFI

A full read/write NTFS implementation for the UEFI firmware environment, with a B+Tree index engine that grows and prunes the on-disk tree in place. The $MFT and its $BITMAP grow together, handling the non-resident bitmap of a real multi-gigabyte volume; the test battery leaves the volume chkdsk-clean. WOF/CompactOS streams compressed with LZX decode byte-exact against Windows, verified across real binaries from 72 KB to 7.6 MB. EfiNtfs & EFI Commander →

EFI Commander

A dual-panel file manager that runs at the firmware level, in the Norton/Far Commander tradition: SHA-256 and CRC32, verified copy, recursive tree compare with one-sided update, quick view of text/hex/directory, recursive search, attribute and timestamp editing, a read-only view of the firmware boot entries, and launching an EFI image with its own arguments — down to a Ctrl+O command line over the same code the panels use. EfiNtfs & EFI Commander →

Onion Downloader

A native multi-circuit Tor downloader in a single 2.67 MiB Windows executable (x64 and ARM64). One GUI queue and a complete CLI share the same engine: a file that supports byte ranges is split into regions and fetched by ten parallel workers spread over several independent Tor daemons, with durable resume. A client-only Tor 0.4.9.11 is packed into the icon resource — no installer, no browser bundle, no external tor.exe. C++23 and WinAPI, no libcurl, no browser engine. Onion Downloader →

UnderVolter

Native UEFI undervolting that runs before any operating system, driving CPU voltage and power through model-specific registers: per-domain voltage offsets via MSR 0x150, per-package power limits, and ICC Max, with CPU detection matched on the exact {family, model, stepping}. It works at the level of the silicon’s own voltage/frequency behaviour, down to DLVR-regulated parts such as Lunar Lake. UnderVolter →

KvcForensic

Offline credential forensics from an lsass minidump — MSV, Kerberos, WDigest, DPAPI master keys and Credential Manager. It parses the MDMP format directly with no DbgHelp dependency and keeps every offset and signature in external JSON, so a new Windows build needs a config edit rather than a recompile — a deliberate departure from mimikatz and pypykatz. The Windows and Linux/WSL builds produce byte-identical output. KvcForensic →

CMDT — Cross-Architecture Assembly

Run-as-TrustedInstaller with a full token inheritance chain, shipped as three native binaries for x86, x64 and ARM64. The ARM64 build is hand-written A64 (AArch64) assembly assembled with armasm64 — not a recompile of the x64 source — carrying the same complete feature set across all three architectures. CmdT →

RegEdLin

A native GTK4/libadwaita editor for offline Windows registry hives, running on Linux. A two-pane Commander interface sits over an original regf parser and writer that reads and mutates hive files directly, without libhivex. RegEdLin →

Low-level engineering, Windows internals, and kernel-mode development sit at the centre of the work, and it extends into the firmware layer: a complete read/write NTFS driver and a dual-panel file manager that run inside the UEFI environment, where there is no operating system to fall back on and every on-disk structure has to be handled correctly by hand.

I am the author of a range of system-level tools published as open source, among them KVC (Kernel Vulnerability Capabilities), KernelResearchKit, KvcKiller, CmdT, and the NTFS driver for UEFI. The work spans NT internals, process protection models including PPL, driver loading mechanics, DSE behaviour, token manipulation, BYOVD kernel-mode process termination, and IFEO offline hive editing. KernelResearchKit resolves kernel offsets against a KASLR-randomised ntoskrnl base and stays resilient across Windows updates and changing PDB versions, patching the SYSTEM hive directly on the raw disk to control HVCI and DSE state across a reboot.

The research side is mitigation assessment through controlled proof-of-concept: driver signature enforcement logic, protected-process semantics, and early-boot trust-chain behaviour, measured rather than assumed, in both Windows and UEFI.

The same approach carries across Windows, Linux/Unix, macOS and Android: correct on-disk and in-memory structures, measured performance, and reproducible results.

Work runs from vulnerability discovery to a functional, validated proof-of-concept, under formally authorised research mandates.

Quick Access