v1.4.3 — a purge that reported zero and left the payload

Found by purging a real repository and then scanning what came back.

A 29,057-byte api.js survived the rewrite, and the purge printed blobs still carrying a hidden payload: 0. The verify step re-runs the same cleaner, so anything the cleaner cannot see verifies clean — a false clean in remediation, reported with a number beside it.

Why it was invisible

The file opened with the whitespace wall. 424 tabs, then 28KB of code on the same line, and that was the whole file. One rule needs real code in front of the run; the other needs the payload to look obfuscated. This satisfied neither.

The obfuscation style was unrecognised — no _0x identifiers, no \u00 escapes, no eval(, no atob(. Just long random identifiers (RvJq_qacMrKUHEOocOXlFJqDe) and an array of hex strings decoded at runtime.

What changed

• A line starting with 50+ spaces or tabs, long, dense, carrying a hard campaign marker is dropped on that basis alone. The whitespace prefix is the structural tell, and no honest file opens that way.
• Two adjacent 8+ character hex strings inside an array literal is now an obfuscation signal of its own.

Verified on the live sample: cleans to 0 bytes. Controls untouched — snare's own guard pattern, a minified vendor bundle, deeply indented source, a JSON document, a tab-indented recipe.

If you have run --purge-history before, run it again with this version. A clean report from an older one did not mean the history was clean.

snare update && snare fix <owner/repo> --purge-history --push