Author Archives: Nick Price

Let’s Repair an Ancient Macintosh SE/30, part 1: Looks Like it’s Broken

This weekend I attended the 7th Vintage Computer Festival Southeast in Roswell, GA. Before going, I promised myself that I wouldn’t buy anything, but they happened to have an as-is Macintosh SE/30 for sale for $60, and I happened to have been looking at them all week, so I took a chance and bought it.

Unsurprisingly, when I got it home and powered it on, it seemed less than functional.

My first thought was that there are probably some blown capacitors to deal with, and that I’ve probably got a dead horizontal sync signal going to the CRT.  Let’s crack it open!

The first thing I noticed was a Lapiz Technologies high-resolution display adapter.  I figured it might be interfering with the video, so I removed it and powered the device back on.  No change.  I then pulled out the mainboard and discovered that the problem might’ve been a bit more serious than I’d hoped.

Thirteen leaky capacitors and a blown RTC battery that had all been sitting around and corroding nearby components for years.  Time to break out the DeoxIT.  I snapped off the capacitors, soaked the board, and then went to down with a cheap Dremel.  After some elbow-grease, the board and components cleaned up pretty nicely.

The corrosion in a lot of areas was bad enough that I got down to bare copper when it was all removed.  I went back and used some solder to clean up and re-tin parts that needed it.  One really bad one was the ROM SIMM which sat directly next to the battery that exploded.

I took this picture after re-tinning half of the ROM board.  It cleaned up pretty well!  After everything was cleaned up, I ordered Tantalum capacitors from Mouser to replace all of the electrolytics, along with several ICs to replace ones I wasn’t sure about, and a new RTC battery and holder.  Once they arrive, I’ll get them installed, and we can see what happens when we try to fire this thing up again!

Getting into the Pace 5268AC Router, part 2: Dumping the Flash Chip, Finding Keys

My attempt to crack the md5crypt hash found in /etc/shadow on the device had failed (due to someone unplugging the machine I was using in the middle of the job), and after poking around at test pads around the SOC and finding nothing immediately useful, I decided the next step would be to dump the flash chip. I ordered an inexpensive device programmer from China along with a TSOP48 socket and it finally arrived after several weeks, so I bit the bullet and rendered my router useless for a while.

I was able to remove the flash chip from the board pretty cleanly with a hot air station. The flash chip uses a TSOP48 package, which has 48 0.25mm pins, 24 on opposite sides of each other, and it took several tries to get all of the pins lined up properly in the device programmer.

I was able to download and verify the data on the Flash chip, producing a 128MB binary (and a vague unease as I’d killed my only way to get onto the Internet)

I went ahead and cleaned up the pads on the board.

Since I had issues with pin alignment on the flash chip, I went ahead and wrote the binary to a brand new chip, and was able to get it put back on the board (drag soldering technique) and it fired right up.

After digging around in the flash chip, I found what appeared to be two PKCS12 bundles stored as base64-encoded variables passed to the bootloader.

I had to manually remove a few 64-byte chunks throughout the base64 data I was reading – my assumption is that these are EXT2 block descriptors or something, but once I removed the extraneous bytes, I was able to decode valid PKCS12 bundles from the base64 strings.

We’re almost there!  Next step is to find the passwords.

After doing some grepping, I found some lua scripts on the device that seemed to refer to the certs I’d extracted.

The most interesting thing here is the tw_ulib_get_network_cert method.  After doing some more grepping, it looks like it’s exported from Let’s take a look with radare2’s cutter.

Another interesting call here – librgw_sec_get_shroud_key.  That one is defined in  Let’s check there!

So, at first glance, it looks like we take the devkey, serial number, and an ASCII string, and append them to each other to unlock these certs. Let’s see if we can find them on the flash.

Bringo! Both of the missing values are right here. Let’s give them a try.

Tried several different combinations and ordering, and capitalization, but no dice. I think we’re very close though. Next time, we’ll take a look at how the system is actually pulling back the devkey and serial number, and we’ll go back over the method being used to reassemble everything.

Getting into the Pace 5268AC Router, part 1: Terminals and Hashes

I got stuck on my Casio SK-1 project and needed to take a break, so I started on another project I’ve been meaning to do.

I’ve had gigabit fiber service at my apartment in Atlanta for nearly two years through a major global telecom provider. The service itself has been pretty good, but one thing I didn’t like was the fact that I couldn’t use my own router, or put theirs into a proper “bridged” mode.

When trying to use my own router, even after cloning the MAC of theirs, I was unable to obtain a DHCP lease. By sniffing the traffic between the router and the OTN, I found that the router needed to use 802.1X authentication to communicate with the OTN. So, I decided to tear open the router.

At the front of the router, I found what appeared to be some sort of debug port via an edge connector with 14 pins, and I soldered some 30ga Kynar wire to each pin for further investigation.

When I first fired up the device, it took a while to come up, and I got a worrying error message. Fortunately, it seems that this was just temporary.

After a lot of trial-and-error, I identified the four pins required to get a good, working serial console on the device.


The pins on the debug port are labeled 1 to 16 (two are missing but pin count is still incremented), and these are the ones I ended up with, along with port settings:

At this point, my plan was to remove the Flash chip from the board and dump it, but thanks to the prior work of Jhutchins, I was able to find the URL to download the firmware for this device. I modified the URL to match the firmware version running on my device, and downloaded the firmware.

Once I had the ROM downloaded, I used binwalk to extract the contents of the file.

After a quick search, I found what looks like the md5crypt password hash for the root account on the device

Tomorrow, I’ll be borrowing the hashcat rig at my office to try and obtain the plaintext password and attempt to log in with it.

Reverse-Engineering the Casio SK-1, part 2: The ROM is now an Arduino

After some trial and error, I settled on adding some right-angle connectors to the board where the ROM lived. I staggered them so that the connectors would fit properly.

I used the same pins on both sides that I’d used to dump the ROM, however, now the inputs and outputs are switched because we’re getting address data from the keyboard and sending back bytes.

In addition, I connected a digital I/O pin to the Chip Enable (CE) pin to be able to tell when the keyboard is trying to read from ROM or when it’s trying to communicate with RAM.

After a bit of plumbing, I modified the code on the Arduino to invert how it operated previously.

Fired it up, and results were not as expected.

I broke out a logic analyzer to see what was going on, and my suspicions were confirmed: the Arduino could not change its pin states as quickly as the previous ROM allowed access.

In essence, when CE goes high, all data lines should go to 0. When CE is low, the chip is enabled. The Arduino isn’t cycling quickly enough.

The next step will be trying an EEPROM or something similar that will have sub-200ns access times (per the ROM spec), and using the Arduino to program it.

Update: Let’s try NVRAM!

Reverse-Engineering the Casio SK-1, part 1: Dumping the ROM

When I was younger, I had a Casio SK-1 keyboard that I had a ton of fun with.  Of course, I found out about “Circuit Bending,” and in short order, my keyboard was no longer functional.

The Casio SK-1 is famously modifiable, its simple electronics making all manner of sounds when fed unexpected data across its 8-bit data bus, however, given my previous experience years before, rather than circuit-bending the instrument, I decided that I was going to reverse-engineer the data formats used. In theory, this will allow me to program the keyboard myself, rather than feeding it garbage data and using trial-and-error to find something that sounds interesting.

Disclaimer: I have absolutely no clue what I am doing.

First steps first: set up a bench and break the thing open.

Once inside the unit, three chips became immediately apparent – two 8K RAM chips and one 32K ROM.  My assumption here is that sampler recordings and other settings are temporarily stored in RAM, and the ROM contains the patch data we care about.

The 23C256 (bottom) is the one we care about here

Now that we’ve identified the chip we want to dump, we’ll remove it from the board and hook it up to a microcontroller to read the data.


Now, let’s check the pinout and put it in a breadboard.  (I couldn’t find any breadboards in my house and was almost lazy enough to hook leads directly to the pins. I ended up going down the street and spending the $5 and grabbing a breadboard.)

What we need. +5v to 28, GND to 14, 20 and 22 tied to GND, and the rest are address lines and output lines. It’s common for CE and OE to be LOW when a ROM is ready to be read.

Always take notes

To make things simple, I mapped blocks of digital I/O pins on an Arduino MEGA to the data and address pins on the ROM.

Address/data lines connected

I wrote a little bit of code to use the Arduino to dump the ROM:
(Pretty sure I used the wrong types in a bunch of places but it works)

Used some bitwise operators here to make converting between bytes and individual bits easy.

Now, let’s hook up the power and other lines (we can just feed the ROM with the +5v from the USB)

Here goes nothing…

Results coming back…


Next time, we start looking at decoding the data with the help of a logic analyzer, as well as dropping in an Arduino in place of the ROM so we can start manipulating values.

If anybody wants to poke at it, here’s the SK-1 ROM dump.

I Feel Personally Victimized by the Rust Lexer

I just spent way too long trying to figure out a missing comma.

Say you have some code that looks like the following (note the missing comma between &self.srcaddr and &self.dstaddr)

What error would you expect the compiler to spit out?

Something like expected token: ','?

What about invalid reference to argument '3' (there are 3 arguments)?

It turns out that since whitespace is ignored, the second ampersand in the above code is interpreted as a bitwise AND, with one reference and one variable as its operands. Rather than complain about a missing token, the compiler interprets what it sees as valid syntax, and indeed it ends up with one less argument than it expects based on the provided format string.