Skip to content

Instantly share code, notes, and snippets.

@sgInnora
Created April 17, 2026 11:52
Show Gist options
  • Select an option

  • Save sgInnora/23092dcb2237de0f2ff331b031b815b3 to your computer and use it in GitHub Desktop.

Select an option

Save sgInnora/23092dcb2237de0f2ff331b031b815b3 to your computer and use it in GitHub Desktop.
Innora Security — Independent Blockchain Security Research Portfolio

Innora Security — Independent Blockchain Security Research

About

Innora Security provides independent security research and audit services for Web3 infrastructure, smart contracts, and hardware wallets. Founded by Feng Ning (CISSP), founder of Innora.ai and an early Chinese security researcher now based in Penang, Malaysia, our work starts from attacker-controlled assumptions: low-level systems vulnerability research, economic invariant analysis, and high-throughput fuzzing.

We value reproducible evidence over opinion. Our work spans the blockchain stack, from node infrastructure and hardware signing devices to high-value DeFi protocols. Our working rule is simple: No code is done until it is committed, documented, and fully reproducible.

Recent Findings

Our track record focuses on technical root causes, edge-case logic, and reproducible attack paths across the blockchain ecosystem.

1. Saturn Protocol — Vault Accounting Edge Cases

Date: 2026-04-14 | Status: Publicly disclosed (DeFiHackLabs PR #1035, open) | Target: ERC4626 Vault (~$35.7M TVL at time of report)

  • SAT-001 — Withdrawal freeze up to 30 days: Identified an arithmetic underflow path where strcBalance < unvestedAmount can cause a Solidity panic and freeze withdrawal processing.
    • Vendor response: The team noted a mitigating check exists. We believe the edge case remains valid under specific sequencing; discussion is ongoing.
  • SAT-002 — 33.33% extraction via tolerance parameter: Identified a conversion path where toleranceBps = 2000 can compound across price and amount checks.
    • Vendor response: Classified as a trusted-role design observation. The parameter value was verified at the time of disclosure.

2. imKey Pro / imToken — Hardware & BLE Surface

Date: 2026-04-17 | Status: Reported; coordinating disclosure | Target: Wallet Infrastructure

  • V1 — TSM API information disclosure: Identified an unauthenticated TSM information-disclosure path exposing device metadata such as applet versions, device identifiers, and SDK modes. Testing against a limited candidate set confirmed valid device exposure.
  • V2 — BLE proximity denial of service: Found that an adjacent attacker can write malformed data to an exposed FTSAFE GATT characteristic without pairing, causing the secure element to stop responding until the BLE session is reset. Impact is strictly localized DoS; there are no funds at risk, and PIN-locked devices are immune.
  • V3 — Rate limiting: Identified insufficient infrastructure-level rate limiting in the identity verification flow.

3. Mezo Finance — Lending Logic Issue

Date: 2026-04-15 | Status: Reported to security@mezo.org | Target: Mezo Finance Lending Flow

  • Borrowing capacity update failure: Reported a lending logic issue where maxBorrowingCapacity does not update after addColl() is called. A user’s borrowing capacity remains tied to the previous value despite supplying additional collateral. A workaround exists through refinance(), but it incurs a 0.02% fee and may fail during protocol Recovery Mode. The impact is degraded functionality and capital inefficiency.

4. Base Node — Configuration Security Review

Date: 2026-04-15 | Status: Analysis complete; pending HackerOne submission | Target: Infrastructure Node Topology

  • Conducted a private review of Base Node deployment topologies. Identified hardening issues involving JWT handling, exposed pprof, OP Node RPC binding, and local permission configuration. Attackability depends on additional network exposure or pivot conditions. Technical details are withheld pending vulnerability disclosure review.

5. Linux Kernel — Vulnerability Research

Date: 2026-04-15 | Status: Submitted upstream (LKML / linux-bluetooth v3) | Target: Core OS

  • Bluetooth L2CAP ECRED fix: Submitted a v3 patch to the Linux Bluetooth mailing list addressing a low-level ECRED channel teardown race. This systems-level work directly supports evaluation of validator environments, TEEs, and embedded signing devices used in Web3 infrastructure.

Technology

CuEVM-fast: GPU-Native EVM Fuzzing Engine

CuEVM-fast expands state-space exploration by moving EVM execution from CPU interpreters to custom CUDA kernels. The engine maps 43 core EVM opcodes directly to GPU execution, with coverage-guided mutation and a zero-copy memory pipeline. To handle state dependencies, it pulls chain state through RPC and reconstructs local memory mappings for parallel execution.

Measured Throughput: Standard ERC20 / DeFi Local-State Iterations

  • 7.8 million simulated transactions per second on a single NVIDIA H200.
  • 11 million+ simulated transactions per second across a four-H200 cluster.

In an internal historical evaluation against 20 real DeFi vulnerabilities across 9 protocols, CuEVM-fast reproduced the root-cause conditions and evaluated 2,148 candidate attack paths before manual deduplication.

Note: Raw execution throughput expands the searchable state space. It does not replace manual invariant design. Performance varies with protocol storage access patterns.

Services

Smart Contract Security Review

For DeFi protocols, vaults, bridges, staking systems, and custom financial logic.

  • Accounting and share-price invariants
  • Liquidation, borrowing, and collateral logic
  • Oracle assumptions and stale-price handling
  • Privileged roles and upgrade paths
  • ERC4626, AMM, lending, and reward-distribution edge cases
  • Deliverables: Executive summary, technical findings, Foundry PoCs, invariant recommendations, patch guidance, and retest summary.

Blockchain Infrastructure Security

For RPC nodes, validators, indexers, relayers, sequencers, and off-chain protocol services.

  • Exposed admin or debug surfaces
  • Key and token handling
  • Service-to-service authentication
  • Node and RPC hardening
  • Deployment configuration review

Wallet and Hardware Security

For signing flows, BLE surfaces, secure-element integrations, and wallet infrastructure.

  • BLE protocol behavior and DoS conditions
  • Secure-element command boundaries
  • Signing-path assumptions
  • Metadata exposure

Contact

Email: feng@innora.ai
X / Twitter: https://twitter.com/Innora_sg
GitHub: https://github.com/sgInnora

For technical diligence, request sample redacted reports, CuEVM-fast benchmark notes, disclosure references, or available audit windows.

Full Disclosure Reports

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment