C++
C++ security review
C++ is a systems language used for node clients, consensus engines, and wallets that read untrusted blocks and peer traffic. Hackerbane audits that code for memory bugs and for integer bugs that can split a network.
scope
What we review
We audit C++ node software: the client that accepts a block, consensus and fork handling, and the wallet or daemon that holds a key. A contract review does not cover this. We look for a parser a peer can reach, an integer wrap that two nodes compute differently, and an RPC that can halt the process.
Parsers that read untrusted blocks, transactions, or peer messages into C++ objects and buffers.
Memory bugs and integer wraps (overflows) in consensus or key-handling code, including bugs that make two honest nodes disagree.
RPC and admin calls that can halt, stall, or reconfigure a running node.
Build flags and dependencies that change what is actually linked and run.
Threads and object lifetimes that free memory another path still reads.
Advanced Threat Detection
We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.
How we review this language
A C++ review follows the same five-stage engagement as every Hackerbane audit. For node software we spend that time on memory safety, the parsers a peer can reach, integer handling in consensus, and who can call RPC.
Two senior engineers read the client in parallel. Sanitizers and fuzzers run against the parse paths a peer controls, and static analysis covers the rest of the tree. A crash under a sanitizer is a finding, not a flake.
Scope and threat model
We lock the client, the commit, the network, and which RPC and admin calls are in scope, including who can halt or reconfigure a node, before the review starts.
Architecture and design review
We read the peer, parser, and consensus design against that model to find the flaws a line-by-line pass would miss.
Hybrid code and infrastructure review
Two senior engineers read the C++ in parallel, backed by static analysis, sanitizer builds, and fuzzers driven at the parse paths a peer controls.
Exploitability and root-cause analysis
High and Critical findings ship with a reproducer under a sanitizer and the root cause, so the class of memory bug gets fixed, not only the instance.
Reporting and remediation
A prioritized report, a live walkthrough, and verification of every in-scope fix within the remediation window.
Tools and practices
We work in the build you already ship. CMake, Bazel, or a makefile keeps its layout. We add sanitizer builds and fuzz harnesses on the untrusted parsers, then hand those artifacts back with the report.
What you get
Prioritized findings your engineers can ship against, each with root cause and a recommended fix.
Reproducers for High and Critical issues, runnable under a sanitizer.
A report you can share with partners, operators, and downstream integrators.
Remediation verification and a final report that reflects the fixed state of the client.
The fuzz harnesses and sanitizer configuration used during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | The client builds cleanly from a fresh checkout with the flags you run in production. |
| 02 | The codebase is stable, with no major refactor planned mid-audit. |
| 03 | Architecture, consensus assumptions, and the RPC and admin calls are documented. |
| 04 | The parse paths a peer can reach are identified, and known limitations are written down. |
| 05 | Scope is defined: which module, which commit, and which build configuration. |
Other pages
Questions
- Do you review the node client, not just the contracts?
- Yes. A contract review does not cover the client that accepts the block. If you run or fork a node, we read the parse paths, consensus handling, and who can halt or reconfigure the process.
- Which sanitizers and fuzzers do you use?
- We build with the address, undefined behavior, and memory sanitizers where they apply, and drive the untrusted parsers with coverage-guided fuzzing. The exact set depends on your platform and your clang or gcc version.
- What about the build flags?
- They are in scope. A release build can link different code than the tree we read, so we confirm what actually ships and review that configuration.
Next step
Request an audit
Share the repository, the client or module in scope, and your timeline. We will propose an audit plan and estimate. CMake and Bazel trees build as they are.