AntSword: a cross-platform webshell client built on Electron

What AntSword is for, and who should not touch it

AntSword is a desktop application for managing a website once you already have a way in. The README describes it as "an open source, cross-platform website administration tool, being designed to meet the needs of penetration testers together with security researchers with permissions and/or authorizations as well as webmasters." That sentence is doing a lot of work: the intended audience is people who hold permission, and the README follows it with an explicit prohibition on illegal use and on publishing unauthorized modified versions.

The practical use case is a tester who has planted several webshells across a target and needs one place to browse files, open a terminal, and query a database without juggling browser tabs and hand-written POST requests. The screenshots in the repository show exactly those four surfaces: a file manager, a terminal, a database panel, and a plugin store.

The wrong audience is anyone who does not have that authorization, and there is no way to read this project's documentation that changes that. If you are looking for a general-purpose remote administration tool for machines you own, the webshell model here is a mismatch: AntSword talks to a script running on a web server, not to an SSH daemon or an agent.

The Electron shell, the loader model, and the plugin store

The development stack listed in the README is Electron, ES6, dhtmlx and Node.js, "and other libraries called in the project." The repository layout backs that up: app.js sits at the top level as the entry point declared in package.json, with modules/, source/, static/ and views/ alongside it. This is a conventional Electron split, where the main process boots the app and the renderer draws the dhtmlx-based interface.

The design idea the README names is modularization, framed as a way to "provide easy-to-understand codes and modification guidelines for users of different levels." In practice that means the shell type is a plugin rather than a hard-coded feature. The related searches people run for this project include antsword php, antsword jsp and antsword aspx, which maps onto the plugin store screenshot: the loader for a given server-side language is something you add, not something baked into the core binary.

The dependency list in package.json tells you what the client does under the hood. superagent and superagent-proxy handle HTTP and proxying, node-rsa and crypto-js cover the encoding and encryption paths, iconv-lite and jschardet deal with character set detection for responses that are not UTF-8, and nedb provides the local embedded datastore. That last one matters for how you treat the app: your shell configuration lives in a local file-based database, not in a server-side account.

Installing AntSword and adding a first shell

The README does not carry install steps. Its Quick Start section is a single link to the project documentation at yuque.com, and the Contribute section links elsewhere as well. What the repository does give you is the release page and the package metadata, so the honest instruction is: get the build from the releases page, and follow the Quick Start document for the click-by-click path.

If you are working from source instead of a release, package.json defines two scripts. Note that the start script is not the usual electron invocation; it calls an "AntSword" binary with app.js as the argument, and build simply runs start.

"scripts": {
  "start": "AntSword app.js",
  "build": "npm start"
}

Because that start script depends on an "AntSword" executable being resolvable on your PATH, running npm start in a fresh clone is not guaranteed to work the way a typical Electron project would. The release build avoids that question entirely, which is why the documentation's Quick Start is the safer route.

The version to expect is pinned in the same file, and it matches the most recent release tag:

{
  "name": "antsword",
  "version": "2.1.16",
  "main": "app.js",
  "license": "MIT"
}

Once the app is running, the workflow the screenshots imply is: open the shell management view, add a new entry, select the shell type that matches the server-side language of the target, and paste the connection details for the script already on the server. If the type you need is not in the list, the plugin store is where you look. The README does not document the exact fields of that add-shell form, so treat the Quick Start document as the reference rather than guessing at key names.

Where AntSword gets awkward: updates, cadence and documentation

The release history is uneven. Version 2.1.16 was published on 2026-04-25, but the release before it, 2.1.15, dates to 2022-07-17, and 2.1.14 to 2021-07-25. That is a multi-year gap between 2.1.15 and 2.1.16, which tells you something about how this project ships: long quiet stretches punctuated by a release. The last push to the default branch was on 2026-04-29, so the repository is not archived, but a team that needs predictable release notes and a support window should plan around that cadence rather than assume it.

The documentation split is the second friction point. The README itself is thin by design: development stack, screenshots, a Quick Start link, a Contribute link, a licence pointer. Anything operational lives on the external yuque site. That is fine for a human following a tutorial, and awkward if you wanted to script a setup or check a config key without opening a browser.

The package.json update block is also worth reading closely. It carries an empty md5 and empty logs field, with a single update source pointing at the GitHub releases/latest URL. Whatever the in-app updater does with that, the metadata in the repository does not describe a signed or verified update channel.

Finally, the licence situation is not as simple as the MIT identifier suggests. package.json says MIT and the LICENSE file is present, but the README adds its own restriction: "publishing unauthorized modified version is also prohibited." That is a project-level statement layered on top of the licence text, and if you plan to redistribute a fork, the two documents are what you need to reconcile.

AntSword against Behinder and generic HTTP clients

The search data around this project pairs it with Behinder, and that comparison is the useful one. Both are graphical clients for managing a webshell, and both target the same kind of authorized engagement. The difference is in the packaging and the extension model. AntSword is an Electron application with an explicit plugin store for shell types and a modular codebase the README invites people to modify. Behinder is a separate project with its own client and its own shell format, and shells written for one are not interchangeable with the other; the loader on the server side is what ties you to a client.

If you are not already committed to the webshell model, a plain HTTP client such as curl or a Burp Repeater tab is the real alternative, and the trade-off is stark. A generic client gives you full visibility into every request and response and works with any payload you can construct, at the cost of doing file browsing, terminal interaction and database queries by hand. AntSword's value is precisely that it packages those four operations into a GUI, and its cost is that you inherit an Electron app, a plugin ecosystem and a local nedb store holding your connection profiles.

There is no built-in answer here for someone who wants a command-line, scriptable client. The repository is a desktop app; nothing in the README suggests a headless mode.

Frequently asked questions

The questions below cover the points a new user hits first: what the tool is, what it runs on, and what the licence actually permits. Answers stay within what the README, package.json and release list state.

Editorial conclusion

AntSword fits testers and researchers who already hold written authorization and want a desktop client that manages many webshells across PHP, JSP and ASPX targets from one Electron window. It is the wrong tool for anyone without that authorization, and it is a poor fit for teams that need a documented, scriptable CI workflow, since the README points to external documentation for setup. Before adopting it, verify the loader for your target language actually exists in the plugin store, check that the Electron build runs on your OS, and read the MIT LICENSE alongside the README's prohibition on unauthorized modified versions, because those two texts pull in different directions.

Frequently asked questions

Official sources

1. AntSwordProject/antSword on GitHub
2. License: MIT
3. Project website
4. README
5. Releases