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).
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.
I came across this Andy Kirby guy on youtube, and his videos really came across as very sensationalized, exaggerated and clickbaity, which drew me away from meshcore, as I associated him with the project organization. This seems to validate my gut feeling.
That TAP data was leaked on a tor hidden service, in multiple files, and download was extremely slow on the days following the leak. One of the files was much smaller, and my friend had the bad luck to have his data in that one.
His phone was spammed so incessantly he had to change his number almost immediately.
Don't you think it's a huge stretch to compare those to modern generative AI in this context? Those don't raise any of the questions that make current usage questionable.
reply