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

June 13, 2022 by Arya Voronova 30 Comments

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.

DOOM On A Desk Phone Is Just The Tip Of The Iceberg

August 13, 2021 by Tom Nardi 23 Comments

These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.

As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.

If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.

Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.

[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.

Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.

Remoticon Video: Firmware Reverse Engineering Workshop With Asmita Jha

November 19, 2020 by Mike Szczys 4 Comments

Taking things apart to see how they work is an important part of understanding a system, and that goes for software as much as for hardware. You can get a jump start on your firmware reverse engineering skills with Asmita Jha’s workshop which was presented live at the Hackaday Remoticon. The video has just been published, and is found below along with a bit more on what she covered in her hands-on labs.

Continue reading “Remoticon Video: Firmware Reverse Engineering Workshop With Asmita Jha” →

Poking Around Inside A Pair Of Classic Gaming Gifts

January 7, 2020 by Tom Nardi 5 Comments

Retro gaming is huge right now, and like probably millions of other people, [wrongbaud] found himself taking possession of a couple faux-classic gaming gadgets over the holidays. But unlike most people, who are now using said devices to replay games from their youth, he decided to tear into his new toys to see how they work.

The first to get pulled apart is a handheld The Oregon Trail game, which Hackaday readers may recall from a teardown we did back when it was first released. His work continues right where our teardown left off, by pulling the game’s two EEPROM chips out and dumping their contents. As expected, [wrongbaud] found that the I2C connected chip contained the game save information, and the SPI flash chip stored the actual game files.

Next up was an HDMI “stick” from Bandai Namco that allows the user to play a selection of NES games. Here again [wrongbaud] liberates the flash chip and dumps it for examination, this time using an ESP32 tool of his own creation. Inside the firmware image he’s able to identify several elements with the help of binwalk, such as splash screen graphics and text strings.

But perhaps most interestingly, he found that binwalk was able to automatically extract the NES ROMs themselves. After verifying they were standard ROMs with an NES emulator, he theorizes that repacking the firmware with different ROMs should be possible should anyone feel so inclined.

Both of these hacks are fantastic examples of how you can reverse engineer a device’s firmware with low cost hardware, open source tools, and a healthy dose of patience. Even if you aren’t interested in fiddling with The Oregon Trail or swapping out the Mappy ROM for Contra, this write-up is an invaluable resource for anyone looking to do their own firmware analysis.

This isn’t the first time [wrongbaud] has hacked around inside these extremely popular retro games, either. Just last month we covered some of his previous exploits with the re-released versions of Rampage and Mortal Kombat.

Hacking Your Way To A Custom TV Boot Screen

December 7, 2018 by Tom Nardi 45 Comments

More and more companies are offering ways for customers to personalize their products, realizing that the increase in production cost will be more than made up for by the additional sales you’ll net by offering a bespoke product. It’s great for us as consumers, but unfortunately we’ve still got a ways to go before this attitude permeates all corners of the industry.

[Keegan Ryan] recently purchased a TV and wanted to replace its stock boot screen logo with something of his own concoction, but sadly the set offered no official way to make this happen. So naturally he decided to crack the thing open and do it the hard way The resulting write-up is a fascinating step by step account of the trials and tribulations that ultimately got him his coveted custom boot screen, and just might be enough to get you to take a screw driver to your own flat panel at home.

The TV [Keegan] brought was from a brand called SCEPTRE, but as a security researcher for NCC Group he thought it would be a fun spin to change the boot splash to say SPECTRE in honor of the infamous x86 microarchitecture attack. Practically speaking it meant just changing around two letters, but [Keegan] would still need to figure out where the image is stored, how it’s stored, and write a modified version to the TV without letting the magic smoke escape. Luckily the TV wasn’t a “smart” model, so he figured there wouldn’t be much in the way of security to keep him from poking around.

He starts by taking the TV apart and studying the main PCB. After identifying the principle components, he deduces where the device’s firmware must be stored: an 8 MB SPI flash chip from Macronix. He connects a logic analyzer up to the chip, and sure enough sees that the first few kilobytes are being read on startup. Confident in his assessment, he uses his hot air rework station to lift the chip off the board so that he can dive into its contents.

With the help of the trusty Bus Pirate, [Keegan] is able to pull the chip’s contents and verify its integrity by reading a few human-readable strings from it. Using the binwalk tool he’s able to identify a JPEG image within the firmware file, and by feeding its offset to dd, pull it out so he can view it. As hoped, it’s the full screen SCEPTRE logo. A few minutes in GIMP, and he’s ready to merge the modified image with the firmware and write it back to the chip.

He boots the TV back up and finds…nothing changed. A check of the datasheet for the SPI flash chip shows there are some protection bits used to prevent modifying particular regions of the chip. So after some modifications to the Bus Pirate script and another write, he boots the TV and hopes for the best. Finally he sees the object of his affection pop up on the big screen, a subtle change that reminds him every time the TV starts about the power of reverse engineering.

Hacking A KVM: Teach A Keyboard Switch To Spy

August 8, 2015 by Mike Szczys 11 Comments

When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.

Continue reading “Hacking A KVM: Teach A Keyboard Switch To Spy” →

Hacking The Linksys WRT120N Part 2

February 21, 2014 by Adam Fabio 12 Comments

linksysjtag

[Craig Heffner] has been busy with his Linksys WRT120N router. When we last checked in on [Craig] he had reverse engineered the obfuscation techniques used in the router’s firmware. Since then, he’s re-enabled JTAG, cracked the “encryption” used for saving configuration backups, and now he’s devised a simple attack to change the admin password. With the firmware unlocked, [Craig] went after the hardware JTAG. His first hurdle was a missing jumper connecting the TDI pin to the processor. With a solder blob making the connection, he then found the router would connect to his JTAG debugger, and immediately reset. TDI had been re-used as a GPIO in software, and assigned to the reset button on the back of the router. [Craig’s] JTAG pod was pulling the pin low and causing the reset. To make matters worse, the bootloader also redefined and checked for the reset button. If the button were pressed it would boot into a recovery mode. [Craig] patched the bootloader with a little help from IDA pro. He then desoldered the router’s flash and programmed it outside the system. The firmware required a similar patch. Rather than desolder the flash chip again, [Craig] created a firmware update the router would accept and flashed it via the router’s web interface.

Since he already was deep into the Linksys Firmware, [Craig] looked for any obvious attack vectors. He found a big one in the /cgi/tmUnBlock.cgi. Inside the firmware, the URL sent to the CGI would be sent through sprintf(). In plain english, it means that no input length checking was happening – so a URL longer than the firmware engineers expected (in this case 256 bytes) would overflow into areas of memory it wasn’t supposed to – in this case, the stack. For an astute attacker, that’s a wide open door. [Craig] was able to use find some Return Oriented Programming (ROP) gadgets and created an input value that would cause the router to reset its own administrator password. After running the exploit, a quick trip to the router’s webpage proved his attack was successful.

If that wasn’t enough, [Craig] also spent some time looking at the patches to the router’s firmware. The release notes of one of the patches mentioned encrypting configuration files. The WRT120N, like many routers, allows the owner to download and save the configuration as a file. It turned out that the “encryption” scheme was nothing more than an exclusive OR with 0xFF. A pretty weak encryption scheme by any standards. To [Craig] we send our congratulations. To the WRT120N software engineers, we’d suggest taking one of [Craig’s] embedded device exploitation classes.