Schneier on Security

Clive Robinson • October 6, 2026 4:08 PM

@ ALL,

On the assumption the clock is involved, one way to do this is to “stop the clock” or keep resetting the clock time back just a couple of minutes or longer.

Another way is a bit more subtle, any CRUD access to memory generally means at least a two step process of the application writing to a buffer and the OS then writing the buffer to the memory. The reason for this is to keep the memory in a sane state.

An OS generally uses some form of signals mediated “Inter Process Communication”. Thus has flags tucked away in the OS to control the signals to App Buffer Memory.

If you block those signals by blocking the flags or flag mechanism then the memory does not get updated by a “Create, Update, or Delete” action.

The way to get around the issue is quite old and was used in Mil Kit back in the 1980s and I assume later.

You actually do this by encrypting the data contents of every memory object with it’s own key. If you delete or change the key at any time it mostly does not do any harm even to open Apps as long as the most basic of meta-data is not damaged…

It must be a decade and a half or more since we discussed the issues with memory encryption on this blog, as it’s something that has in effect been abstracted away in more modern OS’s and Systems.

The last time I remember was with “a snake eating it’s tail”(Ouroboros). The idea being that you actually re-encrypted blocks of memory by having the keys cycle around. With part of the key held in memory and the other part held via a CPU register, as a way to get around the LNO attack on DRAM and SRAM that had had power removed.

Clive Robinson • October 7, 2026 10:27 AM

@ Hacketry, ALL,

With regards,

“… any software can be hacked, directly or what it does in the computer…”

Actually depending on what you mean by “software” and “computer” that might not be true.

Those old enough to have worked in FMCE as design engineers back into the mid 1990’s and earlier will have used “Mask Programmable Microcontrollers”. Those working on lower production runs would have used the equivalent of a diode “fuse programmable array.

Untill much the same time the BIOS and similar for Personal Computers were written into either ROM or EPROM. But on boot up the code in them would copy down into RAM which then made them vulnerable in the way you are suggesting.

Even today comparatively hard as they are to get now, there are still actual ROM or PROM parts you can get in Mil Spec byte-wide parts that are not Flash or “Electrically Erasable PROM”(EEPROM). I use them in CubSat and other HiRel and HiSec designs where code should not be alterable.

The other issue is “control Flags” for signals and buffers as I mentioned above, they are also usually RAM based and thus vulnerable. Moving them to X

Thus the trick is to design systems where executable code can not run in RAM and where control instructions (think branches in ASM) can not be available from RAM.

This way malware has nowhere to go in the system, and software can not be changed by it.

Basically you have to think of the memory in a secure system as ranging from “fully mutable” to being “immutable”. You want executable code in “immutable memory”. Likewise control flags and similar to being where possible in CPU registers only.

One more modern trick you see in some systems where security is considered important but code needs to be changed is to have an encryption key chain system where the executable code is encrypted in a way that if it gets changed it fails to decrypt and execute.