Linux and IoT malware analysis with r2ai

Linux and IoT Malware Analysis with r2ai

Speaker: Axelle Apvrille (Fortinet / FortiGuard Labs)

Conference: NorthSec 2025 — May 15–16, 2025, Marché Bonsecours, Montreal

Watch on YouTube: https://www.youtube.com/watch?v=cyuwcKAlE6g

Reading time: ~7 minutes

TL;DR

Axelle Apvrille demonstrates how r2ai — a plugin connecting the Radare2 disassembler to large language models — can dramatically accelerate Linux and IoT malware analysis. Using live demos against a real Linux shellcode from March 2025 and a recent variant of the Ladvix/Rhomba/Ebola malware family, she shows both the direct and automatic modes of r2ai, documents where the AI produces accurate output, and teaches analysts where and how to catch the errors it reliably introduces. The verdict: AI-assisted reverse engineering is genuinely useful, but the analyst must remain in control.

Introduction

A thorough malware analysis takes between half a day and ten days, depending on the binary's complexity and the desired level of detail. The question Axelle Apvrille set out to answer — with genuine open-mindedness about the result — was whether artificial intelligence assistance could meaningfully compress that timeline.

Apvrille, a security researcher at Fortinet's FortiGuard Labs, approached the experiment by selecting recent Linux and IoT malware she had never analyzed before, deliberately avoiding any samples she might have had prior intuition about. The tool she chose was r2ai, a plugin for the Radare2 open-source reverse engineering framework that bridges the disassembler to a configurable LLM backend. The results, she reported, were "astonishingly good" — with important caveats that form the core of the talk.

Radare2 is nearly twenty years old, professionally capable, and supports a wider variety of architectures and binary formats than many more commonly cited alternatives. R2 — the nickname for the disassembler component within the Radare2 toolbox — is the primary interface, and r2ai extends it by allowing the analyst to direct queries at any LLM the user chooses to configure: GPT-4.1, Claude Sonnet, Mistral Codestral, or a locally-hosted model. Apvrille notes that she tested GPT-4.1 — released just days before the talk — and it worked out of the box without any r2ai-specific development.

Direct Mode: Decompiling a Linux Shellcode

The first live demonstration targets a small (4 KB) Linux x86 shellcode from February 2025, part of a larger family originating in late 2024, internally named Shellcode ConnectBack. The binary is deliberately chosen for its difficulty: standard decompiler output in Ghidra produces output that does not resemble readable C code, and the binary contains no useful strings.

Apvrille opens the binary in R2, runs aa (analyze all) and afl (list functions), observing a single entry point — expected for a binary this small. She then calls r2ai, sets the model to Mistral's Codestral via a free API key (a point she explicitly highlights for accessibility), and runs -d to decompile the entry point.

The initial output is functional but rough: register names appear as variable identifiers, and the presence of socket calls is visible but semantically unclear. She demonstrates the iterative improvement process that characterizes effective use of AI assistance — instructing the model not to use register names as variable names and to substitute meaningful identifiers. The revised decompilation becomes substantially more readable, clearly showing socket creation, a connection operation, and memory operations.

▶ Watch: Live r2ai Demo — Shellcode Decompilation (8:00)

Where AI Gets It Wrong: Validation Is Mandatory

Apvrille is explicit and methodical about the AI's failure modes, treating them not as edge cases but as expected behavior that every analyst must account for.

The first class of errors involves factual mistakes in decompiled output. The shellcode connects to a remote C2 server, but the AI reported the destination IP address as localhost and the port as 80 rather than the actual port 27427 and the real remote IP address. The error is plausible — malware connecting to localhost is possible — but incorrect. Apvrille demonstrates the verification process: mapping the raw bytes of the connect call onto the sockaddr_in C structure to confirm the actual destination.

The second class involves omissions. The AI correctly identified the presence of mmap and mprotect system calls but omitted a critical line in the decompiled output: the instruction that executes the stack after marking it read/write/execute. The purpose of the MPROTECT call — enabling the shellcode to receive and execute an additional payload from the C2 — is entirely lost without that line. An analyst who accepted the AI's output without verification would have produced an incomplete and misleading analysis. Apvrille puts it directly: "You've got to check what it didn't say."

The third class involves hallucination. The AI invented an mmap call that was not present in the binary. The system call was actually mprotect, a functionally different operation. The fabrication was internally consistent with the code the AI had seen, which is what makes it dangerous — it looks plausible.

▶ Watch: Catching AI Errors — IP Address and Omissions (14:01)

Automatic Mode: The AI as an Agentic Analyst

The more powerful — and more complex — capability Apvrille demonstrates is r2ai's automatic mode. In this mode, the analyst gives the AI a goal (for example, "decompile main") and grants the AI permission to invoke a defined set of tools autonomously: R2 commands, JavaScript, Python scripts, and external binaries.

The workflow is agentic: the AI determines what information it needs, requests permission to run a specific R2 command (for example, ie to find the entry point), receives the output, incorporates it into its reasoning, and continues issuing commands until it has enough information to answer the original question. Each tool invocation requires explicit analyst approval before execution.

Apvrille is clear about the safety boundary here: the analyst must review every proposed command before granting execution. In one engagement she describes, the AI requested that she launch the malware in a debug session to gather dynamic information. She refused — executing live malware on the analysis host to satisfy the AI's information needs is not acceptable practice, regardless of how helpfully the suggestion is framed.

▶ Watch: Automatic Mode Explained (18:00)

Working with Ladvix/Rhomba/Ebola

The second malware family Apvrille analyzes is Ladvix — also known as Rhomba or Ebola — a more complex Linux malware targeting IoT devices. While the full live demo occupies the latter portion of the talk, the structural lessons from the shellcode analysis apply directly: the AI is capable of identifying key functional components and producing readable decompilations, but the analyst must systematically verify every claim against the underlying assembly.

Apvrille's broader methodology, applicable across both samples, can be summarized as: use the AI to generate a first-pass understanding of what a function does, verify the claims that matter for the analysis, iterate on the prompt to improve output quality, and treat every piece of AI-generated output as a hypothesis rather than a conclusion. The AI functions as a highly capable but unreliable colleague — one who produces excellent first drafts and confidently incorrect details in roughly equal measure.

▶ Watch: Ladvix Analysis and Broader Methodology (20:00)

Notable Quotes

"Do not expect the AI to do all the work. You will have to assist the AI to assist you, actually."

"The AI is an excellent storyteller, and it can very well invent things — and make it like it would be possible."

"Do not stop yourself at the first thing that the AI spits, because you can usually improve it very much."

"You've got to check what it didn't say."

Key Takeaways

• r2ai is a genuine force multiplier. For analysts working on unfamiliar binaries, the tool can compress time-to-understanding significantly — particularly for small binaries with limited string artifacts or legible decompiler output.
• Model choice is flexible. R2ai works with any of the major LLM providers as well as locally-hosted models. Mistral's Codestral offers a free API tier, lowering the barrier to entry.
• Verification against assembly is mandatory. The AI will produce incorrect IP addresses, wrong port numbers, missing critical instructions, and hallucinated function calls — all presented with the same confidence as accurate output.
• Omissions are as dangerous as hallucinations. The AI's decision to skip "unimportant" lines can remove precisely the lines that explain the malware's most consequential behavior.
• Automatic mode requires analyst oversight. Granting the AI agentic tool-calling capability dramatically increases its usefulness, but every proposed command must be reviewed before execution.
• Free API keys lower the barrier. Mistral's free tier makes this workflow accessible to analysts without enterprise tool budgets.