KapeFiles: community Targets and Modules for the KAPE triage tool

A Target says what to collect, a Module says how to read it

The two file types are the whole mental model of this repository, and separating them is what makes KAPE extensible by ordinary people. A Target describes which files to gather: the paths, the file name patterns, the registry keys or other artefacts that hold the interesting data on a given device or in a given storage location. A Module describes how to parse what the Target collected, turning a raw artefact into structured output an investigator can read. KAPE itself is described as an efficient and highly configurable triage program that will target essentially any device or storage location, find forensically useful artefacts, and parse them within a few minutes. Because the two halves are separate files, adding support for a new application means writing a collection rule and a parser rather than modifying the tool, and that is why a community repository of text files can extend a program meaningfully. The primary language recorded for the repository is unknown, which is consistent with the content being configuration and parser definitions rather than application code.

Getting the files into KAPE is one button or one flag

The mechanism for taking updates from this repository into the tool is deliberately simple. To download the latest files, you click the Sync with GitHub button in gkape.exe, or run the equivalent from the command line:

kape.exe --sync

The KAPE program itself is downloaded separately, from the Kroll site, and the documentation lives at a separate documentation site which the README says will always be the latest documentation. The repository itself holds no binary and nothing to compile. The top level entries are the Modules directory, the Targets directory, a kape directory, a CONTRIBUTING file, a licence file, a .yamllint configuration and the logo image. The .yamllint file is worth noting, because it tells you the files in the repository are YAML, and linting them is how a contribution with a syntax error gets caught before anyone tries to parse it. The repository was pushed to on 2026-10-19 and carries the MIT licence, with no GitHub releases.

Guides and templates, so a contribution does not start from nothing

The resources for people writing these files are listed explicitly, and the pattern is the same for Targets and Modules. For Targets there is the official KAPE documentation page on tips and tricks with a section on target creation, a Target guide, a Target template, and then the same trio again for compound targets: a compound target guide and a compound target template. Modules have the identical set, with a module guide, a module template, a compound module guide and a compound module template. The distinction the repository draws is that a compound artefact combines several files into one logical thing, which is common in modern applications where the interesting data is spread across a database, a log and a cache. The templates exist so a contributor starts from a working skeleton with the required sections filled in, and the guides explain what each section means. One instruction is easy to miss and matters for every Module: point the BinaryUrl property to the download location in the Module file, and document everything else, including the requirements, in comment blocks at the end of the Module.

The pull request checklist is not optional

The contributing section is short but the emphasis is clear. You are asked to see the CONTRIBUTING file for guidance, and then there is a note in capitals: before initiating a pull request, please ensure you have completed the steps listed within the pull request template prior to submission. The pull request template is therefore part of the contribution process rather than a formality, and the likely reason is that a Target or Module that passes review but fails in the field is worse than one that never gets merged, because a forensic tool that silently collects the wrong files produces a wrong conclusion. The repository also maintains a To Do list as a project board, described as a development roadmap for KAPE Targets and Modules, and the invitation is to contribute ideas or to finish tasks in the To Do column. For a domain where artefact formats change with every application release, that backlog is the mechanism that keeps the coverage current.

Two licences, and the difference is not academic

There are two separate licensing questions here and they are easy to conflate. This repository, which holds the community Targets and Modules, carries the MIT licence with the file at the root. KAPE, the program the files are for, has its own usage permissions, and the README carries a note that these have been clarified for commercial applications with a link to the details in the frequently asked questions page of the documentation. So the permissive licence covers the contributed files and the tool has separate terms. If you are using KAPE inside a commercial product or a paid engagement, the repository licence is not the thing to rely on; the clarification in the documentation is. The documentation also has a KAPE Manual page, and the contributing and support routes are split: a discussions board for general questions, an issue tracker for bugs, and the Targets and Modules sections of the README for help with the files themselves.

Why a community repository beats a monolithic tool for this problem

The obvious alternative to a community repository of Targets and Modules is for the tool vendor to ship every parser, which is what a single binary with baked-in coverage would be. The difference in approach is where the maintenance burden lands and how quickly coverage moves. Vendor-shipped parsers are written by the vendor against the applications they choose to support, and they go stale when a vendor changes a format, which for chat applications and browsers happens often. Community Targets and Modules put the parser next to the people who know the artefact, so a format change is fixed by whoever noticed it, and a broken parser is fixed rather than abandoned. The cost is that you have to judge the quality of a community contribution, and the project is candid about that by requiring the pull request checklist, by linting the YAML, and by shipping guides and templates that specify what a good Module contains, including where the binary comes from and what the requirements are.

What to check before you trust a Target or a Module

Because these files decide what gets collected and how it is interpreted, there is a short list of things worth verifying before you rely on one. First, that the Module names where its binary comes from, since a parser that silently depends on a download you cannot account for is a problem when you need to repeat the acquisition months later. Second, that the requirements are documented in the comment blocks at the end of the file, which tells you what the parser needs to run. Third, that the Target's paths and patterns match the current version of the application, since a path that moved means silent non-collection rather than an error. Fourth, that the module version in the collection matches the artefact format. None of this is documented as a checklist for the reader, and the guides are written for the author, but they are the same questions the pull request template asks the contributor to answer, and reading the guide for a module before running it is the shortest way to know whether it has been thought through.

Editorial conclusion

KapeFiles suits a forensic analyst who already runs KAPE and wants coverage of an application or an artefact type the tool does not handle, and who is comfortable writing a small parser and a collection rule. It does not suit someone looking for a ready-made acquisition tool, because there is no executable here, and the value of a contribution depends entirely on the parser being correct. Before you start, read the target and module guides and copy the templates rather than writing from scratch, and if you plan to run the tool in a commercial context, read the usage permissions note the README points to, since the licence of this repository and the licence of KAPE itself are separate things.

Frequently asked questions

Official sources

1. EricZimmerman/KapeFiles on GitHub
2. Issues
3. License: MIT
4. README