fix(amwscan): the discriminator is in the parentheses, and the => line is source

[thiagoluga]

Found by reading the raw report from a live account — which only became possible with #94, because raw_ref pointed at the process's stdout until then.

What the real engine emits

 => [!] Function (exec) [line 147]
    - Potentially dangerous function `exec`
      => exec('kill -' . (int) $signal . ' ' . (int) $pid . ' 2>/dev/null', $out, $code)

Function is not in the rule table and never will be. exec is, and has been all along — the adapter captured it into a field used only for display, then classified on the rule name.

On that account, of 333 Function findings:

token	count	table says	reported as
eval	199	backdoor / critical	other / medium
assert	42	backdoor / high	other / medium
exec	29	webshell / critical	other / medium
shell_exec	12	webshell / critical	other / medium

288 of 333, all landing on the generic fallback.

And the => line is not a category

It was read as the category the engine assigned, with priority over everything else. It is the source that matched. On that account the resulting "categories" read lave, tressa, ipconfig, suhosin — fragments of somebody's source code.

lave is eval backwards. AMWScan detects strrev-obfuscated calls and prints the reversed string it found, so an obfuscated backdoor classified as unknown while the plain word eval sat one pair of brackets away.

That text comes out of the scanned file, which means its author chooses it. Nothing today exploits that — the snippet is usually far too long to collide with a table key — but a finding's category should not be selectable by the thing being examined.

Scope — corrected after measuring it

I first wrote that verdicts and quarantine decisions do not change. That was too strong, and an A/B run against the real engines showed why.

For the Function (...) findings it holds: both eval and the unknown fallback are heuristic, the multiplier is identical, and only the category and severity a human reads to triage change — 199 eval hits shown as generic medium rather than backdoor/critical.

For Signature (<hash>) it does not hold. Those used to be classified by the snippet, and in the container's corpus that snippet is the word backdoor, which maps to a heuristic entry. They now fall through to signature:

before:  vote: amwscan  weight 0.80 x heuristic = 0.64  (rule Signature)
after:   vote: amwscan  weight 0.80 x signature = 0.80  (rule Signature)

A signature hit now carries the weight the project always intended for it — the rule table's own comment calls it "the only case where it claims to recognize the THREAT, not a pattern". It is a correctness fix, and it raises scores, which means a finding can cross a verdict threshold it previously did not.

In this corpus nothing crossed one. Same image, only the classification line reverted:

without the fix:  confirmed=1  likely=3  suspicious=3  clean=0
with the fix:     confirmed=1  likely=3  suspicious=3  clean=0

Flagging it rather than burying it: on a site with a signature hit plus one other weak vote, this can turn likely into confirmed, and confirmed is what authorises an automatic quarantine.

My first attempt at that comparison was worthless, and I want it on the record. I compared against a run in which the engines had failed to download, so it had no AMWScan at all — two numbers that differ because one scan had two more engines say nothing about a classification change.

The fixture, and the uncomfortable part

The old fixture is genuine. => backdoor really was printed — that hit's matched content happened to be the word "backdoor". One sample's coincidence was read as structure, and a parser plus a passing test were built on it.

PROVENANCE.md now records the lesson next to the earlier one it already carried: a real capture is necessary and not sufficient. Where a format matters, capture more than one file, from more than one site. The second capture disagreed with the first about the only thing that mattered.

New fixture: real-0.15.1-function-and-exploit.txt, sanitised (paths rewritten, long snippets truncated as the engine truncates them, nothing else altered), covering Function (eval|exec|assert|shell_exec|proc_open), Exploit (execution|hex_char), Signature (<hash>) and the two strrev hits.

TestAMWScanTheTagBeatsTheRuleName is replaced by TestAMWScanASignatureIsKnownMalware. Confirmed by mutation — classifying on the snippet again fails with exec: category "other", wanted "webshell".

Left deliberately undone

The Exploit vocabulary — execution (732), base64_long, hex_char, nano, etc_passwd, php_uname, clever_include — is not in the table. Each needs the engine's own description read before being mapped; those descriptions are in the report, on the - line under each finding, and the distribution is recorded in PROVENANCE.md for whoever does it. Mapping them from the names alone is the guess this PR is about not making.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[thiagoluga]

Deployed, and confirmed on the account it was found on

v0.1.12-9-gb27b5ef is on the validation host — sha256 verified before and after the move, panel answering, public in 0.56s.

The classification across that account's votes, before and after:

category	before	after
other	180	45
backdoor	—	97
webshell	—	38
known_malware	36	36

135 findings left the generic bucket. The 45 still in other are the unmapped Exploit vocabulary, which #97 addresses.

One detail worth recording, because it demonstrates the concern rather than arguing it

known_malware is 36 both before and after — but for different reasons, and the difference is the whole point.

On this account, a Signature hit's matched source is the word exploit, which is not in the rule table, so it fell through to the rule name and classified correctly by accident. In the validation container, the same rule's matched source is the word backdoor, which is in the table — so it classified as backdoor/heuristic and carried 0.64 instead of 0.80.

Same engine, same rule, two different wrong answers, decided by what the scanned file happened to contain. That is what "the file's author chooses the category" means in practice, and it is why the matched source is now evidence only.