DEV Community: Sandeep Kumar

Stopping LLM Hallucinations in Reverse Engineering: Meet Reverify

Sandeep Kumar — Fri, 04 Sep 2026 03:28:30 +0000

Large Language Models (LLMs) are changing how we write, debug, and understand code. But when you throw an LLM at compiled binaries, things get messy quickly.

If you’ve ever tried to use an AI agent to analyze malware, reverse-engineer a proprietary protocol, or solve a CTF challenge, you have likely run into the hallucination barrier. An agent will confidently assert that a specific function starts at 0x401120, uses an RC4 decryption routine, and reads a struct with a 16-byte offset. You open the binary in Ghidra or IDA Pro, check the address, and realize... none of that exists. The LLM simply hallucinated a plausible-looking structure because it fit the probabilistic pattern of its training data.

Binary analysis is an unforgiving domain. A single incorrect byte, mismatched register, or offset shift of 4 bytes breaks everything. In reverse engineering, close enough is not good enough.

This is where Reverify comes in.

Reverify is an advanced, deterministic verification loop designed to ground AI reverse-engineering agents in actual binary bytes. It acts as an automated judge that forces LLMs to prove their hypotheses using binary parsing, disassembly, pattern matching, and CPU emulation.

The Problem: Why LLMs Fail at Binary Analysis

LLMs are probabilistic engines designed to predict the next token. They are excellent at understanding semantic patterns but struggle with exact physical structures and arithmetic calculations. When analyzing a binary, an AI agent faces several distinct challenges:

Spatial and Structural Hallucinations: AI agents routinely guess struct offsets, assembly layouts, and function boundaries based on naming conventions or contextual clues rather than physical reality.
Execution Blindness: Static analysis alone is rarely enough. An LLM cannot execute a code path in its head to verify if a decryption loop actually produces a specific key.
Lack of Ground-Truth Feedback: When an agent acts autonomously, it lacks a tight feedback loop. If it makes an incorrect assumption early in its chain of thought, every subsequent conclusion is compromised.

To make autonomous reverse-engineering agents viable, we must transition them from a "guess-and-check" methodology to a formal hypothesis-and-verification loop.

What is Reverify?

Reverify bridges the gap between probabilistic LLMs and deterministic execution engines. It provides a structured verification layer that tests LLM assertions against reality.

Instead of allowing an AI agent to simply state:

"The function at 0x1000 is a custom XOR decryption routine."

Reverify forces the agent to interact with a verification framework that asks:

"Prove it. Provide the disassembly, trace the register states, emulate the execution using Unicorn, and show that the output bytes at target memory locations match your claim."

The Tech Stack

Reverify leverages a powerhouse stack of binary analysis and dynamic instrumentation tools:

LIEF: For structural parsing of executable formats (ELF, PE, Mach-O).
Capstone Engine: For multi-architecture instruction disassembly.
Unicorn Engine: For lightweight CPU emulation, allowing register and memory tracing without running the full binary on the host system.
Frida: For dynamic instrumentation and hooking during live process execution.
Model Context Protocol (MCP): To expose these validation tools natively to LLM agents (like Claude or GPT-based agents) as structured tools.

Under the Hood: Key Components

Let's dive into some of the core components of the Reverify codebase to see how it enforces this deterministic verification loop.

1. Orchestration and Tool Exposure: `reverify/cli.py`

The command-line interface (reverify/cli.py) serves as the entry point for both human analysts and automated agents. It exposes commands that allow agents to query, parse, disassemble, and run emulation checks.

Rather than just outputting raw text, the CLI outputs structured JSON that agents can parse directly to adjust their internal state. This structured feedback loop is critical for correcting the agent's path before it goes off the rails.

2. Validating Assumptions: `benchmarks/prologue_prior.py`

A classic hallucination point for LLM agents is identifying function entry points. When analyzing stripped binaries, agents often guess where functions start based on compiler-specific patterns (like push rbp; mov rbp, rsp).

The benchmark and analysis script benchmarks/prologue_prior.py validates whether function prologues actually exist at the addresses proposed by the model.

# Simplified concept of prologue verification in Reverify
def verify_function_prologue(binary_bytes, offset, architecture="x64"):
    # Read the bytes at the claimed offset
    prologue_bytes = binary_bytes[offset:offset+4]

    # Define known valid prologues for validation
    valid_prologues = {
        "x64": [
            b"\x55\x48\x89\xe5",  # push rbp; mov rbp, rsp
            b"\x48\x83\xec",      # sub rsp, imm
        ],
        "x86": [
            b"\x55\x89\xe5",      # push ebp; mov ebp, esp
        ]
    }

    # Force the agent to ground its claim in actual byte sequences
    if any(prologue_bytes.startswith(p) for p in valid_prologues.get(architecture, [])):
        return True, "Valid prologue found."
    return False, f"Invalid prologue at offset {hex(offset)}. Found bytes: {prologue_bytes.hex()}"

If an agent proposes a function boundary, Reverify executes a check like this. If the check fails, the agent receives an immediate, actionable error message: “Failed: Bytes at 0x401050 do not match standard function prologues. Found 0x00000000 instead.” The agent is then forced to revise its hypothesis.

The Verification Loop in Action

How does this look in practice? Imagine an autonomous agent analyzing a piece of malware containing an obfuscated string.

       +---------------------------------------------+
       |             AI RE Agent (LLM)               |
       |  "I think 0x4012A0 decrypts the payload"    |
       +----------------------+----------------------+
                              |
                     Hypothesis & Proof Request
                              v
       +---------------------------------------------+
       |             Reverify Engine                 |
       |  1. Disassemble 0x4012A0 (Capstone)        |
       |  2. Set up emulation state (Unicorn)        |
       |  3. Run to return instruction               |
       +----------------------+----------------------+
                              |
                     Deterministic Feedback
                              v
       +---------------------------------------------+
       |             AI RE Agent (LLM)               |
       |  "Ah, the register EDX held the key.        |
       |   The decrypted string is 'flag{u_got_me}'"  |
       +---------------------------------------------+

The Hypothesis: The agent theorizes that calling the function at 0x4012A0 with register rdi pointing to a ciphertext buffer will decrypt a payload.
The Verification Setup: The agent invokes Reverify’s emulation tool via MCP. It configures a virtual CPU state:
- Maps memory at 0x400000 (binary base).
- Writes the ciphertext to a virtual stack/heap.
- Sets rdi to the ciphertext address.
- Sets rip to 0x4012A0.
Execution: Reverify uses Unicorn Engine to emulate execution. It steps through instructions, tracking changes to memory and registers.
Validation: The emulation runs until a ret instruction is hit, or a timeout occurs. Reverify inspects the memory address where the agent expected the decrypted string to appear.
The Verdict: Reverify returns the precise memory state and registers back to the agent. If the memory contains plaintext, the hypothesis is confirmed. If the memory is unchanged or faulted, the agent is given the exact CPU state at the point of failure so it can debug its assumptions.

Key Use Cases

1. Automated Malware Analysis

Malware authors use packer, crypters, and custom obfuscation to defeat static analysis tools. Reverify allows security analysts to build autonomous triage pipelines where AI agents can systematically strip obfuscation layers, run unpacking loops in safe emulated sandboxes, and verify decrypted payloads with absolute confidence.

2. Autonomous CTF Solving

In Capture The Flag (CTF) competitions, speed is key. An AI agent powered by Reverify can quickly parse binary targets, verify function logic, validate vulnerability hypotheses (like buffer overflow offsets), and test exploit payloads locally using emulated environments before throwing them at the remote flag server.

3. Copilot for Human Reverse Engineers

Even when a human is in the loop, Reverify serves as an excellent assistant. You can ask an LLM to analyze a complex function, but have Reverify run behind the scenes to verify every assertion made by the model. This significantly reduces the time analysts spend manually double-checking hallucinated details in Ghidra.

Conclusion

The future of reverse engineering is undeniably collaborative. AI agents have the potential to speed up vulnerability research, malware triage, and binary analysis by orders of magnitude. However, they cannot do it alone. Without strict guardrails, they are prone to confident mistakes that waste analyst time.

By introducing a deterministic validation loop, Reverify turns LLMs from unreliable guess-engines into precise, verified analysis partners.

Are you building AI-powered security agents, or looking to supercharge your binary analysis workflows? Check out Reverify, explore the source code, and start building deterministic validation loops into your security stack today.

Stop Wasting API Tokens: How to Bridge ChatGPT Web to Your IDE Using MCP

Sandeep Kumar — Fri, 04 Sep 2026 03:27:13 +0000

If you are an active user of AI-powered IDEs like Cursor, VS Code with Copilot, or Windsurf, you already know the sinking feeling of seeing this notification:

"You have used 100% of your fast premium requests for this billing cycle."

Suddenly, your snappy, context-aware coding assistant slows to a crawl or starts racking up expensive pay-as-you-go API bills.

At the same time, you are likely paying $20/month for a ChatGPT Plus or Team subscription that sits underutilized in a browser tab. You use it for general questions, but it lacks direct, real-time access to your local codebase, forcing you to engage in a tedious dance of copying and pasting code blocks.

What if you could bridge this gap? What if you could let ChatGPT Web do the heavy reasoning and planning using your local context, while saving your premium IDE tokens for fast auto-completions?

In this article, we’ll explore a highly novel, intermediate-level setup that does exactly this. By leveraging the Model Context Protocol (MCP), Node.js, and secure Cloudflare Tunnels, you can route heavy code-planning tasks directly to your web-based ChatGPT Plus subscription safely and completely free of extra token charges.

The Philosophy: Let ChatGPT Think, Let Your IDE Work

When building complex software with AI, your workflow generally splits into two distinct phases:

Reasoning & Planning (High Token Usage): This is where you ask the AI to read 10 source files, understand the architecture, design a new feature, or find a subtle bug. This consumes massive amounts of context window tokens.
Execution & Autocomplete (Low Latency): This is where the AI writes single lines of code, refactors a function, or autocompletes your imports. This requires fast, inline API queries.

Paying premium API rates (per token) for Phase 1 is incredibly expensive. This is where this open-source MCP bridge project shines. It exposes a read-only view of your local project as an MCP server. Your web-based ChatGPT (via custom GPTs or MCP integrations) can securely read your workspace, do the heavy thinking, and output a detailed implementation plan. You then let your local IDE execute that plan.

How It Works: The Tech Stack

The magic lies in bridging your local file system to a remote web browser without opening risky ports on your home router.

┌────────────────────────┐                   ┌────────────────────────┐
│   ChatGPT Web (Cloud)   │                   │   Local IDE (Cursor)   │
└───────────┬────────────┘                   └───────────┬────────────┘
            │ (Secure HTTPS)                             │ (Fast Autocomplete)
            ▼                                            ▼
┌────────────────────────┐                   ┌────────────────────────┐
│   Cloudflare Tunnel    │ ◄────────────────►│   Local Codebase       │
└────────────────────────┘                   └────────────────────────┘
            │
            ▼
┌────────────────────────┐
│ Local MCP Bridge Server│
│ (Node.js / Read-Only)  │
└────────────────────────┘

The system uses:

Node.js & pnpm: To run the lightweight, local MCP server.
Model Context Protocol (MCP): An open standard developed by Anthropic that allows LLMs to query local tools and file structures safely.
Cloudflare Tunnels (cloudflared): Creates a secure, encrypted tunnel from Cloudflare’s edge directly to your local MCP server. No public IP or port forwarding required.
OAuth / Access Control: Ensures that only your authenticated ChatGPT session can access your files.

Step-by-Step Setup Guide

This guide assumes you have Node.js (v18+) and pnpm installed on your machine.

Step 1: Clone and Install the MCP Bridge

First, clone the bridge repository and install its dependencies:

git clone https://github.com/your-repo/mcp-web-bridge.git
cd mcp-web-bridge
pnpm install

(Note: Replace the URL with your specific fork or the community repository you are using).

Step 2: Configure Your Project Workspace

The bridge relies on a SKILL.md or a configuration file to understand which directories it is allowed to expose. To keep your system secure, the bridge operates on a strict read-only basis. It will index your files but will never write changes back to your disk without your explicit consent via the terminal.

Create a .env file in the root directory:

PORT=3000
WORKSPACE_PATH=/path/to/your/active/project
ALLOWED_EXTENSIONS=.js,.ts,.tsx,.json,.md,.py,.go

Step 3: Set Up the Cloudflare Tunnel

To allow your browser-based ChatGPT to query this local server, you need to expose your port 3000 through a secure tunnel.

Install the Cloudflare Tunnel CLI (cloudflared):
- macOS: brew install cloudflare/cloudflare/cloudflared
- Windows/Linux: Download from Cloudflare's official releases.
Authenticate and start a quick tunnel:

   cloudflared tunnel --url http://localhost:3000

Copy the secure .trycloudflare.com URL generated in your terminal. It will look something like this: https://your-unique-subdomain.trycloudflare.com

Step 4: Connecting ChatGPT Web via MCP

With your tunnel running, you can now hook this up to ChatGPT.

Go to ChatGPT Web.
Open your Custom GPT builder or use a client that supports custom MCP endpoints.
Provide the OpenAPI schema exposed by your local server at: https://your-unique-subdomain.trycloudflare.com/openapi.json
ChatGPT will recognize the tools available: list_directory, view_file, and search_grep.

Putting it to the Test: A Real-World Workflow

Let's look at how this changes your day-to-day development loop and saves you money.

Scenario: Refactoring a Legacy Authentication Module

Instead of asking Cursor to "Read all these 4 files and tell me how to refactor them" (which would cost you roughly 15,000 to 30,000 input tokens in your IDE API quota):

Ask ChatGPT Web:

"Using my connected local workspace, find the authentication helper file, read its contents, and design a modern OAuth2-compatible flow that integrates with our current database schema."
ChatGPT Web Acts:
Through the secure tunnel, ChatGPT calls search_grep to locate files like auth.ts or db.ts. It reads only those files via view_file.
The Brainstorm:
Because you are on a flat-rate ChatGPT Plus plan, you can chat back and forth 20 times, refining the architecture, asking "what if" questions, and hashing out edge cases. Total cost: $0.00 in API tokens.
The Execution:
Once ChatGPT Web provides the final, pristine code blueprint, you copy the target changes, jump into Cursor, and let your fast, local autocomplete implement the structural plan.

Security Best Practices: Keeping Your Code Safe

Exposing your local files to the web should always be done with caution. Here is how this setup keeps you secure:

Strict Read-Only Middleware: The Node.js server contains no write APIs. Even if a malicious actor hijacked your tunnel URL, they could not delete or alter your local files.
CORS and Token Authentication: The project configuration allows you to set a custom authorization header token in your .env file. ChatGPT will include this header in every request, blocking unauthorized web scrapers.
Scope Limitation: Never set your WORKSPACE_PATH to your user root (~/ or C:\Users\). Always point it to the specific project folder you are actively working on.

Conclusion: Smart Resource Allocation

Being a productive developer in the age of AI isn't just about using the best models—it’s about using them efficiently.

By offloading the heavy-lifting, high-context reasoning tasks to your flat-rate ChatGPT Web subscription via this secure MCP bridge, you can preserve your premium IDE tokens for what they do best: lightning-fast inline completions and real-time edits.

Give this setup a try on your next major project, and watch your API bills plummet while your productivity stays sky-high!

Have you experimented with the Model Context Protocol (MCP) yet? Let us know your thoughts, configurations, or alternative cost-saving setups in the comments below!

Escaping the Browser: Why We Need a Dedicated Desktop Client for MetaMask

Sandeep Kumar — Tue, 01 Sep 2026 08:51:52 +0000

The Web3 revolution was built on the back of the browser extension. For years, MetaMask has been the undisputed gateway to the decentralized web, living snugly in the top-right corner of Chrome, Brave, and Firefox. It made interacting with smart contracts as simple as clicking a button.

But as Web3 transitions from a niche playground for early adopters into a mature ecosystem of decentralized finance (DeFi), institutional trading, and complex developer workflows, the limitations of the browser extension model are becoming increasingly obvious.

If you are a Web3 developer, active trader, or power user, you've likely felt the pain points: browser performance lag, constant context-switching, and the nagging anxiety of keeping your private keys in the same application where you open random Twitter links.

Today, we are looking at a paradigm shift: a standalone, cross-platform desktop client for MetaMask. By taking the wallet out of the browser sandbox and running it as a dedicated desktop application, we can unlock a more secure, isolated, and highly performant Web3 workflow.

The Problem with the Browser Extension Monopoly

To understand why a desktop client is necessary, we must first look at the inherent limitations of browser extensions.

1. Security Risks and the Shared Memory Space

Browsers are inherently noisy environments. Every time you install an extension, visit a sketchy website, or open a tab with unvetted JavaScript, you expose your system to potential threats. Cross-Site Scripting (XSS) attacks, malicious extensions designed to hijack your clipboard, and phishing pop-ups are constant threats. Running your primary cryptographic key manager inside the same program you use to browse the web is a massive attack surface.

2. Resource Clutter and Performance

Modern browsers are notoriously memory-hungry. When you run heavy dApps, decentralized exchanges (DEXs), and analytics dashboards alongside an active wallet, your browser’s performance can tank. Memory leaks from active tabs can cause your extension to freeze right when you are trying to sign a time-sensitive transaction.

3. Developer Friction

For Web3 developers, testing local smart contracts (via Hardhat, Anvil, or Foundry) while connected to a browser extension can be frustrating. Extensions frequently cache state aggressively, struggle with local RPC network switches, and suffer from CORS issues. Resetting your wallet's state to clear a stuck nonce is a chore that developers have to perform far too many times a day.

Introducing the Desktop Client: A Dedicated Web3 Workspace

The desktop alternative solves these problems by creating a completely isolated environment for your digital assets.

"An unofficial, cross-platform desktop client for MetaMask that frees your Web3 workflow from the browser."

By moving MetaMask into a dedicated desktop application, you gain a focused, secure workspace. The project leverages modern desktop application frameworks to package the core MetaMask interface and wallet logic into a lightweight executable running natively on Windows, macOS, and Linux.

The Architectural Blueprint

Building a desktop wallet is a delicate balance of security, performance, and user experience. This project sits at the intersection of several powerful technologies:

┌─────────────────────────────────────────────────────────┐
│                    Desktop UI                           │
│     (React / TypeScript / Tailwind CSS)                 │
└──────────────────────────┬──────────────────────────────┘
                           │ IPC Bridge
┌──────────────────────────▼──────────────────────────────┐
│                    Desktop Runtime                      │
│             (Tauri / Rust or Electron / Node)           │
└──────────────────────────┬──────────────────────────────┘
                           │ Secure API Calls
┌──────────────────────────▼──────────────────────────────┐
│                   Web3 Core Engine                      │
│           (Web3.js / Ethers.js / Wallet Connect)        │
└─────────────────────────────────────────────────────────┘

The app's stack leverages:

Electron & Tauri: Offering the robust runtime of Electron alongside the lightweight, memory-safe footprint of Tauri (written in Rust).
TypeScript: Ensuring type-safety across complex transaction signing mechanisms and state management.
Ethers.js & Web3.js: Powering RPC provider communication, transaction gas estimation, and cryptographic key derivations.

Under the Hood: Resolving the "DApp-to-Wallet" Bridge

One of the biggest technical challenges of a standalone desktop wallet is communication. When MetaMask lives in the browser, it injects a global provider object (window.ethereum) directly into active web pages. This allows dApps like Uniswap or OpenSea to automatically detect the wallet.

How does a standalone desktop application interact with a dApp running inside your browser?

The desktop client solves this using a two-pronged approach:

1. The Local RPC/WebSocket Bridge

The desktop client can run a lightweight, highly secure local WebSocket server on localhost (e.g., 127.0.0.1:xxxx).
When a dApp tries to connect, a companion browser extension (acting purely as a lightweight relay with no private keys stored in it) routes the request directly to your desktop client. This keeps your keys completely isolated in the desktop app while maintaining compatibility with your favorite browser-based dApps.

2. Integrated WalletConnect Support

By leveraging the WalletConnect protocol, the desktop client can act as a native desktop companion. You simply scan a QR code or paste a connection URI from any dApp, and your desktop client establishes a secure, end-to-end encrypted session to sign messages and authorize transactions.

Setting Up and Running the Client Locally

For developers looking to audit the code, run their own build, or contribute to the project, setting up the repository locally is straightforward.

Prerequisites

Make sure you have Node.js (v18+) and your preferred package manager (npm, yarn, or pnpm) installed. If you are building the Tauri-based version, you will also need the Rust toolchain installed on your machine.

Installation Steps

Clone the Repository:

   git clone https://github.com/your-repo-link/metamask-desktop-client.git
   cd metamask-desktop-client

Install Dependencies:

   npm install
   # or
   pnpm install

Run in Development Mode: To launch the application in a local hot-reloading development window:

   npm run dev

Build the Production Executables: To package the application for your specific operating system (generating a .dmg for macOS, .exe for Windows, or .deb/AppImage for Linux):

   npm run build

Why Developers Should Care

If you are a developer, using a desktop client isn't just about security—it’s about streamlining your daily workflow.

Independent Network Profiles: You can configure your desktop client to stay permanently connected to your local Hardhat or Anvil node, while keeping your web browser free for standard mainnet research or DeFi interactions. No more constantly switching RPC endpoints back and forth.
Isolated State: Clear your test account nonces, reset your local state, and import disposable private keys for testing without affecting your actual personal browser profile.
Streamlined UI: A dedicated window means you can snap the wallet to one side of your monitor while keeping your IDE open on the other, allowing you to watch state changes and incoming contract call requests in real time.

Security First: A Note on Best Practices

While a desktop client drastically reduces your exposure to browser-based attacks, desktop environments have their own unique security vector.
If you choose to use a desktop client, remember these security fundamentals:

Always run authenticated builds: Build the binary directly from source if you are managing significant capital.
Keep your OS secure: Isolated apps protect you from browser malware, but they cannot protect you from system-level keyloggers or RATs (Remote Access Trojans).
Pair with a Hardware Wallet: The ultimate setup is using this desktop client as a highly polished visual interface paired with a hardware wallet (like Ledger or Trezor) to handle the actual private key authorization.

Conclusion

The future of Web3 is moving toward dedicated, purpose-built workspaces. Just as developers moved from running everything in basic terminal windows to robust, dedicated IDEs, Web3 users are ready to move from lightweight browser extensions to robust, secure, and isolated desktop clients.

Freeing your wallet from the browser browser-extension bottleneck is the first step toward a faster, safer, and more productive Web3 workflow.

Have you tried running Web3 wallets outside of the browser? What are your thoughts on the Tauri vs. Electron debate for secure desktop apps? Let’s discuss in the comments below!

DEV Community: Sandeep Kumar

Stopping LLM Hallucinations in Reverse Engineering: Meet Reverify

The Problem: Why LLMs Fail at Binary Analysis

What is Reverify?

The Tech Stack

Under the Hood: Key Components

1. Orchestration and Tool Exposure: reverify/cli.py

2. Validating Assumptions: benchmarks/prologue_prior.py

The Verification Loop in Action

Key Use Cases

1. Automated Malware Analysis

2. Autonomous CTF Solving

3. Copilot for Human Reverse Engineers

Conclusion

Stop Wasting API Tokens: How to Bridge ChatGPT Web to Your IDE Using MCP

The Philosophy: Let ChatGPT Think, Let Your IDE Work

How It Works: The Tech Stack

Step-by-Step Setup Guide

Step 1: Clone and Install the MCP Bridge

Step 2: Configure Your Project Workspace

Step 3: Set Up the Cloudflare Tunnel

Step 4: Connecting ChatGPT Web via MCP

Putting it to the Test: A Real-World Workflow

Scenario: Refactoring a Legacy Authentication Module

Security Best Practices: Keeping Your Code Safe

Conclusion: Smart Resource Allocation

Escaping the Browser: Why We Need a Dedicated Desktop Client for MetaMask

The Problem with the Browser Extension Monopoly

1. Security Risks and the Shared Memory Space

2. Resource Clutter and Performance

3. Developer Friction

Introducing the Desktop Client: A Dedicated Web3 Workspace

The Architectural Blueprint

Under the Hood: Resolving the "DApp-to-Wallet" Bridge

1. The Local RPC/WebSocket Bridge

2. Integrated WalletConnect Support

Setting Up and Running the Client Locally

Prerequisites

Installation Steps

Why Developers Should Care

Security First: A Note on Best Practices

Conclusion

1. Orchestration and Tool Exposure: `reverify/cli.py`

2. Validating Assumptions: `benchmarks/prologue_prior.py`