SN971 discussion

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


Well-known member
Oct 1, 2020
Listening to SN971 Steve talks about the gateways being damaged, but the sensors likely being fine. However most of these sensors are remote programmed, using that same communications bus, and also most of them do not have any sort of login on that comms method, you just send the correct packet, and they will respond with an acknowledge, and the next bytes addressed to the device will set bitmaps internally to them, overwriting the existing info. So you could have multipurpose sensors, set up here as a pressure and temperature controller, that was say being used to run an oil refinery cracking column, now suddenly getting an update with random data, and now, instead of having to maintain a pressure say of 10 bar and 250C at the base of the column, it now get scrambled, so the input got changed from temperature measuring a K type thermocouple, to measuring millivolts instead, and switching on the heat, because you need to reach 250mV, and currently it is around 11mV input from the thermocouple assembly. Same for the pressure, changed to something different, and thus the sensor will no longer work even with a new gateway.

Output sensors can be destroyed, your valve controllers can easily be changed to maximum current limit, and then sent past the software limits, destroying the physical plant.

As to the gateways yes the flash will be destroyed, as the malware operates below wear levelling if there, erasing single pages of the flash over and over, and writing an inverse bit pattern to it, hoping that the flash will have a hard erase fault before power cycling wipes the code from RAM, though I would say the code likely keeps on writing itself again and again to the flash, and thus removes any firmware there.
  • Like
Reactions: Badrod