Topic Actions

Topic Search

Who is online

Users browsing this forum: Google [Bot] and 4 guests

Computers and the OBS

This fascinating series is a combination of historical seafaring, swashbuckling adventure, and high technological science-fiction. Join us in a discussion!
Re: Computers and the OBS
Post by DMcCunney   » Thu May 02, 2019 3:46 pm

DMcCunney
Captain of the List

Posts: 421
Joined: Mon Jul 02, 2012 1:49 am

Joat42 wrote:
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.)
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.

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.
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.

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.
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.)
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.
Something like that. I never worked on DG machines. I logged time on competitor Digital Equipment's gear.

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.)
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.
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.

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...
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.

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
Top
Re: Computers and the OBS
Post by mhicks   » Thu May 02, 2019 5:07 pm

mhicks
Lieutenant (Senior Grade)

Posts: 71
Joined: Mon Apr 13, 2015 12:53 am
Location: WA

DMcCunney wrote:
Michael wrote:Now using a second AI to hack the Key might be okay IF!! there is no possibility of the second AI communicating electronically to anything outside itself (no radio, bluetooth, etc). Only thing allowed would be basically visual/keyboard communication. Even then it's risky since if it's a another recorded personality (maybe Schuler himself!) it might try to fool people into allowing electronic communication and then hack into all of the IC's stuff (like Owl).
There's a larger risk that would make this a non-starter for the IC.

TextEv earlier has Owl speculating that if the key was encrypted by a high level civilian AI, attempting to hack into it would trigger routines that would wipe the contents. If it was encrypted by a military AI, the response would wipe him, too.
...


And while there may be a recorded personality in the Key, remember that the Key is a memory module, not a computer. That personality would need to be loaded into something like the VR unit Owl made for Narhmann to execute and function. What might it load into if Owl or a clone could access it?

______
Dennis


What if the whole purpose for the key is for it to overwrite and delete what ever is written in the TEMPLE? If the response of the inscription could kill OWL and wipe him clean, what if that is the purpose of the key. To wipe out the computers all throughout the Temple and rewrite it with the new "Schueler" program that deactivates the OBS.

We don't know much about Schuler. We are starting to think that he was taken advantage of by Chihiro, and that Chihiro wrote the book and slapped his name on it. With what happened to Kody it is likely that Schuler with his accesses wrote a program to make use of a back door in the system that will disable the work Langhorn and Chihiro did.

That is my wish for Schueler. That he was a good guy in reality. The Key has so much memory on it. I have to believe it more than just one personality on it. It has to be a program to take command of something.
Top
Re: Computers and the OBS
Post by DMcCunney   » Sat May 11, 2019 7:06 pm

DMcCunney
Captain of the List

Posts: 421
Joined: Mon Jul 02, 2012 1:49 am

mhicks wrote:What if the whole purpose for the key is for it to overwrite and delete what ever is written in the TEMPLE? If the response of the inscription could kill OWL and wipe him clean, what if that is the purpose of the key. To wipe out the computers all throughout the Temple and rewrite it with the new "Schueler" program that deactivates the OBS.
Since we don't know what all is in the Temple (and note that Merlin in his persona as Captain in the Archbishop's Guard when Michael paid a visit to the Temple in person and met with Grand Vicar Timothy Rhobair saw a lot more networks and power sources in the Temple not detectable from the outside than had been assumed.)

I do assume a distributed network with all manner of devices connected through sub-nets specific to their purpose. I don't see whatever is in the Key taking down the entire Temple. That would be non-trivial and require require a level of skill I don't believe Schueler himself had. We don't know much about him save that his brief as Archangel seemed to be Justice, and he was possibly something like a high level member of the TF's Department of Justice (or whatever they called it) before being assigned to Operation Ark. We do know from TextEv that he and Chihiro knew each other and worked together on Operation Ark planning before that effort was launched, and RFC mentioned at a con that Chihiro had been a historian and high level government official before becoming part of the Operation Ark command crew. My suspicion is that he leaned on his senior position to get himself posted to Operation Ark in the first place, but that might not be the case.

We don't know much about Schuler. We are starting to think that he was taken advantage of by Chihiro, and that Chihiro wrote the book and slapped his name on it. With what happened to Kody it is likely that Schuler with his accesses wrote a program to make use of a back door in the system that will disable the work Langhorn and Chihiro did.
Agreed we don't know much about Schueler.

I think the Punishment of Schueler was an after the fact addition to the Book of Schueler written and inserted by Chihiro, who had edit access to the master copies of the Writ in the Temple. (And note that TextEv says the Books of Chihiro and Schueler were not in the original copy of the Writ approved by Langhorne, and got added later.)

That is my wish for Schueler. That he was a good guy in reality. The Key has so much memory on it. I have to believe it more than just one personality on it. It has to be a program to take command of something.

I concur, but the question is what?

I'll also be fascinated to know more about where the Key came from. The physical manufacture would not be a challenge, and might have been performed by fabrication units in Zion or in Hamilcar. Creation of the content would be a different matter. While we have little actual knowledge of Schueler, nothing we know suggests he was a hacker who could write things to hijack Temple programs himself. He presumably had assistance in creating the Key, and it will be interesting to see what assistance that was an who provided it.
______
Dennis
Top
Re: Computers and the OBS
Post by jgnfld   » Sun May 12, 2019 9:41 am

jgnfld
Captain of the List

Posts: 454
Joined: Sat Dec 28, 2013 8:55 am

In the 70s I analyzed a national health database on a Xerox Sigma 9? mainframe. The database was embodied first as a large trolley carrying 1 or 2 hundred pounds of punch cards. Maybe more, I just remember the trolley was hard to start and stop.

We finally got some 9" tape drives and got all the data on to 6 tapes as I remember.
Top
Re: Computers and the OBS
Post by DMcCunney   » Sun May 12, 2019 2:16 pm

DMcCunney
Captain of the List

Posts: 421
Joined: Mon Jul 02, 2012 1:49 am

jgnfld wrote:In the 70s I analyzed a national health database on a Xerox Sigma 9? mainframe. The database was embodied first as a large trolley carrying 1 or 2 hundred pounds of punch cards. Maybe more, I just remember the trolley was hard to start and stop.

We finally got some 9" tape drives and got all the data on to 6 tapes as I remember.
The first computer I dealt with was an IBM mainframe at a major bank in the 80s. There was a card reader in the data center, but I don't recall it ever being used. Online storage was on 3380 DASD, with offline storage on magnetic tape. But the punch card metaphor was firmly embedded. When I submitted jobs, I was dealing with a virtual card deck stored on Partitioned Data Sets in the DASD, and my editor displayed files of 80 column card images with the first few cards being the JCL that told the OS what followed *was* a job, what executables is would run to do it, and what resources contained the data the executables would process. The last card in the deck was more JCL saying "Job Ended".

DASD could be a source of grim amusement. I had lunch at one point with a CDC field engineer who repaired such drives. A programmer had sent a request to mount a disk pack on a drive. The operator powered down a drive, removed the disk pack it had held, mounted the requested pack, powered up the drive, and tried to read it. It failed. He tries the same pack on another drive. It failed. He called in his boss, and between them, they tried it on five more drives.

The pack was badly defective, trying to read it caused head crashes on every drive it was mounted on, and there was a $33,000 repair bill to fix them. Given that bank, I suspected the operator and his boss still had jobs when the dust settled... :P

But thanks for the mention of the Xerox Sigma machines. I had forgotten that Xerox had once made things classifiable as mainframes. When I was involved, you had IBM and the BUNCH - Burroughs, Univac, NCR, Control Data, and Honeywell. Xerox was already out of that end of the business, as was RCA and several others.

(And there was an amusing piece in one of the trade journals back then with an RCA exec saying RCA wasn't chased out by IBM - they absolutely could have competed, but simply saw better places to invest the money needed to compete. Yeah, right, guys. RCA no longer exists, but the trademark does, and I recently got an Android tablet produced under the RCA brand name by the outfit that licensed the trademark.)
______
Dennis
Last edited by DMcCunney on Mon May 13, 2019 9:08 am, edited 1 time in total.
Top
Re: Computers and the OBS
Post by jgnfld   » Sun May 12, 2019 9:38 pm

jgnfld
Captain of the List

Posts: 454
Joined: Sat Dec 28, 2013 8:55 am

DMcCunney wrote:...

But thanks for the mention of the Xerox Sigma machines. I had forgotten that Xerox had one made things classifiable as mainframes. When I was involved, you had IBM and the BUNCH - Burroughs, Univac, NCR, Control Data, and Honeywell. Xerox was already out of that end of the business, as was RCA and several others. ...


The wonderful thing about the Xerox OS of the time was that it resembled what would become DOS later. (I've read this is not exactly a coincidence, but don't know for sure.) That is, to copy a database from one location to another you could issue a 1 line copy A to B command. In the JCL of the 70s this took many lines--a couple of dozen--with much parameter setting. The Xerox approach was a joy and God send.

Earlier in the 70s I used a CDC machine to invert a 50 by 50 matrix for a large regression. The canned CDC-supplied routine crashed out at 20x20. So I researched some old 19th century texts and found a way to invert using the method of submatrices which allowed me to only declare 1 50x50 matrix (the input) along with 2 50x1 vectors and to then operate only with them.
Top
Re: Computers and the OBS
Post by DMcCunney   » Mon May 13, 2019 10:09 am

DMcCunney
Captain of the List

Posts: 421
Joined: Mon Jul 02, 2012 1:49 am

jgnfld wrote:
DMcCunney wrote:...

But thanks for the mention of the Xerox Sigma machines. I had forgotten that Xerox had one made things classifiable as mainframes. When I was involved, you had IBM and the BUNCH - Burroughs, Univac, NCR, Control Data, and Honeywell. Xerox was already out of that end of the business, as was RCA and several others. ...
The wonderful thing about the Xerox OS of the time was that it resembled what would become DOS later. (I've read this is not exactly a coincidence, but don't know for sure.) That is, to copy a database from one location to another you could issue a 1 line copy A to B command. In the JCL of the 70s this took many lines--a couple of dozen--with much parameter setting. The Xerox approach was a joy and God send.
I think that depends on what Xerox OS you are talking about.

I have fond memories of IBM JCL. Eight statements in the language, but it was considered black art, and programmers all used someone eldse's canned procs rather than write their own. (I got ripped a new one by the manager of applications programming at the bank for modifying the JCL of a job I submitted to run it at a higher priority. I'm not sure which annoyed him more - that I had done it in the first place, or that I wasn't a DP staffer and worked for an end user department. :P) I think I still have an IBM JCL manual around somewhere.

The Sigma 9 was a result of Xerox purchasing Scientific Data Systems in 1969, and the Sigma was an SDS offering. (There's an interesting historical document here:
https://www.andrews.edu/~calkins/profess/SDSigma7.htm. Sigma machines were popular in universities, and this comes from one that used them.)

The DOS on PCs derives from a product called 86DOS, from a company called Seattle Computer Products. They made a line of machines using the Intel 8086 CPU on an S-100 bus. 86DOS apparently had roots in Digital Research's CP/M OS for early 8 bit micros. It didn't appear to use DR code, but was a work-alike intended to make it easier tp get popular CP/M programs like WordStar and Visicalc up on newer machines.

Microsoft had already provided a version of BASIC that could run on PCs. IBM asked them for an OS as well, and they got a non-exclusive license for 86DOS from SCP and used it as the base for MSDOS.

(There was a time when MSDOS, the UCSD P System, CP/M 86 and a couple of other things were competing to be the PC OS. MSDOS won.)

Early MS/PC-DOS looked a lot like CP/M under the hood, and you had legacies like ^Z as End Of File marker CP/M needed that, as CP/M before v3.0 did not store the length of a file in the directory entry, and the OS needed a way to know where the file ended. IIRC, it took till DOS 5 before that legacy went away.

CP/M used a utility called PIP to copy files, as the CP/M command processor did not have it as a built-in. PIP in turn derived from Digital Equipment mini-computers.
Earlier in the 70s I used a CDC machine to invert a 50 by 50 matrix for a large regression. The canned CDC-supplied routine crashed out at 20x20. So I researched some old 19th century texts and found a way to invert using the method of submatrices which allowed me to only declare 1 50x50 matrix (the input) along with 2 50x1 vectors and to then operate only with them.
Cool! How much work was required to do that? And which language did you use?
______
Dennis
Top
Re: Computers and the OBS
Post by Louis R   » Mon May 13, 2019 3:06 pm

Louis R
Rear Admiral

Posts: 1161
Joined: Thu Jan 01, 2015 8:25 pm

hmmmm...

Details are vague at this remove, but I can't say I'm too surprised. Between grades 11 & 12 [or was it between 10 & 11. like i said, this was long ago] the school board switched from running our work on the IBMs at the university to a contractor using CDC. which meant that _we_ were flipped from Watfiv to MNF - without replacing our textbooks, of course. Turns out that the lads at UWaterloo had taken a lot of things off the shoulders of the programmer. Looking back, it was probably a good lesson in the importance of paying attention to your environment, but at the time we were ticked. It took 2-3 months to get all our decks from the previous year fully usable again, and you never knew if what they told you in the book would actually work. Or precisely how to fix it when it didn't.

There are a number of reasons it was IBM and the Seven Dwarfs, and being a marketing monster was far from the main one.


jgnfld wrote:
The wonderful thing about the Xerox OS of the time was that it resembled what would become DOS later. (I've read this is not exactly a coincidence, but don't know for sure.) That is, to copy a database from one location to another you could issue a 1 line copy A to B command. In the JCL of the 70s this took many lines--a couple of dozen--with much parameter setting. The Xerox approach was a joy and God send.

Earlier in the 70s I used a CDC machine to invert a 50 by 50 matrix for a large regression. The canned CDC-supplied routine crashed out at 20x20. So I researched some old 19th century texts and found a way to invert using the method of submatrices which allowed me to only declare 1 50x50 matrix (the input) along with 2 50x1 vectors and to then operate only with them.
Top
Re: Computers and the OBS
Post by Loren Pechtel   » Mon May 13, 2019 9:49 pm

Loren Pechtel
Captain of the List

Posts: 737
Joined: Sat Jul 11, 2015 7:24 pm

DMcCunney wrote:
Loren Pechtel wrote:All modern mass storage devices have processors without which you're not going to read what's on them.
They do, but those processors are dedicated storage controllers. They have firmware that allows you to connect to the device and access the content.


They're only dedicated in the sense they have no other IO systems. They are ordinary off-the-shelf processors and can run anything written in their language. I've heard of a proof-of-concept of them being hacked to run malicious code.

It was not always thus. I still have my old PC clone that ran MSDOS and has a couple of Seagate ST-225 20 megabyte hard drives. The controller card plugged into a motherboard slot and provided access the the drives using MFM.


I don't have anything that ancient around anymore.

But the dedicated controller can't run code stored on the device it controls.


My point was that identifying it as simply a huge storage device almost certainly does not mean it doesn't contain a processor that can have it's own anti-tamper code. If nothing else, it's cheaper to make such devices with a processor. If it's pure memory you have the issue of bad blocks. (Think back to that MFM drive--they usually came with a list of bad sectors that had to be locked out and if one was in a critical location the drive was tossed.) Now the drive controller handles such lockout invisibly, the user simply sees perfect storage space.
Top
Re: Computers and the OBS
Post by Loren Pechtel   » Mon May 13, 2019 9:55 pm

Loren Pechtel
Captain of the List

Posts: 737
Joined: Sat Jul 11, 2015 7:24 pm

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.)


Nothing says the code on the storage medium isn't written for the language spoken by the storage controller. If nothing else, I would expect over time for chips to converge on a single language.

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.
______
Dennis


Which says nothing about whether it could have nasty anti-tamper precautions.
Top

Return to Safehold