Nobody likes opening up a hacking target and finding a black epoxy blob inside, but all hope is not lost. At least not if you’ve got the dedication and skills of [Jeroen Domburg] alias [Sprite_tm].
It all started when [Big Clive] ordered a chintzy Chinese musical meditation flower and found a black blob. But tantalizingly, the shiny plastic mess also included a 2 MB flash EEPROM. The questions then is: can one replace the contents with your own music? Spoiler: yes, you can! [Sprite_tm] and a team of Buddha Chip Hackers distributed across the globe got to work. (Slides here.)
[Jeroen] started off with binwalk and gets, well, not much. The data that [Big Clive] dumped had high enough entropy that it looks either random or encrypted, with the exception of a couple tiny sections. Taking a look at the data, there was some structure, though. [Jeroen] smelled shitty encryption. Now in principle, there are millions of bad encryption methods out there for every good one. But in practice, naive cryptographers tend to gravitate to a handful of bad patterns.
Bad pattern number one is XOR. Used correctly, XORing can be a force for good, but if you XOR your key with zeros, naturally, you get the key back as your ciphertext. And this data had a lot of zeros in it. That means that there were many long strings that started out the same, but they seemed to go on forever, as if they were pseudo-random. Bad crypto pattern number two is using a linear-feedback shift register for your pseudo-random numbers, because the parameter space is small enough that [Sprite_tm] could just brute-force it. At the end, he points out their third mistake — making the encryption so fun to hack on that it kept him motivated!
Decrypted, the EEPROM data was a filesystem. And the machine language turned out to be for an 8051, but there was still the issue of the code resident on the microcontroller’s ROM. So [Sprite_tm] bought one of these flowers, and started probing around the black blob itself. He wrote a dumper program that output the internal ROM’s contents over SPI. Ghidra did some good disassembling, and that let him figure out how the memory was laid out, and how the flow worked. He also discovered a “secret” ROM area in the chip’s flash, which he got by trying some random functions and looking for side effects. The first hit turned out to be a memcpy. Sweet.
Well, victory if all you wanted to do was hack your music onto the chip. As a last final fillip, [Sprite_tm] mashed the reverse-engineered schematic of the Buddha Flower together with [Thomas Flummer]’s very nice DIY Remoticon badge, and uploaded our very own intro theme music into the device on a badge. Bonus points? He added LEDs that blinked out the LSFR that were responsible for the “encryption”. Sick burn!
Editor’s Note: This is the last of the Remoticon 2 videos we’ve got. Thanks to all who gave presentations, to all who attended and participated in the lively Discord back channel, and to all you out there who keep the hacking flame alive. We couldn’t do it without you, and we look forward to a return to “normal” Supercon sometime soon.
Hey, congratulations!
I was one of the people on the thread, and did some work teaching the new instructions to ghidra to reverse engineer the ROM (ghidra is _awesome_), but after several failed attempts to get hold of the actual hardware eventually gave up. (There are multiple manufacturers of these things not all of which use the same architecture and I always ended up with the wrong one.) I’m glad to see that people have been continuing to pick away at this.
The CPU, BTW, is a really interesting 8051 variation with 16-bit instruction extensions. It’s almost like two CPUs glued together. I did 3/4 of a compiler port for it but without being able to run actual instructions to figure out the details of what the 16-bit instructions do was unable to finish it — there’s no information in the SDK beyond the names. The great thing about the chip is that it’s capable of running code out of RAM, unlike a lot of 8051 clones, which means that if it were possible to get hold of the chips they’d make really nice little development systems: you can load programs on-the-fly from an actual filesystem. I don’t know how much RAM they’d got but it’s on the order of 8kB. That’s loads for such a cheap processor.
I love the 8051. It’s the architecture that Will Not Die. Everything about it is terrible, and yet people still keep coming up with more and more terrible things to do with it…
Got to agree about the 8051. I worked on a project that had several 8051 cores in it, and it was always entertaining to work with them (ASM only). The low number of gates required to implement them is probably an attraction for manufacturers too.
I always wondered if the 8051 / 8031 were a favourite microcontroller in universities were everyone “cut their teeth”? I see 8051 clones everywhere.
In Australia a Uni favourite was the Motorola 68HC11 but you don’t see them in the wild, I rarely see any Motorola MCUs in the wild.
I my early days for the favourite you had to keep the drive to output ratio as linear as possible and avoid secondary emission. And we didn’t even have an assembler!
Z80 followed by ARM and 68k here. The latter being one of my least favourite architectures ever.
“I found a copy of the SDK in the hive of scum and villainy on the backwards bits of the internet that’s called … Github.”
Lol! Love it!
I’ve seen a similar-looking IC with a “JL” logo on it in a cheap (and hard to trace what company it came from) bluetooth controlled robot toy called the “orbit bot”. The chip number is jl ab20bp02343.
Some of the language doesn’t seem to cross over or translate to well.
Random means unpredictable.
Pseudo random means like random – perhaps very difficult to predict.
A LFSR outputs every number in it’s range, in an only just maybe “pseudo random” order. It does NOT repeat any number during this full cycle just every number exactly once. Then the cycle repeats with every number in exactly the same order meaning that after only one complete cycle any future output is 100% predictable. There is nothing even “pseudo” random about that.
So using a LFSR at best could possibly be called obscurification and not encryption. Obscurification is a term more related to security (or the lack of) than encryption.
Only need 2N+1 bits to identify the LSFR used, especially for maximal length taps. Brute strength certainly shows the power of modern cpus.
See Wikipedia,https://en.m.wikipedia.org/wiki/Berlekamp%E2%80%93Massey_algorithm
Googled a possibly correct Implementation in python.
https://github.com/thewhiteninja/lfsr-berlekamp-massey
LSFR are generally used in wireless comms to whiten the data, don’t want that nice psk collapsing to a tone when someone transmits all zeros/ones.
The greatest irony here is that Chinese manufacturers do this to prevent their products (IP) from being cloned by other Chinese manufacturers.
Their only real competition.