SIREEN · FORGE-BACKED SECURITY WORKBENCH
Prove
The Exploit.
Turn a Solidity suspicion into a reproducible PoC. Forge verifies it. Evidence proves it.
LOCAL · FORGE-BACKED · PROPRIETARY
1// SPDX-License-Identifier: MIT2pragma solidity ^0.8.19;3 4contract Vault {5 mapping(address => uint256) public balances;6 7 function deposit() external payable {8 balances[msg.sender] += msg.value;9 }10 11 function withdraw() external {12 uint256 amt = balances[msg.sender];13 (bool ok, ) = msg.sender.call{value: amt}("");14 require(ok);15 balances[msg.sender] = 0;16 }17}
SUSPICIOUS LINE FLAGGED
withdraw() sends value before it updates state:
- 1FIRST
msg.sender.call{value: amt}("")external call executes first — value leaves the vault - 2TOO LATE
balances[msg.sender] = 0state update arrives after — the balance is still spendable
- ENTRYwithdraw()Vault.sol
- CALLmsg.sender.call{value: 10 ETH}value sent out first
- CALLBACKreceive() external payableattacker contract
- RE-ENTERwithdraw()balance not yet zeroed — passes
- DRAINrecursive withdrawal loopvault emptied in one transaction
1// generated by SIREEN — attack path compiled into a test2function testExploit() public {3 address exploiter = makeAddr("exploiter");4 vault.deposit{value: 10 ether}();5 vm.prank(exploiter);6 exploiter.attack(); // re-enters withdraw()7 assertEq(address(vault).balance, 0, "vault drained");8}
$forge test --match-test testExploit
[compile] 2 files · solc 0.8.19
[compile] done in 1.9s
PASS testExploit() (gas: 84 213)
RUNS1 executed · 1 passed · 0 failed
VAULT BALANCE AFTER TEST EXECUTION
10 ETH→0 ETH
assertion held — address(vault).balance == 0
sha256:9f2c…e41a
testExploit()
PASS · 1/1
held
10 ETH → 0
--match-test
F-042 · REENTRANCY · VAULT.WITHDRAW()
- FORGE EXECUTED
- ASSERTION HELD
- EVIDENCE SEALED
Nothing became CONFIRMED because a model said so.
WHY SIREEN
- AI REASONINGis not proof.
- A POCis an attempted demonstration.
- FORGEprovides independent execution evidence.
- EVIDENCEmakes the result reviewable.
SIREEN DOES NOT SAY “LOOKS SECURE.”
Every run ends in one of five verification states. Uncertainty stays visible.
- CONFIRMEDForge verified. Evidence complete.
- DEGRADEDVerification incomplete. Manual review required.
- UNVERIFIEDHypothesis only. Nothing has executed.
- FAILEDPipeline execution failed. No claim is made.
- CLEAN WITH COVERAGENothing found within verified coverage.
PLAIN ANSWERS
QUESTIONS PEOPLE ACTUALLY ASK.
Stated once here, in plain text, so the answer is the same wherever it's read.
What is SIREEN?
SIREEN is a Forge-backed security workbench for Solidity. A human states a specific attack hypothesis; SIREEN turns it into a proof-of-concept, executes it with Foundry (Forge), and produces evidence — instead of asserting a vulnerability from AI reasoning alone.
What does SIREEN verify?
Whether a proof-of-concept, executed by Forge against the target contract, reproduces the exploit a hypothesis describes. Every run ends in one of five states: CONFIRMED, DEGRADED, UNVERIFIED, FAILED, or CLEAN WITH COVERAGE — see above.
How does SIREEN use AI?
AI assists in reasoning about a hypothesis and in drafting the candidate proof-of-concept. AI reasoning is not treated as proof — only an executed Forge test that holds its assertions can move a finding to CONFIRMED.
Does SIREEN use Foundry?
Yes. SIREEN executes every proof-of-concept with Foundry's Forge and reports the real compile and test output; nothing is marked CONFIRMED without a Forge run.
Can SIREEN generate proof-of-concepts?
Yes. SIREEN constructs an attack-path-driven Foundry test — a PoC — from the hypothesis, then runs it under Forge.
Is SIREEN open source?
No. SIREEN is proprietary software. The SIREEN source code is not publicly available.
Who is SIREEN for?
Security researchers and Solidity developers who have a specific hypothesis about a contract and want it tested with real execution evidence rather than a heuristic guess.
What does SIREEN currently support?
SIREEN Core v0.1 analyzes one selected Solidity file for reentrancy, access-control, and arithmetic issues. Oracle manipulation, flash-loan attacks, governance attacks, and repository-wide analysis are not yet supported — SIREEN states this directly rather than implying broader coverage.
How is SIREEN different from traditional smart-contract auditing?
Traditional audits and static analyzers typically report a list of suspected issues. SIREEN instead requires each hypothesis to run in Foundry and produce an executed-evidence pack — source, PoC, Forge output, assertion result, and a sealed hash — before it can reach CONFIRMED, keeping AI reasoning separate from that verification step.
Where does SIREEN run?
Locally. SIREEN is local-first — your Solidity file never leaves your machine. This page's demo is a static visualization of a local run, not a live service call.
SMALL SCOPE · STRONG EVIDENCE
BUILT NARROW ON PURPOSE.
One selected Solidity file. SIREEN Core v0.1 would rather say “not yet” than pretend.
SUPPORTED
- Reentrancy
- Access control
- Arithmetic
NOT YET
- Oracle manipulation
- Flash loans
- Governance
- Repository-wide analysis
LOCAL-FIRST · FORGE-BACKED · PROPRIETARY
YOU SAW THE PROOF.
NOW RUN IT YOURSELF.
Run SIREEN on your machine. Your code stays local.
Setup commands live in the repository README. Nothing on this page executes anything — the investigation above is a demo visualization of a local run.