x64dbg Plugin Manager: fetching and installing debugger plugins on Windows

A file copier for the x64dbg plugin ecosystem

x64dbg is a debugger for Windows binaries, and reverse engineers accumulate plugins for it: script engines, format decoders, extra analysis views. Each plugin is a separate binary that has to land in the right directory of an x64dbg installation. This project takes that chore off the user. Its description is a single line, "Plugin manager for x64dbg", and the repository delivers exactly that: a Windows program that fetches a list of known plugins from a server, shows it, and installs or removes modules in a chosen x64dbg root.

Two groups care about it. The reverse engineer who has just cloned a plugin repository and wants it working inside an existing debugger rather than copying files by hand, and the plugin author who wants a known installation path instead of asking users to sort out folder layout themselves.

What it does not do is extend the debugger. There is no new disassembly view, no new analysis pass, no script dialect. Everything here is about acquiring and placing plugin binaries, which is why its output is a list of modules rather than a new debugging capability.

The console flags tell you the whole workflow

The tool has two front ends and the README shows the console one. The executable is x64plgmnrc.exe, and the documented invocation sequence is short. First you point it at the debugger root:

x64plgmnrc.exe -G "C:\x64dbg_root"  // Set root path for x64dbg

Then the remote catalogue is refreshed from the server:

x64plgmnrc.exe -U                   // Update list from server

The current list can be printed at any point:

x64plgmnrc.exe -S                   // Show list of plugins

Installation then names the plugin. The README shows the core x64dbg plugin and a third party one:

x64plgmnrc.exe -i x64core           // Install last version of x64dbg

x64plgmnrc.exe -i AdvancedScript    // install AdvancedScript

The ordering falls straight out of the flags: -G establishes where x64dbg lives, -U refreshes the list, -S shows it, -i performs the install. The README does not document what happens if -i runs before -G, or whether -U is required once per session, so that ordering is something you confirm on your own installation.

The published download is a Beta tag

The README shows a GUI as well as the console, with separate screenshots for each, both stored under docs/ in the repository.

The distribution route is a release tag rather than a package index. The Download section points at the releases tag Beta in the horsicq/x64dbg-Plugin-Manager repository on GitHub, and that address is the only download location the project documents.

That the official link is a tag named Beta is worth sitting with for a moment. It means the artifacts people install are beta builds, and that the numbered releases, 0.05 and 0.06, sit in the same release list. For a tool whose job is to place binaries into a debugger, a rolling channel is a defensible choice, since the manager has to stay compatible with whichever x64dbg build is in front of the user. The cost is that the version you receive is decided by the maintainer rather than pinned by you.

The manager is also a separate program that operates on the x64dbg plugin directory. It is not itself a module loaded into the debugger, so it runs before a debugging session starts rather than inside one.

Building on Windows needs Visual Studio 2013 and Qt 5.6.3

The build recipe is a short list of prerequisites: Visual Studio 2013, Qt 5.6.3 for VS2013(x86), and 7-Zip, each pointing at the maintainer's build_tools repository. The clone has to be recursive, which matters because the repository carries a .gitmodules file:

git clone --recursive https://github.com/horsicq/x64dbg-Plugin-Manager.git

The build then depends on three paths inside build_win32.bat, named VS_PATH, SEVENZIP_PATH and QT_PATH, which you point at your own installations before running the script:

build_win32.bat

The toolchain versions are old, and that is the single largest practical obstacle to adopting this project yourself. Visual Studio 2013 and Qt 5.6.3 both sit well past their support windows, and the project file is a qmake .pro file rather than a CMake one, which is consistent with that era rather than with current practice. The README documents no alternative build path for a modern Visual Studio, so your options are reconstructing the historical toolchain, or porting the build, or consuming the published binary instead.

The plugin catalogue lives in another repository

Adding a plugin is not something the manager does on its own. The README states that you should make a pull request with a new plugin to the list.json file in the x64dbg/PluginManager repository. The catalogue therefore lives somewhere else entirely, and this project is the client for it.

That split has real consequences. A plugin absent from list.json cannot be installed by name with -i, because the manager installs from a remote list rather than from an arbitrary URL. Publishing means a pull request against a JSON file in a repository you do not own, reviewed by that project's maintainers, which makes the catalogue curated and slow to change but keeps the supply chain in one reviewable place.

It also lets the manager and the catalogue drift apart. There is no route for adding an entry from inside the manager itself, and the README does not describe how the list is fetched, verified or signed. The ssl/ directory in the tree indicates transport security is handled in code, but the trust story around the list itself is undocumented.

One C++ class per step of the install pipeline

The source layout describes the pipeline in process-per-step form. Each stage is a separate class: getfilefromserverprocess for retrieving data, updategitprocess for the git side, installmoduleprocess for placing a module, createmoduleprocess and removemoduleprocess for adding and removing, and convertprocess for the format conversions handled by the Formats/ directory.

The two front ends are separated as well, with the graphical code under gui_source/ and the console code under console_source/, and a shared x64dbgPluginManager_source.pro project file tying both to common helpers in utils.cpp and global.h. Interface pieces are split into their own directories: XAboutWidget, XOptions, XShortcuts, XUpdate, XArchive and XGithub. The separate XUpdate and XArchive directories suggest that updating an existing plugin and unpacking a downloaded archive are concerns the code keeps apart.

The presence of .gitmodules explains the recursive clone requirement, since submodules have to be fetched for the tree to be complete.

Current commits, old release tags, MIT licence

Maintenance here runs on two different clocks. The commit history is current: the repository is not archived and the last push was on 2026-10-19. The tagged releases are not: version 0.06 dates from 2023-03-02, the Beta tag from 2023-02-23, and 0.05 from 2021-07-12. The source is therefore being touched while the published artifacts are years old, and that combination is worth verifying for yourself before relying on that download link.

The licence is MIT, one of the most permissive software licences available. You may read the code, modify it, redistribute it and use it inside a commercial product, provided the copyright notice and the licence text travel with copies. The repository also keeps a THANKS.md file and a changelog.txt in the tree, so attribution and change history live alongside the source.

What the MIT licence does not settle is the status of the plugins being installed. It covers this manager's own code only, and every plugin it places into an x64dbg root comes from another author under separate terms.

Editorial conclusion

Adopt x64dbg Plugin Manager if you reverse engineer on Windows with x64dbg and want plugins placed into a debugger root with a single command instead of manual file copies, and if you are comfortable with a Beta download tag and a curated catalogue. Do not adopt it if you need reproducible pinned builds, work outside Windows, or want to publish a plugin without filing a pull request against list.json in the x64dbg/PluginManager repository. Before committing, check two things: that list.json contains the plugins you actually need, and that the build you download from the Beta release tag matches the x64dbg version you run.

Frequently asked questions

Official sources

1. horsicq/x64dbg-Plugin-Manager on GitHub
2. Issues
3. License: MIT
4. README
5. Releases