That article is sobering. The fact that this malware stayed under the radar for 20 years is pretty ominous in itself.
Fast16: High-precision software sabotage 5 years before Stuxnet
61–70 of 107 posts
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#62Earlier quoted context omitted.
My favorite part of the paper is that the “attack” isn’t just exploiting a bug — it’s exploiting how different components interpret the same input. Modifying an executable as it’s loaded into memory is one example, but the deeper pattern is the mismatch. What’s interesting about the malware in this post is that it goes one step further: instead of exploiting mismatches, it corrupts the computation itself — so every i…
Just curious, are you purposely mocking the LLM writing style?
That’s how everybody in academia, tech, and published authors in general used to write.
Where do you think the LLM is getting it from? ^_^
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#63IEEE-754 only mandates correct rounding for +-*/ and sqrt. Transcendentals (sin/cos/exp/log/pow) are explicitly allowed to vary in the last few ULPs, and glibc, musl, MSVC, and Intel SVML all do. PID is just basic ops, so libm divergence doesn't hit there, but motor vector control or sensor linearization touches these functions every cycle and small disagreements compound. Two firmware revisions can have zero source diff and still drift in production. The only thing that changed was the linked libm. It actually shows up in Payne-Hanek argument reduction and at the worst table-maker's-dilemma boundaries. Probably why safety-critical guidance pins a specific libm build instead of just "IEEE-754 compliant".
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#64sabotaging science must be the most morally corrupt thing you can do as a civilisation
The first thing I thought of was The 3-Body Problem series. If you've read the books (or watched the shows you'll know what I mean).
Even funnier as one of the co-author (Juan) and one of contributor (Costin) are both in the "3-buddy problem" podcast.
Obviously IOCs are presented.
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#65sabotaging science must be the most morally corrupt thing you can do as a civilisation
As a scientist and a father I can say that the most morally corrupt thing is doing bad things to children, not scientists.
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#66My favorite part of this was: That kind of notation, called SCCS/RCS, is the equivalent of finding a rotary phone in a modern office. Nobody uses it in 2005 Windows kernel code unless their programming background goes back decades, to government and military computing environments — The astrophysics lab I worked at in 2006 was still using svn and had a bunch of Fortran with references to systems from the 70s and 80s.…
Re-factoring code is a _panacea_ -- it's more likely factors that contributed to the code needing re-factoring in the first place, are very much in place still to contribute to the same condition repeating eventually, and another round you go. The factors that produce the causes of re-factoring, usually border on psychological causes embedded deeply within the brains of the developer or developers that are owners of the code. Habits, beliefs, convictions, even "professional traumas". Related here is Conway's Law, where the team, for all individual capacity and capability, cannot but build software that mimics the structure of the developers' ultimate (larger) organisation, thus tying the success of the former to the success of the latter. Re-factoring will only largely repeat the outcome if the organisation hasn't changed.
The exception being obviously a team approaching someone else's codebase -- including that of their predecessor, if they can factor in for Conway's Law -- to re-factor it.
But the same person or persons announcing re-factoring? I always try to walk away from those discussions, knowing very well they're just going to build a better mouse trap. For themselves.
Don't get me wrong, iteration of your own then-brain's product is all well and good, but it takes _more_ to escape the carousel. It takes sitting down and noting down primary factors driving poor architecture and taking a long hard look in the mirror. Not everything is subjective or equivalent, as much as many a developer would like to believe. It's very attractive to stick to "as long as we're careful and diligent, even sub-optimal design can be implemented well". No, it won't be -- this one is a poster-child exception to the rule if there ever was one -- your _design_ is the root and from it and it alone springs the tree that you'll need to accept or cut down, and trimming it only does so much.
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#67sabotaging science must be the most morally corrupt thing you can do as a civilisation
Killing children and justifying this form of murder by calling them terrorists takes a higher toll, imho.
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#68Interesting that this was discovered after embarking on a journey to understand how widespread the use of Lua is, in the exploits realm ..
I also wonder why they opted to make this an injectable worm and not just a side-loaded 'feature' of the OS?
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#69I recently read:
Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers
by Andy Greenberg
Very good book. Perhaps a follow up series will be needed with the new information coming out and of course what we have seen/learned since.
Re: Fast16: High-precision software sabotage 5 years before Stuxnet
#70My favorite part of this was: That kind of notation, called SCCS/RCS, is the equivalent of finding a rotary phone in a modern office. Nobody uses it in 2005 Windows kernel code unless their programming background goes back decades, to government and military computing environments — The astrophysics lab I worked at in 2006 was still using svn and had a bunch of Fortran with references to systems from the 70s and 80s.…
Re-factoring code is a _panacea_ -- it's more likely factors that contributed to the code needing re-factoring in the first place, are very much in place still to contribute to the same condition repeating eventually, and another round you go. The factors that produce the causes of re-factoring, usually border on psychological causes embedded deeply within the brains of the developer or developers that are owners of…
Did you mean to say placebo?
A panacea is a cure-all. So if code refactoring is a panacea then we should refactor code often.