📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives

That is a Good PR

also $'\u' can be used @zoutjebot
and $'\U' can be used also

Not just $'\x'

also can be used

relunsec@relunsec:~$ $'\103'
C: command not found

We need a dedicated rule for that one at PL3 for reducing FPs

Thanks for the fix and for adding tests. The approach is clever — leveraging t:cmdLine to strip backslashes and quotes so the regex only needs to match the normalized form. Low-complexity addition with no FP regressions per the quantitative test.

A few gaps worth addressing before merge:

1. Missing ANSI-C escape variants

Bash ANSI-C quoting supports more escape forms than just \x, and all of them are real evasion techniques:

(@HackingRepo flagged \u, \U, and the octal form earlier in the thread.)

A broader pattern covers all of them:

$(?:x[0-9a-f]{2}|u[0-9a-f]{4}|[0-7]{3}){3,} (but this should be written in .ra format)

Note that after t:cmdLine lowercasing, \U collides with \u, so the 4-hex-digit branch handles both.

2. Threshold of {3,} misses common short commands

Classic RCE probes use 2-char commands (id, ls, cd, sh, ps):

$'\x69\x64' → $x69x64 → only 2 pairs → no match

id is arguably the most common first-probe in real exploits. I'd suggest {2,} — the $ anchor plus explicit escape syntax keeps FP risk low, and the quantitative test would confirm.

3. Test coverage

Only one positive (cat) and one near-miss negative. Worth adding:

• positive for \u Unicode variant
• positive for octal variant
• positive for a 2-char command if the threshold drops to {2,}
• negative for a legitimate value that happens to contain $abc123-style hex-looking content, to confirm the $ anchor requirement

4. Minor: .ra comment

The raw input $'\x69\x64' never actually contains the substring $x69x64 — the match only works after t:cmdLine strips the backslashes and quotes. Worth noting this in the .ra comment so future maintainers don't puzzle over the regex:

##! ANSI-C quoting hex-encoded commands (`$'\x69\x64'` -> $x69x64 after t:cmdLine)
$(?:x[0-9a-f]{2}){3,}

But wait, @fzipi,

After deep fuzzing $'\U, you can also do that, so attackers can evade that

relunsec@relunsec:~$ echo -n $'\U00000043' 
Crelunsec@relunsec:~$ 

relunsec@relunsec:~$ echo -n $'\U00000043' 
Crelunsec@relunsec:~$ 

and

relunsec@relunsec:~$ echo -n $'\U000043' 
Crelunsec@relunsec:~$ 

also works, for $'\U', it can be 8 digits or just 4 or 6

and even 2 digits

relunsec@relunsec:~$ echo -n $'\U43' 
Crelunsec@relunsec:~$ 

ping @zoutjebot, can you address that evaison with $'\U', and add tests for that is detected

hey @zoutjebot, care to push this one to the finish line?