IDA 9.4: Wider Processor and Platform Support

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:

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:

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/.