radare2 6.2.0: a reworked pseudo-decompiler and a generic resource API

What happened on this date

At 18:27 UTC on 2026-08-07, radare2 published 6.2.0 on GitHub. The notes count 503 commits from 25 contributors since 6.1.8, and the Highlights section holds only a placeholder link. Going by the sections: the pdc pseudo-decompiler moved into a core plugin that builds a region AST and emits structured if/else; analysis gained type-recovery work such as synthesizing structs from pointer-argument access patterns; the binary-format layer gained a generic resource API covering Mach-O code signatures and certificates, GLib Resources in ELF, PE/CLR resources and NE/LE/LX resources, plus Rust v0 demangling and pluggable demanglers; DEX header and string validation was tightened; Swift Mach-O type, member and field metadata gained bounds checks; and a long list of out-of-bounds, use-after-free and overflow fixes landed across the Mach-O, ELF and DEX loaders, with Capstone 4 now the minimum.

Why it matters for people protecting app logic

No single item is dramatic, but together they show a trend: free, scriptable tools keep getting better at structure recovery and metadata parsing. Defenders can take three points from it. First, struct synthesis and structured pseudocode are exactly the preconditions that make disassembly easier for LLMs to read. Second, a generic resource API means resources embedded in binaries, such as .NET resources, GLib resources and signing certificates, are treated as first-class objects to list and extract, so configuration stored there is not hidden. Third, Swift metadata parsing and Rust demangling are reminders that type and field names preserved by the language runtime can expose business vocabulary directly. The release notes give no measurements of pseudo-decompiler quality, so this is about direction of capability, not a quantified change.

Concrete checks

First, list every resource embedded in your release packages on each platform (PE/CLR resources, GLib resources, resource directories and so on) and confirm none holds keys, internal endpoints or complete business rules. Second, check whether Swift type and field names or Rust symbols leak unnecessary business terminology, and decide whether naming or stripping policies need adjusting. Third, maintain a fixed sample set of your own builds and re-run it when tools such as radare2 ship new releases, comparing what has become visible. Fourth, when reading tool release notes, focus on format parsing and type recovery; those usually say more about your exposure than new commands do.

Your checklist

• Inventory embedded resources; confirm no keys or internal endpoints
• Check whether Swift/Rust metadata and symbols leak business terms
• Keep a sample set of your builds and re-run after tool updates
• Focus on format parsing and type recovery in release notes