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. The code ran perfectly well thanks to modern optimizing compilers and having moved from Vax to Linux in the 90s, it was a surprisingly seamless transition.
It reminds me of a conference talk I’ve referenced before “do over or make due” basically implying rewriting large amounts of mostly functioning code was not worth the effort if it could be taped together with modern tools.
Ha, I worked for a company that until ~2012 still used RCS-backed SCM, absolute hack job on a shared file share that wrapped RCS with a "project file" to allow a tree of specific revisions for a "project". "MKS" it was called. And by the sound of it the "old" '90s version, not the java EE rewrite.
That meant the files has the entire "$Revision: 1.3 $" nonsense and "file changelog" at the top too - though many newer files never bothered to include the tags to actually get RCS to replace them. Inconsistent as hell.
And while the "family" of devices the software was for traces it's origin to the mid '90s, functionally none of the code was older than ~5 years at that time.
Naturally even with only a few tens of engineers it regularly messed up, commits stepped on each other's toes and the entire tree got corrupted regularly. For fun I wrote a script that read it all and imported the entire history into git - you only had to go back a few years before the entire thing was absolute nonsense.
I have no idea why that was still being used then, but I assume it had been in use from the very start of that entire hardware family. Perhaps as it was fundamentally a "hardware" company - which until surprisingly recently seemed to consider "source control" to be "shared folders on remote machines" - "software" source control wasn't considered a priority.
The issue was the rcs files were simply corrupt - no matter what tool you used the older deltas were just bad. Just people didn't notice/care as they were "old" revisions.
And I couldn't find any tool that supported the mks "project" files that linked multiple rcs revisions into a single "commit", so something a little custom was needed anyway. At least for the ancient mks version used.
Quite a bit of effort was put into it during the "official" migration, but they eventually gave up too as even the oldest backup archives they could find had the same issues.
If you're using R in 2026, you're probably invoking code compiled from Fortran from the 70s/80s somewhere along the line. It's a foundation for a lot of numerical computing.
Yeah, I used to be skeptical of the government provenance of things like Stuxnet (I am not any more, I'm fully sold, like everyone else), and notes like this were why. People used RCS well into the 2000s! RCS as a tool had virtues over SVN and CVS.
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 infected system agrees on the same wrong answer!
More broadly: any interpretive mismatch between components creates a failure surface. Sometimes it shows up as a bug, sometimes as an exploit primitive, sometimes as a testing blind spot. You see it everywhere — this paper, IDS vs OS, proxies vs backends, test vs prod, and now LLMs vs “guardrails.”
Fun HN moment for me: as I was about to post this, I noticed a reply from @tptacek himself. His 1998 paper with Newsham (IDS vs OS mismatches) was my first exposure to this idea — and in hindsight it nudged me toward infosec, the Atlanta scene, spam filtering (PG's bayesian stuff) and eventually YC.
The paper starts with this Einstein quote "Not everything that is counted counts and not everything that counts can be counted", which seems quite apt for the malware analyzed here :)
On Linux, with a compose key, it's <compose><-><-><.> (at least with the settings I have, I don't think I overrode that one). "⸻" is even more fun. You can even make your own sequences, e.g. I've got <compose><O><h><m> for "Ω", and <compose><m><u> for "μ", very handy for electrical stuff like "160μA at 1.8V needs a resistance of 1.25kΩ, dissipating 288μW".
On a Mac, at least, the "correct combination of buttons" is trivial and easy to remember, even for someone like me who rarely uses em-dash. (But, I want to start using it more because I'm sick to death of people treating it as a scarlet letter.)
> used to be skeptical of the government provenance
Do you mean skeptical on which government was responsible or that it was in fact a government effort?
I can see how attribution could be debatable (between two main suspects mainly), but are / were there any good arguments against this being a gov effort? I would find it highly unlikely that someone other than a gov could muster up so much domain knowledge, source pristine 0days and be so stealthy at the same time.
I didn't want to give bumptious government CNE teams that much credit, and also a lot of the indicators people were giving of state origin didn't seem all that predictive. I don't agree with your premise that it takes a state-level adversary to collect the domain knowledge needed to do this stuff, and I certainly don't agree about the "pristine zero days".
I do wonder if these breadcrumbs were also left intentionally. “Oh look, we are using old stuff, don’t be afraid!” Or for some other reason. It is a little surprising to pull off such a sophisticated attack and miss details you could find running ‘strings’ unless I’m missing something and this part was encrypted.
I think that in the time period we're talking about, RCS wasn't really even all that old. Like, RCS is old, sure, but it was also in common use especially by Unix systems people; it's what you might have reached for by default to version your dotfiles, for instance.
Yes, but even back then I was aware of the sections in executables (wasn’t this where it was found?) and any neckbeard from the 70s and 80s might be even more so aware. That said, yeah, sure, it’s a very possible and understandable oversight, but I’m weary because of all the text in viruses and such as indicators. Seems like a pass over ‘strings’ would be obvious. Though. TIL, strings doesn’t necessarily scan the entire executable.
The same binary has encrypted strings so I assume there was a pass, but if you look at the source control strings they seem to decrease the appearance of maliciousness, even today they are out of place for malware
Does that mean that three-letter agencies were/are able to recruit from the fields for each type of malware? For example, fast16 might actually be written by someone who used to write scientific calculation software, while Stunex was written by someone who used to work for Siemens?
Don't think of it as a materials simulation engineer being recruited and trained on how to write complex malware.
Rather this was developed by a team of 6-8 people. Maybe two or three of them working on the implant, another engineer handling the exploits and propagation, and yet another building the LP and communications channels. They are supported by a scientist with deep knowledge of the process they are messing around with (say developing nuclear weapons), and a mathematician that knows how to introduce subtle and undetectable errors.
I doubt you will find an answer here, but a few bits of anecdata:
1. CIA had recruiting events that invited STEM majors at my university, I suspect they do this very broadly.
2. Our funding came partially from the Air Force and part of the rules was our data and source had to be open. We know from conversations and other details from integrating with Air Force partners that they had models like ours that were an order of magnitude more accurate because they amalgamated models from all academics in our field and had their own career scientists on staff (often coming up through military ranks)
Try to remember how hypothetical everything tended to be before Snowden. And 'twas a meager pittance that was revealed. They have toys that'd blow minds and people yee'd swear weren't people. It's all fun and games to poke fun, but holy shit those guys are NTBF'dW.
Every academic institution, every school, all under the radar of recruitment and more. It's difficult to believe, but the network is real.
There are certainly people here on HN who've been solicited, most who'll never mention it.
It's fun to imagine, though, what tight groups of highly motivated, stupidly intelligent people can do when they collectively commit to doing so - and with a hefty budget to assist.
Fun to imagine that and painful to think of what we could have if such efforts and budgets were put toward education, healthcare, social welfare, public infrastructure + reliability, etc.
Exactly. But there's ideology, and there's reality. You know how pervasive and colossal the black budget is. We could be, as a society, almost unimaginably advanced of where we are, sans such things, sans the modern patent system, sans greed, sans corruption.
But we are, precisely where we are
Edit: I thought it prudent to leave a reminder, that the US military operates beyond patent regulations. If they want or need something, the silly games end there. And they do what they will.
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.
I mean to write "not a panacea", my bad. That it's not the universal cure people think it is. And people _do_ think that re-factoring will magically solve problems, while it doesn't do all that much in practice, less so when you factor in the costs spent on re-factoring.
We used cvs, but did switch to svn before/around 2006, but I could be mixing that up. We did not switch to git even by 2012 when I left.
The reference to the 70s and 80s code didn’t imply it was version controlled before svn/cvs though if that’s what you meant, but by that time it was and still had old timestamps commented in the text files.
I just wanted to say that "still using svn in 2006" sounds odd when talking about version control system that existed just for several years and what turned out to be its replacement was 1 year old.
gcc, for example, transitioned to subversion in 2006 and switched to git only in 2019 [0]
I miss the days of knowing who last touched every source file and precisely what version it was:
$ what /usr/bin/file
/usr/bin/file:
PROGRAM:file PROJECT:file-106
$File: apprentice.c,v 1.309 2021/09/24 13:59:19 christos Exp $
$File: apptype.c,v 1.14 2018/09/09 20:33:28 christos Exp $
$File: ascmagic.c,v 1.109 2021/02/05 23:01:40 christos Exp $
$File: buffer.c,v 1.8 2020/02/16 15:52:49 christos Exp $
$File: cdf_time.c,v 1.19 2019/03/12 20:43:05 christos Exp $
$File: cdf.c,v 1.120 2021/09/24 13:59:19 christos Exp $
$File: compress.c,v 1.129 2020/12/08 21:26:00 christos Exp $
$File: der.c,v 1.21 2020/06/15 00:58:10 christos Exp $
$File: encoding.c,v 1.32 2021/04/27 19:37:14 christos Exp $
$File: fsmagic.c,v 1.81 2019/07/16 13:30:32 christos Exp $
$File: funcs.c,v 1.122 2021/06/30 10:08:48 christos Exp $
$File: is_csv.c,v 1.6 2020/08/09 16:43:36 christos Exp $
$File: is_json.c,v 1.15 2020/06/07 19:05:47 christos Exp $
$File: is_tar.c,v 1.44 2019/02/20 02:35:27 christos Exp $
$File: magic.c,v 1.115 2021/09/20 17:45:41 christos Exp $
$File: print.c,v 1.89 2021/06/30 10:08:48 christos Exp $
$File: readcdf.c,v 1.74 2019/09/11 15:46:30 christos Exp $
$File: readelf.c,v 1.178 2021/06/30 10:08:48 christos Exp $
$File: softmagic.c,v 1.315 2021/09/03 13:17:52 christos Exp $
$File: file.c,v 1.190 2021/09/24 14:14:26 christos Exp $
...
WHAT(1) General Commands Manual WHAT(1)
NAME
what - show what versions of object modules were used to construct a file
SYNOPSIS
what [-qs] [file ...]
DESCRIPTION
The what utility searches each specified file for sequences of the form
"@(#)" as inserted by the SCCS source code control system. It prints the
remainder of the string following this marker, up to a NUL character,
newline, double quote, `>' character, or backslash.
The following options are available:
-q Only output the match text, rather than formatting it.
-s Stop searching each file after the first match.
EXIT STATUS
Exit status is 0 if any matches were found, otherwise 1.
SEE ALSO
ident(1), strings(1)
STANDARDS
The what utility conforms to IEEE Std 1003.1-2001 ("POSIX.1"). The -q
option is a non-standard FreeBSD extension which may not be available on
other operating systems.
HISTORY
The what command appeared in 4.0BSD.
BUGS
This is a rewrite of the SCCS command of the same name, and behavior may
not be identical.
macOS 26.4 December 14, 2006 macOS 26.4
For posterity, there was a subthread about how the main submission was some kind of AI generated article. This appears to have been deleted. (Or some HN magic happened where threads are merged? I don't know.)
Which while apparently being AI generated, does have some additional information over the other sources. (Which have apparently also been deleted from the thread.)
For example it makes a reference to this relevant paper, though it fails to cite it properly.
IEEE-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".
This is an amazing find. I'm very curious regarding the specific targets of these rules, and in the exact changes to the results. Wonder if they will only make a difference in simulated conditions super specific to nuclear reactors?
I dug into how software such as LS-DYNA could have been modified. Take for example the EOS_JWL equation at [1] (vendor website, public manual) which is implemented by LS-DYNA. This equation seemingly could be used, alongside other equations implemented within LS-DYNA, to answer questions such as how long it'd take for a detonator in a missile warhead to detonate a primary explosive substance to cause a particular pressure wave at 20m distance. Working backwards from this result may provide a required fuze timing. Equations and parameters used with LS-DYNA are derived from scientific research, such as [2], which is US government research from the 1980's providing experimental results for high explosive substances. One such example from [2] is experimentation to determine the friction an explosive substance has against different materials which may enclose it. Given the software has equations purposely designed for explosives modelling, it'd be fairly easy to just target those equations in ways which will just slightly frustrate a scientist/engineer into thinking they've got a problem with the manufacturing quality of steel, rather than suspect the software is deliberately adding +/-20% noise to a friction coefficient.
The modern equivalent may be something like {insert adversarial country name here} downloading a pirated version of Ansys Autodyn 2026 R1 shortly after official release from a Chinese cracking group on a Chinese bulletin board forum, where just a handful of seeders sit behind Russian ISPs. And then {insert adversarial country name here} later notice during experimentation that the software calculations never quite match experimental results, and maybe then suspecting the pirated copy was deliberately tampered with and distributed. However, this situation may be fairly easily solved by {insert adversarial country name here} by just grabbing a copy of the software they want off a hacked network of a random university or engineering consulting firm in the aerospace and defence sector. Plus it may be naive to assume {insert adversarial country name here} in 2026 couldn't develop their own software from scratch (and/or perform calculations manually), or just rely on experiments, to achieve whatever outcome some other nation state group of hackers is trying to avoid. {insert adversarial country name here} would have to have experimentation equipment and skills regardless to verify manufacturing quality. Simulation software mostly reduces costs and timeframes by reducing the number of mockups and physical experiments needed. For example, it's cheap to run 1000 simulations of an artillery shell hitting vehicle armor plates as shown in [3], and more expensive and time consuming to do the same repetitive thing in the real world.
The govemerment, 1984-like agencies and some others in Middle East will truly hate Guix and reproducible computing being portable to Powerpc and even legacy machines. There more heterogeneous your setup, the better.
Thank you for sharing this. I was recently pushing the limits of precision computing and this illuminated a part of my research. It built on top of largely government funded research, where I found a surprising dearth of available precision frameworks with verification. Perhaps national security interests, as elucidated by the original poster, discourages transparency of methods for arbitrary precision calculations.
Haha it's a fun finding though; The source control comment feels a little off; I'm sure there were SCCS (hmm or did cvs use similar?) still around at that time.
I believe that comment was specific to it being unusual in Windows software, suggesting the developers were also working in UNIX stuff (where usage SCCS/RCS was common).
I was about to respond saying what a terrible article it was, as it reads as if the author has no idea what he was talking about. Attempting to paraphrase the original article would explain it.
Not just Iranians, something odd it's happening with the JPL people.
Shitty and brainwashed people in Middle East comes in both ways.
Can't wait to the Chinese secularizing all the Abrahamic bullshit by brute force -not by war, but my mere productivity and good reasoning- throwning all the Abrahamic legacy to the dust bin.
So, y'all think you are the center of the world, Mediterranean fools? The Chinese got everything you brag from Math in the same way (basic algebra, proto-integration). And, if any case... the Egyptians were before any Abrahamic nonsense. Heck, the Exodus was just a primitive form Nationalist brainwashing, a la North Korea. So, the days for the Mediterranian Jingoism -and oil, of course are numbered the day the Chinese set a working fusion reactor.
These middle eastern "civilizations" which torture and mutilate their own children... it's hard to see such barbarity winning out in the very long run against intelligence and human rights.
violence is the undisputed rule of life. rationalize the power of intelligence to whatever degree you may .... the bigger guy is still gonna wipe the floor with the smaller one. and if an entire homogenous block of the world agrees on a core set of violent tenets, they are bestowed a greater capacity to violence.
Scientists and engineers also invented Zyklon-B gas and built the crematoriums in the concentration camps. Don’t underestimate what scientists and engineers can do to Jews.
I’d be surprised if it were a lot. At that time (open to corrections) not a lot of scientific research was done on consumer intel platforms.
Obviously it was found by a mathematician, but I still suspect it wasn’t obvious in published research or that it ended up not causing significant enough deviations to cause research to revisit the calculations.
My team ran into some interesting but very small deviations when we moved our iterative solar wind model from 32 bit to 64 bit, but the changes weren’t significant enough to revisit or re-do prior research wholesale.
Like my team in the 2000s I suspect anyone who had data crunched by this bug also revisited it and either concluded it wasn’t significant enough or redid the work and it didn’t change the conclusions.
I am curious now if this bug was cited in any papers at the time to give a rough idea how aware or affected academics were.
At that time (open to corrections) not a lot of scientific research was done on consumer intel platforms.
We had researchers doing what I suppose might be called HPC on Sequent Symmetrys, which were i386s in the mid-80s and Pentiums by the mid-90s. There were other high-performance x86 SMP boxes that were roughly equivalent (e.g. NCR 3550). That plus some pretty good x86 FORTRAN compilers (e.g. Lehey (sp?)) made this reasonable. I also know a lot of folks who had desktop/side SMP PPros + FORTRAN to save grant money on the big iron and got useful work out of them.
Basically, x86 was way cheap and had useful amounts of FP. There's a reason x86 displaced risc; this is one. I'm sure they would have rather used something like an X/MP-48, but one plays the hand one is delt.
What you should worry about is how many scientific "results" are still wrong due to random bugs in numerical code. If anyone's actually verifying the results, they'll catch things like the FDIV bug just as easily as a mistake in the calculations.
None of the science being sabotaged was being published in peer reviewed journals was it? (besides the Portuguese hydrodynamic modeling stuff, but it could have been accidental or had other uses)
And yes, to be clear, I don’t consider it contributing to “science” if it’s not published, reviewed, and reproducible.
at some point this science exists to do that, e.g. directly (via things like zyklon b gas), or indirectly (such as how social media screws up kids, and is doing so, wholesale, across civilization)
My 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. The code ran perfectly well thanks to modern optimizing compilers and having moved from Vax to Linux in the 90s, it was a surprisingly seamless transition.
It reminds me of a conference talk I’ve referenced before “do over or make due” basically implying rewriting large amounts of mostly functioning code was not worth the effort if it could be taped together with modern tools.
Ha, I worked for a company that until ~2012 still used RCS-backed SCM, absolute hack job on a shared file share that wrapped RCS with a "project file" to allow a tree of specific revisions for a "project". "MKS" it was called. And by the sound of it the "old" '90s version, not the java EE rewrite.
That meant the files has the entire "$Revision: 1.3 $" nonsense and "file changelog" at the top too - though many newer files never bothered to include the tags to actually get RCS to replace them. Inconsistent as hell.
And while the "family" of devices the software was for traces it's origin to the mid '90s, functionally none of the code was older than ~5 years at that time.
Naturally even with only a few tens of engineers it regularly messed up, commits stepped on each other's toes and the entire tree got corrupted regularly. For fun I wrote a script that read it all and imported the entire history into git - you only had to go back a few years before the entire thing was absolute nonsense.
I have no idea why that was still being used then, but I assume it had been in use from the very start of that entire hardware family. Perhaps as it was fundamentally a "hardware" company - which until surprisingly recently seemed to consider "source control" to be "shared folders on remote machines" - "software" source control wasn't considered a priority.
RCS->CVS and from that you can convert it to GIT or SVN.
The issue was the rcs files were simply corrupt - no matter what tool you used the older deltas were just bad. Just people didn't notice/care as they were "old" revisions.
And I couldn't find any tool that supported the mks "project" files that linked multiple rcs revisions into a single "commit", so something a little custom was needed anyway. At least for the ancient mks version used.
Quite a bit of effort was put into it during the "official" migration, but they eventually gave up too as even the oldest backup archives they could find had the same issues.
If you're using R in 2026, you're probably invoking code compiled from Fortran from the 70s/80s somewhere along the line. It's a foundation for a lot of numerical computing.
Same for SciPy (At least the last time I dove into it around 10 years ago).
A lot of the C code you see for numerics is a straight up f2c run checked in.
Yeah, I used to be skeptical of the government provenance of things like Stuxnet (I am not any more, I'm fully sold, like everyone else), and notes like this were why. People used RCS well into the 2000s! RCS as a tool had virtues over SVN and CVS.
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 infected system agrees on the same wrong answer!
More broadly: any interpretive mismatch between components creates a failure surface. Sometimes it shows up as a bug, sometimes as an exploit primitive, sometimes as a testing blind spot. You see it everywhere — this paper, IDS vs OS, proxies vs backends, test vs prod, and now LLMs vs “guardrails.”
Fun HN moment for me: as I was about to post this, I noticed a reply from @tptacek himself. His 1998 paper with Newsham (IDS vs OS mismatches) was my first exposure to this idea — and in hindsight it nudged me toward infosec, the Atlanta scene, spam filtering (PG's bayesian stuff) and eventually YC.
https://users.ece.cmu.edu/~adrian/731-sp04/readings/Ptacek-N...
The paper starts with this Einstein quote "Not everything that is counted counts and not everything that counts can be counted", which seems quite apt for the malware analyzed here :)
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? ^_^
the full on em dash requires a different character than - or --
it was generated that way, or else this person happens to know the correct combination of buttons to make that happen.
in 2026, at least 20-40% of social media traffic is bots (and probably higher with better LLMs), so it is usually safer to just assume.
On Linux, with a compose key, it's <compose><-><-><.> (at least with the settings I have, I don't think I overrode that one). "⸻" is even more fun. You can even make your own sequences, e.g. I've got <compose><O><h><m> for "Ω", and <compose><m><u> for "μ", very handy for electrical stuff like "160μA at 1.8V needs a resistance of 1.25kΩ, dissipating 288μW".
In pedantic tradition, I would like to gently remind you that there should be a space between a number and its unit, according to SI standard/NIST.
On a Mac, at least, the "correct combination of buttons" is trivial and easy to remember, even for someone like me who rarely uses em-dash. (But, I want to start using it more because I'm sick to death of people treating it as a scarlet letter.)
Option-shift-hyphen
Thanks for sticking up for my humanity ;)
Microsoft Word changes "--" to an em-dash, by default.
> or else this person happens to know the correct combination of buttons to make that happen.
Yes, some people care about maximum impact of their words.
> at least 20-40% of social media traffic is bots (and probably higher with better LLMs), so it is usually safer to just assume.
Look around you. If you see 40% bots in HN comments, find a therapist.
> used to be skeptical of the government provenance
Do you mean skeptical on which government was responsible or that it was in fact a government effort?
I can see how attribution could be debatable (between two main suspects mainly), but are / were there any good arguments against this being a gov effort? I would find it highly unlikely that someone other than a gov could muster up so much domain knowledge, source pristine 0days and be so stealthy at the same time.
I didn't want to give bumptious government CNE teams that much credit, and also a lot of the indicators people were giving of state origin didn't seem all that predictive. I don't agree with your premise that it takes a state-level adversary to collect the domain knowledge needed to do this stuff, and I certainly don't agree about the "pristine zero days".
> People used RCS well into the 2000s!
I still use RCS today. It's certainly not my preferred option, but my collaborator likes it, and it's not too annoying for me to use.
I do wonder if these breadcrumbs were also left intentionally. “Oh look, we are using old stuff, don’t be afraid!” Or for some other reason. It is a little surprising to pull off such a sophisticated attack and miss details you could find running ‘strings’ unless I’m missing something and this part was encrypted.
I think that in the time period we're talking about, RCS wasn't really even all that old. Like, RCS is old, sure, but it was also in common use especially by Unix systems people; it's what you might have reached for by default to version your dotfiles, for instance.
Yes, but even back then I was aware of the sections in executables (wasn’t this where it was found?) and any neckbeard from the 70s and 80s might be even more so aware. That said, yeah, sure, it’s a very possible and understandable oversight, but I’m weary because of all the text in viruses and such as indicators. Seems like a pass over ‘strings’ would be obvious. Though. TIL, strings doesn’t necessarily scan the entire executable.
The same binary has encrypted strings so I assume there was a pass, but if you look at the source control strings they seem to decrease the appearance of maliciousness, even today they are out of place for malware
Does that mean that three-letter agencies were/are able to recruit from the fields for each type of malware? For example, fast16 might actually be written by someone who used to write scientific calculation software, while Stunex was written by someone who used to work for Siemens?
Don't think of it as a materials simulation engineer being recruited and trained on how to write complex malware.
Rather this was developed by a team of 6-8 people. Maybe two or three of them working on the implant, another engineer handling the exploits and propagation, and yet another building the LP and communications channels. They are supported by a scientist with deep knowledge of the process they are messing around with (say developing nuclear weapons), and a mathematician that knows how to introduce subtle and undetectable errors.
I doubt you will find an answer here, but a few bits of anecdata:
1. CIA had recruiting events that invited STEM majors at my university, I suspect they do this very broadly.
2. Our funding came partially from the Air Force and part of the rules was our data and source had to be open. We know from conversations and other details from integrating with Air Force partners that they had models like ours that were an order of magnitude more accurate because they amalgamated models from all academics in our field and had their own career scientists on staff (often coming up through military ranks)
Try to remember how hypothetical everything tended to be before Snowden. And 'twas a meager pittance that was revealed. They have toys that'd blow minds and people yee'd swear weren't people. It's all fun and games to poke fun, but holy shit those guys are NTBF'dW.
Every academic institution, every school, all under the radar of recruitment and more. It's difficult to believe, but the network is real.
There are certainly people here on HN who've been solicited, most who'll never mention it.
It's fun to imagine, though, what tight groups of highly motivated, stupidly intelligent people can do when they collectively commit to doing so - and with a hefty budget to assist.
Fun to imagine that and painful to think of what we could have if such efforts and budgets were put toward education, healthcare, social welfare, public infrastructure + reliability, etc.
But then I am getting too utopian
Exactly. But there's ideology, and there's reality. You know how pervasive and colossal the black budget is. We could be, as a society, almost unimaginably advanced of where we are, sans such things, sans the modern patent system, sans greed, sans corruption.
But we are, precisely where we are
Edit: I thought it prudent to leave a reminder, that the US military operates beyond patent regulations. If they want or need something, the silly games end there. And they do what they will.
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.
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.
I mean to write "not a panacea", my bad. That it's not the universal cure people think it is. And people _do_ think that re-factoring will magically solve problems, while it doesn't do all that much in practice, less so when you factor in the costs spent on re-factoring.
>in 2006 was still using svn
Perhaps you meant cvs? Subversion was released in 2004 and git appeared in 2005.
Subversion 1.0 was released in 2004, but it was already widely used before then.
We used cvs, but did switch to svn before/around 2006, but I could be mixing that up. We did not switch to git even by 2012 when I left.
The reference to the 70s and 80s code didn’t imply it was version controlled before svn/cvs though if that’s what you meant, but by that time it was and still had old timestamps commented in the text files.
I just wanted to say that "still using svn in 2006" sounds odd when talking about version control system that existed just for several years and what turned out to be its replacement was 1 year old.
gcc, for example, transitioned to subversion in 2006 and switched to git only in 2019 [0]
[0] https://gcc.gnu.org/wiki/GitConversion
I miss the days of knowing who last touched every source file and precisely what version it was:
For posterity, there was a subthread about how the main submission was some kind of AI generated article. This appears to have been deleted. (Or some HN magic happened where threads are merged? I don't know.)
At any rate, the original link was
https://hackingpassion.com/fast16-pre-stuxnet-cyber-sabotage...
https://archive.ph/7VpWv
Which while apparently being AI generated, does have some additional information over the other sources. (Which have apparently also been deleted from the thread.)
For example it makes a reference to this relevant paper, though it fails to cite it properly.
https://onlinelibrary.wiley.com/doi/10.1155/2024/1672269
---
Another great source for the story is:
https://www.theregister.com/2026/04/24/fast16_sabotage_malwa...
And in case it changes again, the current link is:
https://www.sentinelone.com/labs/fast16-mystery-shadowbroker...
Which is a write up by the actual researchers.
The subthread is here in this discussion, auto-collapsed: https://news.ycombinator.com/item?id=47913855#47914315
Download link for anyone who is curious enough:
https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
I'll probably build a Windows XP VM first.
Has anyone posted the windows service file yet? That looks just to be the loader.
No I haven't found it yet. AFAIK MalwareBazaar (right now I cannot access the website) only has two files, one .exe and another one some 30K.
That article is sobering. The fact that this malware stayed under the radar for 20 years is pretty ominous in itself.
IEEE-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".
This is an amazing find. I'm very curious regarding the specific targets of these rules, and in the exact changes to the results. Wonder if they will only make a difference in simulated conditions super specific to nuclear reactors?
I dug into how software such as LS-DYNA could have been modified. Take for example the EOS_JWL equation at [1] (vendor website, public manual) which is implemented by LS-DYNA. This equation seemingly could be used, alongside other equations implemented within LS-DYNA, to answer questions such as how long it'd take for a detonator in a missile warhead to detonate a primary explosive substance to cause a particular pressure wave at 20m distance. Working backwards from this result may provide a required fuze timing. Equations and parameters used with LS-DYNA are derived from scientific research, such as [2], which is US government research from the 1980's providing experimental results for high explosive substances. One such example from [2] is experimentation to determine the friction an explosive substance has against different materials which may enclose it. Given the software has equations purposely designed for explosives modelling, it'd be fairly easy to just target those equations in ways which will just slightly frustrate a scientist/engineer into thinking they've got a problem with the manufacturing quality of steel, rather than suspect the software is deliberately adding +/-20% noise to a friction coefficient.
The modern equivalent may be something like {insert adversarial country name here} downloading a pirated version of Ansys Autodyn 2026 R1 shortly after official release from a Chinese cracking group on a Chinese bulletin board forum, where just a handful of seeders sit behind Russian ISPs. And then {insert adversarial country name here} later notice during experimentation that the software calculations never quite match experimental results, and maybe then suspecting the pirated copy was deliberately tampered with and distributed. However, this situation may be fairly easily solved by {insert adversarial country name here} by just grabbing a copy of the software they want off a hacked network of a random university or engineering consulting firm in the aerospace and defence sector. Plus it may be naive to assume {insert adversarial country name here} in 2026 couldn't develop their own software from scratch (and/or perform calculations manually), or just rely on experiments, to achieve whatever outcome some other nation state group of hackers is trying to avoid. {insert adversarial country name here} would have to have experimentation equipment and skills regardless to verify manufacturing quality. Simulation software mostly reduces costs and timeframes by reducing the number of mockups and physical experiments needed. For example, it's cheap to run 1000 simulations of an artillery shell hitting vehicle armor plates as shown in [3], and more expensive and time consuming to do the same repetitive thing in the real world.
[1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
[2] https://www.osti.gov/servlets/purl/6530310
[3] https://www.youtube.com/watch?v=_dv2PecKUBM
The govemerment, 1984-like agencies and some others in Middle East will truly hate Guix and reproducible computing being portable to Powerpc and even legacy machines. There more heterogeneous your setup, the better.
Thank you for sharing this. I was recently pushing the limits of precision computing and this illuminated a part of my research. It built on top of largely government funded research, where I found a surprising dearth of available precision frameworks with verification. Perhaps national security interests, as elucidated by the original poster, discourages transparency of methods for arbitrary precision calculations.
I 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.
Interesting 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?
What would the difference be? They would have the same effect.
Easier to deliver as an OS bundle, no worm required.
heh the key move is the worm. you can't catch it by checking on a second box because there is no clean box.
Haha it's a fun finding though; The source control comment feels a little off; I'm sure there were SCCS (hmm or did cvs use similar?) still around at that time.
I believe that comment was specific to it being unusual in Windows software, suggesting the developers were also working in UNIX stuff (where usage SCCS/RCS was common).
I hope when people see RCS rev data on some of the stuff I publish it gives them pause.
The submitted article appears to be an LLM summary of https://www.sentinelone.com/labs/fast16-mystery-shadowbroker...
Changed now from https://hackingpassion.com/fast16-pre-stuxnet-cyber-sabotage.... Thanks!
No clue if the link that I posted is an AI summary. I also just found it somewhere.
But indeed many more details in the link you shared. Thanks for posting this!
> This one did not destroy machines or blow things up. It corrupted the math.
This LLM style of writing has had it's day.
https://www.theregister.com/2026/04/24/fast16_sabotage_malwa...
This one has some additional details, based on a talk given by one of the authors.
I think LLMs would do a better job.
I was about to respond saying what a terrible article it was, as it reads as if the author has no idea what he was talking about. Attempting to paraphrase the original article would explain it.
Thank you for finding this - the original is a really interesting article.
(@dang - consider re-pointing to this?)
Or to https://www.theregister.com/2026/04/24/fast16_sabotage_malwa...
The current article is hard to read
I don't see how it can be an LLM summary of that page given that it mentions many things that your link doesn't.
Edit: Old link for those wondering, since it got changed: https://hackingpassion.com/fast16-pre-stuxnet-cyber-sabotage...
It appears to be a summary of both the official SentinelOne article, and this one:
https://www.theregister.com/2026/04/24/fast16_sabotage_malwa...
No, these aren't all mentioned there either: https://news.ycombinator.com/item?id=47914748
Such as?
Have you read both of them? There's a ton of stuff. "Advances in Civil Engineering", "TMSR-LF1", "Black Hat Asia"...
[dead]
[dead]
[dead]
[dead]
[dead]
So that's why China still can't make ballpoint pens? /s
[dead]
sabotaging science must be the most morally corrupt thing you can do as a civilisation
How about killing scientists and engineers? [1]
[1] https://en.wikipedia.org/wiki/Assassinations_of_Iranian_nucl...
Not just Iranians, something odd it's happening with the JPL people.
Shitty and brainwashed people in Middle East comes in both ways.
Can't wait to the Chinese secularizing all the Abrahamic bullshit by brute force -not by war, but my mere productivity and good reasoning- throwning all the Abrahamic legacy to the dust bin. So, y'all think you are the center of the world, Mediterranean fools? The Chinese got everything you brag from Math in the same way (basic algebra, proto-integration). And, if any case... the Egyptians were before any Abrahamic nonsense. Heck, the Exodus was just a primitive form Nationalist brainwashing, a la North Korea. So, the days for the Mediterranian Jingoism -and oil, of course are numbered the day the Chinese set a working fusion reactor.
These middle eastern "civilizations" which torture and mutilate their own children... it's hard to see such barbarity winning out in the very long run against intelligence and human rights.
violence is the undisputed rule of life. rationalize the power of intelligence to whatever degree you may .... the bigger guy is still gonna wipe the floor with the smaller one. and if an entire homogenous block of the world agrees on a core set of violent tenets, they are bestowed a greater capacity to violence.
Being bigger and stronger didn't work well for dinosaurs.
sure worked well for the meteors that annihilated them though
Scientists and engineers also invented Zyklon-B gas and built the crematoriums in the concentration camps. Don’t underestimate what scientists and engineers can do to Jews.
Spying on and sabotaging weapons development of foreign adversaries is a completely normal government function
I hope one day, it will no longer be normal - it will be wild.
I wonder how many results got nerfed via https://en.wikipedia.org/wiki/Pentium_FDIV_bug before it was known about.
I’d be surprised if it were a lot. At that time (open to corrections) not a lot of scientific research was done on consumer intel platforms.
Obviously it was found by a mathematician, but I still suspect it wasn’t obvious in published research or that it ended up not causing significant enough deviations to cause research to revisit the calculations.
My team ran into some interesting but very small deviations when we moved our iterative solar wind model from 32 bit to 64 bit, but the changes weren’t significant enough to revisit or re-do prior research wholesale.
Like my team in the 2000s I suspect anyone who had data crunched by this bug also revisited it and either concluded it wasn’t significant enough or redid the work and it didn’t change the conclusions.
I am curious now if this bug was cited in any papers at the time to give a rough idea how aware or affected academics were.
At that time (open to corrections) not a lot of scientific research was done on consumer intel platforms.
We had researchers doing what I suppose might be called HPC on Sequent Symmetrys, which were i386s in the mid-80s and Pentiums by the mid-90s. There were other high-performance x86 SMP boxes that were roughly equivalent (e.g. NCR 3550). That plus some pretty good x86 FORTRAN compilers (e.g. Lehey (sp?)) made this reasonable. I also know a lot of folks who had desktop/side SMP PPros + FORTRAN to save grant money on the big iron and got useful work out of them.
Basically, x86 was way cheap and had useful amounts of FP. There's a reason x86 displaced risc; this is one. I'm sure they would have rather used something like an X/MP-48, but one plays the hand one is delt.
What you should worry about is how many scientific "results" are still wrong due to random bugs in numerical code. If anyone's actually verifying the results, they'll catch things like the FDIV bug just as easily as a mistake in the calculations.
Developing weapons is pretty high on my list of shitty things to do as humanity.
We will probably keep doing it until we encounter an alien intelligence and snap out of it.
None of the science being sabotaged was being published in peer reviewed journals was it? (besides the Portuguese hydrodynamic modeling stuff, but it could have been accidental or had other uses)
And yes, to be clear, I don’t consider it contributing to “science” if it’s not published, reviewed, and reproducible.
As a scientist and a father I can say that the most morally corrupt thing is doing bad things to children, not scientists.
at some point this science exists to do that, e.g. directly (via things like zyklon b gas), or indirectly (such as how social media screws up kids, and is doing so, wholesale, across civilization)
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.
Killing children and justifying this form of murder by calling them terrorists takes a higher toll, imho.
Nah; it's to prevent a country from developing a superweapon and possibly triggering WW3 / worldwide nuclear annihilation.
This comment is very exaggerated, I can think of a few more "morally corrupt" things to do.
this reminds a lot about the Three-Body Problem series. There it's aliens sabotaging science. In reality it was always the NSA.
The NSA can't touch China before turning the whole commerce with the US into shards.
They are improving like crazy on clear energies and the Oil Jihad can't do nil.
Why did this get downvoted so much?