Stuxnet Source Code

A phenomenal piece of engineering and spycraft, this implant was the reason I wanted to apply for officer school at the airforce

Shortly after, the Snowden leaks would happen, which influenced my decision otherwise

They won’t agree and would file suit but legally this isn’t a highly tested area. The closest we get is Sony Computer Entertainment, Inc. v. Connectix Corp. as far as I’m aware and that can be seen as more of a win for the reverse engineering than Sony. The particulars are but different to be sure though.

Realistically it unlikely that anyone would attempt to decompile and fully reverse engineer excel and attempt to package it as a product that they own. It just doesn’t make sense practically. But throwing something in Jira isn’t the same thing as actually putting in the work to reverse engineer it and make it effectively a perfect replication. You don’t unbake the cake, you can’t. You just figure out a process to end up with the same cake.

As for TOS goes, that’s its own other legal issue that has a mixed history erring on the side of TOS not actually being enforceable.

The people who did this work I think are fine to ask people to respect their license. They don’t have to worry about the US/Israel knocking at the door to tell them they can’t claim ownership anyways.

I asked GPT to describe the main rootkit code. The high level view made it a little easier to find my way around.

https://chat.openai.com/share/d5f0f002-6739-4b0f-ad50-d71207...

    SetFastIoDispatch(): This function sets up the Fast I/O dispatch table for the driver. Fast I/O operations are a more efficient way to handle certain I/O operations in the Windows kernel.

    HookingFileSystems(): Hooks into the file systems (NTFS, FastFAT, CDFS) to intercept file system operations. It modifies system behavior by redirecting calls to these file systems.

    HookOne(): Hooks a single file system. It references a file system object by name and then attaches to it.

    DriverNotificationRoutine(): A notification routine called when the driver's status changes, such as when a device is attached or detached.

    AttachDevice(): Attaches the rootkit's device object to a target device in the system, allowing the rootkit to intercept calls to this device.

    IsAllreadyAttached(): Checks if the rootkit is already attached to a target device.

    CreateDevice(): Creates a device object for the rootkit, enabling it to interact with the system as a device driver.

    IsMyDevice(): Checks if a given device object belongs to the rootkit.

    SettingFlags(): Sets various flags for a device object to define its characteristics and behavior.

    AttachToStack(): Attaches the rootkit's device object to the device stack of the target device.

    OnFileSystemControl() and OnDirectoryControl(): These functions handle specific file system control and directory control operations, respectively. They are likely points where the rootkit intercepts and manipulates file system requests.

    SetCompletionFileControl() and SetCompletionDirControl(): Set up completion routines for file and directory control operations, allowing the rootkit to execute additional code when these operations complete.

    FileControlCompletionRoutine() and DirectoryCompletionRoutine(): Completion routines for file and directory control operations. They are invoked when file system and directory operations are completed, allowing the rootkit to intervene at this stage.

    FreeMdl(), AllocateMdl(), CreateWorkRoutine(), WorkerRoutine(): These functions manage memory descriptors (MDLs) and work items, which are kernel objects used for deferred or asynchronous work.

    GetOffsets(), FileCheck(), StrCheck(), TMPCheck(): These functions are involved in analyzing and potentially modifying file information during directory listings. They seem to be designed to hide or manipulate certain files or directories from being listed or accessed in a specific way.

    CallDriver(), IRPDispatchRoutine(), SetZero(): Helper functions for handling IRP (I/O Request Packet) processing and manipulating device extension structures.

    DriverEntry(): The entry point for the driver, setting up the rootkit when it is loaded into the system.

It already is quite difficult to recover to this level, even for a relatively small malware codebase this probably took hundreds of man-hours to decompile into a meaningful state.

To protect it beyond a basic level - You can try but it's a cat-and-mouse game. A sufficiently skilled reverser will drop a debugger on your program, execute the code until it's past any decryption and then dump it from memory. So better schemes to obfuscate applications have been developed, like VMProtect, which makes a simple virtual machine with a custom instruction set and uses it to obfuscate your application. It's of course possible to break that as well, but it takes more time and requires more skill.

Those who find stuxnet interesting, might appreciate some older art, just for fun to see where malware technology was in 2001: http://pferrie.epizy.com/papers/zmist.pdf?i=1

Author mirrored web page: https://z0mbie.dreamhosters.com/