WPeGPT: an IDA plugin that puts an LLM inside your decompiler window

The gap WPeGPT fills between decompiler output and a chat window

The usual loop for a reverse engineer is: read pseudocode in IDA, copy a function into a browser or terminal, paste it to a model, read the answer, then manually re-annotate the listing. WPeGPT removes the copy step. It is an IDA plugin that takes the decompiled pseudocode of the function you are looking at, sends it to an LLM, and writes the model's result back into IDA as comments. The README describes the target user plainly through its five interactive actions: function analysis (purpose, usage environment, behavior), variable renaming, Python reconstruction of small routines such as XOR decryption, vulnerability finding in the current function, and an attempt at PoC exploit generation.

The project is explicit about the epistemic status of its output. The README carries a note that "AI's analysis results are for reference only", followed by a joke about analysts being out of work otherwise. Treat that as the design intent, not modesty. Nothing in the repository suggests a validation layer between the model's answer and the comment it writes into your database.

WPeGPT is a fork-line descendant of Gepetto, which the README credits as the inspiration. The update history shows the lineage: version 1.0 in February 2023 was "Based on Gepetto", and the project has since diverged through DeepSeek support, an automatic analysis mode, and the v3.0 rewrite. If you have used Gepetto, the interactive shortcuts and context menu will feel familiar; the automated pipeline is where the two projects now differ most.

How the plugin, the config module and WPeServer fit together

Version 3.0 split a single script into three parts: WPeGPT.py, config.py and wpe_ai_controller.py. The repository layout matches that description at the top level, with WPeGPT.py and the WPeGPT_Config/ directory side by side. The README states the split explicitly in the 3.0 entry of the update history.

The interactive path is the simple one. You select a function, trigger a shortcut or a context menu entry, and the plugin reads the decompiled pseudocode, builds a request, and posts it to the endpoint named by API_BASE_URL using the key in API_KEY and the model in MODEL. The response is parsed and inserted as comments. Model choice is a configuration value, not a code change: the 2.5 release notes say support for other models is set through the MODEL variable, and the 2.6 notes say DeepSeek requires setting PLUGIN_NAME to WPeChat-DeepSeek and filling model_api_key, with 'deepseek-reasoner' as the R1 option.

The automated path is new in 3.0 and is the more interesting architecture. WPeServer is described as an embedded TCP server inside IDA that accepts commands from an external controller and supports multiple concurrent IDA instances. That inverts the usual model: instead of a human clicking in the GUI, a controller drives one or more IDA processes over TCP. On top of that sits a three-phase pipeline (global scan, critical path, full scan) exposed as three modes.

The modes differ mainly in how much gets sent to the model. The README's table gives light as a global scan plus critical path function analysis at roughly 2 to 5 minutes, full as global scan plus critical path plus full function analysis at roughly 10 to 30 minutes, and vuln as critical path vulnerability analysis at roughly 5 to 20 minutes. Those are the project's own estimates, and they will scale with binary size, model latency and MAX_WORKERS.

Before any model call, 3.0 runs local triage. Strings are sorted into ten categories (networking, keylogging, crypto, injection, persistence, antianalysis, dropper, code execution, memory/file ops, installer framework). Network indicators are extracted: IPs, domains, URLs and ports, with an attempt to detect and decrypt encrypted C2 addresses. Functions get a suspiciousness score built from keyword matching, caller and callee relationships, size, and standard-library filtering, and that ranking decides what the model sees first. Shellcode loader detection is pattern-based. Results land as both JSON and Markdown under a directory named after the binary with the suffix _WPeAI_Results/.

Installing WPeGPT and running a first function analysis

The README gives three install steps and they are short. First, install the dependencies from requirements.txt, which pins openai >= 0.27.0 and httpx.

pip install -r ./requirements.txt

Second, edit WPeGPT_Config/config.py. The README names the fields you must set: API_KEY, API_BASE_URL, MODEL, and ZH_CN (True for Chinese, which the README says is the default, False for English). ANALYSIS_MODE and MAX_WORKERS are listed as optional. The README does not print the file's contents, so open it and read the surrounding comments rather than assuming field names beyond the ones named here.

Third, copy WPeGPT.py and the WPeGPT_Config/ folder into your IDA plugins/ directory and restart IDA. The README adds a note that IDA must be configured to use Python 3. That note is not decorative: an IDA instance on the legacy Python 2 interpreter will not load this plugin properly.

Once IDA restarts, the interactive surface is a set of shortcuts and a context menu. According to the README, Ctrl+Alt+G runs function analysis, Ctrl+Alt+R renames function variables, Ctrl+Alt+E looks for vulnerabilities, and Ctrl+Alt+W starts light auto analysis. You can also right-click in the pseudocode window or use the menu bar under Edit, then WPeGPT.

For a first real use, open a binary, place the cursor in a function, and press Ctrl+Alt+G. The plugin sends that function's pseudocode and writes the model's analysis back as comments in the listing. Expect the comments to appear in the language selected by ZH_CN. If the call fails, the README's troubleshooting section points at the network path first: check the urllib3 version, because v1.26 has known proxy issues, and it prescribes downgrading.

pip uninstall urllib3
pip install urllib3==1.25.11

The same section says you can set FORWARD_PROXY in config.py, for example http://127.0.0.1:7890, or route through a reverse proxy by pointing API_BASE_URL elsewhere. For the headless path, the README points at the separate wpegpt-analyzer repository or the menu entry Edit, then WPeGPT, then Auto-WPeGPT, with reports written to <binary_name>_WPeAI_Results/.

What WPeGPT cannot do, and where the documentation stops

The most consequential limitation is one the README states as a warning rather than a feature note. Model output is inserted as comments with no described verification step. A confident, wrong vulnerability finding becomes a comment in your IDA database, and a later analyst may read it as established fact. The exploit generation feature is described as an attempt, and the update history records that version 1.2 was uploaded without testing because of OpenAI server lag, so the project itself has a history of shipping AI-facing features ahead of validation.

Configuration is another weak point. API keys live in a Python file inside the plugins directory. There is no documented environment-variable path, no keyring integration, and nothing in the README about excluding that file from version control. If you distribute an IDA setup or commit a plugins folder, that is on you to handle.

The automatic pipeline has real cost implications that the README does not quantify. The full mode is listed at 10 to 30 minutes, and that is wall-clock time against a paid API with your key. Nothing in the repository documents a token budget, a cost estimate, or a way to cap spending beyond MAX_WORKERS, which controls concurrency rather than total volume.

Upgrade and rollback are undocumented. The README says existing installations are unaffected by the v3.0 rename, which addresses the plugin identity, but it does not describe how to revert from v3.0 to v2.7, whether the config format is backward compatible, or what happens to an existing WPeChatGPT install's settings. The releases list shows v3.0, v2.7 and v2.6, so downgrading is at least possible in principle, but the project offers no procedure.

Finally, the scope of the automated analysis is narrower than the feature list suggests. String classification, IoC extraction, suspiciousness scoring and shellcode detection are described as pattern-based or keyword-based. They are triage heuristics that decide where to spend model calls, not detectors with stated accuracy.

WPeGPT against Gepetto: same idea, different automation model

The honest comparison is with Gepetto, which the README credits as the inspiration and which version 1.0 was based on. Both are IDA plugins that send decompiled code to an LLM and return text. The difference is what happens around that call.

Gepetto's shape, as the lineage suggests, is the interactive one: you invoke it on a function and read the answer. WPeGPT keeps that mode and adds a second one. Version 3.0's WPeServer turns IDA into a TCP-driven worker that an external controller can command, and the three-phase pipeline decides which functions are worth analyzing before any request is made. The local triage layer (string categories, IoC extraction, suspiciousness scoring, stdlib filtering) exists to keep the model from reading an entire binary.

That is a genuine architectural difference, not a rebrand. It also changes the failure profile. An interactive plugin that returns a bad answer costs you a few seconds. A headless pipeline that runs full mode across a queue of binaries spends real money and produces reports that someone downstream may treat as findings. WPeGPT's triage heuristics are the only thing standing between your API budget and every function in the binary, and the README describes them in a feature table rather than with thresholds or tuning guidance.

If your workflow is one analyst, one binary, one function at a time, the interactive half of WPeGPT and a straightforward Gepetto-style plugin are close substitutes, and the deciding factor is which providers you want to reach. If your workflow is triaging binaries in bulk without a human at the keyboard, WPeGPT's v3.0 pipeline is the part with no direct equivalent in the project's own stated lineage.

Licence, maintenance and the cost of keeping WPeGPT current

The repository has no licence file at its top level, and the README does not state a licence. That is a fact you have to weigh yourself: without an explicit licence, the default copyright position applies, and redistributing the plugin inside a commercial toolchain or an internal product is a question for your legal team, not for this article. The same absence means you cannot rely on a licence text to tell you the project's intentions about derivatives.

The maintenance picture is mixed. The last push was on 2026-05-27, which is the same date as the v3.0 release, and the repository is not archived. Before that, releases came in December 2025 (v2.7), February 2025 (v2.6) and November 2023 (v2.4), so the cadence is irregular rather than steady. A major rewrite landed in May 2026 and nothing has been pushed since; whether that means the architecture has stabilized or the maintainer has moved on is not something the repository states.

Upgrade cost is dominated by the config file. Because API_KEY, API_BASE_URL, MODEL, PLUGIN_NAME and model_api_key are edited in place inside WPeGPT_Config/config.py, a reinstall means re-applying your settings unless you keep that file under your own version control. The dependency surface is small (openai and httpx), but the README's own troubleshooting section shows it is version-sensitive: it prescribes pinning urllib3 to 1.25.11 to work around proxy problems in 1.26. That pin is old, and holding it while the openai package moves forward is the kind of conflict you will hit during an upgrade.

There is also a naming migration to track. WPeChatGPT became WPeGPT at v3.0, and the README says existing installations are unaffected, but the release history still lists v2.7 and v2.6 under the WPeChatGPT name. If you search for documentation or issues, both names are in play.

Editorial conclusion

Adopt WPeGPT if you already live in IDA and want a second opinion on a function without leaving the pseudocode window, or if you need the v3.0 headless pipeline to triage many binaries through WPeServer. Do not adopt it if you cannot send pseudocode to a third-party API, or if you expect a maintained, versioned configuration story: API keys live in a Python file you edit by hand, the repository carries no LICENSE file, and the README documents no rollback or upgrade path. Before trusting any output, verify what the plugin actually sends by reading WPeGPT_Config/config.py, and confirm that your IDA instance runs Python 3, since the README states that requirement explicitly.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WPeace-HcH/WPeGPT on GitHub