The speaker PCB inside of the speaker, with a flash chip ZIF holder soldered to the SPI flash pads on the PCB

Bluetooth Speaker Domesticated Through Firmware Mod

This might sound like a familiar problem – you get a Bluetooth speaker, and it sounds nice, but it also emits all kinds of weird sounds every now and then. [Oleg Kutkov] got himself a Sven PS460 speaker with FM radio functionality, but didn’t like that the “power on” sound was persistently loud with no respect for the volume setting, and the low battery notification sounds were bothersome. So, he disassembled the speaker, located a flash chip next to the processor, and started hacking.

Using a TL866 and minipro software, he dumped the firmware, and started probing it with binwalk. The default set of options didn’t show anything interesting, but he decided to look for sound file signatures specifically, and successfully found a collection of MP3 files! Proper extraction of these was a bit tricky, but he figured out how to get them out, and loaded the entire assortment into Audacity.

From there, he decided to merely make the annoying sounds quieter – negating the “no respect for the volume setting” aspect somewhat. After he exported the sound pack out of Audacity, the file became noticeably smaller, so he zero-padded it, and finally inserted it back into the firmware. Testing revealed that it worked just as intended! As a bonus, he replaced the “battery low” indicator sound with something that most of us would appreciate. Check out the demo video at the end of his write-up.

Domesticating your Bluetooth speakers tends to be called for. If you can’t do that for whatever reason, you can rebuild them into an audio receiver – or perhaps, build your own Bluetooth speakers, with aesthetics included and annoyance omitted from the start.

iPhone 6 with Linux boot log on its screen

Boot Mainline Linux On Apple A7, A8 And A8X Devices

[Konrad Dybcio] tells about his journey booting Linux on A7/8/8X processors, playing around with an old iPhone 5 he’s got in a drawer. It’s been a two-year “revisit every now and then” journey, motivationally fueled by the things like Linux on M1 Macs announcement. In the end, what we have here is a way to boot mainline Linux on a few less-than-modern but still very usable iPhones, and a fun story about getting there.

[Konrad]’s work is based on the Sandcastle project research, but he couldn’t quite figure out how to make their code work, and had to make sense of it as he went. At some point, he got stuck on enabling the MMU, which was the main roadblock for a while. Joined by another developer intrigued by Apple hardware, they were hacking away at it, developing tools and neat tricks on their way, but to no avail. With the framebuffer accessible and no other decent debugging methods in sight, he tells about a code snippet they wrote that printed register values as valid barcodes Continue reading “Boot Mainline Linux On Apple A7, A8 And A8X Devices”

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.