Hex-Rays Blog

Hex-Rays IDA MCP Server

Sun, 18 Oct 2026 10:57:02 GMT

We are happy to introduce the official IDA MCP server! This free and open source software connects your IDA installation with AI agents, enabling them to disassemble, decompile, and support reverse engineering tasks. It works great with models like Gemini, Qwen, or Opus using familiar harnesses like Claude Code, Codex, or Pi. Across our internal malware analysis-focused benchmark, IDA MCP’s “code mode” architecture reduced token consumption by approximately 20% compared to popular alternatives.

The reverse engineering capabilities of LLMs have dramatically improved over the past year and coding agent adoption has skyrocketed. The Model Codex Protocol is here to stay and we will provide you with the best tools to integrate LLMs into your day-to-day RE workflows.

One of the most exciting features of IDA MCP is that it can share many IDBs across many agents (and a human!) at the same time. This means a fleet of agents can collaborate on a project or an orchestrator agent can use subagents to concurrently study different parts of the same program. When IDA is open in the GUI, changes like renaming, commenting, or applying types, take effect immediately.

The MCP server is model-agnostic, enabling seamless integration with any capable LLM, whether deployed locally or accessed through a cloud provider. This means it fits well in an airgapped environment. Since it works headlessly with idalib, you can deploy IDA MCP in AI-supported reverse engineering systems, such as large-scale pipeline processing.

IDA MCP is freely available and open source, and works with IDA Pro, Home, Classroom and OEM.

Get started with IDA MCP today using HCLI with this one-liner (if you already have uv installed)

uvx ida-hcli mcp install

Key Features & Usage

When you install the IDA MCP server, your agent gains access to IDA’s disassemblers and decompilers to help reverse engineer programs. Some of the most exciting aspects of its capabilities include:

that the codemode architecture is very token efficient, reducing token consumption by approximately 20% compared with popular alternatives.
that the underlying ida-nexus library coordinates access across many agents to many IDB files, enabling realtime collaboration across a swarm of users.
that the server is model agnostic and runs fully locally, making it a good choice for environments that are airgapped.

Let's look into these in more detail.

The Code Mode Architecture

We’ve found that many LLMs already have a really good knowledge of IDA and quickly begin exploring programs effectively. The IDA MCP server provides a minimal and powerful set of tools to the agent, along with descriptions that explain when and how to use them:

Database: open, close, list, save
IDAPython: read/write/update the database and evaluate logic using Python
Reference: search for API documentation and examples using keywords

Note that this is a very small set of tools! Many other MCP servers provide a separate tool for each operation: list the functions, list the strings, list the imports, decompile one or more functions, disassemble a range, etc. Since IDA has so many features, you easily end up with 100+ tools that each need to be tuned separately. Every tool takes up space in the context window, and more importantly, the tools are not composable and all intermediate output ends up in the context window, too. These systems are slow, token hungry, and inefficient.

Instead, IDA MCP uses the architecture known as Code Mode that was popularized by Cloudflare. Agents interact with structured data by evaluating programs written in languages such as Python or Javascript. Based on user reports, models already naturally reach for IDAPython when it is available to them, so we decided to make that the primary way for a model to interact with an IDB. A further advantage is that giving your agent skills with generic IDAPython/IDA Domain snippets will automatically improve its performance when using the IDA MCP.

A tradeoff with this approach is that, because IDA does not yet isolate its Python interpreter from the wider system, the agent can evaluate scripts that reach beyond IDA’s database. While coding agents typically already have a Bash tool for manipulating the system, it's important to understand this additional surface provided by IDA MCP. Therefore, we recommend running the harness and IDA MCP in a sandboxed environment when dealing with untrusted data.

IDA Nexus Resource Coordination

When an agent interacts with an IDB already open in the IDA GUI, changes are reflected instantly in the UI, as if the agent and human are working together in the session.

However, the IDA MCP server does not require the user to open a binary in the IDA GUI first. An agent can independently create or open a new database, which spawns a headless idalib instance to manage the analysis. This session can then be automatically reused by the next open_database call for the same binary. This enables an agent to extract a second-stage payload from a malware sample, open it up independently and continue the analysis without any user interaction.

There is always one instance of IDA (headless or GUI) running for each open IDB, and one or many parallel agents connect to these instances to perform their analysis. IDA MCP, via ida-nexus, coordinates this resource tracking. Ultimately this means that changes made by an agent are instantly reflected in the IDA GUI and vice versa. You can also use IDA Nexus in your own projects!

An example of a community integration is ida_buddy, which is a CLI tool for interacting with IDA. Because ida_buddy uses the IDA Nexus library it can operate on an IDB that is currently also in use by the MCP.

Another example is ida-tui, which allows you to use IDA from the terminal. If you have a binary open in the IDA GUI, you can SSH into your machine and see/edit that binary remotely without closing the GUI

IDA MCP is Model Agnostic

While State of the Art (SOTA) models provided by organizations like Anthropic and OpenAI perform great on reverse engineering tasks, we know that not every reverse engineer can use these options. Token costs for frontier models are very high, data retention policies vary by provider, and some models refuse cybersecurity tasks without onerous additional approval by the vendor. The good news is that open weight models are widely available and have recently become proficient at reverse engineering tasks!

According to our internal, malware analysis-focused benchmarks, we’ve found that DeepSeek v4.1 Flash, Kimi K3, and GLM 5.3 perform on a level similar to GPT-6-Luna and Gemini 3.8 Flash. Unfortunately, they do require dedicated hardware. For “prosumer grade” hardware (128-256GB VRAM), DeepSeek V4 Flash 0731 and GLM 5.3 Flash also give decent results.

We also tested Qwen 3.8 27B, which can run (quantized) on a single consumer GPU (24GB NVIDIA RTX 3090). This class of models can perform reverse engineering tasks, but tends to get stuck and overthink, so you need a more hands-on approach. That being said, a minimal harness like Pi and the small footprint of the IDA MCP tools make a suitable combination for consumer hardware where prefill speeds are relatively low.

Recommended Setups

In our experience the following model and harness combinations work well with IDA MCP:

Use Opus 5.5 via Claude Code with a monthly coding plan. However, cybersecurity safeguards frequently interrupt work, so falling back to Opus 4.6 might be necessary.
Use GPT-6-Sol or Astra via Codex with a monthly coding plan.
Use DeepSeek 4.1 Flash, Gemini 3.8 Flash, Kimi K3, or GLM 5.3 via OpenRouter using Pi.

We recommend using a VM or other sandboxed environment. Install IDA with HCLI. Once IDA MCP is installed, your agent will reach for IDA any time you have reverse engineering tasks!

Demonstration

To demonstrate IDA MCP, we explore a scenario called ParcelDesk that involves multiple, related PE files. The idea of the challenge is that you need to enter a parcel identifier and the corresponding collection code to open a door and retrieve some mail. In our case we need to obtain the collection code for parcel ZX-4815.

[Hint] If you would like to play along at home you can find the files here.

To get started we extract the challenge files into a new folder and open a coding agent there (we used Claude Code with Sonnet 5 for this demonstration). Then we can ask:

Can you obtain the collection code for parcel ZX-4815 in ParcelDesk.exe?

The agent will work for a few minutes, iteratively calling open_database and execute_python on the relevant binaries and it should come back with an answer like this:In this case none of the binaries were opened in the IDA GUI, but this makes no difference from the agent’s perspective. Calling open_database on a file that is already open in IDA will reuse that instance instead of spawning a headless idalib worker.

Notably, this challenge required the agent to traverse three separate DLL files and extract raw data from resource sections. Using IDA MCP, it successfully traces data flow across binaries, identifies the correct DLLs, extracts and parses PE resources, and replicates a custom decryption algorithm.

If you’re curious about how the agent came to these conclusions, you can read through the tool call trace that we’ve exported here. It’s amusing to see how an agent decides to combine API functions to collect data, and to contrast this with how a human approaches reverse engineering.

Installation

Since IDA MCP communicates with external AI systems, their use may not be compatible with every organization's security or air-gapped deployment policies. Consequently, IDA MCP must be explicitly installed and configured before it can be used. It is provided as a free, open source software.

You can find detailed installation instructions in our documentation, but in short, once you have uv installed you can use HCLI to install the plugins for IDA and your coding agent. Today we support one-command installs for Claude Code, Codex, GitHub Copilot, Pi and oh-my-pi, but any client supporting stdio MCP servers works, including LM Studio and Antigravity.

uvx ida-hcli mcp install

or, if you already have hcli installed

hcli mcp install

Acknowledgements

We would like to thank Joe T. Sylve for giving us the ida-mcp name on PyPI. Additionally we would like to thank our early access testers for the feedback and ideas!

LLMs Have Reshaped How We Think About Decompilation and Collaboration

Sun, 18 Oct 2026 10:57:02 GMT

Shifting Times

A few weekends ago, I was playing DEF CON CTF Quals, the qualification event for the "Olympics of Hacking," with my team Shellphish. I say "playing" because I am, at this point, a washed-up hacker, but add me to the 40-something ranks! Nonetheless, I showed up, downloaded a binary, and went to open it in IDA Pro: a reflexive, built-in response to anything compiled. But as that ever-knowing face rendered on my screen, I paused for a moment to take in the surrounding feverish hacking. Something was strange: no one else had IDA Pro open. In fact, no one had any decompiler open!

Across the room and on my machine too, we all had Codex open, a flexible coding agent that was now doing the hacking. This agent, of course, had IDA Pro open, because it actually needed to analyze the binary like a real hacker. So what did we, the humans, do for the whole game? We each became a multi-challenge hacker: a sort of general with an army. We spent most of our time suggesting high-level reversing routes, invalidating broken PoCs, and fixing or enabling better tools for our agents.

But after some of our armies began to falter on the harder tasks, we encountered a new problem. How do we coordinate our armies, validate what they found, and know where they are stuck? Or, better put, in this new world of hacking, how do we optimize the way information is relayed and validated in an agent-human hacking environment? Funny enough, this is the premise of this post: we've been trying to solve almost this exact collaboration problem for years. Now the same problem is coming back, except the workers are agents and the humans are supervising the whole mess.

Collaborating with Humans

In 2021, days before that year's DEF CON Finals, we began development on our decompiler collaboration framework BinSync, which recently won second place at the Hex-Rays plugin contest. At the time, it was obvious that no challenge was an island, entire of itself, and so we needed many eyes on one binary. We had two problems then:

Not everyone on the team was equally good at hacking (especially me!). Therefore, a level of control was needed to keep noobs and pros from clobbering each other's work.
We had a diverse breakdown of decompiler usage: 70% used IDA Pro, 20% used Binary Ninja, 5% used Ghidra, and 5% used the angr decompiler (mostly Fish and I). We couldn't just share IDBs, and we couldn't rely on one-off translations from each tool.

The solutions emerged somewhat naturally. Do not share the whole decompiler database; share the information learned from the binary. Record names, types, patches, and other facts in a form with history and the ability to selectively merge that history: Git! When storing information, lift it from one specific tool (decompiler) into something high-level and human-readable. Finally, to get that information back into each tool, translate it from high-level form back into the tool-specific format (think _WORD versus uint16). This gave every tool a path to collaboration and let pros selectively merge changes from noobs into their local reversing branches. Wrap all of this in a fancy GUI that works on all decompilers, and we were rolling!

Since every atom of information learned was a commit in BinSync, it also created a cool historical way to view team progress. Here is what one DEF CON Quals looked like by commit, with annotations indicating when a challenge was solved. If you look closely, you can see when the team was sleeping.

Before long, BinSync created a way for our team to share information rapidly, but the more interesting thing it created was shared reversing memory. As we (myself, Shellphish, and SEFCOM) continued to refine it, more teams began to adopt it in some form. Eventually, people started using it for open-source reversing (reversing a binary with the diff living on GitHub), which was awesome! This all created a sense that we were trending in the right direction for closing the gap in human-to-human hacking collaboration. The durable lessons were about common representation, history, selective trust, and visibility into progress.

But snap back to reality: does any of this matter now?

Collaborating with Agents

Our recent hacking experience has taught us that humans are no longer the center of the collaboration chain. Agents are now the central workers in any program-hacking task. Agents talk to other agents, which in turn talk to tools, and a final agent talks to us. This reframing makes some previous work less central, but it also opens new avenues for research. Let's start with what changes.

First, although agents may use multiple decompilers, they are often perfectly happy to translate between those formats themselves, with no BinSync needed. They do benefit slightly from a lifted common format, but those gains may not justify the effort. So, you really don't need the same translator layer when LLMs are already built-in translators.

Second, agents rarely need help from other agents when reverse engineering. In our early experiments, the majority of binaries you encounter on a system are fully reversible by a single Codex agent. These agents can much more easily "fan out" and explore every path to an exploit through independent work rather than relaying information. Goodbye to Git merging as the way agents send changes to each other.

Third, the human-first GUIs we've come to develop, both in BinSync and more broadly in decompilers, matter much less to agents. This hurts especially hard, since those GUIs are often the parts that took the longest to refine.

Not all previous lessons disappear, however. Coordinating many agents with humans for oversight and redirection is actually a lot like being a captain on a big CTF team. You need ways to know where agents are stuck at scale, what they already tried, and how much you should trust what they found. This also matters significantly on multi-binary targets like firmware. Lessons learned from BinSync are beginning to take shape as similar history, provenance, and progress analytics, but for agents. Thanks, Git!

However, harder concepts still exist. For an expert hacker, learning how to effectively redirect or steer these agents is hard to measure and improve. So hard, in fact, that we have published papers and won awards for exploring the early science of this process. But there is still much we do not know. Do you only need to know the right words to unstick a model? Are there higher-level concepts in hacking that improve performance when taught to a model? Can we represent any of this graphically and build better human interfaces for understanding reversing reasoning?

More questions than answers, but isn't it exciting!?! We are in a whole new era, and the science of hacking collaboration has a new direction.

The Future

I see a few changes coming to a local tool near you. Decompilers, as they exist now, are going to undergo significant change in this age of agent collaboration. The tools best suited for agents will likely be the ones to survive into the next era of reversing. For the first time in a long time, you may see significant changes to the GUIs of your decompilers.

The new interfaces need to toe-the-line on what really must be known by a human, and what instead can be automated. It should expose what agents believe, what evidence they used, what paths they already tried, where they are stuck, and when a human should step in. That is not the same as dumping a chat log next to pseudocode. It is closer to making reversing progress inspectable, an area currently receiving significant money and attention through AI.

For better or for worse, how we collaborate, how we reverse engineer, and how we hack, is changing. The best tools in this next phase will not hide the human or pretend the agent is magic. They will make the handoff between human judgment and agent work cleaner, faster, and easier to trust.

Discovering the ways we can harness that change to improve our lives and the security of the world will require work. We, on the BinSync team, look forward to chasing the next phase of that collaboration and sharing it with you all.

See you on the other side!

Help Shape the Next Generation of Reverse Engineering

Have an idea for improving how humans, agents, and analysis tools work together? Turn it into an IDA extension and enter the 2026 IDA Plugin Contest.

Whether your project uses AI to support smarter analysis, improves collaboration, automates repetitive work, or connects IDA with another tool or ecosystem, we want to see what you build.

Compete for cash prizes, an IDA Pro Expert-2 license, and the opportunity to showcase your work to the reverse-engineering community.

Submit your project by November 30, 2026.

Hex-Rays is Heading to Hacker Summer Camp 2026

Sun, 18 Oct 2026 10:57:02 GMT

Vegas in August generally means one thing for the reverse engineering community: Hacker Summer Camp. Hex-Rays will be on the ground for all three events, and we've packed the week with demos, a workshop, some light recruiting and more. Here's where to find us.

Black Hat

Our Tech Evangelist, David Rushmer, will be available for meetings Monday, August 3 - Wednesday, August 5. If you'd like to have a chat or get a demo of new or upcoming features like our revamped Teams Add-On or upcoming Malware Add-On, just email marketing@hex-rays.com and we'll get something on the calendar.

B-Sides Las Vegas

David will be onsite and ready to talk all things IDA. Whether you've got a technical question, want to share your current or upcoming research, feedback on the product, or just want to say hi, drop a line to marketing@hex-rays.com and we'll make it easy to connect.

DEF CON 34 | Malware Village

DEF CON is where we're really setting up shop this year. We will be stationed within the Malware Village at our own table.

Demos: Malware Analysis Add-On (Private Beta)

📅 Friday, August 7 & Saturday, August 8. Every hour on the hour, 10:00am – 4:00pm.

This demo will walk through three features available today in private beta:

Unpacking Helpers, which detects packed binaries on load and unpacks them in-place so analysts can get straight to work
One-Click Debug, which launches emulation-based debugging from a single button without leaving IDA or risking execution on the wrong system
Sandbox Integration, which pulls code coverage, API call timelines, and memory regions from sandbox runs directly into IDA's UI

If you've ever lost time to boilerplate unpacking, manual debugger setup, or manually correlating sandbox output with static analysis, this demo is for you.

Workshop: Follow the Execution - A DLL Sideloading Teardown & Intro to IDA

📅 Saturday, August 8 @ 12:55pm

Join us for a hands-on DLL sideloading teardown and intro to IDA. Space is limited to 40 seats, and registration is required.

👉 Read the Workshop Overview & Register Here

Need a license to participate? We've got you covered — just note that a license will be provided subject to standard KYC (know-your-customer) verification requirements.

Recruiting for US-Based Roles

We're looking to fill two US-based positions. Come learn more about the company and the roles, and more importantly, meet the people you might work with.

Teams Add-On: Now Git-Native

We'll also have a live demo of the newly revamped Teams add-on. Teams can now run on top of any Git server — GitHub, GitLab, Bitbucket, or self-hosted. No new server to spin up, no new credentials to manage — just clone, analyze, commit, push. Migration guides are available for teams moving over from Vault.

➥ We're looking for qualified corporate testers with a minimum of two users to try our collaboration features at no charge. Specific eligibility terms apply.

To see if you qualify, email sales@hex-rays.com for more info or come talk to us at our table.

What's New in IDA 9.4

We'll be spreading the word on the latest release and happy to answer any questions. A few highlights worth asking about:

Reworked Dyld Shared Cache handling — a cleaner workflow for navigating Apple's system-framework bundles, with better accuracy and support for the latest iOS formats.
Swift, Rust, and Go get smarter — the decompiler now understands Swift's calling convention, detects Rust crate versions, and reads Go binaries more reliably.
Pathfinder, a new widget that traces call paths between two points in a binary, plus a redesigned Xrefs Graph.

Read more: IDA 9.4 Release Overview Blog
➥ Pssst... we'll also have a special license discount for those who visit us in-person.

Bring Your Feedback, Take Home Swag

As always, we want to hear what's working and what isn't. Swing by our sponsor table in the Malware Village, share your IDA feedback, and walk away with some swag for your thoughts.

See you in Vegas!

Teams: Git-native Versioning & Collaborative Reversing

Sun, 18 Oct 2026 10:57:02 GMT

Teams is a collaboration add-on for IDA Pro recently revised to focus on two pillars: version control and team collaboration with features like Deep Links. It brings Git-based versioning and real-time sharing directly into IDA, so reverse engineering teams can work together on the same binaries without losing work, duplicating effort, or managing files manually.

With the most recent version of IDA, Teams has been fully integrated inside IDA with a significantly improved interface. With the IDA 9.4 release, we brought a new set of collaboration and version control features — including Git integration and Deep Links.

Teams is designed for teams, but the version control features are equally useful for individual analysts who want a reliable history of their work.

Version Control with Git Integration

Teams add-on for IDA Pro use Git as its version-control backbone. Teams works with any Git provider you already use — GitHub, GitLab, Bitbucket, or Gitea. No new server to deploy. No new credentials to issue.

Create or clone a repository. Repositories are designed to hold multiple IDA databases, so when you’re working across a family of related binaries it keeps everything in one place.

Start a new repository from your existing working directory, or clone a shared repository from a remote server. The git-ida compression filter is configured automatically, keeping repository size small by storing only the differences between database versions. Git LFS is also supported for teams working with large IDB files.

Commit. Commit regenerates the packed database and records your changes locally with a message you create. Optionally, you can Commit and Push at the same time.

Push and Pull. Push your commits to the remote when ready; pull to bring in your teammates' latest work. If a pull produces conflicts, IDA opens a three-way merge view so you can resolve them in context. (A fan favorite.)

Full revision history. History shows the complete Git log for the open database. Compare any two revisions, step through what changed commit by commit, or compare a past revision against your current working copy.

Local Changes. Before committing, Local Changes shows a semantic diff of everything you've changed since the last commit — renamed functions, updated types, new comments — so you know exactly what you're about to record. Made changes you want to discard? Revert rolls everything back to the last commit cleanly and immediately.

Semantic diffing. Differences between database versions are presented as meaningful analysis changes — not raw binary deltas. See what actually changed in the analysis, not just what bytes shifted.

Flexible infrastructure. Use your existing Git provider, or run Gitea in a single Docker container with as little as 1 GB of RAM for air-gapped or compliance-sensitive environments. The Teams documentation includes a ready-to-go docker-compose.yml.

Vault migration included. A command-line migration utility (team-migrate) moves existing Vault-based databases to Git. For setup and migration instructions, refer to the Teams Server Administration Guide.

Collaboration for Teams, Featuring Deep Links

Once your work is in version control, Teams will make sharing it with colleagues seamless. Multiple analysts can work on the same project simultaneously — each committing their own findings, pulling teammates' changes, and resolving conflicts through IDA's built-in merge tools.

Work together on the same binary - The binary one analyst opens is the same binary the whole team is improving. Changes sync through a shared Git repository, so there is no risk of conflicting versions going undetected.

Online or offline - Teams doesn't require a constant connection. Analyze on a airplane, in a SCIF, or off the grid. A connection is only needed when you publish.

Pull with smart auto-merge - Pull brings in teammates' latest commits. Non-conflicting changes — comments on different lines, renames at different addresses, non-overlapping type changes — are resolved automatically in the background. Real conflicts open IDA's interactive three-way merge view, side by side.

Manage multiple repositories - The Manage Repositories view lists every IDB repository on your machine. Pull and push across projects without needing to open a database first.

Deep Links, our latest update for 9.4, make it easy to point a teammate directly to something you've found — a function, an address, a string, a type — without any back-and-forth about where to look.

Share a location with a URL. Right-click any item in IDA and choose Copy Link. This generates an ida:// URL encoding the database, resource type, and exact location. Paste it into a chat, a ticket, a report, or an email.

Navigate to link. Navigation links take you directly to a specific location in IDA. A teammate can open the link in an existing IDA session, or use hcli, which will launch IDA if needed and automatically open the correct database and view.

Stable across reloads. Links are based on relative virtual addresses (RVAs) rather than absolute addresses. If a database is rebased, links still resolve correctly.

Nine resource types. Functions, addresses, strings, segments, names, imports, exports, types, and bookmarks can all be linked to directly.

Twelve view targets. Links can open in disassembly, graph, pseudocode, hex view, or any of the dedicated IDA windows — whichever makes most sense for what you're sharing.

Python API. Deep Links can also be opened programmatically via ida_kernwin.open_ida_link(), making them useful in scripts and automation workflows.

Whether you're a solo analyst who wants a reliable history of your work, or part of a team tackling a complex binary together, Teams is built for the way reverse engineers actually work.

IDA 9.4 Release: A New Dyld Shared Cache, Swift Analysis, New Teams add-on, and more ...

Sun, 18 Oct 2026 10:57:02 GMT

After weeks of feedback and refinement from our beta testers, we are excited to introduce IDA 9.4!

Building on 9.3, this release reworks how IDA handles Apple's Dyld Shared Cache, teaches the decompiler to speak Swift, adds two brand-new processor modules, and reshapes everyday navigation with the new Pathfinder widget and a redesigned Xrefs Graph. There is also a change we are especially happy about for hobbyists: idalib, our headless automation library, now ships with IDA Home.

Below is an overview of the key features and improvements in IDA 9.4. For the complete technical details, be sure to check out the official release notes.

Apple Dyld Shared Cache, Reimagined

IDA 9.4 completely overhauls how it loads and analyzes Apple's Dyld Shared Caches, the bundles that pack the system frameworks on modern macOS and iOS.

Dedicated widgets and specialized workflows make it far easier to work inside a shared cache, with seamless navigation between its components.
Analysis is more accurate and more correct, and the loader keeps up with the latest formats, including the dyld shared caches introduced with iOS 27.
Objective-C reversers benefit from recovered method prototypes and correct handling of the newer libobjcMsgSend selector stubs.

Apple-ecosystem reversers should have a much easier time with the new system. See the DSC workflow documentation for the concepts and workflows.

Swift, Rust, and Go: Deeper High-Level Language Support

The decompiler continues to close the gap between stripped native binaries and the languages they were written in.

The decompiler and type system now understand the Swift calling convention. New keywords let you declare the self register (__swiftself), the async context (__swiftasync), and the error path (__swiftthrows), so the pseudocode reads the way the original Swift did, with the confusing register plumbing rewritten as clear intrinsics. On stripped binaries, IDA can now also recover __swiftcall, throwing calls, and spilled arguments on its own.
Rust analysis gains detection of the rustc version and crate list (shown in the header), typed panic locations, and a dedicated Rust calling convention.
Go analysis improves across the board, with better pclntab discovery for PIE binaries, buildinfo dependency parsing for Go 1.18 and later, cleaner struct types, and more reliable argument and return-type detection.
Objective-C ARC helpers (the retain and release stubs) are now recognized and can be shown or hidden on demand.

Decompiler Improvements

Beyond the language work, the decompiler gains a batch of output-quality and workflow upgrades.

New interactive actions: edit a type straight from the pseudocode with e, add a cast to an expression, collapse code blocks using the chevrons in the margin, and invert an if/else with a single command.
Argument name hints render parameter names right at the call site, so you no longer have to open a prototype to remember what an argument means.
Strings recovered during decompilation now appear automatically in the Strings list.
Many readability refinements, including memcpy calls folded into simple assignments where possible, if-then-else reconstructed from phi merges instead of gotos, fabs and negation recognized from IEEE 754 bit manipulation, true/false and nullptr used in the right contexts, and a long list of internal-error fixes across architectures.

Expanded Processor and Platform Support

IDA 9.4 widens hardware coverage with two new processor modules and substantial work on existing ones.

A brand-new Qualcomm Hexagon (QDSP6) module brings Qualcomm DSP firmware into reach, paired with a Qualcomm MBN boot-image loader (SBL and XBL containers, multi-ELF, hash validation). See the Hexagon reference for packet-based execution and ISA coverage.
A new MCore (CSky V1) module adds stack-pointer tracking, automatic stack-variable creation, and higher-quality disassembly.
ARM gains full SVE2 and SME disassembly, along with recognition of more switch constructs seen in modern console SDKs.
TriCore receives full type-system support, a new register finder, better switch-table recognition, and relocation support. RISC-V adds RP2350 (hazard3) extensions, the compressed Zcmp, Zcmt, and Zclsd instructions, and Soteria support. V850 recognizes more switch patterns.
IDA is now available as a native ARM64 build for Windows-on-ARM.

Loaders and Program Structure

Functions can now be grouped in the Functions list by the compilation unit they came from, reconstructed from COFF, PSX, OMF, TDS, DWARF, PDB, and Go, mirroring the binary's original source-file layout.
ELF loading adds compact relative relocations (DT_RELR) and recognizes Linux kernel modules, adding modinfo to the listing header. Mach-O handling keeps entry-point segments visible when they have no sections and decrypts Apple-protected segments located past the header.

Navigation and UI: Pathfinder, Jump Anywhere, and a Redesigned Xrefs Graph

Navigating a large database gets meaningfully faster in 9.4.

The new Pathfinder widget (View > Open subviews > Pathfinder, Shift-F9) gives an answer which every RE wants to know: how does execution get from here to there? It finds call paths between two or more waypoints. Add the function under your cursor with Ctrl-Shift-F9, exclude known noise, tune the search, and view the result as a cross-references tree or a path-highlighted Xrefs Graph. Find out what Pathfinder can answer about your binary.
Jump Anywhere is now the default action for the g shortcut, replacing the classic jump-to-address dialog with a unified, type-ahead navigator: names, expressions like cpu.EIP, function comments, live disassembly, pseudocode, and hex previews, and a jump history.
The Xrefs Graph has been significantly redesigned, with a new graph manager, informative node headers (comments, bookmarks, breakpoints, and missing references), a cleaner layout, and reorganized settings. It can also display and highlight the paths found by Pathfinder.
A unified Scripts window replaces the old Execute script and Snippets dialogs, with tabs for IDB snippets, recent external scripts, the shipped IDAPython examples, and a search across all three.
IDB deep links let you share a pointer to an exact location in a database and open it in an already-running IDA, without shipping files around.

Teams, Now on Git

The Teams add-on for IDA Pro can now run on top of a Git server.

Share IDB files using the Git provider you already use, whether GitHub, GitLab, Bitbucket, or self-hosted, with no server to deploy and no new credentials to issue. Just clone, analyze, commit, and push.
git ida works in the terminal through an automatically managed global Git configuration, and migration guides are available for teams moving over from Vault. See the Git getting-started guide to set things up.

Debugger Advancements

The GDB remote backend has been broadly modernized, with more reliable stepping, better handling of misbehaving stubs, library and module discovery on startup, and image-base detection from the TIB.
RISC-V debugging is now supported through the GDB backend.
Win32 and WinDbg fixes correct TEB segment labeling and add a PEB segment.

Automation: idalib Comes to IDA Home

Headless automation is no longer a Pro-only capability.

idalib, the library that lets you drive IDA's full analysis engine from a standalone script with no GUI, now ships with IDA Home and is activated automatically during installation. Home users also get analysis.idc bundled, which enables the -B batch switch. You can see idalib in action here or check out our recent Plugin Contest winner using it here.
A new release of the IDA Domain API (v0.5.0) adds microcode and pseudocode access along with object store and retrieve APIs. See What's new in the IDA Domain API for the details.
IDAPython now detects Python environments managed by uv, Anaconda, and Homebrew, warns on version mismatches, and exposes the new database indexer that powers Jump Anywhere.
The SDK gains a large set of new EA-based APIs (covered in the porting guide) and a new dscu.h header for programmatic access to the new Dyld Shared Cache infrastructure.

Performance

Loading large DWARF files is faster and uses less memory.
Files that add a large number of names, such as Dyld Shared Caches, load faster, and frame analysis has been sped up.

And more ...

For the complete technical details, be sure to check out the official release notes.

Keep us in the loop!

If you see something, say something. You can report bugs here: https://support.hex-rays.com
Have ideas on how we can improve IDA? We want to know! Send your feedback directly to product@hex-rays.com, or post it on Discourse.

Getting IDA 9.4

If you have an active IDA license, you will see IDA 9.4 in the Download Center of the My Hex-Rays customer portal.

IDA 9.4: Improved analysis of compiled Swift binaries

Sun, 18 Oct 2026 10:57:02 GMT

IDA 9.4 constitutes the first step towards better handling of Swift binaries. Perhaps unsurprisingly, our focus is on Swift for ARM64 Mach-O files, but we generally aim to improve Swift support also in the more unusual settings across different architectures and file formats like x86-64 and ELF. For 9.4, we want to highlight two different improvements: proper modelling of the Swift ABI, and proper typing of Swift runtime functions.

Proper Modelling of the Swift ABI

With IDA 9.4, we introduce three new keywords for function prototypes: __swiftself, __swiftthrows, and __swiftasync.

Those three keywords all are preconditioned on the function being declared as __swiftcall. __swiftcall has existed for many IDA releases already, but it now acts as a strong discriminator for any Swift-related logic inside IDA. For Objective-C/Swift mixed binaries, __swiftcall is your way to tell IDA that a function should be handled by the Swift machinery.

Let's go over the three new keywords one by one: since each of them is strongly linked to a Swift-specific ABI register, they are best presented by understanding the corresponding part of the Swift ABI.

The Self Register

Probably the most relevant one, because it made Swift reversing terribly annoying. The following very small snippet of ARM64 assembly code highlights the problem rather clearly:

Disassembly

__text:000000010000530C         ADD     X20, SP, #0x70+stack_str ; self
__text:0000000100005310         MOV     X0, X27 ; other
__text:0000000100005314         MOV     X1, X28 ; other
__text:0000000100005318         BL      _$sSS6appendyySSF ; String.append(_:)

The code just concatenates two Swift strings: the existing string is a temporary placed on the stack (#0x70+stack_str), and the string that is to be appended, the compiler stored in register pair X27 and X28. We'll get to the peculiarities of Swift string internals at a later point in time; the annoyance we are trying to solve here is how the compiler passes both the existing and the to-be-appended strings to the String.append function. We see that the to-be-appended string is passed by value in registers X0 and X1, but the existing string is passed via a pointer in X20. X0 and X1 are standard argument registers under the regular ARM64 calling convention, but X20 is callee-saved under standard AAPCS64. Pre-9.4 IDA knew that a Swift::String occupied two 8-byte registers, but it had no concept of the Swift ABI specialties, so the decompiler would (wrongly) render this as follows:

Pseudocode

Swift::String v14; // x0
// ---------------------------------------------------
v14._countAndFlagsBits = v11;
v14._object = v13;
String.append(v14);

The attentive reverser will immediately spot that String.append wrongly receives just one argument: the string that is to be appended. Crucially, we have no clue about the target of the string append operation. This might be recoverable/guessable from context in this isolated example, but since the Swift compiler actually relies a lot on passing pointers to objects in X20, the overall decompiler output becomes almost unintelligible, because the relationship between entities is difficult to track.

For this purpose, IDA 9.4 introduces the __swiftself annotation for arguments in function prototypes. With this new keyword, the String.append function looks as follows:

Pseudocode

void __swiftcall String_append(Swift::String *__swiftself self, Swift::String other);
                                              ^~~~~~~~~~~ new keyword

With the updated function signature, the call site in the decompiler renders exactly as we would expect, with an explicit pointer to the object being manipulated passed as the first argument.

Pseudocode

Swift::String v14; // x0
Swift::String stack_str; // [xsp+8h] [xbp-68h] BYREF
// ---------------------------------------------------
v14._countAndFlagsBits = v11;
v14._object = v13;
String.append(self: &stack_str, other: v14);

Only functions carrying the __swiftcall keyword can contain exactly one __swiftself-tagged argument. On x86-64 Swift binaries, the same logic is applied to r13.

The Async Context Register

A similar problem arises if we study the following snippet:

Disassembly

__text:0000000100003EA4 ; void __swiftcall specialized thunk for @escaping @convention(thin) @async () -> ()()
__text:0000000100003EA4 _$sIetH_yts5Error_pIegHrzo_TR10async_MainTf3npf_n
__text:0000000100003EA4
__text:0000000100003EA4 var_20  = -0x20
__text:0000000100003EA4 var_18  = -0x18
__text:0000000100003EA4 var_10  = -0x10
__text:0000000100003EA4
__text:0000000100003EA4         PACIBSP
__text:0000000100003EA8         ORR         X29, X29, #0x1000000000000000
__text:0000000100003EAC         SUB         SP, SP, #0x20
__text:0000000100003EB0         STP         X29, X30, [SP,#0x20+var_10]
__text:0000000100003EB4         ADD         X16, SP, #0x20+var_18
__text:0000000100003EB8         MOVK        X16, #0xC31A,LSL#48
__text:0000000100003EBC         MOV         X17, X22
__text:0000000100003EC0         PACDB       X17, X16
__text:0000000100003EC4         STR         X17, [SP,#0x20+var_18]
__text:0000000100003EC8         ADD         X29, SP, #0x20+var_10
__text:0000000100003ECC         MOV         X0, #0  ; request
__text:0000000100003ED0         BL          _$sScMMa ; type metadata accessor for MainActor
__text:0000000100003ED4         STR         X0, [X22,#0x10] ; (A)
__text:0000000100003ED8         MOV         X20, X0
__text:0000000100003EDC         BL          _$sScM6sharedScMvgZ ; static MainActor.shared.getter
__text:0000000100003EE0         STR         X0, [X22,#0x18] ; (B)
__text:0000000100003EE4         ADRL        X8, _$s14sampler_arm64e3AppV4mainyyYaFZTf4d_nTu ; async function pointer to specialized static App.main()
__text:0000000100003EEC         LDP         W9, W0, [X8] ; size
; ---------------------------- snip ---------------------------------

Despite the PAC-aware prologue, what draws our attention here are the X22-based memory accesses without an obvious preceding sequence that would make X22 point to anything sensible. Again, that would be fair confusion on compiler-generated AAPCS64 code, but the Swift compiler reserves X22 (and its x86-64 counterpart r14) as the async context register.

The async context stores state needed to suspend and resume an async function, such as continuation/resume information, but most notably async frame data, which can often span entire Swift objects. Keeping it in a dedicated callee-saved register lets Swift async code access that state cheaply across calls without repeatedly passing it as a normal argument.

This deviation from the regular ABI used to confuse pre-9.4 IDAs once again. Here's the corresponding pseudocode in IDA 9.3 (ignore the terrible whitespacing induced by the Swift demangler for a second):

void __swiftcall specialized thunk for @escaping @convention(thin) @async () -> ()()
{
  _QWORD *v0; // x22
  _QWORD *v1; // x0
  __int64 v2; // [xsp+18h] [xbp-8h]

  v0[2] = type metadata accessor for MainActor(0).value;
  v0[3] = static MainActor.shared.getter();
  v1 = swift_task_alloc(0x160u);
  v0[4] = v1;
  *v1 = v0;
  v1[1] = specialized thunk for @escaping @convention(thin) @async () -> ();
  if ( ((v2 ^ (2 * v2)) & 0x4000000000000000LL) != 0 )
    __break(0xC471u);
  specialized static App.main()();
}
// 100003ED4: variable 'v0' is possibly undefined
// 100003F4C: variable 'v2' is possibly undefined
// 100006964: using guessed type __int64 __swiftcall static MainActor.shared.getter();

The key is the line saying // 100003ED4: variable 'v0' is possibly undefined: in GUI IDA, v0 would render in red, indicating that the underlying register was read from before it was written to. (Such red markers serve as a great indicator that something is wrong with the current pseudocode.)

In IDA 9.4, we can mark this function as __swiftasync to tell the decompiler that X22 carries a pointer to a meaningful async context:

pseudocode

void __swiftcall __swiftasync specialized thunk for @escaping @convention(thin) @async () -> ()()
{
  _QWORD *async_context; // x22
  _QWORD *v1; // x0
  __int64 v2; // [xsp+18h] [xbp-8h]

  async_context = __swift_get_async_context();
  async_context[2] = type metadata accessor for MainActor(request: 0).value;
  async_context[3] = static MainActor.shared.getter();
  v1 = swift_task_alloc(size: 0x160u);
  async_context[4] = v1;
  *v1 = async_context;
  v1[1] = specialized thunk for @escaping @convention(thin) @async () -> ();
  if ( ((v2 ^ (2 * v2)) & 0x4000000000000000LL) != 0 )
    __break(0xC471u);
  specialized static App.main()();
}

As you'll notice, we decided against modelling the async context as an explicit parameter, and rather fall back to a custom intrinsic, __swift_get_async_context. This intrinsic is internally marked as non-propagating, so that it always results in an explicit local variable that can be explicitly typed by the user. This way, we can define a new struct type my_async_ctxt, then incrementally build up information about the currently executing async context and edit the underlying type as we go.

The Error Return Register

Which brings us to our last contender for the top spot in the bizarre ABI zoo: the error return register (ARM64 X21 / x86-64 r12). Here is the third snippet for you to study:

disassembly

__text:0000000100000EC0 ; Swift::Int __swiftcall callTyped(_:)(Swift::Int)
__text:0000000100000EC0 _$s10swift_errs9callTypedyS2iF          ; CODE XREF: _main+100↑p
__text:0000000100000EC0
__text:0000000100000EC0 var_10          = -0x10
__text:0000000100000EC0 var_s0          =  0
__text:0000000100000EC0
__text:0000000100000EC0                 SUB             SP, SP, #0x30
__text:0000000100000EC4                 STP             X22, X21, [SP,#0x20+var_10]
__text:0000000100000EC8                 STP             X29, X30, [SP,#0x20+var_s0]
__text:0000000100000ECC                 ADD             X29, SP, #0x20
__text:0000000100000ED0                 MOV             X21, #0
__text:0000000100000ED4                 BL              _$s10swift_errs11typedThrowsyS2iAA7MyErrorOYKF
__text:0000000100000ED8                 CMP             X21, #0
__text:0000000100000EDC                 MOV             X8, #0xFFFFFFFFFFFFFFFD
__text:0000000100000EE0                 CSEL            X0, X0, X8, EQ
__text:0000000100000EE4                 LDP             X29, X30, [SP,#0x20+var_s0]
__text:0000000100000EE8                 LDP             X22, X21, [SP,#0x20+var_10]
__text:0000000100000EEC                 ADD             SP, SP, #0x30 ; '0'
__text:0000000100000EF0                 RET
__text:0000000100000EF0 ; End of function callTyped(_:)

The most interesting part is how this function treats X21: the MOV at 0x100000ED0 initializes it to zero, followed by a call at 0x100000ED4, which is in turn followed by a check for zero at 0x100000ED8.

Maybe a bit surprisingly, pre-9.4 IDAs would decompile this function as follows:

Pseudocode

Swift::Int __swiftcall callTyped(_:)(Swift::Int a1)
{
  return _s10swift_errs11typedThrowsyS2iAA7MyErrorOYKF(a1);
}

Why? Again because of Swift-specific ABI trickery: in vanilla ARM64, X21 is callee-saved. That means the decompiler sees the sequence "initialize X21; call something [that will preserve X21, because it's callee-saved]; check if X21 is still zero", and consequently concludes that the CMP at 0x100000ED8 will always set the EQ flag and hence the CSEL will always take the X0 input reg (which still holds the return value of the callee in standard AAPCS64) — it hence completely optimizes away the check, leading to the flawed pseudocode output.

In IDA 9.4, however, the __swiftthrows function prototype annotation is here to save the day: unlike the other two new keywords presented in this blog post, __swiftthrows alters the behaviour of all callers, rather than the function that carries the annotation. In our example that means the sole callee of this function is typed

pseudocode

__int64 __swiftcall __swiftthrows _s10swift_errs11typedThrowsyS2iAA7MyErrorOYKF(__int64 result);
                    ^~~~~~~~~~~~~ new keyword

and hence signals to the caller that X21 is precisely not callee-saved, but rather carries the "exception state" (~zero = no exception, ~non-zero = exception; we'll spare you an explanation of Swift's typed exceptions today). As a consequence, the decompiler surfaces any subsequent X21 accesses in terms of the new __swift_get_error() custom intrinsic, and we get the desired result:

pseudocode

Swift::Int __swiftcall callTyped(_:)(Swift::Int a1)
{
  Swift::Int result; // x0
  void *error; // x21

  result = _s10swift_errs11typedThrowsyS2iAA7MyErrorOYKF(result: a1);
  error = __swift_get_error();
  if ( error != nullptr )
    return -3;
  return result;
}

This is tremendously helpful for analyzing complex control flow. The __swiftthrows keyword is either deduced from the demangled function prototype (if available) or inferred from the callee's structure for unsymbolicated but known-Swift callees. We had to make this auto-detection check rather strict to prevent false positives because, sure enough, in other parts of the code — in non-excepting contexts — the Swift compiler uses X21 as a perfectly fine callee-saved local scratch register. This new keyword and mechanic in the caller supersedes the old way of handling the Swift error return register, where IDA would work with spoils lists when it detected a thrower via the prototype (resulting in incantations like Swift::Int __swiftcall __spoils<CF,ZF,NF,VF,X0,X1,...,X17,X21,Q0,...,Q31> Thrower(Swift::Int x, Swift::Int y, Swift::Int z);).

Runtime Symbol Typing

Modelling the ABI fixes how Swift functions talk to each other. The other half of the readability problem is the functions a Swift binary talks to: the runtime and standard library. A typical app calls hundreds of swift_* entry points, and historically IDA had nothing to say about any of them. They are not described by the __swift5 metadata IDA walks (that metadata describes the types the binary defines, not the runtime it links against), so the best IDA could do was the usual __int64 __fastcall foo(_QWORD, _QWORD, ...) guess. Multiply that by every call site, and a Swift pseudocode listing turns into a sea of untyped quadwords.

IDA 9.4 ships a curated set of prototypes for the runtime surface and applies them by name, so these functions arrive fully typed: with __swiftcall, the right argument types, and meaningful enums. Take swift_beginAccess, the exclusivity-checking primitive the compiler emits around inout and stored-property access. Before:

pseudocode

// __int64 __fastcall swift_beginAccess(_QWORD, _QWORD, _QWORD, _QWORD); weak
swift_beginAccess(v1 + 16, a1, 33, 0);
swift_beginAccess(v0 + 16, v3, 1, 0);

and after:

pseudocode

// void __swiftcall swift_beginAccess(void *pointer, void *buffer, Swift::ExclusivityFlags flags, void *pc);
swift_beginAccess((void *)(self + 16), buffer, Tracking|Modify, nullptr);
swift_beginAccess((void *)(v0  + 16), buffer, Modify,          nullptr);

The prototype is now the actual one — __swiftcall, with typed arguments rather than a guess. Notice how the flags argument is typed as Swift::ExclusivityFlags, so 33 prints as Tracking|Modify (0x20|0x1) and 1 as Modify.

The Future

Those of you closely following IDA’s progress over the last releases already know that what was presented above is just the beginning. Upcoming IDA versions will address many more shortcomings (Strings, Metadata, Typing, Mangling, …) of current analysis and continue closing the gap between Swift binaries and the analysis they deserve.