new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Solana & Anchor Auditor · all subjects

Tooling and audit workflow

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

What does cargo-audit catch in a Solana codebase?

`cargo audit` (RustSec advisory DB) flags known-vulnerable dependency versions — for Solana work the high-signal hits are `solana-program`, `anchor-lang`/`anchor-spl`, `spl-token`/`spl-token-2022`, and borsh versions with deserialization advisories. Historical example: older `solana-program` versions lacked sysvar owner hardening; old anchor versions predate the `init_if_needed` reinit fix (0.25) and various discriminator/close fixes — pinning a stale anchor is itself a finding. Also run `cargo deny` for license/ban checks and check `Cargo.lock` is committed (programs are deployed from lockfiles; a floating dep means the on-chain build may differ from the audited one). Limit: cargo-audit knows nothing about YOUR logic — it catches maybe 5% of real Solana findings. Treat it as hygiene gating CI, and pair with `solana-verify` / verifiable builds to confirm the deployed binary matches audited source.

How do you fuzz a Solana program with Trdelnik or Trident?

Ackee's fuzzing tools are the Solana-native options as of early 2026: Trdelnik (older, built on anchor-client + honggfuzz) and Trident (newer, actively developed, AFL/libfuzzer-backed with account-state-aware fuzzing). The value is NOT random input throwing — it's INVARIANT-DRIVEN: you declare properties ("sum of all vault token balances >= total shares * rate", "no instruction sequence decreases admin balance without admin signature", "PDA X can only be initialized once") and the fuzzer sequences random instruction calls with realistic account snapshots to violate them. Trident can derive account contexts from your Anchor IDL, dramatically cutting harness-writing time. Practical setup: extract pure logic into a testable crate, write invariants as Rust functions over account state, run fuzzing in CI with corpus persistence. What fuzzing finds: arithmetic edge cases, unexpected instruction orderings (init-close-reinit), and duplicate-account aliasing you didn't model.

How do you write a PoC exploit with solana-program-test and banksClient?

`solana-program-test`'s `ProgramTest` spins up an in-process BPF runtime — the standard PoC harness. Skeleton: `let mut pt = ProgramTest::new("my_program", program_id, processor!(entry));` — then `pt.add_account(attacker_pubkey, Account { lamports, owner: system_program::ID, .. })` to stage the attacker's fake accounts (this is where you prove the owner-check bug: you fabricate the malicious account the runtime would let through), add real mints/token accounts via `spl_token` instructions in a setup tx, then `let (mut banks_client, payer, recent_blockhash) = pt.start().await;` and send your exploit `Transaction` signed with chosen keys, asserting post-state. For a finding writeup, the PoC must show: vulnerable instruction called with attacker-controlled accounts, state before/after, and value extracted. Faster modern alternatives: LiteSVM (in-process SVM, much quicker than program-test) and Mollusk (Anza's minimal harness) — both fine for PoCs as of early 2026.

What does anchor's built-in checking NOT cover?

Anchor's account constraints eliminate maybe 60% of historical Solana bug classes (owner, discriminator, seeds, signer-as-type) — auditors must know the residue. Anchor does NOT check: business-logic invariants (share math, fee rounding, liquidation health); duplicate mutable accounts unless you write the inequality constraint; that a token account's MINT is the expected one (type only proves "a token account"); remaining_accounts at all; CPI program targets beyond typed `Program` fields; oracle freshness/confidence; overflow inside your `#[program]` logic (profile flag aside); Token-2022 extension behavior; and cross-program state composition. Also note `anchor build` runs the IDL generation and `cargo check`-level lints, and `anchor test` defaults to local validator — none of this simulates adversarial account sets. Workflow: after the constraint-layer review passes, switch to attacker-model review assuming every account not address-pinned is hostile.

What does manual review catch that Solana tooling misses?

Every tool above operates below the business-logic layer; the highest-severity Solana findings are usually economic/design bugs no linter knows about. Manual-review checklist that consistently pays: (1) value-conservation invariants per instruction — where does every lamport/token unit enter and leave; (2) permission matrix — who can call what, and what can a compromised but legitimate key do (centralization findings); (3) economic attack modeling — oracle manipulation cost vs extractable value, flash-loan-funded sequences (Solana's atomic multi-instruction txs make single-block composability attacks free of execution risk); (4) cross-program trust — what breaks if an integrated program (Saber-style LP, Pyth, another vault) is malicious or manipulated, per Cashio; (5) spec-vs-code drift — docs promising "only admin can pause" while seeds allow anyone to derive the pause authority. Write invariants BEFORE reading code, then hunt violations.

How do you verify the deployed program matches audited source?

Solana programs are upgraded BPF blobs; source-to-binary divergence is a real attack path (malicious upgrade, compromised CI). Verification stack as of early 2026: use `solana-verify` / Ellipsis verifiable-build tooling, which rebuilds from source in a pinned Docker image and compares the resulting binary hash against the on-chain program account — OtterSec's explorer surfaces this status publicly. Check too: `upgrade_authority` on the program data account (is it a multisig/governance, an EOA, or burned — `set-upgrade-authority --final` for immutable programs); whether `ProgramData` upgrade history shows upgrades AFTER the audit commit; and `solana program show` buffer accounts lingering with authority. For Anchor programs, `anchor verify` wraps the flow. Report finding shapes: unverifiable build = informational-to-medium; unverifiable + live upgrade authority on a hot key = high centralization risk.

Give your agent this brain