MHDDoS: a 57-method DDoS testing toolkit for authorized load work

What MHDDoS is for, and who the README says may run it

MHDDoS is a Python 3 script that generates flood traffic against a target. The README calls it a "DDoS Testing Toolkit" with 57 methods, and the repository description calls it an attack script with 56 methods. That mismatch between 57 and 56 is the first thing a careful reader notices: the method table is the source of truth, and the count in the description has not been kept in step with it.

The stated audience is narrow. The README carries the line "For authorized testing and educational use only" and a warning not to attack systems, websites or networks without the owner's explicit permission. A second caution block states that MHDDoS is 100% free and that anyone asking for money is running a scam. That second note matters more than it looks: tools in this category get repackaged and sold, and the maintainer is telling you the upstream copy is the only legitimate one.

So the real use case is a person who controls both ends. You have a service, you want to know how it behaves when someone hammers it with malformed cookies, partial requests or a SYN flood, and you would rather run that from a script you can read than from a closed appliance. Anything else is outside what the project claims to support.

How the method list is organised across Layer 7 and Layer 4/3

The README splits methods into two tables. Layer 7 holds the HTTP-shaped ones: GET and POST floods, HEAD, a null User-Agent method called NULL, random Cookie, a minimal "GET / HTTP/1.1" request under PPS, Slowloris under SLOW, and a slow data-reading method called DOWNLOADER. Several entries are named after the protection they try to get past rather than the traffic they send: OVH, CFB for Cloudflare, CFBUAM for Cloudflare Under Attack Mode, DGB for DDoS-Guard, AVB for ArvanCloud, GSB for Google Project Shield, plus a generic BYPASS. There is also XMLRPC, which targets the WordPress /xmlrpc.php endpoint, APACHE, BOT for Googlebot-style requests, DYN for random subdomains, and TOR for onion targets.

Layer 4 and Layer 3 are the packet-level methods: TCP, UDP, SYN, OVH-UDP with randomised headers and a binary payload, CPS which repeatedly opens and closes proxy connections, and ICMP echo request floods. The README also lists utility and console helper commands alongside the attack methods, so not every entry in the table is a flood generator.

The naming is the honest part of the design. A bypass method is a claim about a specific vendor's filtering logic, and those claims age badly. When a CDN changes how it scores a request, the method that was written against the old behaviour does not announce itself as broken, it just stops working. Treat the table as a set of hypotheses to verify against your own target, not as a guarantee.

Installing MHDDoS and running a first authorized test

The repository root holds requirements.txt, start.py, config.json, Dockerfile, docker-compose.yml, and two Windows batch files, install.bat and run.bat. The README's installation section points at the same path. On a machine with Python 3 and git available, the documented route is to install the pinned dependencies and then invoke the entry point.

pip install -r requirements.txt

That file is worth reading before you run it. Alongside cloudscraper, certifi, dnspython, requests, impacket, psutil, icmplib, pyasn1, yarl and PyJWT, it pulls pyroxy directly from a git URL:

pyroxy @ git+https://github.com/MatrixTM/PyRoxy.git

A git-sourced dependency means pip needs network access to GitHub and will resolve whatever that repository serves at install time. It is not a version-pinned package from an index. If your environment forbids git dependencies, this is where the install stops.

The container path avoids that on the host. The Dockerfile is based on python:3.12-slim, installs git, copies requirements.txt first so the dependency layer caches, runs pip install -r requirements.txt, copies the rest of the code, and sets ENTRYPOINT to python start.py. The compose file builds that image, names the container mhddos, sets restart to unless-stopped, and bind-mounts config.json and the files directory into /app:

services:
  mhddos:
    build: .
    container_name: mhddos
    restart: unless-stopped
    volumes:
      - ./config.json:/app/config.json
      - ./files:/app/files

Those two mounts are the practical detail. Because config.json is mounted from the host, editing the local file changes the running container's configuration without a rebuild, and the files directory is where any supporting data the script reads should live. The compose file also carries a commented-out image line pointing at ghcr.io/mhprodev/mhddos:latest; it is commented out, so the default path is a local build.

With the container up, the interaction happens through start.py, which presents the method selection and console helpers described in the README. Before pointing it at anything, confirm you have written authorization for the target, because that is the condition the project itself attaches to every method.

Where MHDDoS stops being the right tool

The most concrete limitation is the one the README does not address: there is no documented rollback, no dry-run mode, and no rate cap described anywhere in the repository. A flood method sends what it sends. If you aim it at a production endpoint by mistake, nothing in the documented interface is described as stopping it before damage. That is a design choice typical of this class of tool, and it means the safety boundary lives entirely in your own process, not in the software.

The second limitation is verification. Methods named after specific vendors, CFB, CFBUAM, DGB, AVB, GSB and OVH among them, encode assumptions about how those vendors classify traffic. The README describes what each method does but does not state when it was last confirmed against the vendor's current behaviour, and no test suite is mentioned that would catch a method going stale. You find out by running it.

The third is scope. MHDDoS is a traffic generator. It has no measurement side: no latency percentiles, no error-rate reporting, no comparison against a baseline. If your actual question is "does my autoscaler keep up under load", a load-testing tool with a report is a better fit. MHDDoS answers a narrower question, which is whether a particular request pattern gets through.

Finally, the repository is not archived and the last push was on 2026-09-07, with releases v2.4.6 on 2026-09-02 and 2.4.5 on 2026-08-28 after a gap back to 2.4.4 on 2025-10-22. Recent activity is real, but the release history shows bursts rather than a steady cadence, so plan for periods without updates.

MHDDoS compared with a general-purpose load generator

The nearest alternative in practice is a general-purpose load generator such as ApacheBench, wrk, k6 or Locust. The difference is in what each one models.

A load generator is built to be measured. You give it a request definition and a concurrency level, it drives that pattern and reports throughput, latency and error rates, and the whole point is the number that comes out. MHDDoS is built to be varied. Its Layer 7 table is a catalogue of request shapes, malformed headers, null user agents, random cookies, minimal request lines, slow reads, and its Layer 4/3 table goes below HTTP entirely with TCP, UDP, SYN and ICMP. A load generator typically stays at the application protocol because that is where its metrics are meaningful.

That is the trade. If you need a defensible number for capacity planning, MHDDoS gives you no report to cite. If you need to know whether a specific filtering rule catches a specific malformed request, a load generator will not construct that request for you and MHDDoS will. The two tools are not substitutes, and running a conformance load test through MHDDoS would produce output you cannot use.

There is also a maintenance difference. Projects like wrk and k6 have small, stable surfaces. MHDDoS carries a much larger one, and every vendor-named bypass method is a surface that can rot independently.

Licence, packaging and the cost of keeping up

The repository is MIT licensed, and the LICENSE file sits in the repository root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained. What it does not do is grant you permission to attack anything. The licence covers the code, and the README's authorization requirement is a separate condition the project places on use. Those are two different things, and passing the first does not satisfy the second. This is not legal advice; if your situation is unclear, the LICENSE file and your own counsel are the references that matter.

The upgrade cost is dominated by the dependency set rather than the script. requirements.txt pins most packages to exact versions, including cloudscraper, certifi, dnspython, requests, impacket, pyasn1 and PyJWT, while psutil, icmplib and yarl use lower bounds. The unpinned git dependency on PyRoxy is the one that can change under you between installs. The Dockerfile mitigates this by copying requirements.txt before the rest of the code, so a rebuild reuses the dependency layer unless that file changes.

On the code side, the release cadence is uneven. Three releases landed between 2025-10-22 and 2026-09-02, with two of them inside a week. A burst like that usually means a fix or a new method, and methods added in a burst are the least likely to have been exercised broadly. If you pin to a release, read the diff between it and the previous one before upgrading.

Editorial conclusion

MHDDoS fits engineers who need to reproduce flood-shaped traffic against a lab target they control, and who can read Python well enough to audit a method before running it. It does not fit anyone testing a third party's service, anyone who needs a maintained guarantee, or anyone expecting a GUI: the entry point is start.py and the configuration lives in config.json. Before adopting it, check the methods you intend to use against the current README table, confirm the proxy list format the script expects, and read the LICENSE file in the repository root, because the MIT text there is what actually governs your use, not the warning banner.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MatrixTM/MHDDoS on GitHub
4. README
5. Releases