KSword 5.1: a Windows ARK and kernel forensics suite that keeps R3 and R0 views side by side

What KSword 5.1 actually solves for Windows kernel work

The hard part of Windows kernel inspection is not reading one list. It is reconciling several lists that disagree. A process can be visible to the scheduler and absent from a tool that walks a linked list; a driver can appear in a service entry and be missing from the loaded module list; a handle can be reported by one API and denied by another. KSword 5.1 is built around that reconciliation. The README describes the codebase as focusing on "R3/R0 cross-view evidence", which means the same object is queried from user mode and from the kernel driver and the results are compared rather than merged.

The audience is narrow on purpose. This is for people who already know what SSDT, PiDDB, DriverObject and MajorFunction mean, and who want a GUI that puts those views in one dock layout. The README lists the full Qt application, a lightweight native Win32 build called KswordARKLight, the KswordARKDriver kernel driver, KswordCLI, desktop helper components and an optional installer. If your job is triaging a suspected rootkit on a live Windows host, or validating that a driver you wrote registers the callbacks you think it does, that is the target case. If you want a packet capture tool or an EDR agent, this is not it.

How the R3/R0 split and the DynData offset layer work

KSword is not a single binary that does everything in user mode. The architecture separates collection from presentation. KswordARKDriver implements what the README calls process, thread, handle, memory, network, kernel-object, device and security audit protocols, and the user-mode side talks to it through IOCTLs. The README mentions "centrally verified business IOCTL sources" and describes descriptor-table and IOCTL decoding tools, so the IOCTL surface is treated as something to document and check, not just as plumbing.

Offset resolution is the other half. Kernel structures move between Windows builds, so KSword uses PDB and DynData-driven offsets. The README states that when a packaged DynData profile does not match, the full and lightweight applications can resolve an exact runtime PDB profile in the background, and that identity checks are required before any result is applied. That gate matters: a wrong offset does not produce an error, it produces a plausible wrong number, and a tool that silently applies one is worse than a tool that refuses.

The capability list is organised by dock. There are 17 main workspace docks, with subpages for cross-view, PDB catalog, memory regions, PTE/VA translation, driver services, DriverObject and DeviceObject diagnostics, SSDT/SSSDT, hooks, callbacks, object namespace, minifilter and FileObject evidence, a raw filesystem browser with deleted-entry analysis, and security views covering AppLocker, WDAC/Code Integrity, Defender/ASR and VBS/Hyper-V. The documentation also notes that settings moved from the primary docks to the top menu, and that there is a Kernel Knowledge catalog of 71 searchable articles with versioned R3/R0 live-context queries.

Installing KSword 5.1 and running a first cross-view check

The README does not give a package-manager install line. It says KswordSetup is an optional installer that extracts the release payload and creates shortcuts or integration settings, and that manually extracting the full Release\ directory is functionally equivalent. So the practical path is: get the release payload, then either run the installer or unpack it yourself.

The Launcher is the intended entry point. According to the README it is a pure Win32 startup and compatibility assistant that checks the 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. That last part is the answer to the most common first-run problem. The repository contains a Launcher/ directory, and the README names the component as Launcher.

If the Launcher reports missing offsets for loaded kernel modules, use its offline developer collection bundle path rather than starting the Qt app and hoping offsets resolve.

The CLI is the other way in, and the README names it for automation, validation and troubleshooting. The repository contains a KswordCLI directory, so the binary comes out of your own build or the release payload rather than a separate download.

For the GUI path, the first useful check is the Process dock: open Cross-View and compare the user-mode process list against the kernel-mode view. If the two agree on a clean machine, your driver is loaded and the offset profile is sane. If they disagree on a machine you suspect, that disagreement is the evidence you came for. The README also notes lazy initialization of visible docks, so docks populate as you open them rather than all at startup.

Where KSword 5.1 is the wrong tool, and where its own guards stop you

The HVM page is the clearest boundary. The README describes confirmation-gated VMX self-tests, a one-shot guest, and a guarded resident Intel VT-x/EPT monitor with VM-exit telemetry. It then states that resident start is rejected on AMD, under an existing hypervisor, or when power, topology or unload lifecycle guards are unavailable, and that the feature is intended for authorized lab and diagnostic use only. If you are on an AMD host, or you already run Hyper-V or another hypervisor, that page is not available to you at all. That is a documented refusal, not a bug.

The Scanner dock's byte editor is deliberately constrained. The README says it is limited to length-preserving changes, revalidates the source snapshot, atomically replaces the target, and can keep a backup only after explicit risk acknowledgement. If you need to patch a binary in a way that changes its size, this editor will not do it.

There is also a coverage caveat the project states itself. The dock inventory is described as based on recent code, comments, dock-initialization logic and the R0/R3 protocols, and the README points to docs/OpenArk功能对照与TODO.md for the OpenArk coverage comparison and remaining TODOs. That is an admission that coverage is still being filled in. And the README notes that runtime unsupported, partial, truncation, DynData, privilege and hardware limits remain explicit, which means you should expect to see those states rather than a clean answer on some targets. A tool that shows you "partial" is more honest than one that guesses, but it still leaves you without an answer.

How KSword differs from Process Explorer and from OpenArk

Process Explorer is the obvious comparison for the process and handle views, and the difference is architectural rather than cosmetic. Process Explorer is a user-mode tool: it reads what the kernel exposes through documented interfaces. KSword pairs that with a kernel driver that implements its own audit protocols, so the same object can be inspected from both sides and the two answers compared. That is the whole point of the Cross-View pages. If you only ever need the user-mode view, Process Explorer starts faster and requires no driver.

OpenArk is the closer comparison, and the project treats it as such: the README references docs/OpenArk功能对照与TODO.md as an OpenArk coverage comparison with remaining TODOs. The practical difference visible in the README is scope and presentation. KSword ships a Qt/ADS desktop application with a dock layout, a separate lightweight native Win32 build for older systems and low-resource environments, a CLI, and the Kernel Knowledge catalog with 71 articles and versioned R3/R0 live-context queries. The light build is the more interesting divergence: the README describes it as having simpler dependencies, faster startup and a focused feature set, which is a different trade-off from the full application rather than a cut-down copy.

One more distinction worth naming: KSword gates mutation. The README describes transactional MajorFunction and DriverObject/KLDR image and list editors, and says the codebase focuses on read-only audit pages with explicit gates for destructive or mutation-oriented actions. A tool that makes you confirm before it writes to a driver object is slower to use and harder to misuse.

Maintenance, licensing and what a GPL-3.0 Windows driver implies

The repository is not archived. The most recent push recorded for it is 2026-08-29, which is recent enough that the project cannot be described as dormant, and the release list shows a 5.1.4.3 release on 2026-08-28 plus CI builds the same week, including one titled with a fix to log-window refresh selection state. CI builds appearing alongside versioned releases suggests changes land continuously rather than in occasional drops.

Upgrade cost is the real question for a kernel tool. Because KSword depends on PDB and DynData-driven offsets, a Windows update that moves kernel structures can invalidate a packaged profile. The README's answer is the runtime PDB resolution path, where the application resolves an exact runtime PDB profile in the background and requires identity checks before applying a result. That reduces the chance of a wrong reading, but it means offset maintenance is an ongoing activity for whoever runs this, not a one-time setup. The Launcher's offline developer collection bundle exists precisely for the case where loaded modules have missing offsets.

The licence is GPL-3.0, which is a copyleft licence. The README calls the project "source-available" and the LICENSE file at the repository root carries the terms. The practical implication for an engineering team is that distributing a modified KSword, or a product built from its code, brings GPL-3.0 obligations with it, and the kernel driver is part of the same repository. That is a question for your own legal review, not something this article can settle. If you need to ship closed-source code derived from these components, the licence is the first thing to examine.

Editorial conclusion

Adopt KSword if you already do Windows kernel debugging or incident forensics and you want one place where user-mode and kernel-mode views of processes, drivers and objects sit next to each other. Do not adopt it as a general-purpose endpoint agent, and treat the HVM page as lab-only: the README states resident start is rejected on AMD, under an existing hypervisor, or when power, topology or unload lifecycle guards are unavailable. Before you rely on it, verify three things: that the Launcher finds a readable support manifest for your build, that a DynData profile matches your kernel or that the runtime PDB identity check succeeds, and that Driver Integrity plus Module Cross-View agree on the machines you care about. The repository is GPL-3.0, so check how that interacts with your own distribution before you ship anything built from it.

Frequently asked questions

Official sources

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