SDU hacking...

Updates are getting a thin because I'm running out of things to update about; The blog has caught up to real time.

Like most of the complex processors of its era, the Lambda is a microcoded engine. This means that rather than a single chip being the processor which is capable of operation from a cold startup, the processor is made up of a set of boards filled with discrete logic and glue that is incapable of doing anything until initialized and started from an outside source. In the Lambda, this source is the System Diagnostic Unit, or SDU. This is a single-board microcomputer containing an Intel 8086, firmware ROMs, and 64K of RAM. The SDU is capable of driving both the NuBus and Multibus, and mediates access to shared resources when multiple processors are installed in the same machine. The SDU is the source of the terminal text in the "signs of life" article.

The tapes that came with the Lambda proved hard to read with the SDU; Its tape driver is not very robust or tolerant of errors. There is also no way of determining what is actually on a tape - All I can do is try to load diagnostics from it in the hope that it's a diagnostics tape. Therefore, the only way to check out the machine any further was to come up with a way of doing it myself. I would have to write a program that ran on the SDU, a means of executing it, and then use it to download an image of a diagnostics tape from the network and write it out to a blank tape.

The first step in doing this is to dump out the ROMs. There are five, four which contain the SDU firmware and one which contains NuBus target information to be used by other processors when enumerating the bus configuration. I don't need this one.

I expected to have to do this, and had prepared most of an Arduino program for doing it. All I needed was the exact type of EPROM, its datasheet, and a little bit of work. Then it was just a matter of pulling chips from the board and dumping them.

Dumping ROMs

The Arduino sketch just read the ROMs and printed the contents in base64, which I then decoded on Linux to produce binary images which could be loaded into LambdaDelta. The V102 firmware on the chips expects newer revisions of the SDU board than the V8 ROMs I had when developing LambdaDelta, so it won't run at current. But it does run enough for me to boot in Mode 0 and read/write memory. A little bit of tracing in LambdaDelta gave me the offset into the stack to overwrite with a "write memory" command to cause an arbitrary far jump when the command returned; This was my means of executing arbitrary code. I began writing a payload in nasm and a tool to make a text file from it which is downloaded to the SDU as write memory commands on the console. The text file ends in the magic write that jumps to the entry point of the payload. (Does this count as a vuln?)


SDUHAX at work

Kermit doesn't play well with the terminal, it wants to be talking to an xterm or Linux console or something. But it gets the job done. Work on this is still in progress, but it's getting close to being able to download files and make a tape.