Ruby Finds Unsafe Rust Regions in Stripped Binaries

Rust’s safety model narrows many memory-safety risks to code that opts out of compiler checks with unsafe, but that marker disappears once source code is compiled. Existing Rust bug-finding tools can target unsafe blocks when source is available; they are much less useful for third-party libraries, stripped executables, firmware components, or post-deployment binaries where the source-level annotation is gone. The authors introduce Ruby, a machine-learning system for locating likely unsafe regions directly in Rust binaries, then use those predictions to prioritize downstream bug-finding.

Core Contribution

The main contribution is a shift in where unsafe-Rust analysis can operate. Instead of treating unsafe as a source-code label that must be preserved, Ruby learns binary-level instruction patterns associated with code emitted from unsafe Rust. That matters because many practical security workflows begin with a binary, not a build tree: reverse engineering, supply-chain inspection, Android library analysis, and triage of stripped artifacts.

The paper’s claim is not that Ruby proves a binary region is memory-unsafe. It predicts regions likely to originate from unsafe Rust, which is a narrower and more operational target. The value is triage: if the prediction is accurate enough, symbolic execution and fuzzing can spend more time on code where Rust’s usual safety guarantees may not apply.

Technical Approach

Ruby treats the stripped binary as the input rather than relying on debug symbols or source annotations. The system captures subtle differences in binary instructions, then trains a model to classify regions as likely corresponding to unsafe or safe Rust. The available paper material frames this as the first tool aimed at unmasking unsafe Rust regions in binaries, rather than detecting generic memory bugs or classifying function signatures.

That distinction is important. Prior binary-analysis work often tries to recover functions, infer types, identify vulnerabilities, or guide fuzzing over C/C++-style targets. Ruby instead learns a Rust-specific semantic boundary that was explicit in source and erased during compilation. The paper positions this boundary as a useful proxy for where memory-safety bugs concentrate, since unsafe regions are where developers bypass checks that Rust normally enforces.

The downstream workflow is also part of the method. Ruby is not presented only as a classifier; its predictions are used to guide symbolic execution and fuzzing. In that setting, the classifier’s false positives are not merely a reporting issue. They affect compute allocation: too many false positives would dilute the search, while too many false negatives would miss the regions most likely to matter.

Results and Analysis

The headline result is a detection rate of 91.75% over total unsafe regions with a 6.16% false positive rate. For a security triage tool, that is a credible operating point: high recall is more valuable than perfect precision when the next stage is expensive analysis and the cost of missing an unsafe region is higher than inspecting an extra one.

The authors also compare Ruby against large language models named in the paper metadata, including GPT-5.2, Claude-4.5, and Gemini-3, and report that Ruby outperforms them on the unsafe-region identification task. The more meaningful comparison is conceptual rather than brand-based: a task-specific binary model appears to beat general-purpose code reasoning models when the source annotation is absent and the signal lives in compiled instruction patterns.

The downstream experiments are the stronger evidence for practical utility. Guided symbolic execution is reported to speed up by 57.95%, and guided fuzzing by 21.26%. Those numbers suggest the classifier is not just learning a dataset artifact; its predictions improve search efficiency in two different analysis workflows. The Android library fuzzing result is the most concrete security outcome: five bugs were confirmed and patched by Google. That moves the paper beyond offline classification metrics into real bug-finding impact.

Caveats

The evidence still depends on the representativeness of the binaries used for training and evaluation. A classifier trained on compiler-specific instruction patterns may be sensitive to Rust version, optimization level, target architecture, dependency mix, or changes in code generation. The reference pages show the paper situating itself against Rust compiler releases, unsafe-Rust studies, binary similarity, fuzzing, and vulnerability-detection work, which indicates the authors are aware of this interaction, but the generalization boundary remains the issue to watch.

There is also a semantic gap between “compiled from unsafe” and “contains an exploitable memory-safety bug.” Ruby is best read as a prioritization layer, not a bug oracle. Its reported 6.16% false positive rate is low enough to be useful, but every downstream deployment still needs a verifier such as symbolic execution, fuzzing, or manual audit.