The Tools That Lovingly Tore Apart A Vintage Computer Game

The structure of computer game assets can be a bit of a mystery, even more so the older a game is, and some amount of reverse-engineering can be expected when pulling apart a game like 1995’s Night Light.

[voussoir] had fond memories of this game by GTE Entertainment, which had an interesting “flashlight” mechanic to serve the exploration theme. Spooky shapes in dark rooms would be revealed to be quite ordinary (and therefore not scary at all) once illuminated with a flashlight, which was directed by the mouse.

Extracting game assets was partly straightforward, thanks to many of them being laid out in a handy folder structure, with .bmp files for each level in a modest resolution. But there were also some unusual .mov files that were less than a second long, and those took a little more work to figure out.

It turns out that these unusual movie files were 80 frames in length, and each frame was a tile of a larger image. [voussoir] used ffmpeg to extract each frame, then wrote a Python script to stitch the tiles together. Behold! The results are high-resolution versions of each level’s artwork. Stitching the first 16 frames into a 4×4 grid yields a 1024×768 image, and the remaining 64 frames can be put into a 8×8 grid for a fantastic 2048×1376 version. The last piece was extracting audio, but sadly the ISO [voussoir] was using seems to have had errors, and not all the audio survived.

With intact assets in hand, [voussoir] was able to re-create the core of the game, which can be seen about halfway down into the writeup. Audio clues play simply while the flashlight effect is re-created in the browser with the game’s original level artwork, and it’s enough to ring those nostalgia bells. It’s a pretty successful project, even though not all of the assets have been tracked down, and not all of the audio was able to be extracted due to corruption. If you have any insights on that front, don’t keep them to yourself! Send [voussoir] an email, or chime in here in the comments.

Reverse engineering has a strong history when it comes to games, and has manifested itself in sometimes unusual ways, like the time Atari cracked the NES. Had the subsequent legal challenge gone differently, the game landscape might have looked very different today.

A light blue marker with a two-pin header replacing the tip, being pressed against the back of the keypad baord that's removed from the safe

Anyone Can Be The Master Of This Master Lock Safe

[Etienne Sellan] got one of these lovely $5 logic analyzers. As with any shiny new tool, he started looking for things to investigate with it, and his gaze fell on a Sentry Safe (produced by Master Lock). On the surface level, this keypad-equipped safe is designed decently when it comes to privilege separation. You can take the keypad board off and access its backside, but the keypad doesn’t make any decisions, it merely sends the digits to a different board embedded behind the safe’s door. The solenoid-connected board receives the PIN, verifies it, and then controls the solenoid that unlocks the safe.

[Etienne] hooked up a logic analyzer to the communication wire, which turned out to be a UART channel, and logged the keypad communication packets — both for password entry and for password change. Then, he wrote some Arduino code to send the same packets manually, which worked wonders. Bruteforcing wasn’t viable, however, due to rate limitation in the solenoid controller. Something drew his attention from there – if you want to change the password, the keypad requires you enter the factory code, unique to each safe and supplied in the instruction manual. That code entry is a separate kind of packet from the “change password” one.

More after the break…

Continue reading “Anyone Can Be The Master Of This Master Lock Safe”

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”