
Binary Ninja 6.0 (Krypton) is here! This is a major version bump and it’s worth the wait. We’ve shipped a brand new MCP server, a new Binary Similarity feature, and a complete overhaul of the Plugin Manager as the new Extension Manager. Under the hood, you’ll find major improvements to performance and memory usage, a refactored calling convention to properly represent structure parameters and return values, and added HLIL structure initializers. On the scripting side, we’ve upgraded the bundled Python to 3.13 and included it on Linux. We’ve also added a new TMS320C6x architecture, a new user wizard to ease migration, and a long list of debugger improvements. And those are still only some of the new features detailed below.
We’re also improving the free edition. We’ve added the highly requested armv8 (AArch64) architecture as well as the above mentioned MCP server. Additionally, we’re also shipping a new Linux ARM64 build of the free version. Next, as previously announced, with this release we’re putting our new pricing and packaging into effect. Finally, thanks to everyone who participated in our 10 year celebration, we’re looking forward to another decade!
Let’s get some universally applicable improvements out of the way first. No matter how you use Binary Ninja, you’ll see some fantastic speedups in 6.0 while also seeing decreases in memory usage. Exact improvements depend on the workload and hardware so we picked some representative sample binaries and ran a gamut of testing including multiple runs (for all samples but Chrome) to ensure reliability. The results speak for themselves.
5.3 stable 6.0 stable
syspolicyd
Mach-O universal, x86-64 slice
4,215 functions2.6 MB
Analysis time
1.97× faster
CPU instructions
19% fewer
chrome_crashpad_handler
ELF x86-64
6,092 functions1.9 MB
Analysis time
1.06× faster
CPU instructions
21% fewer
locationd
Mach-O universal, x86-64 slice
28,372 functions19.0 MB
Analysis time
1.54× faster
CPU instructions
16% fewer
ntoskrnl.exe
PE32+ x86-64
34,146 functions12.8 MB
Analysis time
2.02× faster
CPU instructions
53% fewer
libbinaryninjaui.so.1
ELF x86-64 shared object
43,957 functions136.1 MB
Analysis time
1.37× faster
CPU instructions
10% fewer
vmlinux 6.14
ELF AArch64, with DWARF
92,961 functions511.8 MB
Analysis time
2.16× faster
CPU instructions
52% fewer
chrome
ELF x86-64, with DWARF
950,042 functions1.47 GB
Analysis time
2.03× faster
CPU instructions
35% fewer
As you can see, across a representative corpus, 6.0 analyzes up to 2.16 times faster than 5.3 while using as much as 55% less peak memory.
These gains come from many changes rather than any single optimization. There were dozens of smaller fixes, hundreds of hours of profiling, new tools developed to analyze memory usage, and Brian, Mark, Ryan, and others working to optimize the system. Nothing was sacred: many long-standing data structures and sections of code were critically examined for potential improvements.
Binary Ninja maintains an analysis cache of analyzed functions. However, choosing when to re-analyze and when to cache can be tricky to get right from a performance perspective. With improved instrumentation and analysis we were able to make much better use of the existing analysis cache while also fixing some bugs along the way.
This is just the beginning as we’re planning to focus even more on save and load times in future releases. However, in 6.0, we’ve already improved both memory usage and total time during saving, as well as fixed a file size creep bug where files could keep growing with repeated saves.
While Tim and BK on the Sidekick team have added MCP support so that Sidekick can access MCP servers in a previous release, with Binary Ninja 6.0, we shipped a first-party MCP server. It’s “batteries included” for the post-LLM world. It can interact directly with the UI you are looking at or, for versions of the product with headless API support, can be accessed directly without the UI at all.
There are two variants. The GUI server runs inside Binary Ninja over HTTP and is included in all editions including free. The headless server is a standalone binaryninja_mcp binary that speaks stdio, and is included with Commercial and Ultimate on macOS and Linux. Native Windows packages don’t ship the headless binary yet. Use the built-in GUI server there or run the Linux build under WSL. This is an unfortunate limitation due to Windows file system locking, where a running MCP server can corrupt or block an install.
Both variants expose the same data and allow the same actions: opening files and databases, selecting BinaryViews, driving and waiting on analysis updates, a compact triage summary of a binary, program structure (entry points, segments, sections, symbols, imports, exports, relocations, data variables, and strings), raw memory reads, function inspection covering metadata, disassembly, Pseudo C, ILs, and many more useful properties. They can rename objects, create and apply types, and create data variables as well.
Turning on the GUI server is easy: enable ui.mcp.enabled in settings and restart to always enable, or run Plugins > MCP > Start Server. With default settings it listens at http://127.0.0.1:24642/mcp, and Plugins > MCP > Copy Connection Info will hand you the exact URL and authorization header for your session so you can paste it straight into your client. If you’d rather lock it down, set ui.mcp.token and clients will need to send a matching bearer token.
The documentation has ready-to-paste configurations for Claude Desktop, Cursor, VS Code, and Codex, as well as much more information.
Binary Similarity is, at heart, the task of noticing that the two functions in front of you are the same person, except one has a cape and one wears glasses.
With 6.0 Mason created our Binary Similarity system for comparing two or more related binaries. It’s not a competing diffing engine to popular tools like BinDiff, Diaphora, or BSim. Rather, it’s a pluggable platform which can not only leverage multiple providers, but also allow you to integrate, compare, and do more with them than before.
We currently ship two providers: Google BinDiff (for finding structurally similar functions) and WARP (for finding exact function matches). All providers report similarity and confidence, allowing you to review possible matches, render them side by side, and apply the available analysis information to the new binary.

For example, when comparing two releases of a popular game, Binary Similarity quickly highlights the changes in cGcFrontendPageShop::GenerateRepShopInventory. Rendering the result keeps both versions in sync and highlights the differences, making it easy to identify patched logic.

Patch diffing is not the only use case. Often you have a heavily annotated binary whose annotations you want to port to a newer (or different) version. With Binary Similarity, we can automatically transfer annotations from one binary to another, saving time and effort.

Of course, the UI is not the only way to use the new Binary Similarity functionality. This is Binary Ninja, after all: everything is pluggable and accessible via an API. The complete system is exposed through the Python API, C++ API, and Rust API, allowing you to create and run sessions headlessly.
Plugins can also register entirely new providers and resolvers. Providers find possible matches, while resolvers choose which results to use (and can apply them automatically), so the system is not limited to WARP and BinDiff or to our built-in matching algorithm(s). In fact, the third-party binja diff plugin, which wraps QBinDiff from Quarkslab, already supports adding QBinDiff as a provider for a second opinion to BinDiff.
NOTE: Binary Similarity is only available in Ultimate.
For more information on configuring sessions, reviewing and applying results, or running it headlessly, see the documentation. Our immediate roadmap includes new integrations and even our own novel matching implementation, so stay tuned!
Brandon’s been on a DSP kick and adding those difficult-to-decompile architectures to Binary Ninja. First it was Hexagon and, now with 6.0, it’s TMS320C6x.
Keep an eye out for an upcoming blog post with more detail about all the behind-the-scenes changes and how we can now handle such a problematic architecture. In the meantime, all customers with current Ultimate support can update to a version with 19 first-party architectures!
Here’s a quick sneak peek for everyone else:

Binary Ninja could previously track and allow users to override only a single global pointer register, but that doesn’t cut it for every architecture. TriCore, for example, uses four registers to point into different global data regions, and Binary Ninja can now track and override each of them independently. With accurate global pointer values available during analysis, references to global data resolve correctly and produce much cleaner decompilation.

Introduced in a previous post, BASE is our automated base address detection feature built into all versions of Binary Ninja. With 6.0, it includes a new “sampling” mode, enabled by default, which can produce accurate results in a much shorter timeframe. It’s especially useful for large files, though the previous IL Analysis Mode is still available when accuracy matters more than speed.

One of our main thrusts going forward is better handling of language-specific decompilation. We’ve built language representation features for that, and our workflow system lets us tweak the decompilation in really useful ways. But our type system, calling convention, and ILs likely need changes to fully support the most modern programming languages. Instead of sticking to just treating everything like C, we want to keep working toward language-specific support like we have with Objective-C.
To that end, in 6.0 Rusty refactored our calling convention system. We can now support structure returns and parameters which are used in a number of languages. Most of the changes you’ll see in 6.0 are minimal on the face of it, but this change unblocks several future language-specific decompilation improvements that you should be able to see in upcoming releases (or even sooner on our development branch).
That said, we do ship two specific changes. While the added Go and Pascal calling conventions don’t do much out of the box, when combined with a plugin like Delphinja, you can get some much improved results since it includes type libraries and specific debug information parsing that can leverage the new convention!
The Go calling convention support is in the core, but as we’re not yet processing the metadata available in .gopclntab sections and similar information, you won’t see any automatic changes yet. Keep an eye out for this in the next release, however!
A new IL instruction and a system for initializer expressions greatly simplify structure initializations, resulting in some really clean decompilation.

Fragments from Krypton are usually bad news. Type fragments are the useful kind.
A type fragment represents a bitwise slice of a larger source type while that slice is carried in integer-like storage. When a calling convention passes pieces of a structure in registers, or an optimized inline memcpy copies a typed object in register-sized chunks, those pieces used to decay into anonymous integers and the connection back to the original object was lost. Fragments preserve that relationship, tracking which bits of which source type a given register is holding as it moves through the program.
These are intermediate, in-flight types used by analysis rather than something you’ll define yourself, and they render in decompiled output using __frag notation (or __frag_be when the source is big-endian). Together with the calling convention refactor above, that means structures split across registers keep their types instead of dissolving into integers along the way.
We’ve been shipping a bundled Python in our macOS and Windows builds of Binary Ninja for a while now. Now, in 6.0, we ship this bundled Python with all builds on all platforms, including x86-64 and AArch64 Linux. This means that our support for third-party Linux distributions should be a bit more reliable since we don’t need to make assumptions about what’s installed by default.
While he was at it, Alex also bumped the included version to 3.13 to keep things a bit more modern. Our minimum supported version is still 3.10 if you require something older, however.
This does mean that if you were running the previously bundled version of Python and you switch, none of your dependencies will be installed! The one-time Plugin Migration dialog will reinstall them for you.
A small but noticeable quality-of-life improvement for those who do a lot of scripting: the scripting console now hints at individual parameters instead of just the prototype.

The Plugin Manager is dead, long live the Extension Manager! This change not only sets the groundwork for better plugin features, but also paves the way for native plugins and being able to install things other than plugins like themes or type libraries. Almost half the team touched the extension manager code this release, it was truly a team effort.

Here are the main features you’ll see with the new Extension Manager:

One heads-up if you’re upgrading: Extensions now live in channels/ instead of repositories/, so your first 6.0 launch will run a one-time migration. This will reinstall everything you had previously, dependencies included, and re-enable them when it’s done.
We also want to have a special mention to one of our summer interns Ashvika who did a ton of work to improve our plugin ecosystem. If you notice many more plugins with proper images and readmes, you can thank her for it.

You’ll notice the new name in the API, too: The Python module is now extensionmanager, with a deprecation shim left behind.
It’s hard to switch tools when you’re used to a particular workflow or hotkey, and it’s even harder to dig and find all the settings you might want to change in a new tool. New in 6.0 is a short three-step wizard. You choose a light or dark theme, a preferred experience, and a few privacy and network toggles (automatic crash reports, automatic update checks, and online WARP).
The middle step is for you if you’re arriving from another tool. Next to the Binary Ninja Defaults, you can pick a Ghidra-Like experience, or IDA-Like preset. There are multiple differences among them, and the configuration lives in docs/files in the API repository so contributions are welcome.

If you want more information about what’s different compared to other tools, start with our migration guide.
Krypton gives you a much clearer picture of the process around the code you are debugging. The new Debugger Memory Map sidebar shows every mapped region reported by the debug adapter, including its address range, size, permissions, and name. Binary Ninja can also mirror those mappings as individual memory regions, allowing Find to search mapped memory without trying to scan the entire address space. And when an address belongs to a library that was not part of the original analysis, you can now load symbols from the debugger backend on demand, either for one module or for all loaded modules. These are added as auto symbols, so they participate in analysis and annotations without overriding any names you have defined yourself.

The most common request from Binary Ninja Free users was for AArch64 support, and with 6.0 it’s finally here! The free edition now decompiles armv8 (AArch64) in addition to x86, x86_64, and armv7 (with Thumb2). That covers the overwhelming majority of binaries most people run into today and we’re happy to make the free version even more useful.
Adding armv8 also removed the reason we held back an ARM Linux build of the free edition in 4.1. So 6.0 ships a fourth free installer for Linux available on the free download page.
Armv8 isn’t the only thing new in Free for 6.0. Our new MCP server is included so you can point your favorite LLM at Binary Ninja and let it use our analysis completely for free. Free keeps getting more powerful under a yellow sun.
Everything else stays the same. It’s still free for non-commercial and commercial evaluation uses. The remaining limitations (no API or plugins and a reduced set of ILs) still apply. If you need any of our other architectures, the full breakdown of what ships in each edition lives on the purchase page.
In case you missed it over on the Sidekick blog, we recently launched free Sidekick credits for ALL Binary Ninja users with active support. You don’t need a credit card for a trial or to sign up. Just install the plugin and start using it. The included free credits refill every month.
As we outlined in our 6.0 pricing changes announcement, collaboration is no longer included with Ultimate. It is now a per-seat add-on available for named, computer, and floating Ultimate licenses. You can choose to add it to only the seats that need shared projects, versioned check-ins, real-time chat, and more.
We have also removed the old minimum seat count needed to get access to the Binary Ninja Enterprise Server. Enterprise Servers are no longer licensed separately: Customers with the collaboration add-on or floating Ultimate licenses can download and self-host as many servers as they need, wherever they need them.
The new packaging also greatly improves how Enterprise Servers are managed. Instead of receiving a license for each server, you now create a server deployment in the Binary Ninja Portal. A deployment represents one named server installation and belongs either to your account or to a team you manage.
From the portal’s new Server Deployments page, you can create a deployment, assign floating licenses, and download a server bundle for your chosen platform, release channel, and version. The server bundle includes everything needed to set up the server, and will look very familiar to those who have deployed Enterprise Servers in the past. If the floating licenses assigned to a deployment change, you can also download only a new license bundle without having to download the entire server bundle again.
Each floating license can be assigned to only one deployment at a time; if a multi-seat floating license needs to be divided across deployments, split it in the portal first, then assign each resulting license to the appropriate deployment. Floating licenses can also be released from one deployment and reassigned to another. This lets you decide exactly how to distribute your floating seats across as many self-hosted deployments as your environment needs.
Special thanks to the following open-source contributors whose PRs were merged into this release:
We appreciate your contributions!
abs, min, and max IL instructionsbswap, popcnt, clz, ctz, cls and rbit instructionswmain to analysis.mainFunctionDetection.mainSymbols so navigate-to-main also finds wmainFrameProceduresp-based locals during PDB importpvs tooltip across all ILsBiDiReferenceMap and used it for the code, data and type reference indices, unifying their previously separate forward and reverse halvestypedefsclz(x) u>> log2(W) to x == 0 in HLILphi expression mappingsx86_64original_filename purge option not clearing identifying information from the display_name and virtual path fieldsx86_64 symbols that were previously left unresolvedlea that produced bogus comparisons like this != -0x10adds instructionsFind in HLIL missing matches when HLIL line addresses are non-monotonicGetTypeForAccess returning incorrect fragments for struct accesses spanning multiple fieldsDefaultLiftFunction and CheckForInlinedCall when lifting deeply nested inlined callsAddDataReferences that could crash due to a missing lockPossibleValueSetsstruct bit field member offsets during PDB importUnsignedRange values when both start and end overflowPVS rangesBinaryViewRef when GetViewOfType raced with view removalVariables that could not be represented in their compact internal representationvoid data variables at call targets that had not yet been typed/d2FH4 flagMLIL_STORE_STRUCT_SSA__chkstk and other compiler-inserted functions in PE binaries0typedefstypedefs during normalizationerr family of libc functions as noreturn in the type library, preventing bad disassembly after calls to themIsELFDataRelocation for armv7 by using a switch instead of std::mapSymbolQueue consumersDataRenderer instancesCreate Struct Member at Offset to the Type ViewProject BrowserSnippets.bntheme files? as a full-byte wildcard in FlexHex searchwmain to the list of entry point names recognized by the navigate to main settingProject/File.exe)Display As and type toggle behavior in the UIUIAction aliasesclassic themeViewFrame::navigate unconditionally raising and activating the window, causing focus to be stolen when reverting an undo actionHLIL_IMPORTundetermined even though the correct values were availablesetHighlightTokenOptionsDialog view sort comparatorResource dropdown to list each open tab separately instead of collapsing tabs of the same file into one entryWorkflow view incorrectly accepting navigation requests it couldn’t handle, preventing it from acting as a catch-all navigation sinkCreate Types from C Source dialogVRHADD and VRECPE, and fixed SBC immediate handlingarmv8 support to the free versionocteon MIPS architectureC-SKY v2 architecture and fixed recognition of big-endian M-CORE binariesZba, Zbb, and Zbs bitmanip extensions and WCH instructionsaarch64 instructionsvcvt.f64.s32 and vmov.f64 instructionsx86/x86_64 ELF ABIARM64_RELOC_BRANCH26, ARM64_RELOC_GOT_LOAD_PAGE21, and ARM64_RELOC_GOT_LOAD_PAGEOFF12 relocations on aarch64NDS32 architectureZbs single-bit bit-manipulation instructionsZba address-generation instructionsZbb bit-manipulation instructions for RISC-VZbb instructions for the RISC-V architectureMIPS R5900IT blocks with trailing conditional branchesabs instructions during lifting for the csky architectureabs, min, and max instructions during aarch64 liftingabs, min, and max instructions when lifting Hexagon codeabs, min, and max instructions when lifting nds32 codebswap, clz, and rbit instructions during lifting for armv7bswap, popcnt, clz, ctz, cls, and rbit instructions directly during lifting on aarch64 instead of using intrinsicsbswap, popcnt, clz, and ctz instructions during x86 liftingThumb, and NEON lifting coverage for the ARMv7 architectureMIPS n32 ABI supportdefaultarch inlining to detect registers set to the caller’s return address and treat jumps to them in the callee IL as returnsMIPS R5900octeon and n32 MIPS ABIsabs, min, and max instructions for the tricore architectureTriCore instructions added in the 1.8 architecture revisionthis parameters in GNU3-mangled symbolsZbb bitmanip lifting to use first-class LLIL operations for min/max, clz/ctz, and popcountaarch64, armv7 and x86 lifting to emit new bitwise operation IL instructionsAArch64 Linux0000 in RISC-V disassembly to work around a binary parsing issuevcvt lifting and added support for lifting scalar vabs directly when lane and register widths matchIT conditional block analysis so subsequent instructions like b are correctly recognized as conditionalrev instruction lifting that lost the initial most-significant byte.gnu_debugdata being created as ARM functions instead of Thumb-2rv32gc_wch to match the existing RISC-V architectureIT instruction info in the Thumb2 architectureBFI and BFC on ARMv7ANDN/PANDN/VPANDNFMOV immediate on aarch64pop r16 on x86MOVSS lifting to zero-extend the memory-source formLHA instruction encoding on TriCorelwpc and restore.jrc lifting for nanoMIPSBinaryView leak in VxWorksViewType::IsValidForDataoperator+ overloads on basic_stringCFString in Mach-O binariesGOT entry outside valid memory regionsCALLI variant in the TriCore architecture added in 1.8x64 platform view initialization on WindowsPPC32 and thumb2 type libraries and added an API to remove alternate namesHexagon functions with Exceeds 'analysis.limits.maxFunctionUpdateCount' errorsGNU3 demangler0000 trap instructions that some compilers insert after jumpsARM64_RELOC_GOT_LOAD_PAGEOFF12 and ARM64_RELOC_GOT_LOAD_PAGE21 relocations for aarch64Intel Hex filesIT instructionsLLIL_JUMP(reg) as an inline return when the callee uses a nonstandard return registerpop with segment registers on x86JAL on RISC-V by properly setting the return registerMOVSS and ANDN on x86sbc.s on ARMv7 so the overflow flag is computed instead of left unimplementedARMv7TriCore disassembly operands for instructions added in 1.8sh2add instructionARM/Thumb2 function platform for .gnu_debugdata symbolsARMv7 lsl.s instructionx86 floating point instructionsvld1, vst1, vldmia, vstmia, umaal, and clrexR_RISCV_RELAX relocations on RISC-VC, P, A, and O flags for sbb.d, lsr.d, and.b, and xor.d instructions_exit as non-returning for iOS Thumbabort and other noreturn functions as __noreturn on Apple platforms to prevent them from appearing to fall throughKernelCache workflow activity to rename stubs in __auth_stubs sections based on their target symbol nameobjc_msgSend stub functions, helping with stripped binaries such as macOS 27BinExport command to all paid product versionsTriageTablePanel, adding asynchronous loading, filtering, and sortingKernelCache context menu actionsKernelCache to make it easier to obtain segment boundsbinexport pluginbndb extracted from a container being parsed as Raw/Mapped instead of restoring the analyzed databaseLoad /usr/lib/libFoo.dylib context menu action in the Dyld Shared Cache view to resolve cross-image stub functions to their target imageobjc_msgSend$stub functions incorrectly appearing in __objc_stubs on iOS/macOS 27 shared cachesUTF8 CFStrings in the Objective-C analyzer__auth_stubs in the kernel cache for iOS 27 / macOS 27objc_msgSend calls, preventing users from refining inferred types to account for variadic argumentsnull pointer crash in the plugin install APIPATH when resolving native dependencies like clangplugin_status.json is invalidplugin install API to default to the latest version\n newlines in its JSON outputInstall Python Dependency action hanging the UI by running pip installation as a background taskAuthenticateWithToken API for Enterprise to authenticate directly with a tokenProject Browser, similar to macOS Finder or Windows ExplorerVersionInfo type instead of a plain string.bndb before an initial snapshot has been pushedBNSimplifyDemangledTemplateName APIStringRecognizer APIUnknown() and IsUnknown() builder functions to Unimplemented IL across LLIL/MLIL/HLILUIAction aliases__typeof__ and decltype to the Clang type parserextraSearchableText for UI actions, allowing plugins to namespace their command-palette entriesclang compiler flags when creating BNTLsOnTokenDoubleClicked notification hook to UIContextNotificationBNDemanglerConfig and BNDemanglerResult) with unified demangle and template-simplification functions, replacing the legacy demangler entry pointsLicense tab and license text field to the APIBinaryView field to LinearDisassemblyLinereason field to MLIL_FORCE_VER for use in automated variable splittingVersionInfoDominatorTree for walking immediate dominatorsDataRendererContainer::RenderLinesForData as a replacement for the DataRenderer::RenderLinesForData member functionPyInitConfig based Python initializationDataBuffer implicitly convert to std::spanDefaultWebsocketClient::connect asynchronous instead of blockingDemanglerConfig/DemangleResult C API, with structured template simplification supportNotImplemented in Architecture patch methods with default values or errorsisAuto parameter of BinaryView::StoreMetadata to allow persisting metadata without marking the file as modifiedbnpython3 to read from stdin when the input file is -BNLicenseAddonMetadata object comparisons to use BNMetadataIsEqualFunction.set_user_inline_during_analysis raising a TypeError instead of setting the valueGetSystemCacheDirectory to use the documented pathsLowLevelILFunction::AddOverflow to store its operands in the correct fields of the expressiondemangle_ms returning invalid types and mishandling attributes for vftables, multiple inheritance, and parameterless functionsMenu instancesMake Enum storing concrete types instead of named type referencesMetadata::operator== to perform a value comparison instead of a pointer comparisonSESSION_COUNT not incrementing when cloning a Session_inline_during_analysis_with_confidence not converting InlineDuringAnalysisWithConfidence in the Python APIcopy_expr_to and added builder methods for recently-added instructions in the Python APIArchitecture or ArchitectureHook multiple times in PythonNameError in get_block_lines caused by referencing an undefined instr variable instead of blockBNParseExpression errors weren’t freed with BNFreeParseErrorIsSSAVarLiveAt for MLIL SSA that caused incorrect liveness resultsFileContext current frame during closeuint64_t values greater than INT64_MAXunicode.h__del__ on StructureType, EnumerationType, and NamedTypeReferenceType during Python interpreter shutdownmodules parameter when passed as either a list or a stringDemangler in the Python API@@@get_default_load_settings_for_data, which was referenced in example code but never implementedBinaryView handlesloader.syntheticSectionBase writable instead of read-onlyexcept: clauses with except Exception: in the Python API to fix signal propagationFlowGraphLayout and accompanying APIs for custom flow graph layouts to the Rust APItransform module to the Rust APISettings handles in the Rust APIBinaryViewExt trait and its blanket impl from the binary_view moduleBinaryViewBase::save to save raw file contentsActivity::new_with_action in the Rust API storing a stack pointer to the callback closure, causing use-after-free when the closure captured variablesload_with_options_and_progress to correctly accept None for optionsFunction::set_int_display_type in the Rust APIRef<T> in collaboration project function signatures in the Rust APIMediumLevelILInstruction::lift that could cause a crash or incorrect data being readsave bindings for custom binary viewslibdbus from the Rust secrets providerSettings::new to Settings::global in the Rust API to remove a foot gundebugger.useMemoryMapSegments setting by defaultDebuggerController reference leak caused by AttachProcessDialognull pointer crash in DebuggerUI::CreateForViewFrame when UIContext::contextForWidget returned nullstrdup memory leak in GetPathBaseNameDecodeRLE)DebuggerController being freed while detached worker threads for Launch/Attach/Connect/Go/Step*/RunTo*/Restart/Detach were still runningCorelliumAdapter::BreakInto when m_rspConnector is nullWindowsNativeAdapter destructor when a debugged process exits on its ownDbgEngAdapter::ReadMemory and WriteMemoryEsrevenAdapter::GetProcessListm_rspConnector in WriteMemory and TTD call querynullptr checks on returns from the LLDB APIRelease() loop from the DbgEng adapters’ Reset()Forget This File and Remove From Recent FilesLLIL statesMH_FILESETmultitool.py file download example to actually save the downloaded filegccjsoncpp into a separate namespace when built as part of core, allowing it to be included in statically linked buildsBNTL commands root to Type Library3.10LLVM 22.1.8 and raised the minimum supported Python version.pyc files in the system cache directoryZstd decompression of files with multiple concatenated framessys.executable not being properly set for bnpython3settings.jsonRunGuard teardown and the URL handler threadprintf-style logging callsvirtualenv path settingBNPathExists, BNIsPathDirectory, and BNIsPathRegularFile when the filesystem operation throws an exceptionWith such a large release, we’ve done more than even the list shown here. For even more details, check out our closed milestone on GitHub.