Kokino reads evidence that someone may have prepared to break forensic tools, and in lab mode it serves several examiners over the network. This page says how to report a problem, how Kokino defends itself, and what has been tested so far, with numbers.

Please write to lab@zeroscience.mk and do not open a public issue.

Helpful to include:

• the Kokino version and build (Help > About), and the operating system;
• what you did and what happened (a crash, a hang, memory use, a wrong result, access you should not have had);
• if a file triggers it, the smallest file you can share. Never send real case data: if the problem only shows on real evidence, describe it and we will work out a way to reproduce it.

We confirm receipt, keep you informed while we fix it, and credit you in the changelog unless you prefer otherwise. Fixes go into the next release; there are no separate patches for older versions.

Every parser that reads bytes from evidence was fuzzed with a purpose-built mutation fuzzer (crates/kokino-fuzz), on stable Rust:

• Inputs: small valid samples of each format (the test fixtures, plus seeds made by scripts/make_fuzz_seeds.py), changed by 1 to 8 stacked mutations: bit flips, random bytes, boundary values (0, 0x7F, 0x80, 0xFF, 0x7FFF_FFFF, 0xFFFF_FFFF and so on, little and big endian), filled ranges, copied blocks, truncation, deletion and insertion. Mutations are aimed mostly at the non-zero bytes, where the structures are.
• What counts as a failure: a panic (integer overflow included: the fuzz build checks arithmetic, which release builds do not), a stack overflow on a 2 MiB stack (the size of the server's worker threads), one allocation over 256 MiB or more than 1 GiB in use from a small input, and any input that takes more than 20 seconds.
• Reproducible: each input is a pure function of (run seed, input number), so every failure is saved and replayed exactly. crates/kokino-fuzz/regress.txt lists them all, and cargo test -p kokino-fuzz replays them on every test run.

Each round ran all 15 targets at once, one process each, on an 8-core workstation (Windows 10). Rounds 2 and 3 ran after the fixes from the rounds before them, with new random seeds; two more 5-minute photo rounds followed the JPEG fixes: the first (2,244,470 inputs) found one more crash, fixed, and the second (2,168,107 inputs) found nothing. Those are included in the photo total. Fast targets (LNK, Prefetch, strings) reach millions of inputs a minute; whole-volume targets (NTFS, FAT, EWF, browser databases) parse a full image or database per input and run thousands.

Follow-up rounds after the validation work (VALIDATION.md) added NTFS decompression and new checks in the NTFS and FAT walkers: a new lznt1 target ran 1,938,929 inputs with no finding, and 10 more minutes each on ntfs (190,379 inputs) and fat (470,899) found one more crash in the ntfs crate, number 19 below. That brought the total to 197,062,147 inputs and 18 distinct problems found by fuzzing.

The ext2/3/4 reader and the Linux artifact parsers were fuzzed before they shipped (in 1.2.6):

Virtual disks, optical media and Mac disks (1.2.7):

Deeper NTFS and Windows (1.2.8):

Scheduled tasks (1.2.9):

Internet Explorer index.dat (1.2.9):

Deleted registry keys (1.2.9):

Exports, legacy Office text and registry logs (1.3.0):

Legacy event logs, email and journald compression (1.3.0):

Shadow copies, BitLocker, triage collections, VHDX logs, Outlook and macOS (1.3.1):

The first vss round ran an optimized build without overflow checks and found nothing; the same inputs on the fuzz profile (overflow checks on) found the overflows within seconds, and the stack overflow later. That round and the first bde round were stopped to fix what they found and are not counted in the inputs; the rounds after the fixes found nothing.

The vdisk target writes each input to a file (virtual disks are opened by path), so it runs far fewer inputs than the others.

Watchlist (1.4.0):

STIX and MISP watchlists, SRUM app timeline, push and battery tables (1.5.0):

That first round also stopped on a wrong assumption in the fuzzer's own check (an IP network does not "match itself" as an address); the check was corrected and is not counted as a problem.

ext folder names from the journal, JPEGs in two pieces, SRUM long-term energy (1.5.0):

UDF sparable and virtual partitions, ESXi snapshots (1.5.0):

Plugins and UDF sessions (1.5.0):

JPEGs in three pieces (1.6.0):

PNGs in two pieces and deleted PST items (1.6.0):

ZIP and PDF files in two pieces, deleted PST items in free space (1.6.1):

AD1 and AFF4 images (1.6.1):

Ex01 and more PDF carving (1.6.2):

In all: 951,747,137 inputs over 43 targets, and 43 distinct problems found by fuzzing, all fixed.

Before the fixes, every one of these could stop or slow an ingest, a carving job or a picture scan, or exhaust the examiner's memory, on purpose-made evidence. None allowed code execution or wrote to evidence: Kokino has no unsafe code, so the worst a parser bug could do was crash, hang or use too much memory.

Alongside the fuzzing, the server code that handles requests and runs jobs was reviewed. Fixed:

• Evidence paths inside the cases directory. An examiner could add a file from the cases directory as evidence (another case's exports or audit log, the account file with its password hashes, the TLS key) and read it in the hex view. Such paths are now refused (symbolic links resolved, letter case ignored on Windows).
• A parser panic left its job "running" for ever, which also blocked deleting the case. Every background job now catches a panic and ends as failed, with a message asking to report it.
• Reports served without a sandbox. Case and evidence reports are HTML built from evidence text. They were escaped, but now also carry Content-Security-Policy: default-src 'none'; sandbox, so nothing in a report can run script or act as the signed-in examiner.
• SQLite databases from evidence are opened as described in the threat model above.
• BitLocker unlocking (new): the password or recovery password is sent once in the request body, used to derive the key and dropped. Only the volume key is written, to keys/<evidence>.json in the case folder, outside case.json, so no API response carries it. Reviewers cannot unlock (it is a write). Each attempt costs 2^20 SHA-256 rounds on the server, as it does on Windows.

Checked and found sound: the server folder browser (examiners and admins only), export file names (no path separators survive), report file names (a fixed pattern), downloads (nosniff, attachment names from sanitized parts), session cookies and the CSRF and Host checks.

Each release carries SHA256SUMS.txt, a CycloneDX SBOM listing every third-party crate in the build (version, package URL, the checksum Cargo.lock pins, license), and a build provenance attestation for every file, signed through GitHub's Sigstore integration: it ties the file to the workflow run and commit that built it. Check a download with gh attestation verify <file> --repo zeroscience/Kokino. The Windows and macOS packages are not yet code-signed with a publisher certificate.

• The fuzzer is not coverage-guided and runs without sanitizers (no libFuzzer or AddressSanitizer, which need nightly Rust). Since Kokino has no unsafe code, memory-safety bugs would have to come from a dependency; the fuzzer looks for panics, hangs and runaway memory, which are what safe Rust can still do wrong.
• Third-party code is fuzzed only as Kokino uses it: the ntfs crate through the NTFS target, zlib (flate2) through EWF, ZIP, GZIP and PDF, and SQLite through the browser target (SQLite itself is fuzzed continuously upstream by OSS-Fuzz).
• The browser target is slow (each input is written to a temporary database), so it saw far fewer inputs than the others.
• There has been no external penetration test yet.
• In lab mode, examiners can still add any image file the server can read outside the cases directory. Labs that want to restrict this should run Kokino under an account that can read only the evidence storage.

cargo build --profile fuzz -p kokino-fuzz
./target/fuzz/kokino-fuzz list
./target/fuzz/kokino-fuzz run all --secs 600 --seed 4
./target/fuzz/kokino-fuzz run ntfs --secs 3600
./target/fuzz/kokino-fuzz repro ntfs target/fuzz-findings/ntfs/<file>.bin

Findings land in target/fuzz-findings/<target>/. Add each to crates/kokino-fuzz/regress.txt once fixed.