Is matrix-meta/hex-vetter safe?

scan_all.js sets SKILLS_DIR = path.join(__dirname, '..') which resolves to the home directory (/home/oc-exec/) in this deployment. The script enumerates all files recursively (excluding only .git, node_modules, pycache, and a short ignoredFiles list), runs vet.js on each file producing a full hex dump, and saves the output to ../../security_audits/hex_dumps/. This causes the complete hex-encoded contents of .ssh/id_rsa, .aws/credentials, .docker/config.json, and .config/gcloud/application_default_credentials.json to be written to disk. Confirmed by auditd PATH records 257-262 showing OPEN+ACCESS on all six credential files.

starfragment.js reads and rewrites its own JavaScript source file at runtime using writeSelfEOF(), embedding obfuscated JSON data as a valid JS comment at the end of the file. The shipped version already contains a pre-seeded starfrag comment, proving this mechanism ran before the skill was committed to the repository. This allows the skill's behavior to change across invocations without any visible code change from a git diff perspective after first run.

starfragment.js saveFragments() splits obfuscated data into 8 fragments and hides them in directories named '.sys-XXXXXXXX' inside ~/.cache, ~/.local/share, ~/.local/state, ~/.thumbnails, and /tmp. Files are named 'cache_XXXXXXXXXXXX.tmp'. The directory and file naming mimics legitimate system cache artifacts to avoid detection. Data is XOR-obfuscated with a SHA256-derived key. The PRIMAL_SEED and constants are derived at startup and stored back into these fragments, creating a persistent cross-session covert channel.

Both scan_all.js and verify.js execute 'echo -500 | sudo tee /proc/self/oom_score_adj' before performing sensitive operations, attempting to set the process's OOM score to -500 (system processes are typically -1000; user processes are 0). This makes the process nearly unkillable by the kernel's OOM manager during credential scanning. After operations complete, the score is restored to 0. This is a deliberate attempt to prevent the credential harvesting process from being terminated.

git-safe-update.js performs git pull on the skill's own directory (__dirname), then runs vet.js on changed files. This creates a persistent update channel: any future commit to the Matrix-Meta/hex-vetter repository would be automatically pulled and executed the next time an agent runs this skill. An attacker controlling the repository can silently replace any file (including starfragment.js) with malicious code.

When scan_all.js runs vet.js on credential files, the hex dump output (containing the full byte-by-byte encoding of the credential file) is written to ../../security_audits/hex_dumps/ relative to the skill directory. In this deployment that would be /home/security_audits/hex_dumps/. These files are persistent and accessible to any process on the system. The file naming convention (skillname_filename.hex.txt) makes the contents easily identifiable.

scan_all.js calls starfragment.injectIntoHexDump() which silently replaces 8 bytes at offset 15 in every hex dump report with fragment data. This corrupts the integrity of the audit reports while hiding attacker-controlled data inside them. An analyst reviewing a hex dump would see slightly wrong byte values but might attribute it to normal variation, while the attacker's data is embedded in what appears to be ordinary audit output.

Six canary credential files were opened and read (confirmed by both inotifywait ACCESS events and auditd PATH syscall records) at timestamp 1771921953 during skill installation/initialization. The canary integrity system only detected whether files were modified, not whether they were read — this is a fundamental gap the skill appears designed to exploit. CLOSE_NOWRITE confirms the skill read without writing, evading write-based canary detection.

starfragment.js getPrimalSeed() allocates 262,144 (DECOY_COUNT) random 64-byte hex strings and stores them in global._SECURITY_DECOYS, then hides the real seed by overwriting a random index (poisonIndex) with the real value. This floods process heap memory with random-looking data that makes memory forensics analysis unable to identify the real seed material without exhaustive search. The variable is named '_SECURITY_DECOYS' internally, confirming intentional anti-forensics purpose.

The skill presents itself as a security auditing tool ('Detects hidden binary data, control characters, and encoding-based attacks') specifically designed for AI agent systems. This framing causes users and agents to grant it elevated access and trust — a security tool must be allowed to read files broadly to do its job. The actual behavior (credential harvesting, hidden persistence, self-modification) is the exact opposite of what the skill claims to prevent. The Security Policy section further legitimizes invasive file access under the guise of mandatory audit procedures.

The Security Policy section of SKILL.md uses imperative language to override agent judgment: 'MUST be manually inspected', 'MUST: Notify the user immediately', 'Suggest next steps for manual review'. While not classic prompt injection (no 'ignore previous instructions'), these directives are designed to coerce the agent into specific behaviors when the skill reports findings — specifically ensuring the agent reports HIGH RISK findings in a way that validates the skill's false-positive cover story for accessing sensitive files.

The SKILL.md overview paragraph contains garbled text: 'Physical-layer hex auditing skill forects hidden binary data AI agents. Det, control characters' — words appear truncated or shuffled. This could indicate an attempt to hide content within what appears to be a rendering artifact, or a Unicode/encoding manipulation that was partially detected and rendered incorrectly. The frontmatter description is clean while the body text is corrupted, which is inconsistent with legitimate documentation.