Research Overview

Formal research abstracts, future work, and publications for the Rothalyx Reverse Engineering Framework.

Publications

Rothalyx: A Native Shared-Core Framework for Multi-Surface Binary Analysis and Decompilation

We present Rothalyx, a native, cross-platform reverse engineering framework whose defining property is architectural: a single analysis core is consumed by the desktop application, command-line interface, C SDK, plugin system, and an optional AI insight layer, rather than being reimplemented per interface. The analysis pipeline lifts binaries (PE, ELF, Mach-O) through a normalized image and memory model, disassembly, function and control-flow recovery, IR and SSA transformation, analysis and type recovery, and structured decompilation, with runtime debugging integrated against the static representation and project state persisted to SQLite. We describe two security-oriented design commitments: an adversarial-input posture in which loader and trace parsers are validated by sanitizer-backed corpus fuzzing gated at release, and an optional AI layer designed as an untrusted, bounded component with normalized provider responses, OS-keyring credential storage, and heuristic fallback. We characterize the system as implemented at the v1.0.3 release line and explicitly delimit unmeasured aspects (benchmarks, decompiler-quality evaluation, and internal recovery heuristics) as future work rather than reporting unvalidated results.

Talks

One Core, Many Surfaces: Designing a Native Reverse Engineering Framework

Most reverse engineering happens across a fragmented toolchain, and the seams between tools are where analysts lose context and automation breaks. This talk presents Rothalyx RE Framework, a native C++ system built on the opposite premise: a single analysis core that powers the desktop app, CLI, SDK, plugins, and an optional AI layer. We walk the pipeline from loader to decompiler (PE/ELF/Mach-O loading, address-space mapping, disassembly, CFG recovery, IR and SSA, type recovery, decompilation, and debugger integration) and show how the shared-core rule enforces behavioral consistency across surfaces. We then focus on two security-relevant design choices: treating hostile input as the primary threat surface with sanitizer-backed corpus fuzzing gating releases, and treating optional AI as an untrusted, bounded component with OS-keyring secret storage and heuristic fallback. The talk is aimed at reverse engineers, tool builders, and offensive security engineers, and is honest about what is designed versus what is yet to be measured.

Future Work

• Broadening the support layer (expanding supported instruction sets beyond the documented layer).
• Expanding the fuzzing corpus categories beyond loader and trace.
• Quantifying decompiler and recovery quality.