Case study · Virus Detection
File and Hash Virus Detection with avlsdk-lite-mcp
A security-ops person wires the Antiy virus-scanning MCP (avlsdk-lite-mcp) into AVL Code with one sentence, fixes the default-backend switch the install caused along the way and verifies the install with a real sample, then completes a zero-execution blacklist verdict plus a packing evidence chain on a 902,656-byte suspicious "activator", and finally checks a hash lead that is only an MD5 — three exchanges, and verdict, attribution and response recommendations are all in hand.
avlsdk-lite-mcp 1.1.3 (released 2 weeks ago)· Windows / Linux· npm package (stdio, launched via npx -y)· Sample 902,656 bytes · zero execution· 3 user instructions
Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model
Overview
- 01
Wire up scanning — install, correct, verify live
You say one sentence: AVL Code confirms the package source, probes the tools live, previews with dry_run, then lands the install; after finding the default backend switched away, it restores zworkspace and closes with a real scan to verify.
- 02
Triage the suspicious file — blacklist verdict + packing evidence chain
You hand the suspicious path to AVL Code: scan_file sends it to the Antiy cloud for a black verdict of KMSAuto, while PE parsing, entropy analysis, string and IOC extraction provide local corroboration, and three hash sets plus response recommendations are delivered together.
- 03
Check the intel hash — verdict without the file itself
You give an MD5: scan_hash matches the cloud virus database exactly, attributes it to the Lotok backdoor family, gives triage recommendations and suggests cross-verification.
Task for AVL Code
Install this MCP for me: @antiylabs/avlsdk-lite-mcpPrerequisites: AVL Code is logged in; the network can reach the npm registry and the Antiy cloud engine (this package ships its engine and virus database with it; malicious verdicts come from the Antiy cloud)
Reproduction materials at the end of this article Try it yourself ↓
Wiring Up Scanning
Installing an unfamiliar MCP — the risk is not "it fails to install" but "what got installed and what got changed". AVL Code’s approach is to establish where the package comes from first, then probe it live, and only then land it — stating the risks up front at every step:
Install this MCP for me: @antiylabs/avlsdk-lite-mcpnpm view confirms the package information
→ @antiylabs/avlsdk-lite-mcp@1.1.3 (official Antiy, stdio type, engine and virus database shipped with the package)
→ head/where unavailable on Windows, node not on the default allowlist → switches to the npx route
mcp.test_server one-shot liveness probe → starts successfully, exposing 2 tools: scan_file / scan_hash
mcp.add_server dry_run preview → confirm → landed: name avlsdk-lite · status connected
⚠ After landing, default_backend switched to avlsdk-lite (previously zworkspace)
→ zMCP.admin.setDefaultBackend(name=zworkspace) restores the default backend
avlsdk-lite.scan_file(workspace 小马激活工具.exe) → black · HackTool/Win32.KMSAuto → installation verifiedTriage the Suspicious File
The previous chapter’s verification scan already tagged this file "malicious"; you then give its formal path and ask for one full check. AVL Code does not just repeat "the engine says so" — it supplies a whole local static evidence chain, never running the sample:
Check whether this file is a virus: "E:\tmp\test_avlsdk_mcp\小马激活工具.exe"avlsdk-lite.scan_file(E:\tmp\…\小马激活工具.exe)
→ verdict: black · virus name HackTool/Win32.KMSAuto (a hacking tool)
→ Three hash sets (MD5/SHA1/SHA256) all produced, ready for intelligence comparison
→ Local static corroboration: anomalous sections OEM0/OEM1 + virtual-space expansion (signs of packing) · overall entropy 7.87 · no standard import table
→ IOC extraction: suspicious domain leads such as www.pccppc.comIntel Hash Check
The more common assessment scenario is having no file at all: a 32-character hash from an alert or an intelligence push needs a yes/no answer. This business moment takes one sentence:
Use avlsdk-lite-mcp to verify whether this hash 1ab73824134aea10da876e76690ae6e1 is a virusavlsdk-lite.scan_hash(md5=1ab73824…)
→ verdict: black (the sample is already in the cloud database, the conclusion is trustworthy)
→ Virus name: Trojan/Win32.Lotok[Backdoor] (a backdoor trojan, exact MD5 match)
→ Interpretation: opens a backdoor channel for remote control — downloading and executing files, stealing data, persistent residencyTry it yourself
Reproducing this case takes three instructions: download the session and import it into your workspace to replay the whole process, or paste the instructions below in order in your AVL Code (prerequisites: logged in, network reaching the npm registry and the Antiy cloud engine):
› Install this MCP for me: @antiylabs/avlsdk-lite-mcp› Check whether this file is a virus: "<your suspicious file path>"› Use avlsdk-lite-mcp to verify whether this hash <MD5> is a virus- Step 1 needs no replacement — copy it as-is to install the detection capability package.
- Step 2: replace it with a suspicious file path that really exists locally, corresponding to the scan_file instruction (file scanning).
- Step 3: replace it with the MD5 you hold, corresponding to the scan_hash instruction (hash scanning).
- Note: when the install lands, the default backend switches to avlsdk-lite — follow chapter 1 and check default_backend first, then restore it with zMCP.admin.setDefaultBackend(name=…) as needed.
- Limitation of hash checking: the session has only a single cloud verdict source, so for important conclusions cross-verify with an independent intel source such as VirusTotal (only suggested in the session, not executed).
Next question: What to do after a black verdict — how do you feed the scan_file / scan_hash results (verdict, virus name) and the MD5/SHA1/SHA256 hash sets into alert tickets and the isolation-and-response workflow?