Topic Actions

Topic Search

Who is online

Users browsing this forum: Isilith and 5 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 Loren Pechtel   » Mon Apr 29, 2019 12:09 am

Loren Pechtel
Captain of the List

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

phillies wrote:If the key is only a memory module it cannot directly hack into anything...no logic ability. And here is a use for mechanical computers, namely if you are sure it won't erase itself -- open bet -- you read the output electromechanically one line at a time and see if you can identify the file type.


All modern mass storage devices have processors without which you're not going to read what's on them.
Top
Re: Computers and the OBS
Post by Joat42   » Mon Apr 29, 2019 3:20 am

Joat42
Rear Admiral

Posts: 1423
Joined: Tue Apr 16, 2013 6:01 am
Location: Sweden

Loren Pechtel wrote:
phillies wrote:If the key is only a memory module it cannot directly hack into anything...no logic ability. And here is a use for mechanical computers, namely if you are sure it won't erase itself -- open bet -- you read the output electromechanically one line at a time and see if you can identify the file type.


All modern mass storage devices have processors without which you're not going to read what's on them.

Well, you can bypass all that if you know how - but it's a PITA plus you need some specialized equipment to do it.

But we are talking about FedTech molycircs now, I doubt that type of attack is practical or feasible.

---
Jack of all trades and destructive tinkerer.


Anyone who have simple solutions for complex problems is a fool.
Top
Re: Computers and the OBS
Post by DMcCunney   » Mon Apr 29, 2019 7:22 pm

DMcCunney
Captain (Junior Grade)

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

Loren Pechtel wrote:
phillies wrote:If the key is only a memory module it cannot directly hack into anything...no logic ability. And here is a use for mechanical computers, namely if you are sure it won't erase itself -- open bet -- you read the output electromechanically one line at a time and see if you can identify the file type.
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.

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.

For that matter, the 1541 floppy drive used by the old Commodore 64 had its own 6510 8bit CPU as controller, with 2K of dedicated RAM. It was possible to write machine code in Assembly languuge that could be downloaded to the drive and execute asynchronously to perform operations on data read from/written to the drive.

IDE (Integrated Drive Electonics) devices made the controller part of the device itself. Current SATA drives are extensions of the same concept.

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

And TextEv indicates Owl could access it enough to get an idea of what the file types were there, but there is a vast distance between knowing the file type and being able to read or execute it. That's what encryption is all about.
______
Dennis
Top
Re: Computers and the OBS
Post by Joat42   » Tue Apr 30, 2019 5:48 pm

Joat42
Rear Admiral

Posts: 1423
Joined: Tue Apr 16, 2013 6:01 am
Location: Sweden

DMcCunney wrote:..snip..
IDE (Integrated Drive Electonics) devices made the controller part of the device itself. Current SATA drives are extensions of the same concept.

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

That's only true to some extent, you can break into the CPU on the disk to inject your own code which for example could allow you to run code directly from the media.

Almost ALL disks today allows for the updating of firmware which means you have a pretty good vector for inserting your own code, but most people hacking hardisks use the JTAG-interface to fiddle with the firmware.

---
Jack of all trades and destructive tinkerer.


Anyone who have simple solutions for complex problems is a fool.
Top
Re: Computers and the OBS
Post by DMcCunney   » Wed May 01, 2019 6:30 pm

DMcCunney
Captain (Junior Grade)

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

Joat42 wrote:
DMcCunney wrote:..snip..
IDE (Integrated Drive Electonics) devices made the controller part of the device itself. Current SATA drives are extensions of the same concept.

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

That's only true to some extent, you can break into the CPU on the disk to inject your own code which for example could allow you to run code directly from the media.

Almost ALL disks today allows for the updating of firmware which means you have a pretty good vector for inserting your own code, but most people hacking hardisks use the JTAG-interface to fiddle with the firmware.
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.)

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

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
Top
Re: Computers and the OBS
Post by phillies   » Wed May 01, 2019 10:11 pm

phillies
Vice Admiral

Posts: 1914
Joined: Sat Jun 19, 2010 8:43 am
Location: Worcester, MA

Loren Pechtel wrote:
phillies wrote:If the key is only a memory module it cannot directly hack into anything...no logic ability. And here is a use for mechanical computers, namely if you are sure it won't erase itself -- open bet -- you read the output electromechanically one line at a time and see if you can identify the file type.


All modern mass storage devices have processors without which you're not going to read what's on them.


My DVDs have processors?
Top
Re: Computers and the OBS
Post by phillies   » Wed May 01, 2019 10:17 pm

phillies
Vice Admiral

Posts: 1914
Joined: Sat Jun 19, 2010 8:43 am
Location: Worcester, MA

DMcCunney wrote:They do, but those processors are dedicated storage controllers. They have firmware that allows you to connect to the device and access the content.

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.

For that matter, the 1541 floppy drive used by the old Commodore 64 had its own 6510 8bit CPU as controller, with 2K of dedicated RAM. It was possible to write machine code in Assembly languuge that could be downloaded to the drive and execute asynchronously to perform operations on data read from/written to the drive.

IDE (Integrated Drive Electonics) devices made the controller part of the device itself. Current SATA drives are extensions of the same concept.

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

And TextEv indicates Owl could access it enough to get an idea of what the file types were there, but there is a vast distance between knowing the file type and being able to read or execute it. That's what encryption is all about.
______
Dennis


I remember the old 1541s. Got a lot more data onto a floppy than the competitor did. As I recall, the trick was that Commodore worked out that if you made the bits too close together they did not all become unreadable. There were only a few bit sequences that were problematic. The drive therefore encoded each four bit byte using five bits on the floppy, eliminating the unacceptable patterns.

On the other hand, there was a grad student who kept crashing the 1541 processor, meaning you had to use a cassette drive and tape to reboot the system. He proposed the equipment was bad. I pointed out repeatedly that no one else using the computer had these problems.
Top
Re: Computers and the OBS
Post by Fireflair   » Thu May 02, 2019 12:15 am

Fireflair
Captain of the List

Posts: 534
Joined: Wed Sep 05, 2012 5:23 pm

phillies wrote:My DVDs have processors?


'Mass storage devices', not mass storage media. My first floppy disc was the 8-inch, later the 5 1⁄4-inch before I ended up with the ​3 1⁄2 inch disc, along with tape and cartridge media, as well as DVDs and other media are all storage media.

Devices are things like HDD (which do have media in them), SSDs (in which you could consider the memory chips the media, like a flash card is), are mass storage devices.

If you install a Blu-ray or DVD player/writer in your PC it has a processor that runs the device. Same for the floppy drive or cartridge readers of days of yore. By having the processor run the device it saves on cycles the main processor.
Top
Re: Computers and the OBS
Post by DMcCunney   » Thu May 02, 2019 9:13 am

DMcCunney
Captain (Junior Grade)

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

phillies wrote:
DMcCunney wrote:<...>
For that matter, the 1541 floppy drive used by the old Commodore 64 had its own 6510 8bit CPU as controller, with 2K of dedicated RAM. It was possible to write machine code in Assembly languuge that could be downloaded to the drive and execute asynchronously to perform operations on data read from/written to the drive.
I remember the old 1541s. Got a lot more data onto a floppy than the competitor did.
The competitor being the various Atari machines?
As I recall, the trick was that Commodore worked out that if you made the bits too close together they did not all become unreadable. There were only a few bit sequences that were problematic. The drive therefore encoded each four bit byte using five bits on the floppy, eliminating the unacceptable patterns.
If memory serves, Commodore floppies were 160K single sided disks. IT sound like they implemnted a parity bit for error checking/correction.
On the other hand, there was a grad student who kept crashing the 1541 processor, meaning you had to use a cassette drive and tape to reboot the system. He proposed the equipment was bad. I pointed out repeatedly that no one else using the computer had these problems.
You could boot the C64 itself with a power cycle. It was instant on, putting you into the BASIC interpreter that served as the shell, It came up just fine if there was no floppy or tape drive attached to it, though lacking external storage you were limited in what you could do. :P

I'd love to know what he was doing that crashed the 1541 drive.

(There was an article in one of the C64 publications back when about a young girl who saw that the C64 used a tape drive by default, wondered if you could use video tape to store data and programs, and figured out a way to do it. The Small Systems Manager (mostly DEC PDP machines) at the bank I worked for then read the article and said "That little girl is dangerous!" I told him he needed to keep and eye on her and possibly offer her a job down the road, because he needed people like that... :P)
______
Dennis
Top
Re: Computers and the OBS
Post by Joat42   » Thu May 02, 2019 9:56 am

Joat42
Rear Admiral

Posts: 1423
Joined: Tue Apr 16, 2013 6:01 am
Location: Sweden

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.

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

---
Jack of all trades and destructive tinkerer.


Anyone who have simple solutions for complex problems is a fool.
Top

Return to Safehold