Feature request: Add YARA-X Operations

[malvidin]

I cannot write or test YARA-X rules in CyberChef, like using the "with" statement. It is also faster, which will enhance the user experience.

Add a YARA-X Operation that uses a webasm module compiled directly from the YARA-X codebase instead of a third party integration.

Current Alternatives:

• Use legacy YARA in CyberChef: This forces analysts to avoid new YARA-X features and maintains slower execution times on large datasets. The legacy YARA operation is not updated regularly.
• Test with YARA-X locally: Running the YARA-X CLI tool locally against downloaded payloads breaks worflows that CyberChef provides.
• Use external web testers: Copying payloads to other online YARA testing sandboxes introduces friction and potential operational security (OPSEC) risks if the data is sensitive.

YARA-X is the official successor to YARA, built by VirusTotal. Since it is designed with a strong focus on developer experience and modern architecture, the YARA-X project already includes support for WASM bindings. Leveraging these existing Rust-to-WASM capabilities should significantly reduce the development friction required to implement this operation in CyberChef.

[zainnadeem786]

Hi @malvidin @GCHQDeveloper581,

I'd be interested in helping with this.

Before starting an implementation, I’ll do a feasibility pass on how CyberChef currently integrates WASM-backed operations and how YARA-X’s existing WASM bindings could fit into the operation model.

My initial plan would be to investigate:

• how the current legacy YARA operation is structured
• whether YARA-X’s WASM package can be bundled with CyberChef’s build system
• what the first operation should support, for example rule compilation plus scanning the current input
• how errors and match results should be displayed consistently with existing CyberChef operations
• whether this should be a new “YARA-X” operation rather than replacing the existing YARA operation

I’ll share findings before opening a PR so the implementation direction can be confirmed.

[zainnadeem786]

Hi @GCHQDeveloper581

YARA-X integration looks feasible as a new operation rather than replacing the existing YARA Rules operation.

I checked the current CyberChef YARA implementation, the existing WASM integration patterns, and the official YARA-X JS/WASM bindings. The official @virustotal/yara-x package is first-party, BSD-3-Clause licensed, and exposes the needed WASM API (init, Compiler, Rules, Scanner). A local PoC successfully initialized the WASM module, compiled rules, scanned input, handled invalid syntax, and matched a YARA-X with rule.

I also tested a throwaway webpack build using CyberChef’s current webpack config and a temporary node_modules layout. The YARA-X .wasm asset was emitted successfully without build errors.

Recommended first PR scope:

• Add a new YARA-X Scan operation.
• Keep the existing YARA Rules operation unchanged.
• Support rule text, a basic match summary, optional warnings/metadata/pattern details, and an optional scan timeout.
• Map init/compile/scan failures to OperationError.
• Add focused operation tests, including a YARA-X with rule.

Open decision before implementation: are maintainers happy to add the official npm dependency now? npm currently reports @virustotal/yara-x latest as 1.15.0, while the upstream repository appears newer, so I think we should agree on the pinned version before I start the PR.