Hex-Rays Blog

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

Sat, 08 Aug 2026 15:15:04 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

Sat, 08 Aug 2026 15:15:04 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.

IDA 9.4: Smarter Navigation and Quality-of-Life Improvements

Sat, 08 Aug 2026 15:15:04 GMT

IDA 9.4 makes getting around a binary faster. The Jump dialog becomes smarter by default, a new Pathfinder answers reachability questions directly from the cross-reference graph, and a batch of quality-of-life fixes smooth out the everyday interface.

Jump Anywhere, by default

IDA 9.4 introduces the new Jump dialog. This dialog debuted in 9.2 under the name Jump Anywhere as an opt-in alternative to the classic Jump to address dialog, matured in 9.3 with asynchronous search and demangled-name indexing, and now, in IDA 9.4, it graduates from "the other dialog" to the dialog. Pressing G opens it by default; the muscle memory keeps working, only the dialog behind it gets smarter.

`G` is now Jump Anywhere

The 9.4 default binding for G is the Jump Anywhere dialog. Same key, same place, same muscle memory, only now the dialog accepts names, expressions, segment-relative addresses, and script identifiers without you having to remember which dialog handles which.

Existing input forms still work unchanged:

Plain hex (401000, 0x401000)
seg:off for segmented inputs
Relative offsets (+100, -10000)
Named items, including auto-generated names (sub_401000, loc_4010A0)
C-style arithmetic with $ as the current address

What's new is that the same keypress now also gives you a live, ranked result list across functions, names, local types and segments, without breaking any of the above.

One box, everything IDA knows

The list under the input is more than an address picker. A single query searches every kind of thing in the database at once - functions (library and imported ones included), names (data, strings, and the auto-generated sub_, loc_, a… labels), local types, function comments, and segments - ranks the hits by how well they match, and highlights the characters you typed.

That last bit catches people out: yes, your types are in there too. Type sig and the list interleaves the sigprocmask function, the sigaction and siginfo_t structures, and the aSigaction string literal - each one a single Enter away, the preview pane already showing you where it leads. You stop having to know in advance whether the thing you're chasing is a function, a label, or a struct; you type part of its name and Jump Anywhere sorts the rest.

Live previews

As you move through the result list, a preview pane shows you exactly where each row leads, before you commit the jump. Toggle it between Disassembly, Pseudocode (for functions you've already decompiled), and Hex with the buttons next to the input, and Jump Anywhere remembers your pick for next time.

"But I want the old dialog back"

We hear you. If your fingers expect a no-distractions address prompt, you can keep one. A Feature Flag in Options → Feature Flags… restores the classic Jump to address dialog for G; the new dialog is then still available as the Jump Anywhere action in the Jump menu.

Re-jump to the last address with a single `Enter`

A common pattern with the old G was "press G, type the same thing again, hit Enter." In 9.4 the dialog opens with your most recent jump already selected, so G ↵ takes you straight back to the last place you went: two keystrokes, no typing. Need an address from further back? Arrow down through the history first, then Enter.

If there's something you want to type into Jump Anywhere that doesn't work yet, tell us. The dialog is the one place every navigation request lands, and it's easier to add a syntax than to argue about which menu it should live under.

Pathfinder: Xref marks the path

Every reverse engineer knows the question. You are staring at a dangerous function, system(), a crypto routine, a privileged syscall wrapper, and you need to know: can the code I care about actually reach this? Or the inverse: does the data that arrives in recv() ever flow anywhere interesting?

Until now, IDA's answer was to chase cross-references one level at a time, or to open Xrefs graph to/from and squint at the resulting hairball. The information was always there (the xref graph knows every caller and callee), but the question you wanted to ask was about paths, and there was no way to ask it directly.

IDA 9.4 adds one: the Pathfinder.

State the question, get the answer

Open the Pathfinder with Shift-F9 (or View → Open subviews → Pathfinder). Add two waypoints, the from and the to, and IDA immediately searches the cross-reference graph for every path connecting them.

The result appears right in the widget: between each pair of waypoints you see how many functions participate in some path and how short the shortest connection is ("N nodes, shortest path: M"), and a status bar beneath the waypoint list sums it up ("Found N unique nodes across M segment(s)"). If there is a route, Pathfinder says so, which is often exactly the answer you needed ("Yes, attacker input can reach this sink").

Waypoints can be added three ways:

drag a function straight in from the Functions list,
right-click the waypoint list and pick Add waypoint… to choose a function,
or, from any disassembly or pseudocode view, right-click → Add to path (or just press Ctrl-Shift-F9). This is the fastest way: navigate where you care, press the key, move on.

More than two dots

Paths are rarely a two-point question. Pathfinder accepts an ordered list of waypoints, A through B to C, and finds paths that visit them in order, segment by segment. Drag rows to reorder; the per-segment counts update as you go.

And when the search keeps routing through some hyper-connected utility function that you know is noise, a logging helper or a generic wrapper, drop that function into the Exclusions panel and it is banned from every path. Drag it back up into the waypoint list to re-include it. (Remove any row with its ✕ button; a right-click Clear empties a whole list at once.)

Two checkboxes and a slider tune the search:

Include data xrefs: follow data references too, not just calls (on by default)
Shortest path only: collapse the result to the minimal route
Max depth: bound the search radius (default: unlimited)

Seeing it

Numbers are an answer; a picture is an explanation. Pathfinder has three buttons for that:

Tree (First → Last) and Tree (Last ← First) open the cross-references tree with every discovered path already expanded, the whole route from caller to callee (or callee to caller), ready to walk. For very large results (256+ nodes) IDA asks before building the tree, and the build is cancellable.
Graph renders the paths as an Xref Graph: the path spine and your waypoints get dedicated colors (theme-aware, of course), so the route pops out of the surrounding graph instead of drowning in it.

The graphs Pathfinder creates are ordinary xref graphs, saved with your database and listed in the Xref Graph manager, which is itself new in 9.4: a dockable widget where saved graphs live in folders, with live node counts. Pathfinder even files its graphs into a dedicated Paths folder there.

It remembers

Waypoints, exclusions, and options are saved with your desktop, per database. Close IDA mid-investigation, reopen the IDB tomorrow, and your waypoint list is still there, paths recomputed and ready.

If there is a question you want to ask the xref graph that Pathfinder can't express yet, tell us. The widget is new, and the whole point is to let you ask path questions directly instead of reconstructing answers by hand.

Quality of life: the little things in 9.4

Not every improvement earns its own headline. Here are the small wins that clear friction out of the everyday interface, grouped by where you'll notice them.

Readable in every theme

Expand/collapse arrows in tree views (Functions folders, the cross-references tree, structure members) are legible in every dark theme, not just the default.
Hint-popup titles no longer fade into the background on macOS under the default dark theme.
Merge view detail-pane text is readable against dark backgrounds.

Clicks that land where you meant

Clicking an address in the navigator band from the pseudocode view now switches to IDA-View and jumps there. Previously this did nothing.
Under the debugger, double-clicking a stack variable jumps to that stack-memory slot.

Lists that behave

The cross-references tree name column auto-sizes to its contents instead of clipping.
Quick-filtering a list whose items live in more than one folder no longer shows phantom matches or trips an internal error.
The status-bar analysis indicator updates immediately when toggled.
Dispatching a chooser action from the command palette no longer crashes.

Closing

Taken together, navigation in 9.4 gets both smarter and deeper. The Jump dialog answers "where is this?" the moment you press G, and Pathfinder answers "how do I get from here to there?" straight from the cross-reference graph, while a batch of quality-of-life fixes clears the small frictions out of the way. Many of these improvements started as customer requests, so thank you for your feedback. If there's a navigation workflow or a path question you'd like IDA to handle, tell us on the forum: https://community.hex-rays.com/ or contact support@hex-rays.com.

IDA 9.4: Apple Dyld Shared Cache workflow improvements

Sat, 08 Aug 2026 15:15:04 GMT

Over the years, the Apple ecosystem (iOS, macOS, …) has seen steady gains in security, application load-time, and more. One of the cornerstones enabling those is the "Dyld Shared Cache" (DSC): a highly specific collection of common system libraries, pre-optimized on many fronts and used across applications.

If you have spent time in that field, you have probably noticed that IDA's support for the DSC left a lot to be desired. It took us some time, but IDA 9.4 changes that dramatically, with a far more streamlined workflow, fewer hurdles, much better Swift support, clearer feedback, and (perhaps most importantly) fluid navigation that is no longer broken by missing cross-references, the dreaded "red addresses".

What's new

In a nutshell, we have reconsidered the way reversers approach a Dyld Shared Cache as a whole.

Gone are the days of loading the entire DSC into the database just to keep cross-references intact. The user now gets fluid navigation across every part of the DSC - even the parts that are not loaded: those are brought in on-demand.

IDA 9.4 also ships new, specialized widgets that keep the layout of the DSC in view at all times: what is currently loaded, what is available, and so on. Alongside them comes tooling built for very DSC-specific use-cases:

load image(s) (that is, shared libraries) and their dependencies, down to N levels of depth
extract the list of dependencies from a user application and load those (plus dependencies, if needed)
find which image or section of the DSC contains specific symbols
find your way into the DSC straight from log messages
build your own tooling on top of a specialized API, the same one the entire UI is built on
…

These improvements went through several iterations with a very eager group of alpha-testers, and the result is an experience far ahead of what IDA 9.3 had to offer.

Humans and agents

While IDA 9.4 ships brand new and specialized tooling, it is, by and large, all built on an API - one that humans and agents can both use. The API is, by design, simple, fast, and available in both C++ and Python. Point your agents at it, and they will trivially find their way.

How can I try it?

If you have not already, register for our beta program and give it a spin: point IDA at a DSC's "entrypoint" file and enjoy the trip. Feedback during the beta directly shapes the final release, so tell us what works and what doesn't.

What's next?

IDA 9.4 lays a new foundation for working with DSCs, and there is more to come: now that the groundwork is in place, we can start surfacing more of the data buried in the DSC internals. It is not the only thing on our radar either. KernelCaches and DriverKit share similarities with the DSC, so they should benefit from the same improvements - hopefully soon.

Finally, a huge thank-you to our alpha testers squad - their feedback has been invaluable, and their suggestions greatly helped shape the result. Kudos to everyone who was involved!

IDA 9.4: Wider Processor and Platform Support

Sat, 08 Aug 2026 15:15:04 GMT

IDA 9.4 comes with a brand-new Qualcomm Hexagon DSP module, an MCore family covering C-SKY V1, and deeper coverage of ARM, TriCore and RISC-V.

Qualcomm Hexagon (QDSP6)

We've added a new processor module for Qualcomm Hexagon. If you reverse Snapdragon firmware (audio and compute DSPs, modems or newer NPU images), IDA now disassembles and analyzes it, with loaders for both ELF and Qualcomm's MBN container.

A couple of remarks about Hexagon:

Instructions execute in parallel groups of up to four. IDA shows each packet inside braces, decodes duplex instructions (two sub-instructions in one word), and resolves .new operands.
Zero-overhead hardware loops, marked with :endloop0 / :endloop1.
Packet-aware control flow. A single packet can hold more than one branch.

The output is configurable. Through the processor options you can move braces onto their own lines, show slot labels or annotate .new producers.

MCore and C-SKY V1

For 9.4 we used the occasion to add C-SKY V1. It is derived from and largely compatible with Motorola/Freescale M-CORE, so the two share the decoder.

Supported by the module:

Stack-variable tracking, so frames are recovered and locals get names.
Literal-pool loads shown as = symbol, with the pool entry and its cross-references resolved (e.g. lrw r7, =aBootseqNormal).
Relocation-based cross-references and better function detection.

The C-SKY V1 support covers the CK510, CK610, CK610E and CK620 cores, including their coprocessor and DSP/multiply instructions, in both little- and big-endian variants. The ELF loader detects C-SKY binaries and handles MCore/C-SKY relocations.

ARM: complete SVE and SME

In IDA 9.3, you could decode the SVE/SME subset that turns up in Apple kernels. For 9.4, we implemented the whole thing: the full AArch64 SVE, SVE2, SME and SME2 instruction sets, including the scalable vector registers (Z), predicate registers (P), multi-vector and indexed SME2 operations, and MUL VL addressing.

ARM architecture detection selects an appropriate SVE/SME profile based on the binary’s reported architecture and attributes. As a heuristic, ARMv8.2 targets select SVE, ARMv9 targets select SVE2, and generic AArch64 targets enable SVE2+SME2. You can override it from the processor options if the detection is wrong, or disable the extensions entirely.

Two ABI improvements landed alongside it:

The VFP (hardfloat) ABI is now inferred from the ELF file.
For ARM32 Windows binaries, IDA assumes the AAPCS-VFP ABI.

A few smaller disassembly fixes:

STM SP is recognized as a multi-slot stack-argument store.
Fixed UDF decoding for AArch64.
Improved 64-bit TBB-style switch recovery.

TriCore: calling conventions and analysis

TriCore is the core of Infineon's AURIX family, a dominant microcontroller in automotive ECUs. For 9.4, we gave the module a real type system and an explicit calling-convention model. IDA now knows how arguments and return values are laid out across the TriCore register banks, so function prototypes, argument types and cross-references come out far more accurate on AURIX firmware. This is the groundwork for a decompiler, but it makes everyday disassembly more useful today.

A calling-convention model

Usually TriCore passes the first integer/pointer arguments in the data and address register banks (D4–D7, A4–A7) and spills the rest to the stack. IDA now models this directly: it computes argument locations, the return location, and the varargs layout from a function's prototype, and it distributes operands across the D/A banks the way the ABI requires.

Two common ABIs are selectable from the processor options: the GCC/HighTec EABI and the TASKING ABI. These differ in how some arguments and return values are allocated. IDA will automatically apply heuristics to guess the ABI during analysis, but the user can always change it from "Options/Compiler.../ABI name".

Sharper disassembly

Alongside the ABI work, we improved several analysis passes:

Better switch-table detection, including 16-bit relative offset tables.
A reworked relocation handler with more relocation types and cleaner xrefs.

AURIX TC4x device support

Built-in memory maps and peripheral-register definitions for the latest AURIX TC4x devices — TC45x, TC48x, TC49xN and TC4Dx. Selecting one of these devices lays out the on-chip memory map and names the special-function registers, so peripheral accesses in firmware read as CAN_17_MCMCAN_F0SA instead of a raw address.

RISC-V: vendor extensions and embedded cores

RISC-V keeps spreading into security chips and microcontrollers, and the vendor custom-extension space has grown with it. For 9.4 we widened RISC-V coverage on both fronts.

Soteria

Soteria (Xsoteria) is a custom RISC-V extension encountered in security-chip firmware.

Those opcodes overlap with other vendor extensions (the Andes XAndesPerf set uses the same encodings), so IDA cannot always tell which vendor a word belongs to from the bytes alone. Rather than guess silently, it decodes the configured extension and prints the alternative reading as a comment (alt Xsoteria / alt XAndesPerf), so an analyst working on the wrong assumption sees it immediately.

The non-trivial Soteria instructions lift to microcode and surface as intrinsics in the pseudocode, while constant-argument forms are folded locally:

Pseudocode

unsigned __int32 __fastcall test_grevi_bswap(unsigned __int32 a1)
{
  return _soteria_grevi(a1, 0x18u);
}

int __fastcall test_clear_highbit(unsigned __int32 a1)
{
  return a1 & ~(1 << _soteria_fls(a1));
}

Hazard3 / RP2350

Hazard3 is the RISC-V core in the RP2350 (Raspberry Pi Pico 2). IDA decodes its custom instructions, including the inter-hart synchronization primitives. RP2350 firmware decompiles cleanly, down to the SDK GPIO helpers.

Compressed instructions

The compressed-ISA support was extended with the Zcmp, Zcmt, Zclsd, Zcb and Zihintntl extensions, plus semihosting recognition. Compressed instructions now carry an explicit c. prefix in the listing (c.addi, c.sw, c.j), so it is obvious at a glance which instructions are 16-bit.

Complete HINT decoding

IDA now decodes the full RISC-V HINT space, including standard hints, pause, NTL, semihosting markers, and vendor-reserved encodings. Think of a hint as a "do-nothing" instruction that signals the CPU something (cache, pause) without changing state. Expect to see inline IDA annotations along such instructions.

For example:

Disassembly

add     zero, ra, sp # standard hint
srai    zero, zero, 7 # semihosting exit
slti    zero, ra, 1 # custom hint

Debugger: improved remote and embedded debugging

All the new silicon above has to be debugged somewhere, and for embedded and DSP targets that usually means a remote GDB stub reached over JTAG or a gdbserver. For 9.4 we went through IDA's GDB remote serial protocol (RSP) client and made it more compliant and more compatible with third-party and embedded stubs, plus added a couple of conveniences aimed squarely at microcontroller work.

RISC-V debugger configuration.
Hardware breakpoints are used automatically for addresses in flash ranges, where a software breakpoint cannot be written.
Binary x/X memory transfers when the stub advertises them.
Library and memory-map discovery over qXfer:libraries-svr4:read, the full qXfer:libraries:read XML format, and qXfer:memory-map:read.
When a process fails to launch, IDA shows the real reason behind it.

Closing

Taken together, 9.4 reaches further into embedded and DSP silicon. This is just the groundwork for more in-depth analysis to come. Many of these improvements started as customer requests - thank you for your feedback! If there’s a processor, ISA extension or debugging workflow you’d like to see supported, tell us on the forum: https://community.hex-rays.com/.

IDA 9.4 Beta Is Now Available

Sat, 08 Aug 2026 15:15:04 GMT

If you're part of our Beta Program, the new build is now available in the Download Center of your customer portal. Your testing and feedback are essential in validating new features, surfacing regressions, and ensuring this release is ready for production use.

Not enrolled yet? Joining the program is quick and easy, just click Subscribe from your customer portal dashboard - see below for details.

The IDA 9.4 Beta is here, and we would love your help putting it through its paces. This build brings a major overhaul of Apple shared-cache analysis, new processors, decompiler upgrades, and a lot more. Your feedback during the beta directly shapes the quality of the final release.

Highlights

New Apple Dyld Shared Cache infrastructure. A completely overhauled approach to analyzing Dyld Shared Caches, with dedicated widgets, specialized workflows and actions, seamless navigation between cache components, and improved analysis.
Decompiler. Swift ABI recognition lands in the decompiler and type system, and strings recovered during decompilation now show up automatically in the Strings list. You also get call-site argument name hints, collapsible code blocks, and a new "Edit type" action.
Support for higher-level programming languages: Deeper Rust, Golang, and Objective-C support
New processor modules. A brand-new Qualcomm Hexagon (QDSP6) disassembler paired with a Qualcomm MBN boot-image loader, plus a new MCore / CSky V1 module.
More architecture support. ARM SVE2 and SME are now fully disassembled, RISC-V gains Hazard3 (RP2350), compressed Zcmp / Zcmt / Zclsd, and Soteria extensions, and TriCore sees broad improvements.
Pathfinder and a redesigned Xrefs Graph. The new Pathfinder widget (Shift-F9) finds call paths between functions, and the Xrefs Graph has been redesigned around a new graph manager. Jump Anywhere is now the default "g" shortcut.
Git-based Teams server. Teams add-on for IDA Pro can now version databases through your own Git server instead of the proprietary Vault, and new IDB deep links let you share a location without shipping files around.
Scripting and API. A unified "Scripts" window replaces the old Execute script and Snippets dialogs, and a new IDA Domain API release (v0.5.0) adds microcode and pseudocode access plus object store and retrieve APIs.
Native ARM64 Windows build. IDA now ships as a native build for Windows-on-ARM.

Beyond these, 9.4 adds compilation-unit folders in the Functions list, RISC-V debugging via the GDB backend, faster loading of large DWARF files and shared caches, and a long list of bug fixes.

-> Read the full beta release notes here: https://docs.hex-rays.com/release-notes/9_4beta

Enrolling in the Beta Program is simple

Log in to your customer portal.
Click Subscribe when prompted at the top of your dashboard.

Once enrolled, you will be able to access the beta release in the Download Center. Moving forward, we’ll notify you by email when beta versions are ready for download. Note that beta licenses will automatically match your active IDA license (e.g., IDA Home → IDA Home Beta, IDA Pro → IDA Pro Beta).*

*You must have an active IDA Pro or IDA Home license to beta test.

Get full program details plus the terms and conditions here: https://hex-rays.com/beta-program

Your feedback drives IDA forward

We rely on your feedback to shape the future of IDA. Please report bugs or suggestions using the Early Access Feedback Form or by emailing support@hex-rays.com.

Hex-Rays Blog

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

Apple Dyld Shared Cache, Reimagined

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

Decompiler Improvements

Expanded Processor and Platform Support

Loaders and Program Structure

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

Teams, Now on Git

Debugger Advancements

Automation: idalib Comes to IDA Home

Performance

And more ...

Keep us in the loop!

Getting IDA 9.4

IDA 9.4: Improved analysis of compiled Swift binaries

Proper Modelling of the Swift ABI

The Self Register

The Async Context Register

The Error Return Register

Runtime Symbol Typing

The Future

IDA 9.4: Smarter Navigation and Quality-of-Life Improvements

Jump Anywhere, by default

G is now Jump Anywhere

One box, everything IDA knows

Live previews

"But I want the old dialog back"

Re-jump to the last address with a single Enter

Pathfinder: Xref marks the path

State the question, get the answer

More than two dots

Seeing it

It remembers

Quality of life: the little things in 9.4

Readable in every theme

Clicks that land where you meant

Lists that behave

Closing

IDA 9.4: Apple Dyld Shared Cache workflow improvements

What's new

Humans and agents

How can I try it?

What's next?

IDA 9.4: Wider Processor and Platform Support

Qualcomm Hexagon (QDSP6)

MCore and C-SKY V1

ARM: complete SVE and SME

TriCore: calling conventions and analysis

A calling-convention model

Sharper disassembly

AURIX TC4x device support

RISC-V: vendor extensions and embedded cores

Soteria

Hazard3 / RP2350

Compressed instructions

Complete HINT decoding

Debugger: improved remote and embedded debugging

Closing

IDA 9.4 Beta Is Now Available

Highlights

Enrolling in the Beta Program is simple

Your feedback drives IDA forward

`G` is now Jump Anywhere

Re-jump to the last address with a single `Enter`