A tool that modifies system state should be able to answer a simple question honestly: what did it change, and when? Most utilities answer with a log file you have to take on faith — a file anyone or anything could quietly edit. ContextCleaner answers differently. Its audit log is a cryptographic hash chain, so the record itself can be verified, and tampering with it is detectable.
This deep dive explains how that log is built, what its guarantees actually are, and — just as important — what it deliberately does not claim. It is written for security engineers, sysadmins, and developers who want to understand the mechanism rather than trust a marketing word like “secure.”
The shape of the log
The audit log is a JSONL file: one JSON object per line, append-only. Each line is a single event, and every state-changing action ContextCleaner takes produces one — applying registry changes, creating a backup, restoring a snapshot, changing a setting, restarting Explorer, and administrative actions on the log itself.
Each entry carries a small, well-defined set of fields:
seq— a monotonic sequence number within the current file, starting at 1timestamp— an RFC 3339 UTC timestampschemaVersion— the schema version, so future readers can evolve safelykindandaction— a category and a short machine-readable verb such asregistry.applydetails— a structured, PII-free payload (counts and summaries, not file contents)prevHash— the SHA-256 hash of the previous entryhash— the SHA-256 hash of this entry’s canonical payload
The last two fields are what turn a flat log into a chain.
How the chain works
Each entry’s hash is the SHA-256 of a canonical serialization of that entry’s payload, and that payload includes the prevHash, which is the previous entry’s hash. So entry n commits to entry n−1, which commits to n−2, all the way back to a genesis entry whose prevHash is a fixed all-zeros sentinel.
The consequence is that the entries are cryptographically linked in order. You cannot change the contents of any entry without changing its hash, and you cannot change its hash without breaking the prevHash reference in the entry that follows it. The chain encodes not just each event but the exact sequence of events.
Verification is a single forward walk:
- Start with the genesis sentinel as the expected
prevHash. - For each entry, confirm
seqis the next expected number, confirm itsprevHashmatches the running value, recompute the SHA-256 of its payload, and confirm it equals the storedhash. - Carry that
hashforward as the expectedprevHashfor the next entry.
The verifier stops at the first broken link and reports exactly which sequence number failed and why — a non-monotonic sequence, a prevHash mismatch, or a recomputed-hash mismatch indicating an edited entry. ContextCleaner surfaces this as a green “verified” state or a precise failure in the Diagnostics view.
What this detects
The chain reliably detects the accidental and the casual-malicious:
- Edits. Change any field of any past entry and its recomputed hash no longer matches the stored one.
- Deletions and insertions. Remove or insert a line and the sequence numbers and
prevHashreferences no longer line up. - Truncation. A log cut off mid-write (for example, a crash) shows up as a break, so partial writes are visible rather than silently accepted.
- Reordering. Because each entry commits to its predecessor, shuffling entries breaks the chain.
This is exactly the class of problems that a plain text log cannot catch: with no chain, an edited or trimmed log looks identical to an honest one.
What it deliberately does not claim
Honesty about the threat model is part of the design, and the code’s own documentation is explicit about it. The chain is evidentiary, not cryptographically signed. A sufficiently privileged local attacker can rewrite the entire log from the genesis entry forward and recompute every hash, producing a chain that verifies. Without a secret key or an external anchor, there is no way for a purely local, self-contained log to prevent a full rewrite.
So what is the chain actually worth? Three concrete things:
- It detects accidental corruption — crashes mid-write, partial truncation, a tool that touched the file without knowing the rules.
- It detects targeted edits by anything that does not understand the chain — the common case, where something modifies a line but does not recompute the entire downstream chain.
- It gives support engineers an ordered, verifiable record that a user can be asked to share, with a clear pass/fail integrity check.
Claiming more than that would be dishonest, and the tool does not. It is tamper-evident, not tamper-proof, and the distinction is stated plainly rather than buried.
Append-only writes and rotation
The writer opens the file in append mode, writes a single line, and flushes. Past entries are never rewritten in normal operation. When the active log grows past a soft cap (about 2 MiB, chosen to keep it human-scannable and to keep diagnostics exports small), it rotates: the current file moves to a dated archive, and a fresh chain begins with a genesis entry that records the rotation reason and the previous file’s final hash. That last detail preserves linkage across files — the new chain points back to the tail of the old one, so the history remains continuous even though each file verifies independently. Archives are pruned to a bounded count so the log never grows without limit.
Notably, “clearing” the log is implemented as a rotation, not a deletion. The active chain restarts, but the prior entries are archived rather than destroyed, so a clear performed by mistake does not erase history.
Privacy is built into the write path
The log records registry key names and before/after primitive values — never file contents. More importantly, redaction happens before hashing, not as a later filter. Each entry’s details payload is scrubbed of user-profile paths (your C:\Users\<name> directory is replaced with a placeholder) at write time, so the persisted log, the hash computed over it, and anything that later reads it are all consistently PII-free.
This ordering matters: because the scrub happens before the hash is computed, a verified chain is also a chain over already-redacted data. There is no window in which a raw path is hashed and then cleaned up afterward. The diagnostics export applies the same scrubbing again as a belt-and-suspenders measure for older logs that predate the write-time scrub.
Why a context menu tool bothers with this
It is fair to ask why a right-click menu utility needs a cryptographic audit trail at all. The answer is accountability. ContextCleaner modifies system state, and on a machine someone is responsible for — a developer’s workstation, a managed corporate device, a shared family PC — “what changed the shell last week?” is a real question. A verifiable, local, PII-safe record answers it without sending anything to a cloud service. It is the same instinct behind the automatic backups: changing how Windows behaves should always leave you with a way to understand and reverse what happened.
Frequently asked questions
Is the audit log tamper-proof?
No, and ContextCleaner does not claim it is. It is tamper-evident: it detects accidental corruption and edits made by anything that does not recompute the whole chain. A privileged local attacker who understands the chain could rewrite it entirely, which is an inherent limitation of any unsigned, self-contained local log.
What algorithm secures the chain?
SHA-256. Each entry stores the hash of its own canonical payload and the hash of the previous entry, forming the chain back to a fixed genesis sentinel.
Does the log contain my files or personal data?
No. It records registry key names and primitive before/after values, not file contents, and user-profile paths are scrubbed to a placeholder before the entry is hashed and written. Diagnostics exports re-apply that scrubbing.
What happens when I clear the log?
Clearing rotates the active log to a dated archive and starts a fresh chain that references the old file’s final hash. Your prior entries are archived rather than deleted, so an accidental clear does not destroy history.
Where is the log stored?
In ContextCleaner’s local app data directory on your PC. There is no telemetry and no cloud sync; the record never leaves your machine unless you choose to export and share a diagnostics report.
The bottom line
ContextCleaner’s audit log is a SHA-256 hash chain in append-only JSONL: every system change is recorded as an entry that commits to the one before it, so edits, deletions, truncation, and reordering are all detectable by a simple forward verification. It is honest about being tamper-evident rather than tamper-proof, it scrubs personal paths before hashing, and it keeps everything local. For a tool that changes system state, that is what an accountable record looks like. See the full specifications on the ContextCleaner product page.