KSword 5.1: A Source-Available Windows ARK with Explicit Safety Gates

What KSword Solves and Who It Serves

KSword 5.1 addresses the problem of hidden or malicious kernel-mode activity on Windows. Rootkits and advanced malware often hide processes, threads, handles, or network connections from standard APIs, and they may hook kernel functions or manipulate driver objects. KSword provides a cross-view approach: it compares what the Windows API reports (R3) with what the kernel driver sees (R0) to surface discrepancies as evidence. The intended audience is security researchers, forensic examiners, and system administrators who need to inspect a live system at a deep level. The README emphasizes that the current codebase focuses on R3/R0 cross-view evidence, PDB/DynData-driven offsets, read-only audit pages, and explicit gates for destructive or mutation-oriented actions. That focus tells you the tool is built for analysis, not for everyday system tweaking. It is a serious toolkit for people who understand kernel internals and are comfortable with driver-level access.

Architecture: A Driver, a Full GUI, and a Lightweight Client

The repository contains several distinct components. The central piece is the kernel driver, KswordARKDriver, which implements audit protocols for processes, threads, handles, memory, network, kernel objects, devices, and security. On the user side there are two main applications: Ksword5.1, a full Qt application with an ADS dock layout, and KswordARKLight, a lightweight native Win32 ARK for older systems and low-resource environments. The Launcher is a pure Win32 helper that checks a readable support manifest before launching either target, and it can prepare an offline developer collection bundle when loaded kernel modules have missing offsets. There is also a CLI (KswordCLI) for automation and validation, plus helper components like Taskbar, KswordHUD, and APIMonitor_x64. The optional installer simply extracts the release payload; manually extracting the Release directory is functionally equivalent. This separation means you can run the full GUI for everyday work, the light client for older hardware, or the CLI for scripting, all against the same driver.

How Evidence Collection Works: PDB Profiles and Cross-View

The tool's evidence model relies on versioned kernel offsets. When a packaged DynData profile does not match the target system, both the full and lightweight applications can resolve an exact runtime PDB profile in the background. The README stresses that identity checks are required before any result is applied, which is a safeguard against using wrong offsets that would produce false evidence or crash the system. The KernelDock includes a bilingual Kernel Knowledge center with 71 searchable topics across 12 categories. Each topic has an eight-part article, a versioned R3/R0 live-context query, and centrally verified business IOCTL sources. The user can navigate from a knowledge article directly to the corresponding evidence page. This integration between a knowledge base and live queries is a distinctive feature: it does not just show raw data, it ties each query to a documented explanation of what the data means and which IOCTL the driver uses. The README also mentions that runtime unsupported, partial, truncation, DynData, privilege, and hardware limits remain explicit, so the tool does not silently pretend to have full coverage.

The Scanner Dock and Its Guarded Byte Editor

A dedicated Scanner dock performs background structural scans of PE, ELF, and Mach-O files. This is useful for analyzing binaries that may be packed or modified. The optional byte editor is deliberately constrained to length-preserving changes. It revalidates the source snapshot, atomically replaces the target, and can keep a backup after explicit risk acknowledgement. This design is a direct response to the danger of corrupting files during analysis. Length-preserving edits mean you cannot insert or delete bytes, which limits what you can do, but it also prevents accidental shifts in file structure. The atomic replacement and backup requirement are practical safety measures. The README does not specify how the editor handles files that need structural changes, so if your workflow requires inserting code or changing section sizes, this tool will not work for you. It is a forensic editing tool, not a general-purpose hex editor.

HVM Page: Virtualization Self-Tests with Hard Guards

The HVM page supports confirmation-gated VMX self-tests, a one-shot guest, and a guarded resident Intel VT-x/EPT monitor with VM-exit telemetry. Resident start is rejected on AMD systems, under an existing hypervisor, or when power, topology, or unload lifecycle guards are unavailable. This is a clear limitation: if you are on AMD or already running Hyper-V, you cannot use the resident monitor. The README states that the feature is intended for authorized lab and diagnostic use only. This is not a tool for casual experimentation. The guard logic is a positive sign because it prevents accidental hypervisor conflicts that could crash the host. But it also means the HVM feature has a narrow compatibility window: Intel CPUs, no existing hypervisor, and a system that supports the required lifecycle guards. Before relying on this feature, you must verify your hardware and firmware configuration.

Kernel Forensics and the Raw Filesystem Browser

The kernel and storage forensics modules include clean loaded-image and IDT baselines, descriptor-table and IOCTL decoding tools, kernel disassembly, expanded R0 network inventories, and a raw filesystem browser with deleted-entry analysis. The baselines are important for detecting modifications: by comparing the current state against a clean baseline, you can spot hooks or injected code. The raw filesystem browser operates in read-only mode, which is appropriate for forensic work because it avoids altering the evidence. Deleted-entry analysis can recover remnants of files that standard APIs would not show. The README also mentions driver services, loaded modules, DriverObject/DeviceObject/MajorFunction/FastIo diagnostics, transactional MajorFunction and DriverObject/KLDR image/list editors, and Driver Integrity checks. These are advanced features that require a solid understanding of Windows kernel internals. The tool provides a lot of data, but interpreting it correctly is the user's responsibility.

Getting It Running: Installation and Configuration

The README does not provide explicit installation commands, but it describes the components and the release structure. You can either run the optional KswordSetup installer, which extracts the release payload and creates shortcuts, or manually extract the full Release directory, which is functionally equivalent. The Launcher checks a readable support manifest before launching the Qt or Light target, and it can prepare an offline developer collection bundle when loaded kernel modules have missing offsets. This suggests that the support manifest is a key configuration file that defines what the tool expects from the system. The driver must be loaded, and on modern Windows that requires proper signing and likely a test-signing mode or a signed driver from the project. The README does not detail the driver installation process or the exact commands to start the CLI. You would need to inspect the repository's documentation or source code to find those specifics. The presence of a CLI suggests there are command-line options, but they are not listed in the provided material.

Limitations, Maintenance, and Alternatives

A genuine limitation is the HVM feature's narrow compatibility, as noted above. Another is the byte editor's length-preserving constraint, which limits its utility for structural edits. The README also mentions that runtime unsupported, partial, truncation, DynData, privilege, and hardware limits remain explicit, meaning that some features may not work on all systems or may be incomplete. The project is actively maintained, with recent releases in August 2026, and it is licensed under GPL-3.0, which means you can modify and redistribute it, but any derivative work must also be GPL-licensed. The maintenance cost is moderate: because the tool relies on kernel offsets and PDB profiles, it needs updates to keep pace with new Windows versions. The README includes a comparison document, docs/OpenArk功能对照与TODO.md, which compares KSword with OpenArk. OpenArk is a well-known open-source ARK tool that also provides kernel-mode visibility and is a direct alternative. The key difference is that OpenArk has a longer history and a broader user base, while KSword appears to be a newer, more focused project with a built-in knowledge base and stricter safety gates. If you need a proven tool with extensive community support, OpenArk is a safer choice; if you want the latest features and are willing to accept the additional risk of a newer codebase, KSword is worth evaluating.

Editorial conclusion

KSword 5.1 is for security researchers, forensic analysts, and advanced administrators who need deep Windows kernel visibility and are willing to run a driver and accept the associated risk. It is not for casual users or production machines without a test environment, because the driver and the guarded mutation tools require elevated privileges and can destabilize the system if misused. Before adopting it, verify that your target Windows version matches the packaged DynData profiles, or be prepared to let the tool resolve an exact PDB profile; also check that your CPU and hypervisor state allow the HVM features if you plan to use them. If you need a more established tool with a longer track record, consider OpenArk, which KSword explicitly compares itself against in its documentation. Adopt KSword if you want a source-available suite that separates read-only evidence collection from explicitly gated destructive actions, and verify the driver signature and the integrity of the release build before running it.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes