# Sadpainy/Stuxnet: a reconstructed Stuxnet codebase for static analysis on Windows XP and Windows 7

> Sadpainy/Stuxnet is a reverse-engineered reconstruction of the 2010 Stuxnet worm, published under AGPL-3.0 and aimed at malware analysis and ICS defence research. It only targets Windows XP and Windows 7, and the README states it is not a deployable piece of malware.

**Sadpainy/Stuxnet** — Stuxnet, Here reproduced by me, Only researchs for educations purposes. It set work on Windows XP and Windows 7 only.

- Repository: https://github.com/Sadpainy/Stuxnet
- Stars: 577 · Forks: 106
- Language: C
- License: AGPL-3.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/sadpainy-stuxnet

## What Sadpainy/Stuxnet is, and who the reconstruction is for

Stuxnet needs little introduction as an event. The interesting question for an engineer is what this particular repository gives you that a Symantec dossier or a conference talk does not: a source tree you can open in an editor and step through module by module. The README describes it as "a strictly educational and research-oriented reconstruction of the infamous Stuxnet worm", derived from decompiled binaries, and says it "preserves the original logic and attack vectors while structuring the codebase for readability and analysis". That last clause is the whole value proposition. Decompiler output is usually a wall of numbered subroutines; a reconstruction claims to have renamed things and split them into directories that map onto the components described in published analyses.

The intended audience is narrow and the README names it explicitly: malware analysts studying APT code logic, defensive researchers writing detection content such as YARA rules or Snort signatures, and academics looking at the intersection of cybersecurity and critical infrastructure protection. If you are an ICS engineer trying to understand what a Step 7 hook does to a PLC download, the s7otbxdx and s7aaapix modules are the parts worth your time. If you are looking for something to run, stop here.

The disclaimer is unambiguous: the code is "not intended to be used for any malicious purposes, nor is it a deployable piece of malware". Treat that as a description of the artefact, not just a legal shield. A reconstruction assembled from decompiled output, with a build badge that reads "Build Unstable", is not the same thing as the original binary, and the README does not claim functional equivalence.

## Module map: loader, S7 hooks, and the two rootkit drivers

The repository is organised by the modules identified during analysis of the original samples, and the README's component table is the fastest way to orient yourself. The loader and dropper is winsta.exe with a companion ~WTR4141.tmp, described as the entry point handling initial infection, privilege escalation and deployment of the other components. Privilege escalation itself sits in ~WTR4132.tmp, which the README says exploits a Win32k.sys vulnerability to reach system level.

The two hook libraries are the parts with the most instructional value. s7otbxdx.dll is described as a malicious replacement for the original s7otbxsx.dll, intercepting communication between Step 7 and the PLC. s7aaapix.dll intercepts AUT (Automation Tool) API calls inside the Step 7 engineering environment. Reading those two side by side shows where the worm sits in the engineering workflow rather than in the runtime, which is the detail most second-hand summaries lose.

Persistence and concealment are handled by mrxcls.sys, a kernel-mode driver the README says hides files, processes and registry keys via SSDT hooking, and mrxnet.sys, which filters file system requests and enables peer-to-peer propagation. The payload module is s7plcmain, described as the core logic behind the frequency tampering attack. The top-level directories in the repository (CONN/, Complnd/, Desktop/, DieEinzelheit/, Dropper/, Main/, Rootkit/, s7otbxdx/, xor/) do not map one-to-one onto that table, so expect to spend the first hour working out which directory corresponds to which component.

## Execution flow from USB infection to OB1/OB35 tampering

The README lays out a twelve-stage execution flow, and the useful part is the branch in the middle. Stages 1 and 2 are the initial infection vector (USB or network) and the dropper with escalation. Stage 3 is environment reconnaissance: the worm checks for specific Siemens software (WinCC, Step 7) and specific target PLCs (S7-315 and S7-417). Stage 4a installs the S7 hooks when a target is found. Stage 4b is the case that matters for anyone studying spread: on a non-target machine the code self-destructs or idles.

That check is why Stuxnet is studied as a targeted weapon rather than a generic worm. Propagation continues through USB LNK exploits, network shares via the Print Spooler, and peer-to-peer, but the payload only arms itself against a specific configuration. From there the mechanism is a DLL injection that intercepts the s7blk_write function call, followed by code injection: when a user downloads a project to the PLC, malicious code is appended to the OB1/OB35 blocks. The README states that the PLC then executes the manipulated code, driving connected variable frequency drives to abnormal high or low frequencies and causing mechanical damage.

Stages 9 through 12 are the cleanup layer: install the MRxCls rootkit, hide files and registry keys, load the network module MRxNet, and propagate peer-to-peer. Note the ordering. Concealment happens after the payload has already been delivered, which is worth keeping in mind if you are mapping this flow onto detection opportunities.

## Building the dropper and the S7 hook library

The README is explicit that this codebase is "designed for static analysis and debugging in a controlled virtual environment" and is not intended for live deployment on critical infrastructure. The stated requirements are Microsoft Visual Studio 2019 or 2022 on Windows, or mingw-w64, with Windows XP or Windows 7 as the target OS for driver compatibility. Kernel drivers need the Windows Driver Kit 7600.

Start by cloning the repository and moving into it. The README gives these two commands:

```bash
git clone https://github.com/Sadpainy/Stuxnet.git
cd Stuxnet
```

The user-mode modules build separately. The main dropper is built with nmake from the winsta directory, using the Makefile.win that the README names:

```bash
cd winsta
nmake /f Makefile.win
```

The S7 hook library is compiled directly with cl, linking against user32 and ws2_32:

```bash
cd ../s7otbxdx
cl /LD s7otbxdx.c user32.lib ws2_32.lib
```

What you should see is a compiled user-mode artefact in each directory. What you should not expect is a smooth experience. The repository's own badge reads "Build Unstable", and the README does not document a build for the kernel drivers beyond naming WDK 7600, nor does it list expected compiler warnings or a known-good toolchain combination. The tests badge says passing, but the README never says what the test suite is or how to invoke it, so that badge is not something you can reproduce from the instructions given.

## Analysing the modules in an isolated VM

The README's analysis setup is three steps and reads like standard malware-lab hygiene. First, isolate the environment: a virtual machine in VMware or VirtualBox with host-only networking and internet connectivity disabled. Second, load the .dll and .sys files into IDA Pro, Ghidra or x64dbg. Third, observe behaviour with Process Monitor, Process Hacker and Wireshark.

That is a sensible workflow for reading the hooks, and it is the only workflow the README supports. What it does not provide is any guidance on the practical friction. The target OS is Windows XP or Windows 7, both long out of support, so you are standing up an end-of-life guest to run anything dynamically. Driver signing behaviour on those platforms differs from current Windows, and the README does not address signing at all, which means the kernel modules may or may not load depending on how your VM is configured. There is also no described snapshot or rollback procedure, so plan your own before you execute anything.

The documentation also does not explain how to verify that a rebuilt artefact matches the behaviour described in the component table. If your goal is detection engineering, that gap matters: you can read the reconstructed logic, but confirming that a rebuilt binary behaves like the original sample is left entirely to you.

## Where this reconstruction is the wrong tool

The clearest limitation is stated by the project itself. It is not deployable malware. Anyone hoping to obtain a working sample for testing detections against live behaviour will be disappointed, and that is by design. The README also restricts the target to Windows XP and Windows 7, so the code will not exercise modern Windows internals, and any detection you write from it will be aimed at a platform almost nobody still runs in production.

There is a second, subtler problem. A reconstruction derived from decompiled binaries is an interpretation. The README says it preserves original logic and attack vectors, but it also says the codebase has been restructured for readability, and those two goals pull against each other. Renaming, reordering and splitting code is exactly where a reconstruction can drift from the sample. For an academic reader that is acceptable. For anyone who needs fidelity to the original binary, it is not, and the README does not offer a mechanism to check the reconstruction against the samples.

Finally, the licensing is worth pausing on. The README's Legal and License section says the project is licensed under the GNU General Public License v3.0, while the repository is tagged AGPL-3.0. Those are different licences with different obligations, and the README does not reconcile them. If you plan to redistribute anything derived from this tree, resolve that discrepancy before you rely on either.

## Reading the decompiled original instead

The obvious alternative is to skip the reconstruction and work from the primary sources the README itself credits: the Symantec W32.Stuxnet dossier and Kaspersky Lab's analysis, both named in the Acknowledgements section. Those documents describe the same modules, the same Siemens targeting, and the same OB1/OB35 injection, but they are prose and diagrams rather than source. The difference in approach is one of fidelity versus readability. A vendor dossier is authoritative about what the sample did, because it was written from the sample. It will not let you click into a function and follow a call path.

That trade-off cuts the other way too. If your goal is to understand the attack chain well enough to explain it in a report, the dossier is faster and more reliable than a reconstructed tree with an unstable build. If your goal is to write detection signatures or to trace exactly how a hook intercepts s7blk_write, a source tree is more useful than prose, even an imperfect one. The repository also ships a copy of the Symantec Stuxnet 0.5 dossier as a PDF alongside the code, which suggests the author expects readers to use both together rather than treating the reconstruction as self-sufficient.

A third option is to work from the original binary samples directly. That gives maximum fidelity and maximum effort: no renaming, no restructuring, and no README to tell you which subroutine is the loader. The reconstruction exists precisely to spare you that first pass, and the price is that you inherit someone else's interpretation of the decompiler output.

## Conclusion

Adopt this repository only as a reading and instrumentation target inside an isolated VM, and treat the build badge as a warning rather than a promise. Anyone who needs a working, deployable artefact, or who wants to run the code on a modern Windows host, is in the wrong place: the README restricts the target to Windows XP and Windows 7 and calls the output non-deployable. Before spending time on it, verify three things: that the winsta and s7otbxdx directories actually contain the Makefile.win and C sources the build section names, that WDK 7600 is available if you intend to touch the kernel drivers, and that the AGPL-3.0 terms are acceptable for however you plan to redistribute anything derived from the tree.

## FAQ

### What is Stuxnet?

The README describes Stuxnet as widely recognized as the first known cyber-weapon designed to cause physical destruction to industrial control systems, specifically targeting Siemens Step 7 software and S7-300/400 PLCs. This repository is a reconstruction of it for educational and defensive research, not the original sample.

### What language is Stuxnet written in?

The repository lists C as its primary language, and the build instructions compile C sources such as s7otbxdx.c with cl. The README does not state what language the original 2010 samples were written in.

### Is there a documentary about the Stuxnet virus attack?

The README does not mention any documentary. It credits written threat intelligence instead, naming the Symantec W32.Stuxnet dossier and Kaspersky Lab analysis in its Acknowledgements section, and the repository includes a copy of the Symantec Stuxnet 0.5 dossier as a PDF.

### Can you give me an example of cyber warfare?

The README frames Stuxnet itself as that example, describing it as widely recognized as the first known cyber-weapon designed to cause physical destruction to industrial control systems. The repository reconstructs the code behind that attack for study rather than use.

### What was Operation Olympic Games?

The README does not mention Operation Olympic Games anywhere in its text, so this repository gives no information about it. The material covers the Stuxnet modules, execution flow, build steps and licence only.

## Sources

- [Issues](https://github.com/Sadpainy/Stuxnet/issues)
- [License: AGPL-3.0](https://github.com/Sadpainy/Stuxnet/blob/main/LICENSE)
- [README](https://github.com/Sadpainy/Stuxnet/blob/main/README.md)
- [Sadpainy/Stuxnet on GitHub](https://github.com/Sadpainy/Stuxnet)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sadpainy-stuxnet