capa web "demo"

[nightlark]

Would there be interest in a version of capa that runs entirely client-side in the browser? There would be some limitations such as only supporting the vivisect backend (no ida/binaryninja) and probably a bit slower than running locally on a system, but otherwise should work.

It could either be a separate site deployed like the explorer web page (https://mandiant.github.io/capa/explorer/) but under a different subfolder (e.g. https://mandiant.github.io/capa/web/), or integrated into the explorer web page by allowing users to select binaries instead of just json files.

[williballenthin]

I think this would be pretty neat!

It might take a little massaging of the dependencies (or maybe you can get Pyodide builds of things like msgspec, etc.), but I do really like the deployment model.

Now, to be clear, I'm not sure that the explorer web page gets all that much traffic. Looks like a few hundred visitors in the past month. But, perhaps this sort of feature might draw a bigger crowd and demonstrate what is possible :-)

[mr-tz]

I think this is a very cool idea and over the years I've been asked a few times when capa in the browser is ready :)

[fariss]

There would be some limitations such as only supporting the vivisect backend (no ida/binaryninja) and probably a bit slower than running locally on a system, but otherwise should work.

Ghidra and BinExport2 are open source and are actively maintained.

The open question I have is where will the backend processing be hosted? GitHub Pages free tier is limited and does not offer storage afaik (for analysis results). If we're considering a cloud provider (not free)—then I believe this would be feasible and a great addition, esp because it eliminates the need to install capa as user can just drag and drop, VirusTotal-style.

[nightlark]

Ghidra would also be on the list of unsupported backends (unless someone wants to try to get it compiled/running using WASM). BinExport2 could be possible, I haven't looked at what that requires yet.

It can work fine on GitHub Pages, since the backend processing with vivisect is running entirely client-side. Browser local storage could be used to save analysis results between "sessions" (the user revisiting the page) if desired, or to keep things simple to start, users can just reselect the same file and process it again.

I put a copy of what I've got working in Pyodide so far up at: https://surfactant.readthedocs.io/en/latest/capa/

• First time loading may take some time to install dependencies, subsequently loads are much faster
• Uses IndexedDB to store the rules cache (one of the slowest parts of loading the page for the first time)
• Several pyodide recipes I contributed for binary wheels are still only on the nightly pyodide pypi index, making for some awkward installation (install some deps from pypi.org and others from pyodide nightly in a specific order)
• BinExport2 files give an unsupported format error (haven't looked into it to figure out why)
• aarch64 ELF binaries aren't supported (my understanding is as of the 9.3.1 release with the vivisect backend only x86/x64 is supported)
• Requiresd monkey patching a function in the Rich library to disable use of threading (I think this was used for the little animated icon shown while analyzing a file)

[fariss]

Ghidra would also be on the list of unsupported backends (unless someone wants to try to get it compiled/running using WASM). BinExport2 could be possible, I haven't looked at what that requires yet.

You're right—that would be a tremendous task. However, I am sure the Ghidra decompiler and maybe also the disassembler are written in C++ because that's what rz-ghidra is using to build a self-contained Ghidra decompiler and integrate it into Cutter.

It can work fine on GitHub Pages, since the backend processing with vivisect is running entirely client-side. Browser local storage could be used to save analysis results between "sessions" (the user revisiting the page) if desired, or to keep things simple to start, users can just reselect the same file and process it again.

That makes sense, I initially thought the goal was to have saved analysis that can be shared without sharing the binary and re-analyzing it.

For faster analysis, I think you can keep up to N recent analyses in the browser storage to avoid re-analyzing.

Requires monkey patching a function in the Rich library to disable use of threading (I think this was used for the little animated icon shown while analyzing a file)

Yes, that's one of the reasons.

I put a copy of what I've got working in Pyodide so far up at: surfactant.readthedocs.io/en/latest/capa

This is very good start! Let me know if you want to integrate it into capa Explorer Web. For now, you can download the json and upload it manually.

Might too early for feedback, but it'd be great to have the ability to upload password-protected archives and have the capa web decompress and analyze the binary. Most users wont have live .exe malware on their system.

[nightlark]

Uploading zip archives (with or without password protection) should work now. Also split up the analysis and rendering functionality so switching between output formats should be very quick.

I think it would be nice to integrate with capa explorer web, not sure how tightly coupled would be desired though; bundling it all as a single offline page could be difficult (need to store offline copies of all the Pyodide/PyPI packages). With two separate pages browser local storage could be used to transfer analysis results between them, if they’re just different paths under the same subdomain.