Release notes

LABS351 Changelog

Technical changes and platform evolutions across LABS351 releases.

LABS351 3.5.3 · Search, Navigation and Extraction

Symbol Search and Navigation to Decoded Code

LABS351 3.5.3 will extend search and navigation capabilities to directly connect symbols, project sources and decoded machine code.

Source search will identify occurrences of a symbol in the current document or across all files in the VFS, making it possible to locate multiple occurrences and duplicate symbols.

From the symbol view, navigation to the disassembly will rely directly on the symbol address obtained from binary analysis. LABS351 will locate the corresponding code section, find the associated instruction and automatically position the view on the page and line containing the symbol.

Source and VFS Search

Search for a symbol in the current document
Search across all files in the VFS
Identification of multiple occurrences of the same symbol
Detection of duplicate symbols across project sources
Clear distinction between source search and navigation within the analyzed binary

Symbols → Disassembly Navigation

Direct navigation from the symbol view to decoded machine code
Symbol localization within its .text or __text section
Symbol address lookup within decoded instructions
Automatic selection of the corresponding disassembly page
Automatic positioning on the instruction associated with the symbol
Visual selection of the instruction corresponding to the symbol address

Extraction from Disassembly

LABS351 3.5.3 will also introduce contextual actions for extracting a selection cleanly from the disassembly view.

Extraction will operate directly on the decoded instructions associated with the selected lines, independently of their representation across the different interface columns.

Copy disassembled instructions
Copy addresses and instructions
Extract opcode bytes
Copy a complete representation of the selected disassembly
Preserve decoding information independently of the table presentation

Planned version

LABS351 3.5.2 · Symbol Analysis and ABI Validation

Multi-format Symbol Analysis

LABS351 3.5.2 extends native symbol analysis for ELF, Mach-O and PE/COFF binaries while preserving the semantics specific to each executable format.

Symbol origin, binding and section association are now exposed more precisely, while C++ symbol names are normalized and demangled for display.

BinaryAnalyzer also identifies a candidate symbol directly from the symbols present in the analyzed binary. The selected symbol is visually identified in the symbol view.

Symbol Analysis — Technical Summary

Analysis of ELF symbol tables .symtab and .dynsym
Distinction between dynamic and regular ELF symbols, including local, global, weak, imported and undefined bindings
Native classification of local, external and imported Mach-O symbols
Classification of PE/COFF symbols, exports and imports
C++ symbol demangling and display normalization
Automatic detection of a candidate symbol from the analyzed binary
Visual identification of the selected symbol for ELF, Mach-O and PE/COFF

SIMD/FP Register ABI Validation

LABS351 3.5.2 extends runtime ABI validation to non-volatile SIMD/FP registers that must be preserved by the called function.

This extends the existing general-purpose register (GPR) validation. LABS351 can now simultaneously detect a violation affecting a general-purpose register and a violation affecting a SIMD/FP register.

On ARM64/AAPCS64, validation covers the lower 64 bits of registers V8 through V15. On Windows x86-64 using the Microsoft x64 ABI, it covers all 128 bits of registers XMM6 through XMM15.

When a violation is detected, the affected register is identified in the ABI diagnostics and visually highlighted in the NEON or XMM register view. The existing ABI status now incorporates both GPR and SIMD/FP violations, while stack validation remains independent.

V8–V15 — validation of the lower 64 bits on ARM64/AAPCS64
XMM6–XMM15 — validation of all 128 bits on Windows x86-64 / Microsoft x64
Simultaneous detection of GPR and SIMD/FP violations
Identification of affected registers in ABI diagnostics
Visual highlighting of registers in violation in the NEON and XMM views
Stack validation remains independent from register state

Current version

LABS351 3.5.1 · ARM64 / AARCH64

Extended ARM64 Runtime Introspection

LABS351 3.5.1 extends ARM64 runtime introspection with complete capture of the 32 architectural 128-bit SIMD/FP registers, from V0 through V31.

NEON register contents can be inspected as raw 128-bit values and through typed representations, including integer, Float32, Double64 and ASCII views.

Floating-point runtime state has also been extended with dedicated FPSR and FPCR capture and decoding. Exception status, floating-point controls and the active rounding mode are exposed directly in the register inspector.

Runtime capture

V0–V31 — 32 × 128-bit SIMD/FP registers
FPSR — Floating-Point Status Register
FPCR — Floating-Point Control Register
NZCV — condition flags
Typed SIMD interpretation
Independent ABI and stack validation

LABS351 ARM64 NEON V0 to V31 register inspection with typed representations — NEON register inspection — ARM64 128-bit SIMD/FP registers can be inspected as raw values or interpreted through multiple data representations.

LABS351 ARM64 FPSR and FPCR floating-point state inspection — Floating-point state inspection — FPSR status flags and FPCR control fields, including the active rounding mode, are decoded directly from the captured ARM64 machine state.

PE/COFF — section analysis and export control

LABS351 3.5.1 refines PE/COFF binary handling by distinguishing the virtual size of a section from its physically aligned size in the file.

For PE sections, the debugger now takes VirtualSize into account when it is smaller than SizeOfRawData. Alignment padding present in the file is therefore no longer passed to the decoding engine as if it belonged to the useful virtual area of the section.

This change is strictly limited to the PE/COFF format and does not modify ELF or Mach-O section handling.

Symbol export control

LABS351 3.5.1 also introduces explicit control over the symbol export policy when generating shared libraries.

A new project option allows automatic export directives generated by LABS351 to be enabled or disabled. When disabled, the native behavior of the selected linker is preserved. When enabled, LABS351 explicitly generates export directives for eligible global symbols.

PE/COFF — technical summary

VirtualSize is now taken into account when decoding PE/COFF sections
Padding associated with SizeOfRawData is excluded when it exceeds the virtual size
No changes to ELF or Mach-O handling
New project option for automatic export of global symbols
Ability to preserve the linker's native export behavior
Comparative validation of PE/COFF export parsing against GNU objdump

Version 3.5.1