Recently a question came to me from a friend of a friend… they had a globe that displays text messages that they wanted to use as a Christmas decoration, the only problem was that they couldn’t change the message because it was password protected… could I unlock it?

Hmm… maybe… bring it round and I’ll take a look…

The Magicball MB-1

Once I got my hands on it, it turned out to be pretty much exactly what I guessed it was from the description… a spinning arm with a row of LEDs on the end that uses our eye’s persistence of vision to draw a message in the air. Much like the many DIY versions that I’d seen before.

Most of the arm is formed by the circuit board, with the LEDs mounted at 90 degrees on a daughter board at one end, and a counterweight on the end of a bit of spring steel at the other. It sits on top of a tower that contains both a motor to spin it, and a dynamo that produces the power for the circuit and LEDs without needing any electrical connection.

Even before removing the plastic globe, I’d spotted the Atmel logo on a couple of the chips and was already wondering if I could connect my AVR programmer and dump the contents of its internal eeprom. However, as the image of the circuit board above shows, although it’s an Atmel microcontroller it’s not an AVR. Instead there is a AT89LV52 (datasheet), which is an 8051 compatible microcontroller. This microcontroller doesn’t have any internal eeprom (which actually made things easier in the end), instead it’s connected to an Atmel AT29LV256 32KB flash memory chip.

There’s not much more going on on this circuit board. At the top is the power supply with six diodes, a 3.3V regulator, a few capacitors and a supply supervisor to hold the microcontroller in reset until the voltage builds up and stabilises. On the left are 16 individual transistors and current limiting resistors and the LEDs themselves. These are connected to the microcontroller by a pair of 8-bit latches, and there’s a third 8-bit latch connected to the flash memory’s data bus. Right in the centre is an IR receiver with a lens to give it a 360 degree view, and out of shot, sticking off the bottom of the board, is a hall effect sensor to count the revolutions and tune the display timing.

The only instructions are a few sentences of German on the back of the remote control that comes with it.

Plan Of Attack

Before I could start I needed to come up with a plan. I could think of a few possibilities:

• Use brute force and try all 10,000 combinations.
  I could emulate the remote control and fairly quickly work through each combination, even going slowly and taking half a second per button press it would only take around eight hours to try all ten-thousand combinations.

  But how could I tell when the correct combination was found? Maybe a webcam and opencv? But I don’t even know what happens when the correct code is entered so how could I get opencv to look for it?

  Hmm… this option is getting complicated.

• Read the flash chip and look for possible passwords.
  The chip has a parallel interface and I don’t have a programmer that supports that, but it wouldn’t be too hard to make a circuit to do it. It wouldn’t need much more than a counter to walk through the addresses.

  But then I’d need to find a 4 digit PIN hiding in 32KB of data, and that’s sounding like too much of a needle in a haystack for my liking.

• Sniff the bus between the microcontroller and the flash.
  When I enter a PIN the microcontroller will need to compare it to the stored code, so there’s probably a good chance that it will read the correct code from the flash chip either right before I start entering the PIN, or right after I finish entering it. So if I watch the traffic on the bus at that time I should see the password.

  This is the option I decided to try.

Running It On The Bench

With a plan in place, the first problem I had was that this thing only works while it’s spinning around at high speed, and there’s no way I could hook up my oscilloscope or other tools while it was doing that. So instead of plugging it in to the wall, I started by soldering a pair of wires to the input side of the voltage regulator and feeding it 5V from my bench supply.

This resulted in a whole lot of nothing… no LEDs lit up… pressing buttons on the remote to enter a PIN number didn’t result in any activity from the flash chip… nothing!

I could see everything had stable power at the right voltage, so the only difference from when it was working normally was that it wasn’t spinning. There is a small magnet on the side of the tower that it sits on, and there is a hall effect sensor that detects the magnet passing on each revolution, so I should be able to fool it into thinking it’s spinning.

A quick look at the circuit board and a check with the scope probe showed that the signal pin from the sensor was pulled up to 3.3V, and every time the magnet passed the sensor would pull it down to 0V. I connected my BusPirate to this pin and set it to PWM mode, generating a 5KHz signal with a 95% duty cycle, and straight away the LEDs lit up.

I chose 5KHz as I was guessing that the motor might spin at 5,000 RPM, though with hindsight, 5KHz is actually making it think it’s rotating at 300,000 RPM, but it worked, so it’s all good in the end.

Tapping The Bus

The next job was to tap into the bus between the microcontroller and the flash memory.

Rather handily, the board has two footprints for the microcontroller and has populated the smaller one, so there was a ring of solder points surrounding it that I could use to attach my wires. So I soldered eight hair-thin enamelled wires to the board and attached them to the logic probe head from my ‘scope, after which I could see a blur of traffic which I assume was the message text being read and used to drive the LEDs.

Now I needed to turn the blur into something more intelligible. I needed to give the ‘scope something to trigger off of, but the flash chip didn’t have a clock signal and the Chip Enable, Output Enable and Write Enable signals were not changing either.

In the end I used the output of the IR receiver as the trigger. The data I was interested in was going to be happening shortly after I pressed a button on the remote control, so I could set the ‘scope to single trigger mode and then scroll through the captured data.

Looking For The PIN

From the Google translation of the brief German instructions on the back of the remote control and a brief bit of experimentation, I knew that the the password was requested when entering edit mode by pressing F1. Once F1 is pressed the display changes to the password prompt, it then accepts four digits in the range 0 to 9 (everything else is ignored), and then F5 needs to be pressed to finish.

From this I could guess two likely points where the microcontroller might read the correct password from the flash memory. It could read it up front when F1 is pressed and it knows I’m about to enter the password, or it could read it when F5 is pressed to finalise password entry.

I started by looking at what happens when I pressed F1. As can be seen in the two screenshots above (The IR receiver data is the yellow trace, the 8-bits of bus data are the rest), there is a constant stream of data from the flash memory until the button is pressed, then the data stops while the IR data is read, then there is a small burst of data, then nothing.

The small burst of data looked like it was made up from four distinct chunks, which could be the four digits of the password, but the password only needs four bytes and each of the chunks contains multiple bytes (the second screenshot is a zoomed in view of the second of the four chunks). Unable to make much sense of this data and hoping that it was related to the password prompt rather than the actual password I moved on to look at what happens when F5 is pressed to finish password entry.

As the second pair of screenshots show, the data transferred after pressing F5 looked a lot more promising. This time the bus was silent until the button was pressed, with the constant stream of traffic resuming after the press. However, just before the main flow of traffic restarted, there was a very narrow band of traffic standing on its own, and zooming in on it showed there were exactly four bytes.

Decoding those bytes gave:

• 00110010 = 0x32 = “2”
• 00110000 = 0x30 = “0”
• 00110001 = 0x31 = “1”
• 00110001 = 0x31 = “1”

So four digits in the range 0 – 9!

Is It The Password?

I tried entering this as the password… I pressed F1 and the LEDs went out (password prompt), I pressed 2… 0… 1… 1… F5… and the LEDs lit up again… which is exactly what happened when entering the wrong password! I tried a couple more times, and the result was always the same. But I didn’t know what was supposed to happen after entering the password, and while it wasn’t spinning all I could see was the LEDs were either mostly on or mostly off.

I needed to get it spinning so that I could see what was actually happening, so I removed all of the wires I’d added, reattached the arm to the motor and plugged it in. Then, once again, I tried entering the password, and… nothing! Same result as before, it just resumed displaying the same text it always had… Or did it?

Actually no, the first three characters of the message had changed from “Mer” to “123”, so I must have been in edit mode at some point! Could I have inadvertently changed the password? There was only one way to find out… take the arm back off the motor, solder all those tiny wires back on and take another look at the bus traffic…

Ten minutes later and the traffic reads… “1123”!

So, remove all of the wires once again, remount the arm, plug it in, F1… 1… 1… 2… 3… F5…, and…

It turns out that pressing F5 while in edit mode prompts for a new password, and after successfully entering the old password, my random button pressing had changed the first three digits of the message to “123” and set “1123” as a new password.