C
C security review
C is a systems language used for crypto libraries, wallet cores, and firmware that holds keys. Hackerbane audits the C that parses untrusted input or is called from another language.
scope
What we review
We audit C that other teams have to trust: a crypto library they link, HSM firmware, or a parser a daemon exposes. Typical findings are a length taken from the caller, a key next to a scratch buffer, and a wrapper that drops an error the other language thought was already checked.
Buffer and lifetime bugs on untrusted input, including off-by-one and use-after-free.
Key material that shares a process, and often a struct, with a parser or a socket.
FFI wrappers and language bindings that drop a check or ignore a return code.
Build systems that compile or link a different file than the one we were sent.
Integer wrap on sizes, offsets, and allocations that C will not catch for you.
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. We do a line-by-line pass of the public API, the key store, and the FFI, and we run sanitizer builds and fuzzers on the parsers.
Two senior engineers read the code in parallel. We build with sanitizers, fuzz the parsers, and run static analysis on the public API. A crash under a sanitizer is a finding. Fixes get a retest before the final report.
Scope and threat model
We lock the library, the commit, the public API, and what a caller is trusted to do, including how it is expected to hold a key, before the review starts.
Architecture and design review
We read the public API and the boundary around key material, looking for design bugs 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 on the functions that read untrusted bytes.
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 use. A makefile or CMake tree keeps its layout. We add sanitizer builds and fuzz harnesses on the 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 the teams that link your library or call it through an FFI.
Remediation verification and a final report that reflects the fixed state of the code.
The fuzz harnesses and sanitizer configuration used during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | The library builds cleanly from a fresh checkout with the flags callers actually use. |
| 02 | The public API and its trust assumptions are documented, including how a caller should hold a key. |
| 03 | The functions that read untrusted input are identified. |
| 04 | The FFI wrappers and the checks each side expects are written down. |
| 05 | Scope is defined: which sources, which commit, and which build configuration. |
Other pages
Questions
- You publish a C library other teams link. Is that the review?
- Yes. Their callers inherit your bugs. We read the public API, the unsafe edges, and how a caller is supposed to hold a key.
- Do you review the FFI, or only the C?
- Both. A check that exists on one side and not the other is a common miss. We read the C, the wrapper, and what each side thinks the other already did.
- What if the build compiles generated or vendored sources?
- We review what actually compiles and links. If the build pulls a generated file or a vendored copy that differs from the tree you sent, that is the code in scope.
Next step
Request an audit
Share the repository, what the C process is trusted to do, and your timeline. We will propose an audit plan and estimate. Makefiles and CMake trees build as they are.