Executable parsing
Read Portable Executable structures, identify x86 or x64 targets, and extract initial binary data.
Technical dossier / KRN-01 / Proof of concept
Kernova
A controlled runtime for one Windows application—positioned between a full virtual machine and a basic sandbox.
- Status
- Proof of concept
- Language
- C
- Target
- Windows PE / x86 + x64
- Focus
- Control / inspection / low overhead
Repository evidenceExecutable parser / C
01 / Overview
The middle ground.
Kernova aims to provide VM-like control for a single executable without virtualising an entire operating system.
The runtime parses a target Windows executable, prepares its memory layout, and is intended to execute machine operations through a controlled engine. Selected operating-system calls can pass through to the host while Kernova attaches policy, logging, and breakpoints at the boundary.
The current proof of concept can inspect Windows executables on a non-Windows host, classify them as 32-bit or 64-bit, and begin extracting constants and initial values. Controlled execution, pass-through, and the full inspection workflow remain planned work.
02 / Capability register
Built, next, later.
POC current
Controlled execution
Step and trace machine instructions inside an execution loop that can enforce policy.
Selective pass-through
Allow chosen host operations while recording and controlling each boundary crossing.
Memory inspection
Expose target memory for inspection and controlled modification from the runtime.
Driver support
Explore extending the same containment and observability model beyond user-mode applications.
03 / Conceptual architecture
Control at the boundary.
01Windows executablePE / x86 / x64
Kernova runtime
02PE loaderparse / map / initialise
03Execution enginestep / trace / enforce
04Memory toolsinspect / modify
05Instrumentationevents / breakpoints / logs
06Host boundaryselected operations only
Small binary, direct control
C provides predictable performance and access to low-level structures required by the loader and runtime.
Instrumentation outside the target
The design keeps tracing, breakpoints, and memory inspection in the controlling runtime rather than relying only on in-process hooks.
04 / Intended runtime flow
From file to recorded run.
- 01
Load and classify
Parse the executable, identify its architecture, and prepare its initial state.
- 02
Execute under control
Run instructions through a loop that can trace activity and apply policy.
- 03
Cross selected boundaries
Pass approved host operations through an instrumented layer.
- 04
Inspect memory
Expose memory regions as part of the runtime workflow.
- 05
Record and export
Keep structured run events and artifacts for later analysis.
| Channel | Example observations |
|---|---|
| Loader | PE parsed, architecture detected, sections mapped |
| Execution | Steps, traces, breakpoints, faults |
| Pass-through | Allowed operations, denied operations, policy decisions |
| Memory | Reads, writes, edits, regions |
| Host I/O | Filesystem, registry, and networking when enabled |
05 / Build plan
A staged proof.
- Phase 0 / current
Executable parser
Validate PE handling, architecture detection, constants, and initial values—even away from Windows.
- Phase 1
User-mode runtime
Build the controlled step/trace loop and a minimal pass-through surface.
- Phase 2
Policy and instrumentation
Record boundary crossings, enforce allow/deny decisions, and export run artifacts.
- Phase 3
Memory workflow
Add first-class viewing and editing tools to the controlled run.
- Phase 4 / stretch
Driver exploration
Test whether the containment model can extend beyond user-mode applications.