What does IH-OBF-001 flag?
Flags code that hides what it does: long runs of hex escapes, decoding a long base64 literal at run time, packed JavaScript, keywords split into pieces, and strings built from character codes.
- 12 or more \x hex escapes in a row.
- atob, base64.b64decode or Buffer.from called on a quoted base64 literal of 80 or more characters.
- The classic packer signature eval(function(p,a,c,k …
- Short quoted pieces joined to spell eval, exec, curl or bash.
- String.fromCharCode( or chr(.
Why it matters
Readable code can be reviewed; encoded code asks you to trust it. Obfuscation in a small skill is rarely needed and often hides a command.
Examples
Illustrative shapes with placeholders in angle brackets. They show what the rule looks at; they are not runnable and not taken from real malware.
Can IH-OBF-001 fire on a safe skill?
- chr( and String.fromCharCode( are common in ordinary code.
- Minified vendor bundles and embedded binary data.
How do I fix an IH-OBF-001 finding?
- Ship readable source.
- Reject skills that decode or rebuild commands at run time.
CLI guidance: Reject skills that decode or reconstruct commands at runtime.
How do I tune or allow IH-OBF-001?
If a vendored, minified file is expected, exclude it with ignoreGlobs and document where it came from.
Every key is described in Configuration. To print this rule from the CLI, run ironheights rules show IH-OBF-001.
What can IH-OBF-001 miss?
- Encodings that are not on the list, such as plain hex strings, XOR, ROT13 or compression.
- base64 decoded by a shell tool. IH-EXEC-001 covers that only when the output is piped into a shell.
- Obfuscation spread across lines or files.
No finding means no rule matched. It is not proof of safety. Files larger than 1 MiB are skipped without being read; the verdict is then incomplete, not no findings, but the file is still not checked. See Limitations.
Related rules
ironheights rules list.