[dropbear] recently found herself in a pickle. Dumping some data out of an Android app at a specific point for reverse engineering purposes. While it worked great in the simulator, it was painfully slow on hardware via lldb. The solution was to write a patch and apply it to the ELF file.
Writing the AArch64 assembly to dump the buffer is relatively trivial, but adding it to the existing ELF and repackaging it into a new APK leads to strange errors. The relative offsets into .rodata are now all wrong. For those who don’t routinely interface with the format of ELF files, we have a fantastic resource to take you into the dark depths. But the quick summary version is that sections contain various resources, and you find parts of those resources by relative offsets. The program header describes what type of resources each section contains.
[dropbear] found a NOTE section that just contained some metadata. She created a new section at the end of the file for her custom assembly and modified the header to declare the NOTE section as a LOAD section that pointed at her new section, which would get mapped into memory. All that was left to do was tweak the assembly in the actual code to jump to her new code that dumps. The BSS section was extended by a few bytes so that her program could store its state there.
[Jure Spiler] was at a flea market and got himself a spectrophotometer — a device that measures absorbance and transmittance of light at different wavelengths. This particular model seems to be about 25 years old, and it’s controlled by a built-in keyboard and uses a graphical LCD to display collected data. That might have been acceptable when it was made, but it wasn’t enough for [Jure]. Since he wanted to plot the spectrophotometry data and be able to save it into a CSV file, hacking ensued.
He decided to tap into the the display communication lines. This 128×64 graphical display, PC-1206B, uses a 8-bit interface, so with a 16-channel logic analyzer, he could see the data being sent to the display. He even wrote decoder software – taking CSV files from the logic analyzer and using primitive optical recognition on the decoded pixels to determine the digits being shown, and drawing a nice wavelength to absorbance graph. From there, he set out to make a standalone device sniffing the data bus and creating a stream of data he could send to a computer for storage and processing.
[Jure] stumbled into a roadblock, however, when he tried to use an Arduino for this task. Even using a sped-up GPIO library (as opposed to notoriously inefficientdigitalRead), he couldn’t get a readout frequency higher than 80 KHz – with the required IO readout rate deemed as 1 MHz, something else would be called for. We do wonder if something like RP2040 with its PIO machinery would be better for making such captures.
At that point, however, he found out that there’s undocumented serial output on one of the pins of the spectrophotometer’s expansion port, and is currently investigating that, having shelved the LCD sniffing direction. Nevertheless, this serves as yet another example for us, for those times when an LCD connection is all that we can make use of.
[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?
This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.
Despite being a computer with some extra chips, synthesizers today are still quite expensive. They used to cost far more, but we tend to think of them as instruments instead of computers. And just because it is an instrument doesn’t mean someone like [Peter Sobot] can’t crack it open and patch the OS inside.
The synth in question is a Kurzweil K2500, released in 1996 with a Motorola 68000. Rather than directly start pulling out parts on the kitchen table, [Peter] began by doing some online research. The K2500 operating system is still available online, and a quick pass through Ghidra showed some proper instructions, meaning the file likely wasn’t encrypted.
He found the part of the code that reads in a new firmware file and checks the header and checksum. Certain functions were very high in memory, and a quick consultation of the service manual yielded an answer: it was the volatile RAM. With that tidbit, [Peter] was able to find the function that copied chunks of the new ROM file to RAM and start decoding the file correctly. [Peter] changed a few strings, made sure the checksums were correct, and he was ready to flash. The actual tweaks that [Peter] are made are left up to the reader, but the techniques to get a working decompiled build and a viable ROM image to flash apply to many projects. One benefit is now the K2000 simulates correctly in MAME due to his spelunking. He has his flashing script up on GitHub for the curious.
Ghidra is perfect for this kind of thing. We’ve seen people tweaking their water coolers with it. It opens to door towards tweaking anything to your liking.
My niece’s two favorite classes in high school this year are “Intro to AI” and “Ethical Hacking”. (She goes to a much cooler high school than I did!) In “Hacking”, she had an assignment to figure out some bug in some body of code. She was staring and staring, figuring and figuring. She went to her teacher and said she couldn’t figure it out, and he asked her if she’d tried to search for the right keywords on the Internet.
My niece responded “this is homework, and that’d be cheating”, a line she surely must have learned in her previous not-so-cool high school. When the teacher responded with “but doing research is how you learn to do stuff”, my niece was hooked. The class wasn’t abstract or academic any more; it became real. No arbitrary rules. Game on!
But I know how she feels. Whether it’s stubborn independence, or a feeling that I’m cheating, I sometimes don’t do my research first. But attend any hacker talk, where they talk about how they broke some obscure system or pulled off an epic trick. What is the first step? “I looked all over the Internet for the datasheet.” (Video) “I found the SDK and that made it possible.” (Video) “Would you believe this protocol is already documented?” In any serious hack, there’s always ample room for your creativity and curiosity later on. If others have laid the groundwork for you, get on it.
If you have trouble overcoming your pride, or NIH syndrome, or whatever, bear this in mind: the reason we share information with other hackers is to give them a leg up. Whoever documented that protocol did it to help you. Not only is there no shame in cribbing from them, you’re essentially morally obliged to do so. And to say thanks along the way!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
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.
[Neil555]’s Rosetta StoneMeanwhile, the Internet was still working on this device, and [Neil555] bought a flower too. But this one had a chip, rather than a blob, and IDing this part lead them to an SDK, and that has an audio suite that uses a derivative of WMA audio encoding. And that was enough to get music loaded into the flower. (Cue a short rick-rolling.) Victory!
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.
Fifty years ago, Hewlett-Packard introduced the first handheld scientific calculator, the HP-35. It was quite the engineering feat, since equivalent machines of the day were bulky desktop affairs, if not rack-mounted. [Rob Weinstein] has long been a fan of HP calculators, and used an HP-41C for many years until it wore out. Since then he gradually developed a curiosity about these old calculators and what made them tick. The more he read, the more engrossed he became. [Rob] eventually decided to embark on a three year long reverse-engineer journey that culminated a recreation of the original design on a protoboard that operates exactly like the original from 1972 (although not quite pocket-sized). In this presentation he walks us through the history of the calculator design and his efforts in understanding and eventually replicating it using modern FPGAs.
The HP patent ( US Patent 4,001,569 ) contains an extremely detailed explanation of the calculator in nearly every aspect. There are many novel concepts in the design, and [Rob] delves into two of them in his presentation. Early LED devices were a drain on batteries, and HP engineers came up with a clever solution. In a complex orchestra of multiplexed switches, they steered current through inductors and LED segments, storing energy temporarily and eliminating the need for inefficient dropping resistors. But even more complicated is the serial processor architecture of the calculator. The first microprocessors were not available when HP started this design, so the entire processor was done at the gate level. Everything operates on 56-bit registers which are constantly circulating around in circular shift registers. [Rob] has really done his homework here, carefully studying each section of the design in great depth, drawing upon old documents and books when available, and making his own material when not. For example, in the course of figuring everything out, [Rob] prepared 338 pages of timing charts in addition to those in the patent. Continue reading “Remoticon 2021 // Rob Weinstein Builds An HP-35 From The Patent Up”→