• Please review our updated Terms and Rules here

Secrets Within: The brains of the Butler in a Box

NeXT

Veteran Member
Joined
Oct 21, 2008
Messages
9,187
Location
Kamloops, BC, Canada
Way back in 2017 I followed up on by first entry into Mastervoice and their Butler in a Box ( https://forum.vcfed.org/index.php?threads/stuck-in-the-80s-mastervoices-butler-in-a-box.1070062/ ) with their follow-up product before Mastervoice folded and disappeared entirely, the Mastervoice ECU. ( https://forum.vcfed.org/index.php?threads/mastervoice-ecu-the-butler-in-a-box-tries-again.1070407/ )

To bring everyone up to speed, the Butler in a Box and the ECU were the 80's equivalent to the Amazon Alexa or Google Home Assistant. It was a box that you could speak to and with training it could recognize your voice and be commanded to perform a variety of tasks. It was also able to control a very large selection of X10 products as well as operate more specialty controls such as relay banks through a parallel port (which the manual states is *not* a traditional PC parallel port) while also taking commands over the phone and providing some simple security system functionality. It was obviously expensive but very advanced.
Along with being such an advanced product came its own security. Much like a car stereo you found in the 90's, the first time you power it on it will perform a self-test, then prompt for a PIN.
This was how Mastervoice made sure that stolen units could not be resold. If the backup battery fails/is missing and power is lost it will always come up and prompt for the PIN. The PIN is a four character alphanumeric code (0-9, A-Z) normally written in the manual. A copy of said manual can be found here: ( https://archive.org/details/mastervoice-butler-in-a-box-manual-pages )
Mastervoice could provide you with the PIN should you of lost it back in the day, but 30 years later that option is long gone. If you are going through ebay and see a Butler in a Box, hope you see the manual or the PIN written on it or it's no more useful than a bookend. Obviously the PIN is stored on a ROM inside the Butler in a Box, but where?
Inside any Butler in a Box or ECU you will find a UV programmable Intel 8748 (MCS-48 microcontroller) seemingly handling the telephone functionality, a pair of 27256 EPROMs I would not necessarily call secure and a large black brick. This brick will have a tag stating it's from Mastervoice, messing with it voids the warranty, the product that it's for, the model and the serial number. Seeing how there is no sign of the main CPU on the board anywhere else it is safe to assume it's inside this box, however the box connects to the board using over 75 pins and is itself quite large, so it is safe to assume there is more than a CPU hiding inside, specifically since the box is serialized, the PIN will be stored in this box on a ROM.

That I am aware of nobody up to this point has gone this far into figuring out how these things tick, in part because doing so will likely destroy the module and render the entire unit unusable. However if we remember from my ECU, then the box was initially filled with a potting compound to keep snoops out, the resin failed to properly cure. The resulting mess meant the unit did not work, but also that depotting the module would be easier than normal. Now that I've had some time with depotting and cleaning following my previous adventure with the AMC CeC I decided there was nothing to lose and gave it a go.

The first task was removing the module. This turned out to be far less pleasant than I expected. The solder on the module's pins were stubborn and heating up the pins would cause softened resin to be sucked into the holes. Ultimately the only solution was heat and more prying force than I was really wanting to apply. Eventually, the module came free, along with a half dozen traces...

IMG_6273.JPG

IMG_6297.JPG


The module was set aside and the board cleaned up. All the chips in the affected area were pulled, the board cleaned with hot air, a knife and acetone and new sockets were installed. Broken vias were patched and pulled traces were trimmed and new bodge wires run.

CGS_12118.JPG

CGS_12120.JPG


Now that the unit at least was probably in a working condition my attention went back to the module. The first order was to heat up some of the potting compound and start exploring. In short order, the window of an EPROM appeared, then the numbers from a Rockwell R6501Q microprocessor came into view. Quickly I considered my chances both sides of the PCB inside the module were populated, then took a dremel to behind the EPROM and desoldered it for dumping. It's a 2764.

CGS_12117.JPG

CGS_12116.JPG


Now I had FIVE EPROM images. The first two were the EPROMS from my original Mastervoice Series II, then the two EPROMs from the ECU and now this EPROM buried inside the security module.

The EPROM labeled "P08248" and "PROG" in the two units had a matching checksum A703
The EPROM labeled "V12031" in the Butler had a checksum of 2A76. The EPROM labeled "ECU" in the other had a checksum of 092B. At a glance in the editor they still however look very similar.
This new EPROM pulled out of the module (Which I will from here on call "CDKG") had a checksum of 305B but we have nothing to compare it against.

dataz.png


Copies of these dumps can be found in a ZIP file attached this post (as of 2023).
Curiously as I was extracting the secure EPROM I noticed other chips inside the potting as well. Figuring I had gone this far in already and I was now far past the point anyone else had ever gone I decided it was worth the effort to completely remove the potting and see what other secrets were revealed. The process would take some seven hours.

CGS_12110.JPG

CGS_12111.JPG

CGS_12112.JPG


Beyond one bodge wire on the backside, the potting revealed an SN74HCT245N tri-state octal bus transceiver and an AM27A21PC 256 x 4 1024-bit bipolar PROM.
Man. I got no problems reading fairly standard EPROMs but a PROM like that? How the hell do you even *write* one of those?? Why is this even in here if you already have space for an EPROM??
My guess is that this PROM is being used as additional path logic, but as of right now I have yet to start looking how it interacts with the CPU and the ROM. Is it obfuscating the data bus for the EPROM to prevent it being easily dumped? Is the PIN stored in here? I feel like to proceed much further will require safely dumping that PROM and to go back and verify every other ROM I've dumped so far on the Series II was done cleanly. I can at least say the ones in the ECU were read back good. Clearly we can see that one set matched. The other is close, but something different. More research will need to be done but at the very least we've finally seen for the first time what Mastervoice was hiding inside this module and perhaps we are that much closer to finding a solution for all those systems still out there where the PINs have long been lost.
 

Attachments

Note: This post was written by Kevtris, who can't yet post on the forum here due to posting/reply restrictions:
I got interested in this Mastervoice Butler in a Box after seeing one on ebay, and
doing some research. I came across this thread, with some good pictures of the guts, along
with the ROM dumps and decided to give a little reverse engineering a try.

It didn't take long to see that the potted ROM dump didn't seem to contain any 6502
data, yet the reset/irq/nmi pointers seemed to be present. hmmm... checking out the
PCB pictures, it became clear that the data lines to the ROM was being swizzled.

After deswizzling the code and disassembling, the expected 6502 code was visible.

Immediately present at the end of the data in the clear is the PIN for this unit, and
several digits of the serial number right before it:

At 1F9C in the ROM, 0828908 is visible which matches some of the digits of the serial number,
which is M-08280-EC-1038. I am curious if the 1038 is a sumcheck of the contents; I tried
sumchecking the resulting deswizzled ROM but it didn't match (this might not be the whole
story, see below).

At 1FA3 however is the PIN. It's CDKG which is correct.

This proves that these modules were assembled first, then provisioned before or after
potting. Theoretically they could provision them after potting and before soldering them
down.

Looking through the code, the address where the PIN lives is only called by exactly two
functions:

EBDA : A0 00 LDY #$00
EBDC : B9 A3 FF LDA $FFA3,Y
EBDF : 20 EE D3 JSR $D3EE
EBE2 : C8 INY
EBE3 : C0 04 CPY #$04
EBE5 : D0 F5 BNE $EBDC

This first version seems to be a method of DISPLAYING the PIN to the user somehow...

EF65 : A9 00 LDA #$00
EF67 : 8D 10 03 STA $0310
EF6A : A9 78 LDA #$78
EF6C : A0 B4 LDY #$B4
EF6E : A2 04 LDX #$04
EF70 : 20 13 EE JSR $EE13
EF73 : AD D3 02 LDA $02D3
EF76 : F0 ED BEQ $EF65
EF78 : A0 03 LDY #$03
EF7A : B9 B3 02 LDA $02B3,Y
EF7D : 29 DF AND #$DF
EF7F : D9 A3 FF CMP $FFA3,Y
EF82 : D0 E1 BNE $EF65
EF84 : 88 DEY
EF85 : 10 F3 BPL $EF7A
EF87 : 8C 10 03 STY $0310
EF8A : 60 RTS

The second piece of code is checking the PIN against the user entry. Code entry starts at
EF6A or so; the loop at EF7A is checking all four digits of the user's entry which
lives at 02B3, against the stored copy in ROM at FFA3. If all four digits match, 0xff
is written into 0310, and if it does not match, 00 is written in instead.

Unfortunately, I am pretty sure half of the data is missing- the first function (and many others)
call code at Dxxx range. The EPROM contents are 8K which means it lives at E000-FFFF; I checked
the other two ROMs and they just seem to store speech data (which seems to be CVSD format, btw)

The chip in the potted module is most likely a 27128 if I had to guess; pin 27 exits the potted
module; and if this was a 2764 it would be /PGM. if it's a 27128 it would be A13.

The other option is code is somehow compressed in one of the external chips and is unpacked into
RAM, of which there's 64K but I am not sure yet. There is definitely code missing, however.

As for the PROM, it is doing address decoding. It is attached to A8-A15 (the two port bits
are A13 and 14 when the chip is in extended addressing mode). The four outputs control the on-chip
EPROM chip enable, the 74HC245, and the other signals run off the board to control the other
peripherals and memories.

Attached is the unswizzled ROM data. If anyone wants me to do a complete PCB trace and code RE
on this thing, let me know. I see there's two up on ebay but $400 and $700 is just a bit too much
to spend. It shouldn't be too difficult to fully reverse engineer this thing and get it into i.e.
MAME so others can experience the 'joy'.
 

Attachments

First off, thank you Kevtris for spending the time to sift through the code and whatever dumps I was able to provide in a timely manner. I never dumped that PROM in a reasonable amount of time but I blame that on my 29B's serial port refusing to pass data to/from a host machine.
Same for you Lord Nightmare for passing the response on. This is an incredibly fun read and I'm happy to hear that my knowledge dump was helpful to others in the same boat as me. If you would like me to go back on the potted EPROM and try dumping as a 27128 (since the guess came from a silkscreen and not the etching I wonder if they intentionally mislabeled it? It's off, because the alternate factory part A30853 comes up in several places as 2764 as well but we don't have any other ROM's hiding in clear sight....unless it's the additional firmware boxes that came with my ECU model) I'm up to that and can do that fairly quickly. That also being said since we can confirm that the CDKG found on the security module was in fact the code (so that unit has some sort of another failure preventing it from working) I can look into considerably less destructive ways to remove the module from the main board and extract its EPROM as well. That however might take a little bit more time as I will need to prepare a workspace to perform the work.
 
Last edited:
Here is Kevtris' reply:
I'm glad you went to the trouble of depotting the module, I got interested after seeing that
because I have depotted a bunch of Votrax speech synths over the years.

As for the EPROM, I wasn't sure if it is indeed 2764 or 128; there isn't an easy way to tell other
than half the code seems to be missing. Attempting to dump it as a 27128 might not be a bad idea.
If it is indeed a 27128, dumping as a 2764 would produce the upper 8K, which is what seems to be
present.

I am pretty certain there is a way somehow to display or dump the code out the serial port
via software, which means there should be some way to non-destructively recover it. I couldn't
tell which because the function it calls is missing.

I would be up for tracing the main pcb out and dumping the PROM since it doesn't seem like it is
too complicated. There doesn't seem to be any custom chips on the board except the two MV0014/MV0015
chips; I suspect one is a CVSD codec and the other is probably an active filter for it. They
most likely are harris parts from the look of the package and are military grade (triangle).

If you wish to collaborate more on this I am on discord and IRC (efnet). Lord Nightmare can
facilitate this if so.
 
After about a week of collaborating and validating Kevtris's findings, I can provide a little more insight to the module and how you poke into it from the outside.
The process to do so meant mapping out the entire pinout of the module, plus solving hardware issues with my 29B programmer to dump the PROM's (see below), then tracing around where the external address and data lines were going. Adam over at Hackaday has done a very nice job working through the 6502 assembly which I am very thankful for because I don't know 6502 assembly.

Deswizzle.jpg

Of note above, we can see the address bus directly skips the nonsense with the PROM and the 245 and is available from the outside.
The first I can confirm is that the internal EPROM is not a 27128. If you dump it as such you just get the same data, twice. What is more likely happening is that the missing block of data is packed in the ROM and decompressed to the RAM when powered up. While powering up it also somehow validates the two EPROMs we find on the mainboard and keep in mind we possibly have a checksum also stored in ROM it might be validating against. Like we had observed before, the PROG and P08248 EPROMs are byte and checksum identical, same with the AM27S19 with the capacitor strapped to it. You can put those into my working unit and it will still pass self-test. It's when you swap the ECU and V12031 chips that we see a change. The dead ECU is still a dead ECU, for reasons I'll explain. On our working unit however we don't pass self-test. We get ERROR: 0000-38. The ERROR in the text string is also in plaintext in Kevtris's analysis. So we can confirm that it is comparing against something like a checksum and it is not happy with that one EPROM being switched. Since that suspicion of the checksum hiding in the security module, that had the system back on the bench again to map it out.

BIAB Secure Module Pinout.jpg

This also allowed me to begin verifying if the R6501 was doing anything at all and quickly I concluded He's dead, Jim! We get a clock in and barely any signs of life coming out. The address lines were stuck high, as were many other pins and while I did find two or three pins that were showing logic pulses they were not appropriate levels. It seems that most of the lines cannot drop below 4v and with the CPU physically removed you can tell that there's nothing external to the chip causing this so internally something is shorted and another CPU will need to be sourced to see if replacing the CPU repairs the unit (not not the display, which I've already swiped to fix my Series II) The process to remove the R6501 is one I can say is "hell" but it also let me validate that my probing of what traces went where was correct.

e1cea735-882a-41ef-928e-2d485932e1f5.jpg


Now however that we could confirm the mapping and the module pinout, it was time to explore off the module and see what went where. Interestingly the two EPROMs do not attach directly to the module The RAM attaches to the address bus but doesn't route directly to the CPU either. They use their own ports either on the 8255A's or on the CPU. Same with the display, which is a serial device using a Rockwell 10937P (and I'll tell you this to save you having to desolder and remove the VFD module).

BIAB Chip Map.jpg <---Click for a larger version

Interestingly however, the parallel port does.
Probing finds that the external address and data bus go directly to it. In addition to clocking from the CPU and control lines for the 74HCT245N that lives inside the security module and blocks you from easily reading the entombed EPROM. This is probably so that the external options such as the SRAM backup module, the alternate voice option or the sprinkler controller can communicate directly with the CPU.

BIAB Ports.jpg

The serial port is, well it's a serial port. Pins 2 and 3 are Rx and Tx like the manual states. Ground is on pin 7 (which is normally RTS on a real serial port) and pin 9 has 9v DC living on it (this is normally Ring Indication), straight from the power supply. That is not mentioned in the manual and I'm not sure why you would even need that unless Mastervoice had some other device you could plug in and needed power from the Butler.

So this kinda summarizes the last week. The digital side of the Butler in a Box is now mostly understood and all of the ROMs/PROM's are now dumped. Most of the ROM has been reverse engineered and all the components are now known.
 

Attachments

Back
Top