Live data from Hacker News

Stuxnet Source Code

github.com

91–100 of 127 posts

Re: Stuxnet Source Code

#91

Earlier quoted context omitted.

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 yo…

> 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 run…

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

Re: Stuxnet Source Code

#92

Earlier quoted context omitted.

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 yo…

> 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 run…

> 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.

Re: Stuxnet Source Code

#93

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.

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

Re: Stuxnet Source Code

#94

Earlier quoted context omitted.

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.

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.

Re: Stuxnet Source Code

#95
post #36

Earlier quoted context omitted.

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 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.

Re: Stuxnet Source Code

#96

Earlier quoted context omitted.

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

Re: Stuxnet Source Code

#97

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.

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.

Re: Stuxnet Source Code

#98
post #81

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.

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.

Re: Stuxnet Source Code

#99

Earlier quoted context omitted.

[flagged]

No casual antisemitism here. I would be very surprised if it turns out that Israel wasn't involved in Stuxnet. It's not like they don't have extremely good cyber capacity, or incentives to hinder an iranian nuclear program.

[flagged]

Re: Stuxnet Source Code

#100

Earlier quoted context omitted.

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

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 decisi…

>You don't really need ...

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

Post reply on HN