Soundbar Bested By Virtual Android Bluetooth Sniffer

Out of the box, the Yamaha YAS-207 soundbar can be remotely controlled over Bluetooth, but only when using a dedicated application on iOS or Android. Users who want to command their hardware with their computer, or any other Bluetooth device for that matter, are left out in the cold. Or at least they were, before [Wejn] got on the case.

To capture the communication between the soundbar and the application, [Wejn] first installed Android-x86 in a virtual machine on his computer and then enabled the “Bluetooth HCI snoop log” within Developer Settings. From there, a netcat command running on the virtual Android device continually sent the contents of the btsnoop_hci.log file out to Wireshark on his Linux desktop. As he hit buttons in the Yamaha application, he could watch the data come in live. We’ve seen plenty of people use Android’s integrated Bluetooth packet capture in the past, but never quite like this. It’s certainly a tip worth mentally filing away for the future.

The Pi can now control the TOSLINK connected speakers.

From there, things move pretty quickly. [Wejn] is able to determine that the devices are communicating over a virtual serial port, and starts identifying individual command and response packets. It turns out the commands closely mirror the NEC IR codes that he’d previously decoded on a whim, which helped clear things up. Once the checksum was sorted out, writing some code that can talk to the soundbar from his Raspberry Pi media player was the next logical step.

[Wejn] combined this with the Shairport Sync project, which lets the Raspberry Pi turn on the speaker and switch the input over when he wants to stream AirPlay from his phone. But of course, the same technique could be applied to whatever source of digital audio captures your fancy.

This is one of those posts you should really read in its entirety to truly appreciate. While every device is going to be different, the basic principles and workflow that [Wejn] demonstrates in this project will absolutely be useful in your own reverse engineering adventures. If you’re more of a visual learner, we recently covered a series of YouTube tutorials that cover sniffing BLE devices that’s not to be missed as well.

[Ken Shirriff] Picks Apart Mystery Chip From Twitter Photo

It’s no secret that the work of [Ken Shirriff] graces the front pages of Hackaday quite frequently. He’s back again, this time reverse engineering a comparator chip from a photo on Twitter. The mysterious chip was decapped, photographed under a microscope, and subsequently posted on the internet with an open call to figure out what it did.

[Ken] stepped up, and at first glance, it was obvious that most of the chip is unused, and there appeared to be four copies of the same circuit. After identifying resistors and the different transistor types, [Ken] found differential pairs.

Differential pairs form the heart of most op-amps, and by chaining them together, you can get a strong enough signal to treat it as a logic signal. Based on the design and materials, [Ken] estimates the chip is from the 1970s. Given that it appears to be ECL (Emitter-Coupled Logic), it could just be four comparators. But there are still a few things that don’t add up as two comparators have additional inverted outputs. Searching the part number offered few if any clues, so this will remain somewhat a mystery.

We’ve covered [Ken’s] incredible chip sleuthing before here, such as the Sharp EL-8 from 1969.

Taking Reverse Engineering To The Skies: Cheap Drone Gets PX4 Autopilot

Sometimes bad software is all that is holding good hardware back. [Michael Melchior] wanted to scavenge some motors and propellers for another project, so he bought an inexpensive quadcopter intending to use it for parts. [Michael] was so surprised at the quality of the hardware contained in his $100 drone that he decided to reverse engineer his quadcopter and give the autopilot firmware a serious upgrade.

Upon stripping the drone down, [Michael] found that it came with a flight management unit based on the STM32F405RG, an Inertial Measurement Unit, magnetic compass, barometric pressure sensor, GPS, WiFi radio, camera with tilt, optical flow sensor, and ultrasonic distance sensor, plus batteries and charger! The flight management unit also had unpopulated headers for SWD, and—although the manufacturer’s firmware was protected from reading—write protection hadn’t been enabled, so [Michael] was free to flash his own firmware.

We highly recommend you take a look at [Michael]’s 10 part tour de force of reverse engineering which includes a man-in-the-middle attack with a Raspberry Pi to work out its WiFi communication, porting the open-source autopilot PX4 to the new airframe, and deciphering unknown serial protocols. There are even amusing shenanigans like putting batteries in the oven and freezer to help figure out which registers are used as temperature sensors. He achieves liftoff at the end, and we can’t wait to see what else he’s able to make it do in the future.

Of course, [Michael] is no stranger to hacking imported quadcopters, and if you’re interested in PX4 but want something quieter than a quadcopter, take a look at this autopilot-equipped glider.

Camera Hack Peels Back Layers Of Embedded Linux

Embedded Linux devices are everywhere these days, and sooner or later, you’re going to want to poke around in one of them. But how? That’s where posts like this one from [Felipe Astroza] come in. While his work is focused on the Foscam C1 security camera, the techniques and tools he outlines here will work on all sorts of gadgets that have a tiny penguin at their core.

Rather than trying to go in through the front door, [Felipe] starts his assault with the nuclear option: removing the SPI MX25L12835F flash chip from the camera’s PCB and dumping its contents with a Raspberry Pi. From there he walks through the use of different tools to determine the partition scheme of the chip and eventually extract passwords and other interesting bits of information from the various file systems within.

Getting ready to remove the flash chip.

That alone would be worth the read, but things really get interesting once [Felipe] discovers the FirmwareUpgrade program. Since the Foscam’s software updates are encrypted, he reasons that reverse engineering this binary would uncover the key and allow for the creation of custom firmware images that can be flashed through the stock interface.

Further investigation with Ghidra and friends identifies an interesting shared library linked to the executable in question, which is then disassembled in an effort to figure out how the key is being obfuscated. We won’t ruin the surprise, but [Felipe] eventually gets what he’s after.

This isn’t the first time [Felipe] has played around with the firmware on these Internet connected cameras, and we dare say it won’t be his last. For those who are really into tinkering with these sort of devices, it’s not unheard of to install a socket for the flash chip to make software modifications faster and easier.

Inside Smart Meters Hack Chat

Join us on Wednesday, April 14 at noon Pacific for the Inside Smart Meters Hack Chat with [Hash]!

That electrical meter on the side of your house might not look like it, but it’s pretty packed with technology. What was once a simple electromechanical device that a human would have to read in person is now a node on a far-flung network. Not only does your meter total up the amount of electricity you use, but it also talks to other meters in the neighborhood, sending data skipping across town to routers that you might never have noticed as it makes its way back to the utility. And the smartest of smart meters not only know how much electricity you’re using, but they can also tease information about which appliances are being used simply by monitoring patterns of usage.

While all this sounds great for utility companies, what does it mean for the customers? What are the implications of having a network of smart meters all talking to each other wirelessly? Are these devices vulnerable to attack? Have they been engineered to be as difficult to exploit as something should be when it’s designed to be in service for 15 years or more?

These questions and more burn within [Hash], a hardware hacker and security researcher who runs the RECESSIM reverse-engineering wiki. He’s been inside a smart meter or two and has shared a lot of what he has learned on the wiki and with some in-depth YouTube videos. He’ll stop by the Hack Chat to discuss what he’s learned about the internals of smart meters, how they work, and where they may be vulnerable to attack.

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 14 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “Inside Smart Meters Hack Chat”

Reverse Engineering Silicon, One Transistor At A Time

Many of will have marveled at the feats of reverse engineering achieved by decapping integrated circuits and decoding their secrets by examining the raw silicon die. Few of us will have a go for ourselves, but that doesn’t stop the process being a fascinating one. Fortunately [Ryan Cornateanu] is on hand with a step-by-step description of his journey into the art of decapping, as he takes on what might seem an unlikely subject in the form of the CH340 USB to serial chip you’ll find on an Arduino Nano board.

Starting with hot sulphuric acid is probably not everyone’s idea of a day at the bench, but having used it to strip the epoxy from the CH340, he’s able to take a look under the microscope. This is no ordinary microscope but a metallurgists instrument designed to light the top of the sample from one side with polarised light. This allows him to identify an area of mask ROM and zoom in on the transistors that make each individual bit.

At this point the chemistry moves into the downright scary as he reaches for the hydrofluoric acid and has to use a PTFE container because HF is notorious for its voracious reactivity. This allows him to take away the interconnects and look at the transistor layer. He can then with a bit of computer vision processing help extract a bit layer map, which with some experimentation and guesswork can be manipulated into a firmware dump. Even then it’s not done, because he takes us into the world of disassembly of what is an unknown architecture. Definitely worth a read for the armchair chip enthusiast.

If you’re thirsty for more, of course we have to direct you towards the work of [Ken Shirriff].

Machine Learning Current Sensor Snoops On MCUs

Anyone who’s ever tried their hand at reverse engineering a piece of hardware has wished there was some kind of magic wand you could tap on a PCB to understand what its doing and why. We imagine that’s what put security researcher [Mark C] on the path to developing CurrentSense-TinyML, a fascinating proof of concept that uses machine learning and sensitive current measurements to try and determine what a microcontroller is up to.

Energy consumption as the LED blinks.

The idea is simple enough: just place a INA219 current sensor between the power supply and the microcontroller under observation, and record the resulting measurements as it goes about its business. Of course in this case, [Mark] knew what the target Arduino Nano was doing because he wrote the code that blinks its onboard LED.

This allowed him to create training data for TensorFlow, which was ultimately optimized into a model that could fit onto the Arduino Nano 33 BLE Sense which stands in for our magic wand. The end result is that the model can accurately predict when the Nano has fired up its LED based on the amount of power it’s using. [Mark] has done a fantastic job of documenting the whole process, which also doubles as a great intro for putting machine learning to work on a microcontroller.

Now we already know what you’re thinking: obviously the current would go up when the LED was lit, so the machine learning aspect is completely unnecessary. That may be true in this limited context, but remember, this is just a proof of concept to base further work on. In the future, with more training data, this technique could potentially be used to identify a whole range of nuanced activities. You’d be able to see when the MCU was sitting idle, when it was writing to flash, or when it was reading from sensors. In fact, with a good enough model, it might even be possible to identify the individual sensors that are being polled.

These are early days, but we’re very interested in seeing where this research goes. It might not be magic, but if analyzing the current draw of a coffee maker can tell you how much everyone in the office is drinking, then maybe it can help us figure out what all these unlabeled ICs are doing.