Stuxnet Source Code | Hacker News Reader

Stuxnet Source Code

github.com

211 pointsJimmc414120 comments

According to the README, this is not the Stuxnet source code. Rather it's authored by people mentioned in the license by reverse engineers from the binaries. The real source code would probably have lots of juicy interesting things revealing how it was developed.

// TODO: תקן את זה

// TODO: משה מהמוסד אמר שזה בסדר

When an LTR Android system user selects RTL text, the selection markers are displayed LTR (the wrong way).

Wow I didn’t realize my iPhone would pick up on it and change the selection markers.

On LTR Android right now and the markers are RTL.

Relevant XKCD: https://xkcd.com/1137/

Surprisingly, I couldn't find a relevant XKCD for the post itself.

I remember first hearing about this while working at a US firewall company. The scale and precision of the attack kept this virus in the minds of everyone who appreciated what it proved capable of and the scale of social engineering employed to effect it. It kind of ushered in state-on-state cyber warfare, or at least, brought the reality of weaponized viruses to the public conscience.

Imagine if the same strategy were applied to biological warfare. Novel viruses tailored to be symptomatic and cause harm to just one specific world leader. If the technology exists, it could be the most formidable assassination tool available; a self-delivering, non-nuclear ace-in-the-hole for winning a war.

It's probably not that imaginary. There was much hand ringing during COVID that Russia's testing protocol for meeting Putin would allow them to collect DNA from world leaders.

https://www.reuters.com/world/europe/putin-kept-macron-dista...

And conversely, the article also mentions Putin’s social distancing, which could be a rational defensive measure against biological warfare that he believes might exist, rumors of an undisclosed serious health issue notwithstanding.

This concept is featured in The Dark Forest, the second book in the Three Body Problem trilogy. It was something where you could genetically tag someone and then if they woke up 50 years later from a chrono sleep, various systems were preprogrammed to have "accidents" around them, like self driving cars, etc.

It's also in the (1998) Metal Gear Solid game, where the protagonist is the unknowing carrier of a virus deadly only to specific key people.

It's also explorered in the plot of a Limitless (TV series) episode. There, it targets people that have the Khan marker in their DNA.

I was about to comment “hey, spoiler alert”, but then I realised that you’re talking about a game released a quarter of a century ago. More time has passed since MGS came out than passed between the Ramones’ first gig and MGS’s release. Mad.

There is a very interesting conference from Defcon 25 about this exact subject: https://youtu.be/HKQDSgBHPfY?si=N9C-5VRNMtIoCQBB

Thanks, this was interesting.

Unlikely this could ever be done. We share too much of the same firmware for something like to be possible. The average human genome has about 4-5 M single nucleotide polymorphisms (SNPs) - rate in the order of 1 SNP / 1000 bases. The rate is much lower in functionally important parts of the genome because those tend to be under evolutionary constraint / conservation.

...it is also the plot device of the latest bond movie...

You don't have to imagine it, you can just play Metal Gear Solid!

Corona ?

Targeting a specific individual may not be possible, but targeting an ethnicity might be practical

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

Indeed. It's incredible how important software and networking has become for humanity. Alot of people still don't realise how risky having mobile devices that can sense (GPS/audio/video) on our person and the invisible combination of the zero-day is to our liberty and security.

If you want the story of Stuxnet, Countdown to Zero Day by Kim Zetter is a great book. I have it on Audible and I've probably listened to it three times now.

The relevant Darknet Diaries episode:

https://darknetdiaries.com/episode/29/

Superb podcast. Shame he dropped down to only 1 episode per month

I remember having to write a presentation about Stuxnet while at Uni, it was insane.

At the time they reckoned the authors had a functioning QA environment to ensure it actually worked (broke) the Siemens PLCs they were targeting.

Nitpick but it was even harder, they wanted to keep the PLCs intact, report back normal operation, and change the control output specifically to destroy/damage uranium centrifuges

Yep. I'd be surprised if their QA environment didn't contain at least one uranium centrifuge.

You'd be insane to develop something of the complexity of Stuxnet and not include a full end to end test in the QA process. It would be incredibly embarrassing for this to fail.

Indeed. But as engineers it’s insane to think of having a testing environment that includes a uranium enrichment plant

Fair point. I can barely get access to a testing environment that contains a keycloak server.

You don't really need the centrifuge, just the inverter.

I was working in industrial control and automation at the time, there were sweeping changes to what could and could not be done and by whom at every level.

Old drives of all manufacturers that sat unused were audited and had to be brought up-to-date before any sale or change of hands could occur, serials were noted etc etc.

Never felt like a manufacturer decision since it occurred in unison almost globally.

>You don't really need ...

I think that project was way beyond the "really need" stage.

granted, I don't know that it would give you any extra information though.

Me too! It was such a pivotal moment.

Stuxnet didn't break anything. It was used to override the working regime of centrifuges and conceal this fact from being discovered.

I guess to be more exact, Stuxnet didn't break anything, but the PLC payload it delivered was designed to damage centrifuges, and that would have been the module under test in that QA environment

Wasn't it actually about spoiling the whole stock of Iranian's Uranium by applying damaging amounts of centrifugal force to it? I'm probably wrong about that, just asking.

the payload had a few modes of operation, IIRC

one was to spin it far faster than it should, then stop abruptly in an attempt to damage the centrifuge

one was to run it at the wrong RPM to spoil the product of the centrifuge

in either mode, it would replay 'good' data to make the centrifuge look functional to an administrator

the way I understood, a 'bonus goal' was to keep the Iranians unable to diagnose what was going wrong, both with their production process (producing bad stock) and the failures (promoting distrust in their engineers) - i can't find an article right now, but I remember reading they were churning through site engineers at the time - presumably firing them for the on-site failures of centrifuges or their inability to stop them

What always impressed me about Stuxnet wasn't the technical complexity, but the amount of spycraft that must have gone into identifying exactly what to program it to do, and what they could get away with.

France has enabled nuclear weapons programmes of many rouge states.

Maybe Israelis just went to the Elysee palace, and asked?

I don't know about French nukes, but French-affiliated aerospace has a general rep as being leakier than most. Eh, "leakier" is a negative way of putting it . . how about "loose-lipped"? One tools selection from a French-based vendor - a cloud option for uncontrolled data - was turned down by uniformed dudes from the program office, based on this prejudice. But a similar cloud offering from "Ze Germans"? Oh, that was A-OK. Both products seemed built from compressed pellets of Turkish dander - of course they did, this is DoD shopping - but one of them did have that snappy Aryan zing.

You don’t need to be a genius nor invest very deeply to figure out the technical details of introducing vibration into a high-speed centrifuge using SCADA (industrial automation protocol) in a barely noticeable way. As you suggest, tradecraft is the primary skill, jumping the air gap required an asset inside.

When this happened it was real edge of your seat stuff. I couldn't get enough of the podcasts covering this, nor of the book "countdown to zero".

This was one of the first reports on the subject https://krebsonsecurity.com/2010/07/experts-warn-of-new-wind...

* EDIT removed two paragraphs with wrong information

Have anyone seen the documentary about stuxnet (Zero Days, 2016)? It's incredible.

On the documentary, they mention another virus which was supposed to be even worse than Stuxnet, the project name was Nitro Zeus.

I remember reading a very well written article on stuxnet, detailing the entire way it worked. It was written in a very story-like way that built slowly until it revealed what the actual payload and impact was. Does anyone have a link to this article?

The book about it is a great read although I think it could have used a lot more editing. Chapters approach the timeline from different angles and as a result it does feel like later chapters are going over the same material too many times. Anyhow, you can read part of it here: https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/

I also remember reading something like that. Sorry that I can't help locate it.

Edit: Maybe it isn't what I wanted, but this article was good.

https://arstechnica.com/tech-policy/2011/07/how-digital-dete...

The Perfect Weapon by David Sanger.

Everything Sanger knows about Stuxnet he borrowed from Kim Zetter without attribution.

Goes double for Alex Gibney

The Symantec dossier [1] is a great read.

[1]: https://docs.broadcom.com/doc/security-response-w32-stuxnet-...

This Quora answer isn't article length but follows a similar story-like narrative and is well written imo. I remember reading this before I was working in tech and was amazed at how somebody(ies) came up with this

(Can't link direct URL as work filter doesn't allow Quora!)

https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web...

Check Ars Technica ?

Most likely this. I vividly remember reading this the first time I had heard about STUXNET.

https://www.quora.com/What-is-the-most-sophisticated-piece-o...

edit: someone beat me to it, I just didn't notice since it wasn't a direct link: https://news.ycombinator.com/item?id=38518286

Has anybody else here read Kim Zetter's great book Countdown to Zero Day? It's a wonderful look at the discovery of Stuxnet.

Yes i can't recommend this book enough if you are interested in Stuxnet or cybersecurity. Very detailed and thorough.

>This repository contains RCEd code extracted from Stuxnet binaries via disassembler and decompilers.

Is there a way to write code (make binaries) such that it would be extremely difficult to recover the source code via decompilers or a disassembler?

There’s always movfuscator [1]

[1] https://github.com/Battelle/movfuscator

Yes, there are many ways to do that.

When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read.

If you want to make decompiling even impossible, you could modify the machine code generated by the C compiler. Even slight moderations are already enough.

If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs.

And the countermeasures for that: DEP or pause the program after decryption and inspect its memory.

Yeah true. But at least the virus binary might be able to get passed the heuristic checks of a virus scanner.

> When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read.

Obfuscating C code shouldn't have any bearing on the decompilability of the output.

> If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs.

Unencrypting the binary at startup is somewhat easy to hook into. It's harder to decrypt each individual function when that function is called and then re-encrypt it after the function ends. Bonus points if you re-encrypt after each `CALL`.

This is stuff which was available back in 2003 -- that's when I first used techniques.

There are obfuscators that also make decompilation difficult. See the "two approaches" section at https://www.star-force.com/products/starforce-obfuscator/

> Obfuscating C code shouldn't have any bearing on the decompilability of the output.

This is the entire point of obfuscation and it absolutely does affect how easy the code is to reverse engineer. If it didn’t, there wouldn’t be a market for obfuscators.

> This is stuff which was available back in 2003 -- that's when I first used techniques.

It was available already in the 1980's, so I learned at the time when I was manually disassembling computer games hoping to be able to crack them.

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.

In Iran the copyrights of foreign works are not well protected. This lead to a lot of copying: western software and books are/were available for little more than the price of the writable CD-ROM or paper+ink you got it on. Translations of works were slightly more expensive, that the translator did have to get paid.

Since Windows (etc.) was free, and the university thought curriculum based largely on US uni-books, Windows is/was everywhere, even in sensitive environments. Window has the worst track record privacy and security (remember NSA_KEY?), and Iran got bitten by this very hard.

I'm not a fan of Windows but Stuxnet didn't happen because of Windows. Iran decided to spin up a nuclear program and Israel and the US had concerns and wanted to stop it. They had the resources to develop something tailored for this unique situation, which included windows, Siemens PLCs (IIRC), Centrifuges etc. and developed the malware based on their target. Even if their target used a different stack, they'd find a way to achieve the same result.

It's all about price. Attacking Linux will be harder, thus more expensive.

You make it sound easy, if that was the case they'd launch one attack every few months or so. This stuff is expensive, and making it 100x harder means 100x less attacks before the budget runs out.

Beyond Windows security issues, if you (an organization mainly) are enough motivated you can attack other OSes as well. There is anwjole industry about exploiting bugs for more secure platforms.

https://youtu.be/vjkBAl84PJs

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/

Can anyone explain why Stuxnet was admitted to and publicised so much. Aren’t secret operations usually kept… secret?

What was the motivation for the PR drive?

Chilling effect? "We have the ability to infiltrate any system and catastrophically destroy your hardware."

It was never admitted to though;

https://en.wikipedia.org/wiki/Stuxnet

It was publicised so much because it was the most advanced cyber weapon of its kind to ever been released.

> it was the most advanced cyber weapon of its kind to ever been released

Correction:

... it was the most advanced cyber weapon of its kind to ever been discovered

It was said that it would not have been discovered had it not been modified half way through its life to spread faster. This led to it spreading beyond the Natanz facility that it targeted.

I don't think there was a PR drive from the US/Israeli government, more like despite the US/Israeli government.

Remembering that the only reason we even know about stuxnet is because it was so aggressive that practically every PC on the planet caught it at one point. Also "stuxnet" is the name we gave it, it seems similar to another US Govt project that we know very little about codenamed "Olympic Games".

If it had not been so aggressive it would have gone completely unnoticed. Likely this is the case for a lot of state-sponsored malware. (especially coming out of FIVE-EYES).

A shame EQGroup tightened their security and we’ll possibly never see the other examples.

But probably for the best, considering the havoc EternalBlue caused.

This was 2012 with the kernel module 2014 added

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.

I just love that not only they copyrighted it, they even give excuses for it. You can't copyright someone else's work, regardless of how long you took to reverse-engineer it from disassembled binaries. Obviously the "rights owners" are not going to take those two guys to court (pity though, that would've been hilarious), but since the only reason those two could license this is that this is a computer virus and no one will claim authority, their claims to ownership of the code have no merit. I would love it if someone would publish or use it and not give them credit or "violate" the terms of the license in some manner, as I'd love to see those two try to claim their case.

Is the law clear in this? They created something different from the source material binary program.

This. They don't give you the same as the original virus code, they give you different code (namely readable one), than apparently compiles to the virus assembly.

It's plausible this took effort, so I think it's only fair if they license it - it seems also ethically fair, since their licence is permissive.

Wouldn’t that be considered a derivative work? You can copyright those.

I mean you cannot copyright derivative work.

I am sure big software companies wouldn't agree on this: decompile Excel or Photoshop and copyright the resulting code, and you shall get a nice lawsuit within days, if not hours. However, I guess there would have a bit of ToS breach, a pinch of DMCA and a lot of copyright infringement for reverse-engineering the software, maybe not that much for copyrighting the decompiled code.

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.

its right at the front of the git repo

>but both of us spent hundreds, if not thousands, of hours between ASM code trying to figure out what was behind those binaries and we are providing the product of our hard work (i.e. readable C code) to you for free

also

> It is not a simple job and it is not a short job, both our licenses are extremely permissive

>I'd like to ask you is that our job get recognized...show us your support by giving us credit for what we did

I do not know much about other jurisdictions, but in Germany a derived work has its individual copyright. For example, if one is translating a copyrighted work and publishes the translation without authorization, the translation is still prodected. The orginal copyright owner may sue the publisher of the translation, but the translator may sue anyone who publishes the translation without authorization.

They DO have copyright on the reverse engineering work. But that doesn't mean that they don't have full copyright over the code which looking at the LICENSE file alone it looks they are claiming. There should at least be a copyright line mentioning the original authors, even if just "Unknown Authors". They also obviously don't have permission to redistribute their derivative or to create it in the first place.

Its also ironic that they expect others to follow their license when they are fine with ignoring the copyright of the original hackers.

Ultimately though, copyright as we have it today is extremely silly and all they are asking for is attribution which IMO should be the default.

Technical wonder aside, the argument for using nuclear power over fossil fuels really hits a faultline in situations like this. I wonder how the majority of folk rationalise their viewpoint surrounding this situation without being seen as massively hypocritical?

A nuclear plant is just as weaponizable as any large dam...

Is it? The nuclear fallout of a plant may linger for longer than any destruction done by the water of a large dam I would say or do you mean something else?

A modern nuclear powerplant is incapable of exploding, at worst it can meltdown and leak radiation in the vicinity. This can of course have very bad results, but check Fukushima - more people died from the evacuation, and from a fire caused by a fuel tank in another city due to the natural disasters that caused the meltdown, than did from radiation. A radiation leak is easy to detect (and all areas near nuclear power plants in semi-developed countries have automated collection of radiation), and isn't an immediate death sentence.

Meanwhile when a dam breaks, immediately everyone and everything in its path will be obliterated. Vastly more people have died from dam failures than even the worst of the worst of nuclear power plant incidents, Chernobyl, where staggering incompetence met horrific design flaws and bugs. Something like that is impossible to happen today.

Certain types of nuclear reactors can be used to create fissile material; kind of super weaponisable?

https://en.wikipedia.org/wiki/Breeder_reactor

A dam failure was caused by the nationalistic Chinese government fighting against Japanese forces in the 30s. It killed hundreds of thousands of people.

Do you have an example of nuclear energy plant being weaponized to the tune of hundreds of thousands of deaths?

How, specifically?

What makes this worse than Colonial shutting down from a cyber attack?

Nuclear power is vastly better in terms of emissions, so I'd argue that blowing up a plant or two is worth stopping global warming. But why target plants when a dirty bomb attack would be way easier and more effective?

Additionally, most countries don't have the resources to pull off something like Stuxnet, and the ones that do have much more to gain through corporate and government espionage.

There is some problem there though - peacefully using nuclear power creates plutonium, which could be later extracted.

Not if you use other processes. But those don't produce plutonium so they haven't been invested in enough.

This is fearmongering disguised as "just asking questions" and critical thinking. If your concerns were genuine, the answers about the effectiveness of nuclear would be easy to find.

The exploited software is conveniently developed and controlled by Iran’s adversaries. In another episode of the geopolitical sabotage show,

“In January 1982, President Ronald Reagan approved a CIA plan to sabotage the economy of the Soviet Union through covert transfers of technology that contained hidden malfunctions, including software that later triggered a huge explosion in a Siberian natural gas pipeline, according to a memoir by a Reagan White House official.”

True or not, the risk of software Trojan horses in the big energy game was recognized pretty early. The lesson here is, potentially dangerous technology ought to be matched by a comprehensive security protocol.

Yep, don't run your centrifuges on windows 98 is probably sound advice.

>In January 1982, President Ronald Reagan approved a CIA plan to sabotage the economy of the Soviet Union through covert transfers of technology that contained hidden malfunctions..

Ooh now you've got me thinking about Chernobyl...

Nuclear energy generation and nuclear weapons have very little to do with each other. You can do one, without doing the other.

> I wonder how the majority of folk rationalise their viewpoint surrounding this situation without being seen as massively hypocritical?

It would be useful if you could point out what exactly are you feeling is hypocritical?

Technically, Stuxnet was and is an absolute masterpiece.

Infiltration (dropper/1. Main.c):

Stuxnet infiltrated systems by exploiting vulnerabilities in Windows. It often spread through infected USB drives. When a user plugged the USB into a computer, Stuxnet would use these vulnerabilities to install itself. In the dropper/1. Main.c file, the DllMain function is where this initial infiltration mechanism is initiated. This function sets up the malware in the system after it's been triggered, typically by the insertion of the infected USB.

Staying Hidden (dropper/2. STUBHandler.c):

Once installed, Stuxnet used rootkit techniques to hide its files and processes from antivirus software and the system’s administrators. In dropper/2. STUBHandler.c, the code manages the hiding of Stuxnet's activities, including concealing its files and processes, making the malware invisible to regular detection methods.

Verifying the target (dropper/3. OS.c):

Stuxnet was designed to act under specific conditions. It checked the infected system to determine if it matched its target - typically industrial control systems, particularly those using Siemens software and PLCs. In dropper/3. OS.c, functions like CheckSystemVersion ensure the system is compatible, and potentially, if it matches the target specifications, before proceeding further.

Delivering Payload through PLCs (dropper/6. MemorySections.c and beyond):

real damage was done by manipulating the PLCs controlling the centrifuges. Stuxnet altered the commands sent to these PLCs, causing the centrifuges to spin erratically and eventually fail. In dropper/6. MemorySections.c file likely includes functions for loading the malware's payload into memory, but the specific code targeting PLCs might be in other parts of the codebase that aren't as clearly identified.

Did it also spread in the West? How did they prevent it from affecting also friendly countries nuclear programs, is Iran the only country working at that stage of the technology?

Pretty sure it was delivered by usb not internet access, plus stuxnet was designed to work in a very specific environment (iran nuclear plant)

> plus stuxnet was designed to work

... its way towards ...

> a very specific environment (iran nuclear plant)

Stuxnet was a full stack of plugins (which lends huge weight toward the early "big team" design and build theories of first observers).

There was a payload intended for very specific centrifuges ... and there was replication toward target logic ( Farsi language | locale seeking targets for copying ) IIRC.

The "work" of Stuxnet wasn't limited to screwing up the centrifuges, it also had seeking and limited comms.

To add onto that, the public infection was meant as a smoke screen to provide cover for the CIA setting up a fake business to enter the nuclear facility and installing it via USB. I’m not sure what kind of value the smoke screen created. Maybe created some confusion in Iranian intelligence services as to how stuxnet invaded? But ultimately knowledge of infection was counter productive as stuxnet was design to subtly change the control parameters so that the system would get damaged in a hard to detect way (spinning centrifuges slightly faster than they should have if I recall correctly)

Worth a watch on the subject: https://www.youtube.com/watch?v=U_7CGl6VWaQ

Looks like most of this reply is ChatGPT generated...

"but the specific code targeting PLCs might be in other parts of the codebase that aren't as clearly identified" is something I've seen it generate when I asked details about a codebase as well, but it didn't have all the details.

The grammar is poor in places suggesting human editing, but I'll bet 10 bucks this is mostly ChatGPT too. OP testing a new GitHub code walkthrough tool? 1 day ago OP professed being quite familiar with ChatGPT's capabilities. OP, next time just give us a link to your tool's beta analysis of the repo.

Also, it is mostly wrong. The whole /dropper part is the initial loader, which has nothing to do with either hiding the presence or the actual PLC payload. Effectively it is an somewhat obfuscated stub for obfuscated self-extracting archive that is an dll and not executable.

Reply on news.ycombinator.com