Streaming Video From A Mouse

The first optical mice had to be used on a specially printed mousepad with a printed grid that the four-quadrant infrared sensor could detect. Later, mice swapped the infrared sensor for an optoelectric module (essentially a tiny, very low-resolution camera) and a powerful image processing. [8051enthusiast] was lying in bed one day when they decided to crack the firmware in their gaming mouse and eventually start streaming frames from the camera inside.

Step one was to analyze the protocol between the mouse and the host machine. Booting up a Windows VM and Wireshark allowed him to capture all the control transfers to the USB controller. Since it was a “programmable” gaming mouse that allowed a user to set macros, [8051enthusiast] could use the control transfers that would normally query that macro that had been set to return the memory at an arbitrary location. A little bit of tinkering later, and he now had a dump of the firmware. Looking at the most abundant bytes, it seems to match a profile similar to the Intel 8051. In a fascinating blur of reverse engineering, he traced the main structure of the program back from the function that sets the LED colors for the scroll wheel (which is dependent on the current DPI setting). Unfortunately, the firmware prevented the same macro mechanism from writing to arbitrary locations.

Looking through the code, a good old buffer overflow exploit seemed possible, but it caused the system to reset via watchdog. So he took another approach, invoking recovery mode and loading an entirely new firmware on the device, which a set_report control transfer can invoke.

Next, he moved onto the ADNS-9800 optical sensor (pictured in the top image provided by JACK Enterprises), which had a large encrypted blob in the firmware. Some poking around and deduction lead to a guess that the optical sensor was another 8051 system. With some clever reasoning and sheer determination, [8051enthusiast] was able to crack the XOR stream cipher encryption with a program that showed him versions of the disassembled assembly and allowed him to pick the one that was the most likely. With the firmware decrypted, he was able to see the encryption code and confirm his deducted algorithm.

With the sensor now cracked open, it was onto the 30 x 30 240 fps video stream. The sensor communicates over SPI, and the USB controller has to bit-bang the connection as it doesn’t have the hardware. Putting two custom firmware images on with a few extra functions was easy enough, but the 7 fps was somewhat lacking. The first optimization was loop unrolling and removing some sleeps in the firmware, which bought it up to 34 fps. By measuring the cycle counts of individual instructions, he was able to find some alternatives such as a mov instead of a setb that took one less cycle. Going from a 17 cycle loop to an 11 cycle loop and some other optimizations gave him 54 fps. Not content to stop there, he modified the ADNS-9800 firmware to continuously sample rather than waiting for the USB controller to finish processing. While this yielded 100 fps, there was still more to do: image compression. At a whopping 230 fps, [8051enthusiast] decided to call it done.

However, there was one last thing he wanted to do: control the mouse with the video stream. Writing some image processing into his Python-based program that received the image files allowed him to use the mouse, however impractically.

All in all, it’s an incredible journey by [8051enthusiast], and we would highly recommend reading the whole journey yourself. This isn’t the first time he’s modified the firmware of 8051-based devices, such as modifying the firmware of the WiFi chipset in his laptop.

[Thanks to JACK Enterprises over at Tindie for the use of the image of an ADNS9000].

 

Extracting The WiFi Firmware And Putting Back A Keylogger

In the interest of simplification or abstraction, we like to think of the laptop on the kitchen table as a single discrete unit of processing. In fact, there is a surprisingly large number of small processors alongside the many cores that make up the processor. [8051enthusiast] dove into the Realtek rtl8821ae WiFi chip on his laptop and extracted the firmware. The Realtek rtl8821ae chip is a fairly standard Realtek chip as seen in this unboxing (which is where the main image comes from).

True to his name, [8051enthusiast] was pleased to find that the rtl8821ae was clearly based on the Intel 8051. The firmware was loaded on startup from a known file path and loaded onto the chip sitting in an M.2 slot. Careful consideration, [8051enthusiast] reasoned that the firmware was using RTX51 Tiny, which is a small real-time kernel.

The firmware is loaded at 0x4000 but it calls to code below that address, which means there is a ROM on the chip that contains some code. The easiest way to extract it would be to write some custom code that just copies the masked ROM back to the main CPU via the shared memory-mapped config space, but the firmware is checksummed by the masked ROM code. However, the checksum is just a 16-bit XOR. With a tweak in the kernel to allow accessing the shared config space from userspace, [8051enthusiast] was on his way to a complete firmware image.

Next, [8051enthusiast] looked at what could be done with his newfound hackability. The keyboard matrix is read by the Embedded Controller (EC), which happens to be another 8051 based microcontroller. There also happens to be an RX and a TX trace from the EC to the m.2 slot (where the rtl8821ae is). This has to do with 0x80 postcodes from the processor being routed out somewhere accessible via the EC. With a bit of custom code on both the EC and the WiFi chip, [8051enthusiast] had a keylogger that didn’t run on the main processor broadcasting the PS/2 keystrokes as UDP packets.

Of course, there are plenty of other 8051 based devices out there just waiting to be discovered. Like this 8051 based e-ink display controller.

[Main image source: Realtek RTL8821AE unboxing on YouTube by Евгений Горохов]

Ground Off Part Number Leads To Chip Detective Work

Sometimes when a piece of electronics lands on the bench, you find that its chips have their markings sanded off. The manufacturer is trying to make the task of the reverse engineer less easy, thus protecting their market. [Maurizio Butti] found an unexpected one in an electronic switch designed for remote control systems, it had the simple job of listening to the PWM signal from a receiver in a model aircraft or similar and opening or closing a FET.

From previous experience he suspected it might be a microcontroller from STC based on the location of power, ground, Rx, and Tx pins. This 8051-compatible device could be readily reprogrammed, so he has able to create his own firmware for it. He’s published the code and it’s pretty simple, as it simply replicates the original. He acknowledges that this might seem odd, but makes the point that it is left open for future upgrades such as for example repeatedly cycling the output as in a flashing light.

We don’t see so much of the STC chips here aside from one of their earlier offerings, but the 8051 core features here more regularly as it’s found in Nordic’s NRF24 series of wireless-capable chips.

Reverse Engineering The Sound Blaster

The first sound card to output PCM audio — the kind you need for audio samples — wasn’t the Sound Blaster. The AdLib Music Synthesizer Card could output PCM audio over software. The AdLib card also cost $200 at the time of its release. This was too much for some, and in time the Creative Labs Sound Blaster was released for the rock-bottom price of $125. This was a more capable card, and in the years since prices on the used market have gone through the roof. In 1990, you could buy a Sound Blaster for a Benjamin and a half, in 2019, prices on eBay are reaching and exceeding $400.

With the prices of used cards so high, we start to get into the territory where it starts to make sense to reverse engineer and re-manufacture the entire card. This hasn’t been done before, but that’s no matter for [Eric Schlaepfer], or [@TubeTimeUS]; he’s done crazier projects before, and this one is no different.

In reverse-engineering the Sound Blaster, there are a few necessary components. The Sound Blaster had an OPL2 chip for sound synthesis, which you can get through various vendors. The trick, though, is the microcontroller. This is really just an 8051 with a custom mask ROM.

The goal of this project is actually just to dump the ROM on the Intel 8051-alike microcontroller. This is something that’s relatively commonly done in high-tech labs, and luckily the Bay Area has [John McMaster], the guy who will take you into his lab and strip a die from its epoxy. Looking at the chip under the microscope, it was discovered the mask ROM on this chip was an implant ROM, with the ones and zeros represented by invisible ions in the substrate itself. There was no hope of reverse-engineering this chip from a purely visual inspection, but there was a sense amplifier on one of the data lines. By probing this sense amplifier while running through the address space, [Eric] was able to dump all the bytes of the ROM one bit at a time.

However, and there’s always a however, there are clone Sound Blasters out there, usually from China, and you can dump these chips if you’re lucky enough to get your hands on one. [Eric] reached out to the community and found these clone microcontrollers didn’t have the code protect bit set; dumping these was easy. This ROM was compared to the work [Eric] did with the sense amplifier, and after figuring out the order of the bits, it was found the code matched. The code was successfully cloned, and now new Sound Blasters can be made. Don’t tell eBay that, because someone is trying to sell one of [Eric]’s clone cards for $180.

All the code, files, materials, and everything needed to clone a Sound Blaster can be found in [Eric]’s GitHub, although there are a few open questions as to what’s going on in the Sound Blaster’s microcontroller. There’s a ‘secret’ 512-byte ROM on the die, and no one outside of an Intel NDA knows what it does. This could be used for a manufacturing test, but who knows. Other than that, there are a few features in the code that weren’t used, like previously unknown DSP commands, an ADPCM lookup table, and a routine that plays from SRAM without using DMA. It’s a deep dive into the inner workings of the most popular sound card of all time, and it’s quite simply amazing.

Universal Chip Analyzer: Test Old CPUs In Seconds

Collecting old CPUs and firing them up again is all the rage these days, but how do you know if they will work? For many of these ICs, which ceased production decades ago, sorting the good stuff from the defective and counterfeit is a minefield.

Testing old chips is a challenge in itself. Even if you can find the right motherboard, the slim chances of escaping the effect of time on the components (in particular, capacitor and EEPROM degradation) make a reliable test setup hard to come by.

Enter [Samuel], and the Universal Chip Analyzer (UCA). Using an FPGA to emulate the motherboard, it means the experience of testing an IC takes just a matter of seconds. Why an FPGA? Microcontrollers are simply too slow to get a full speed interface to the CPU, even one from the ’80s.

So, how does it actually test? Synthesized inside the FPGA is everything the CPU needs from the motherboard to make it tick, including ROM, RAM, bus controllers, clock generation and interrupt handling. Many testing frequencies are supported (which is helpful for spotting fakes), and if connected to a computer via USB, the UCA can check power consumption, and even benchmark the chip. We can’t begin to detail the amount of thought that’s gone into the design here, from auto-detecting data bus width to the sheer amount of models supported, but you can read more technical details here.

The Mojo v3 FPGA development board was chosen as the heart of the project, featuring an ATmega32U4 and Xilinx Spartan 6 FPGA. The wily among you will have already spotted a problem – the voltage levels used by early CPUs vary greatly (as high as 15V for an Intel 4004). [Samuel]’s ingenious solution to keep the cost down is a shield for each IC family – each with its own voltage converter.

Continue reading “Universal Chip Analyzer: Test Old CPUs In Seconds”

The Most Flexible Synthesizer Is DIY, Raspberry Pi

[Ivan Franco] sent us this great synthesizer project that he’s working on. Or maybe it’s more like a synthesizer meta-project: a synthesizer construction set. You see, what Pryth has is a Raspberry Pi inside that’s running a custom distribution that includes SuperCollider to generate the sound, OSC for the communication layer, and a Teensy with up to 80 (!) multiplexed analog inputs that you’ll connect up to whatever hardware you desire.

Continue reading “The Most Flexible Synthesizer Is DIY, Raspberry Pi”

Kitchen Timer

A Kitchen Timer Fit For MacGyver

Here’s a project that you don’t want to bring into an airport, ship through the mail, or probably even remove from your home. [ProjectGeek] has built himself a simple kitchen timer masquerading as a bomb. The build is actually pretty simple, but the end result is something that would look at home in a Hollywood action flick.

The timer circuit is built from four simple components. An 8051 microcontroller board is used as the primary controller and timer. The code is available on GitHub. This board is attached to a another board containing four momentary push buttons. These are used to program the timer and to stop the buzzing. Another board containing four 7-segment displays is used to show the remaining time on the timer. A simple piezo buzzer is used to actually alert you when the timer has run out. All of these components are connected with colorful jumper wires.

The physical part of this build is made from easily available components. Old newspapers are rolled up to form the “explosive” sticks. These are then covered in plain brown paper ordinarily used to cover text books. The rolls are bundled together and fixed with electrical tape. The electronics can then be attached to the base with some hot glue or double-sided tape.