Online Tools: a Windows security toolbox that bundles 340 tools and seven AI agents

A portable Windows build rather than an installable program

The manual in the README describes a Windows desktop application aimed at security researchers, penetration testers, CTF players and authorised testers. It is explicitly a portable build: unpack the archive and run it, with no system installation, and all tools, configuration and logs kept in a `storage` folder beside the executable so the whole thing can be backed up or moved like a folder.

The stated system requirements are modest and specific: Windows 10 or 11 on 64-bit, 4 GB of RAM or more with 6 GB recommended when the AI agent is used, and 20 GB of free disk or more depending on how many tools you download. That disk figure is the most useful line in the documentation, because a catalogue of several hundred security tools is mostly binaries.

Distribution runs through two channels. The GitHub Releases page for the project is the official one, with 1.1.1 as the latest version listed, and there is a separate fully featured packaged build at 1.0.3 distributed through a hosted file share. Those two version numbers running in parallel is worth noticing, since it suggests the share build is a differently packaged lineage rather than a mirror of the release page.

https://github.com/CuriousLearnerDev/Online_tools/releases
https://pan.quark.cn/s/d09ada044927

The release notes describe those builds as internal beta releases, with 1.1.1 on 2026-09-06 optimising online update of the program itself and adding an AI analysis feature, and 1.1.0 on 2026-09-03 adding an AI interceptor, fixing agent bugs and adding an incremental vulnerability database update.

The catalogue claims 340 tools across nine functional groups

The README claims 340 integrated security tools and says roughly 4 to 10 more are added per month, though the manual elsewhere says 3 to 9. The tools are grouped into nine categories, and the grouping shows the intended workflow rather than a simple catalogue: operations and defence covering incident response, webshell scanning, log analysis, packet capture, code audit and decompilation; information gathering for subdomain discovery, port scanning, fingerprinting, directory scanning, resource discovery and leak hunting; exploitation across middleware, CMS, framework, OA and application flaws, webshell management, scanners, database and XSS tooling; then combined exploitation with brute forcing, encoding, post-exploitation and command and control; cloud security; mobile tooling for apps and mini programs; wireless security; forensics and steganography work including firmware analysis; and environment tools for lab setups and AI tooling. The mobile and firmware categories are the ones that distinguish it from a generic pentest bundle.

Tools_list.md
Explanationphoto/
img/
storage/

The UI around this is a tabbed interface with a weapons library for downloading, installing and launching tools, a plugin library for Burp and Cobalt Strike extensions, the AI agent workbench, a vulnerability library, a submission box, a discussion forum with tool rankings, a bookmark navigation site, an announcements panel, a monitoring tab for GitHub tool versions and AI run logs, and a settings page for theme, launcher and download sources.

The library view has three display modes worth calling out. The default is a categorised layout with a tree navigation on the left. A full display mode expands every category so more cards fit on one screen. The third is a launcher mode, a small hotkey-invoked search box where typing filters and Enter launches, which is the mode that makes a catalogue this size usable daily rather than merely browsable.

Per-tool usage notes and bundled runtimes that stay out of your PATH

One design choice stands out from the screenshots in the manual: every tool in the library carries its own execution instructions, so you do not have to guess the command line. The README shows what that looks like for POC-bomber, where selecting the tool surfaces the interpreter path and flags it expects:

***********************POC-bomber**********************
..\Python38\python.exe pocbomber.py -h

That example also quietly explains the runtimes section. Tools that depend on an interpreter show a prompt to download the runtime once their download finishes, and if no prompt appears you can fetch it manually from the runtime settings. The manual is explicit about the isolation: the bundled Python and Java runtimes are independent of each other and neither adds to nor modifies any runtime already on your machine, serving only the tools inside the program.

That isolation is the single most thoughtful decision in the documentation. A security tool collection that installed into your system Python would be a genuine hazard, given the packages these tools pull. Restricting them to a private folder beside the executable means you can throw the whole directory away to clean up.

The library also supports batch work: select tools by scenario and install or update them in one action, with a download queue that shows current tasks and extraction progress. An update check syncs the tool list and reports whether the program itself or any installed tool has a newer version. And the plus button in the corner, also reachable by right-clicking empty space, adds your own `.exe`, `.bat`, `.cmd`, `.py`, `.jar` or shortcut into the library, including custom categories, which is how you fold tools the catalogue does not carry into the same workflow.

Eleven components the AI agent downloads into storage

The agent tab is the part that differentiates this from a download catalogue, and it is also the part with the longest dependency list. Before the agent and the vulnerability library work, the program downloads components into the `storage` directory: Python 3.11 as the agent runtime, Claude Code as an engine, a HexStrike engine as the orchestration core, HFinger for fingerprinting, NPS for tunnelling, Hermes as a helper, and OpenCode, Codex, Gemini CLI and Cursor CLI as further engines.

The remaining three are data rather than code, and they are what the vulnerability library searches: Nuclei Templates, Afrog POCs and Exploit-DB. The README gives the scale as 68,000-plus vulnerability entries and 1,800-plus fingerprints, with more than 300 tools, 30-plus plugins and 180-plus navigation bookmarks.

The download dialog offers two choices, download everything including optional engines, or skip, and it notes plainly that skipping leaves some functionality unavailable. That is the right way to present the choice, because the engines have very different footprints and most people want one.

Once running, the interface deliberately collapses the top and bottom bars to give the terminal the full window, restoring them with an in-page expand button. There is a browser open action that jumps to the same interface in a browser, a desktop workbench mode that presents it as a remote desktop when you are working from elsewhere, support for several concurrent windows, and session history you can reopen or delete. Mobile browser access is documented too, and NPS tunnelling is what makes that possible from outside the network. The repository description also credits a HexStrike-AI integration for automated scanning driven from the agent.

Vulnerability search depends on the agent service running first

One dependency in the manual is easy to skim past and then hit immediately: the README states that vulnerability search requires the AI agent service to be started first, because the vulnerability library's data is provided by the agent. In practice the search features are not independent of the agent components, so the order is download the agent stack, start it, then use the library.

The library itself is described as a unified search across Nuclei templates, Afrog POCs and Exploit-DB, with POC search and detail views rather than raw file browsing. Given three upstream sources with different schemas, whatever normalisation happens is happening inside the HexStrike engine rather than in the program's own code, which explains the dependency.

The monitoring tab covers two different things under one heading: watching GitHub repositories for new tool versions, and AI run logs. The 1.x changelog adds server-side AI monitoring and an AI interceptor, which reads as traffic observation and filtering on the agent path rather than as a new scanning feature. Without documentation beyond the changelog entries, the exact scope of the interceptor is not something the repository settles.

Settings, per the manual, cover theme, the launcher, download sources, display mode, and in 1.1.0 additions of zoom and height settings plus a terminal copy function. The launcher hotkey for search mode defaults to Alt + D, is configurable in settings, and the panel can collapse to a floating ball that disappears when idle, with a right-click on the search box or the ball switching between categorised and full display.

What the repository holds, and what that means for trust

The repository tree is short and worth reading carefully: a README, a tool list document, an image folder, an explanation photo folder and a `storage` directory. There is no application source in the tree, and the README does not name an implementation language or a license. The project description frames it as a tool marketplace for operations, security checks and study, with downloads, updates and automated install scripts.

That means this is a distribution and documentation repository rather than an open source one, and the distinction has practical consequences. The catalogue is the product, so the question that matters is where the 340 tools come from, how versions are pinned and whether checksums are verified at download time. The README describes a download source setting and a monitored tool list, which implies some version awareness, but it says nothing about integrity checking.

Two details in the documentation do speak to supply chain indirectly. The bundled runtimes are isolated from the host, so a tool cannot quietly poison a system interpreter. And every tool exposes its run command before you launch it, which at least lets you see whether something is being invoked in a way you did not expect.

What is missing is a stated policy for which tools are accepted. A submission box exists for the community to propose tools, and a rankings page suggests some curation process, but the criteria are not written down. The project has around 1,120 stars and 109 forks with 49 open issues, and the last push was on 2026-09-17, so it is being worked on actively. For an evaluation, the useful approach is to download the catalogue document, spot-check a few tools against their upstream releases, and watch what the program does on first launch.

Editorial conclusion

The honest read on this project is that it is a curated download manager with an AI workbench attached, not an open source security tool. The repository itself holds documentation, screenshots, an explanation photo folder and a tool list; the program arrives as a Windows release build or through a hosted file share. What the README does well is describe the operational details that matter, including the bundled runtimes that do not touch your system Python, the eleven components downloaded into `storage/`, the need to start the agent service before vulnerability search works, and the 20 GB of disk the tool catalogue assumes. What it does not settle is where the catalogue comes from, how supply chain is checked on 340 binaries, and how the agent service is exposed when you open it in a browser.

Frequently asked questions

Official sources

1. CuriousLearnerDev/Online_tools on GitHub
2. Issues
3. README
4. Releases