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.
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.
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
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.
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.
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".
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.
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.
29 comments
[ 0.18 ms ] story [ 47.3 ms ] threadThat 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.
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
https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
I'll probably build a Windows XP VM first.
I also wonder why they opted to make this an injectable worm and not just a side-loaded 'feature' of the OS?
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.
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.