Gaze Inside These Nanopower Op-Amps

[Robo] over at Tiny Transistor Labs has a fascinating look at what’s inside these modern, ultra low-power devices that consume absolutely minuscule amounts of current. Crank up the magnification, and go take a look at the dies on these two similar (but internally very different) devices.

Texas Instruments LPV801, under the hood.

The first unit is the Texas Instruments LPV801, a single-channel op-amp that might not be very fast, but makes up for it by consuming only a few hundred nanoamps. Inside, [Robo] points out all the elements of the design, explaining how a part like this would be laser-trimmed to ensure it performs within specifications.

The second part is the Texas Instruments LPV821 which uses a wee bit more power, but makes up for it with a few extra features like zero-drift and EMI hardening. Peeking inside this device reveals the different manufacturing process this part used, and [Robo] points out things like the apparent lack of fuses for precise trimming of the part during the manufacturing process.

Seeing these structures up close isn’t an everyday thing for most of us, so take the opportunity to check out [Robo]’s photos. Tiny Transistor Labs definitely takes the “tiny” part of their name seriously, as we’ve seen with their 555 timer, recreated with discrete transistors, all crammed into a package that’s even the same basic size as the original.

the dongle developed by Marcel, with a USB-A plug on one end and an SMD antenna on the other

Hackaday Prize 2022: House Ventilation Reverse-Engineered And Automated

[Marcel] thought – what if he had more control over his house ventilation system? You could add some nifty features, such as automatically ventilating your house in the mornings when everyone’s away, only creating noise when nobody’s around to hear it. Sadly, most ventilation systems are not automation-friendly at all – he was lucky, however, as his system came with a wireless remote. [Marcel] reverse-engineered this remote, created a USB dongle speaking the same protocol, and tied it into his Home Assistant setup!

The remote in question is Orcon R15, with an Atmel MCU talking to a CC1101 chip through SPI. He sniffed the SPI communications when pressing different buttons, figured out the protocol by comparing the recordings, and built a test setup with a spare Arduino and CC1101 module. It worked, and he set out to design a separate dongle, using an ATMega32U4. The dongle looks pretty neat, and fits a Hammond enclosure – what’s not to like?

Then he set out to develop the firmware, and didn’t disappoint on that front either. His code doesn’t just imitate the original remote perfectly in terms of control, it also has user-friendly pairing flow, keeps track of the system’s current state, and still lets the original remote be used in parallel. Eagle files for the PCB are available on the project page, with the code and a PDF schematic available in the GitHub repo. This entire journey is described in the Hackaday.io page, and we would recommend you check it out for all the insights it provides!

Ventilation systems don’t tend to be designed for automation, and it’s endearing to see hackers working on conquering this frontier. Last time we’ve seen a ventilation system hack, it had the additional challenge of being landlord-friendly, and we think the hacker nailed it!

Hack Another ELF On The Stack

[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.

It’s an impressive technique, and her program for modifying the program header is on her website under a BSD-3 license.

Photo of the spectrophotometer in question, with a screenshot of the decoding software on the right

Exporting Data From Old Gear Through LCD Sniffing

[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 inefficient digitalRead), 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.

We’ve seen hackers sniff LCD interfaces to get data from reflow ovens, take screenshots from Game Boys and even equip them with HDMI and VGA ports afterwards. With a skill like this, you can even give a new life to a vintage calculator with a decayed display! Got an LCD-equipped device but unsure about which specific controller it uses? We’ve talked about that!

Continue reading “Exporting Data From Old Gear Through LCD Sniffing”

The microcontroller described in the article, on the PCB taken out of the kettle

Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle

[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.

Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”

A Kurzweil K2500 piano

Patching The Kurzweil K2500 Synthesizer

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.

Research: It’s Like Cheating, But Fair

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!