Fully Autonomous End to End Exploitation of a Privacy Protocol Using AI and Glider

The following article demonstrates how researchers at SC Audit Studio managed to fully autonomously exploit a smart contract vulnerability using LLMs and Glider, that would have allowed a complete compromise of a privacy protocol.

Discovery

A typical vulnerability discovery process generally involves the following three steps:

First: Reconnaissance This step involves identifying a target, gathering information about the systems in use, and mapping all valuable resources and assets.

Second: Testing and Exploit Discovery This phase involves testing different attack ideas against identified targets. Depending on the system, this step can be partially automated; however, most complex vulnerabilities still require human creativity.

Third: Proof of Concept (PoC) Once a vulnerability is discovered, a proof of concept is developed. This ensures that the vulnerability is impactful and exploitable. Afterward, a report is submitted to the affected organization.

Previously, steps one and two were difficult to automate. Static scanners cant reason about complex flows an while LLMs have brought significant advancements in testing and exploit discovery, they often still lack the required depth. Reconnaissance has been partially automated for web research, but direct scanning tools for smart contracts are often not public, until 2025.

In 2025, the community program Remedy (part of Hexens) released a tool called Glider. Glider is a Solidity interpreter that allows developers to run Python tests against every verified contract deployed on a blockchain (e.g., Ethereum mainnet).

We decided to test this tool by exploring a known vulnerability in gnarkJS verifiers. The idea for the attack originated after the “Foom protocol” exploit, where $1.6M was lost.

The Vulnerability

A common use case of zero-knowledge (zk) proofs is the verification of off-chain data using cryptographic proofs.

At a high level, a zk setup involves a verifier contract deployed on a blockchain that ensures a proof was generated under strictly defined constraints.

For example, imagine a DeFi protocol that wants to verify a user’s deposit on another blockchain. To do this permissionlessly, the protocol allows users to generate zk-proofs of their deposits. These proofs can then be verified on a different chain using a verifier contract, typically generated by SnarkJS.

If this setup process is executed incorrectly, a Groth16 verifier may be generated where the γ (gamma) and δ (delta) elliptic curve G2 points are identical, specifically set to the BN254 G2 generator.

When γ = δ, the Groth16 trusted setup is fundamentally broken. The separation between γ (which binds public inputs) and δ (which binds the witness) collapses. This allows an attacker to forge valid proofs for arbitrary public inputs without knowing the underlying witness.

In our case, the protocol used this verifier to secure withdrawals from a privacy pool. Users could deposit funds, generate a proof, and later withdraw using that proof. However, due to the vulnerability, attackers could forge proofs and withdraw funds belonging to other users.

The Attack

Verifiers are implemented as an equation. The equation consists of different group elements (points on an elliptic curves) and pairing function. We do not need to understand these in depth for this attack, but to get more context, read more here.

e(A, B) * e(vk_x, γ) * e(C, δ) = e(α, β)

For a valid proof, this equation must hold.

The attacker proceeds as follows:

• Set A = α and B = β, causing part of the equation to cancel out.

e(A, B) * e(vk_x, γ) * e(C, δ) = e(α, β)

Leading to:

e(α, β) * e(vk_x, γ) * e(C, δ) = e(α, β) | divide by e(α, β)
e(vk_x, γ) * e(C, δ) = 1

This removes a key constraint. Now due to the incorrect setup, delta and gamma become the same value:

e(vk_x, γ) * e(C, γ) = 1

So in the next step we just need to recompute:

vk_x = IC0 + Σ(pubSignals[i] * IC[i+1])

This uses only public data, no private witness is required. After set:

C = -vk_x

This ensures:

e(vk_x,γ) * e(-vk_x,γ) = e(vk_x + (-vk_x),γ) | Due to bilinearity

e(vk_x + C, γ) = 1 | Set C as -vk_x
e(vk_x + (-vk_x), γ) = 1 | Reduce
e(0, γ) = 1

At this point, all components reduce to:

1 = 1

This condition always passes, allowing completely fake proofs with arbitrary public inputs to be accepted as valid.

In terms of the privacy protocol, this means we can forge a proof for a deposit that does not exist, withdrawing as many funds as we want.

Automating Everything

Earlier, we described three phases of exploitation. Glider significantly changes this process by automating much of the reconnaissance phase. Combined with recent advancements in AI-driven PoC generation, the only remaining human input is the high-level exploit idea.

The updated workflow becomes:

1. Define a vulnerable pattern
2. Perform end-to-end AI-driven exploitation
3. Generate a report

The verifier setup vulnerability is particularly well-suited for this workflow. It is essentially a configuration issue rather than a complex exploit, making it easy to detect via pattern matching.

Vulnerable contracts share consistent structural traits, making them ideal candidates for static scanning.

Example Workflow

1. Researcher: Defines the exploit idea
2. Machine: Writes a Glider test
3. Machine: Scans the blockchain and identifies multiple vulnerable contracts, including a recently deployed one
4. Machine: Generates a specific PoC and report for the target protocol
5. Machine: Collects additional metadata (e.g., Twitter, ENS, GitHub)
6. Researcher: Initiates contact with the protocol team
7. Protocol: Fixes the vulnerability

After discovery, we contacted a privacy application that fixed the issue immediately. At the time, the total value locked (TVL) was zero, so no funds were at risk. However, the TVL has since increased and would likely have been drained.

Based on periodic scans, we estimate that 1–2 vulnerable contracts are deployed each month. While many are test deployments or low-risk, this highlights that the issue remains a systemic risk.

Summary

The transparent nature of blockchains enables more effective use of modern tools for vulnerability discovery and exploitation.

Even unverified bytecode can often be decompiled and converted into readable Solidity using AI (a topic worth exploring separately).

Although tools like Glider are typically protected by strict KYC requirements, reducing the likelihood of misuse, the risk is not entirely eliminated.

Therefore, every blockchain project should prioritize:

• Thorough security audits
• Proper setup of cryptographic systems
• Compliance to best security practices before deployment

As a side note, privacy-focused blockchains do not inherently prevent large-scale scanning. While they may complicate reconnaissance, any code accessible to low-privilege users is ultimately public and analyzable.

About Us

At SC Audit Studio, we specialize in protocol security assessments. Our team members have worked with companies such as Aave, 1Inch, and many others to conduct in-depth security reviews.

Pioneers should not care about cybersecurity; we take care of it. Reach out to us