No, I would not be amazed. I have some familiarity with the practice. (And teh fact the hardware hacker found an ARM9 core in a drive controller chip is no surprise.Joat42 wrote:Yes, on the micro controller. See https://spritesmods.com/?art=hddhack for example, he actually boots up a stripped down linux on the controller on the harddisk in the end.DMcCunney wrote:I think we are talking past each other. You can hack storage mediums to run code directly from the medium, but where it that code actually executing? I'm willing to bet it's not on the micro controller that controls the storage medium. (If nothing else, incompatible instruction sets an no or insufficient RAM.)
You'd be amazed if you knew the amount of hidden micro controllers in everyday items that's hackable. Did you know that all Bluetooth devices has a CPU and some RAM that can be hacked to some extent? See BlueBorne.
And it's simply growing. A big thing now is IoT devices. They key to those is that CPUs have gotten small, fast, and cheap enough that you can put a 32bit CPU capable of supporting a full TCP/IP protocol stack on devices you can deploy as sensors and micro controllers for a few dollars each. It's the cost that is significant. Previously you used 8bit controllers from folks like ST Microelectronics to get the price low enough to make it feasible.
Something like that. I never worked on DG machines. I logged time on competitor Digital Equipment's gear.It's a bootstrap loader then. It was quite common on the early generation computers. For example, DataGeneral's Nova-series had one instruction that paged in a given block from a device and ran it.DMcCunney wrote:I have a machine that does something like you are mentioning - it is designed so that code can be paged into memory directly from disk, and start executing as soon enough loaded for the CPU to begin execution. It doesn't have to load the entire program to begin running it. (It's a relatively ancient Unix box using an MFM drive, and various tricks were used to get performance.)
But the machine in question wasn't applying the technique to boot loading. It used a technique similar to the IBM PCs boot routine. First, look for a bootable floppy with a Unix kernel on it, and if not found, transfer control the the boot sector on HD.
(There was a deeply amusing episode when a new release of Unix for the platform neglected to specify the value that told the boot routines how long to look for a floppy before giving up and going to HD. Uninitialized, that value defaulted to some millions of machine cycles...)
It was available to provide faster loading and execution for arbitrary user programs stored in the drive once the machine was up and running. I had fun back in the day building the then current version of Gnu Emacs on the machine and getting it to dump to disk in the needed arrangement. (It turned out to be controlled by the order of the arguments to ld, which is about as obscure as a hack gets.)
I still doubt the controller on the Key would be able to run the code for programs stored on it. Even if we assume all TF systems used the same CPU architecture and instruction set, they would differ in power and in what they could run. The controller's job would be too access the content and load it onto the system where it would run.I would say that any programs stored in the Key could probably be run on any Federation system available. We know that the key must contain a "controller" since the it can erase the content if someone tries to force a decryption. Considering the context my guess is that someone went to considerable effort to protect the contents of the Key and that includes a lot of anti-tamper protection which also means fiddling with the "controller" and it's "firmware" probably results in a wipe.DMcCunney wrote:In the case in question, the question is "Even if Owl could successfully access the encrypted contents of the Key, where might any programs stored on it run?" I don't see "on whatever embedded controller is in the Key" as a plausible answer.
My guess is that when you want to read a particular file that's stored on the Key you need to supply a decryption key for the file in question so it can be decrypted and sent. This precludes anyone from getting the file encrypted and then brute-forcing a decryption. Send the wrong decryption key for a file too many times - wipe.
Also, has anyone considered the implication of that the Key is also a verifier? My guess is that it's not enough to have the decryption key - you must also in all likelihood answer a question truthfully for it to be activated.
Now.. I wonder what that question would be...
But the question implied by the Key also being part of a verifier and might require truthfully answering a question to gain access is fascinating. The possibilities for snark in what the question (and answer) might be are likely endless.
______
Dennis