Exploring Custom Firmware On Xiaomi Thermometers

December 8, 2020 by Tom Nardi 55 Comments

If we’ve learned anything over the years, it’s that hackers love to know what the temperature is. Seriously. A stroll through the archives here at Hackaday uncovers an overwhelming number of bespoke gadgets for recording, displaying, and transmitting the current conditions. From outdoor weather stations to an ESP8266 with a DHT11 soldered on, there’s no shortage of prior art should you want to start collecting your own environmental data.

Now obviously we’re big fans of DIY it here, that’s sort of the point of the whole website. But there’s no denying that it can be hard to compete with the economies of scale, especially when dealing with imported goods. Even the most experienced hardware hacker would have trouble building something like the Xiaomi LYWSD03MMC. For as little as $4 USD each, you’ve got a slick energy efficient sensor with an integrated LCD that broadcasts the current temperature and humidity over Bluetooth Low Energy.

You could probably build your own…but why?

It’s pretty much the ideal platform for setting up a whole-house environmental monitoring system except for one detail: it’s designed to work as part of Xiaomi’s home automation system, and not necessarily the hacked-together setups that folks like us have going on at home. But that was before Aaron Christophel got on the case.

We first brought news of his ambitious project to create an open source firmware for these low-cost sensors last month, and unsurprisingly it generated quite a bit of interest. After all, folks taking existing pieces of hardware, making them better, and sharing how they did it with the world is a core tenet of this community.

Believing that such a well crafted projected deserved a second look, and frankly because I wanted to start monitoring the conditions in my own home on the cheap, I decided to order a pack of Xiaomi thermometers and dive in.

Continue reading “Exploring Custom Firmware On Xiaomi Thermometers” →

ESP32 Turned Open Source COVID-19 Contact Tracer

July 28, 2020 by Tom Nardi 17 Comments

Over the past few months we’ve heard a lot about contact tracers which are designed to inform users if they’ve potentially come into close proximity with someone who has the virus. Generally these systems have been based on smartphone applications, but there are also hardware solutions that can operate independently for those who are unable or unwilling to install the software. Which is precisely what [Tom Bensky] has implemented using an ESP32 and a USB battery bank.

The idea is simple: the software generates a unique ID which is broadcast out by the ESP32 over Bluetooth Low Energy. Appended to that ID is a code that indicates the person’s current physical condition. There’s no centralized database, each user is expected to update their device daily with any symptoms they may be experiencing. If your tracker is blinking, that means somebody has come in close enough proximity that you should look at the collected data and see how they were feeling at the time.

It’s not a perfect system, of course, as for one thing the number of people that are willing and able to flash this firmware onto a spare ESP32 and carry the thing around with them all day is going to be extremely small. This might have filled an interesting niche if we were still going to hacker and maker cons this summer, but all of those have gone virtual anyway. That said, it’s an interesting look at how a decentralized contact tracing system can be implemented cheaply and quickly.

Another detail worth taking a look at is how [Tom] handled the user experience in his firmware. In an effort to make the tracer as easy as possible to configure, he’s using the Web Bluetooth capability of Google Chrome. Just open up the local web page in your browser, and it will handle talking to the hardware for you. Even if you’re not in the market for a contract tracer, we think this is a great example for how to handle end-user configuration on the ESP32.

We’ve already looked at contact tracer APIs from Google and Apple, dedicated COVID-19 hardware tokens, and even other open source attempts at decentralized proximity tracking. It’s a lot to process, and everyone seems to have their own idea on how it should be done. In the end, the most practical solution is probably to just stay at home as much as possible.

Poking Around The Wide World Of Bluetooth

January 30, 2020 by Tom Nardi 8 Comments

Bluetooth is a technology with a very interesting history. When it first came around in the late 1990s, it promised to replace the mess of wires that was tucked behind every desk of the day. Unfortunately, the capabilities of early Bluetooth didn’t live up to the hype, and it never quite took off. It wasn’t until the rise of the smartphone more than a decade later that Bluetooth, now several versions more advanced, really started to make sense.

As [Larry Bank] explains in a recent blog post, that means there’s a whole lot to learn if you want to really understand Bluetooth hacking. For example, the Bluetooth versions that were used in the 1990s and 2000s are actually a completely different protocol from that which most modern devices are using. But the original protocol, now referred to as “Classic”, is still supported and in use.

That means to really get your head wrapped around working with Bluetooth, you need to learn about the different versions and all the tools and tricks associated with them. To that end, [Larry] does a great job of breaking down the primary versions of Bluetooth and the sort of tools you might find yourself using. That includes microcontrollers such as the ESP32 or Arduino Nano 33 BLE.

But the post isn’t just theory. [Larry] also goes over a few real-world projects of his that utilize Bluetooth, such as getting a portable printer working with his Arduino, or figuring out how to use those tiny mobile phone game controllers for his own purposes. Even if you don’t have these same devices, there’s a good chance that the methods used and lessons learned will apply to whatever Bluetooth gadgets you’ve got your eye on.

Readers may recall [Larry] from our previous coverage of his exploits, such as his efforts to increase the frame rate of the SSD1306 OLED display or his wireless bootloader for the SMART Response XE. Whenever we see his name pop up in the Tip Line, we know a fascinating hardware deep dive isn’t far behind.

3D Printed Goggles Let R.O.B. See Into The Bluetooth World

December 16, 2019 by Erin Pinheiro 4 Comments

We admit that a hack enabling a 34-year-old video game peripheral to be controlled by a mobile app wasn’t something we were expecting to see today, but if controlling something with something else isn’t the definition of a classic hack, we don’t know what is. The folks at [Croxel Inc.] worked out a way to control R.O.B. using a phone app to demo out their expertise in building hardware and software prototypes, a service they offer at their website.

R.O.B. was a little robot with movable clamp arms bundled with the 1985 release of the NES, an effort by Nintendo of America to drive sales of the console after the gaming crash of 1983 by making it look less like a video game and more like a toy. The robot receives inputs from light sensors in its head, which would be pointed towards the TV playing one of the only two games released with support for it. [Croxel] used this to their advantage, and in order to control the robot without needing a whole NES, they fabricated a board using a BGM111 Bluetooth Low-Energy module which can receive outside inputs and translate them to the light commands the robot recognizes.

To avoid having to modify the rare toy itself and having to filter out any external light, the hack consists of a 3D printed “goggles” enclosure that fits over R.O.B.’s eyes, covering them entirely. The board is fitted inside it to shine the control light into its eyes, while also flashing “eye” indicators on the outside to give it an additional charming 80s look. The inputs, which are promptly obeyed, are then given by a phone paired to the module using a custom app skinned to look like a classic NES controller.

We’ve seen more intrusive hacks to this little robot here on Hackaday, such as this one which replaces the old sluggish motors entirely with modern servos and even plans to reconstruct it from scratch given the scarcity of the originals. It’s interesting to see the ways in which people are still hacking hardware from 35 years ago, and we’re excited to see what they’ll come up with around the 40 or 50 year marks!

[via Gizmodo, thanks Itay for the tip!]

New Bluetooth 5 Channel Hopping Reverse Engineered For Jamming And Hijacking

August 10, 2019 by Mike Szczys 9 Comments

Bluetooth Low Energy (BLE) 5 has been around since 2016 with the most recent version 5.2 published just this year. There’s not much hardware out there that’s using the new hotness. That didn’t stop [Damien Cauquil] from picking apart BLE 5’s new frequency hopping techniques and updating his BtleJack tool to allow sniffing, jamming and hijacking hardware using the new protocol.

As you can imagine, the BLE standard a complicated beast and just one part of it is the topic here: the PRNG-based frequency hopping scheme that is vastly different from BLE 4.x and earlier. The new standard, called Channel Selection Algorithm (CSA) #2 — uses 65535 possible channels, compared to just 37 channels used by its predecessor. Paired devices agree to follow a randomized list of all possible channels in sequence so that they remain in synchronization between hops. This was put in place to help avoid collisions, making it possible for many more BLE devices to operate in close proximity. This is important to note since it quickly becomes obvious that it’s not a robust security measure by any means.

To begin channel hopping the two devices must first agree on an order in which to hop, ensuring they’ll meet one another after each leap. To do so they both run the same 32-bit seed number through a PRNG algorithm, generating a list that will then be followed exactly in order. But it turns out this is not very difficult to figure out. All that’s needed is the access address whose top 16-bits are publicly available if you’re already sniffing packets, and the bottom 16-bits is the counter that increments the hop address list.

If you want to jam or hijack BLE 5 communication you need to establish which “randomized” channel list is being used, and the value of the counter that serves as an index to this list. To do so, [Damien] sniffs packets on two different channels. These channels will be used over and over again as it loops through the channel list, so calculating how much time occurs between each channel indicates how far apart these channels are on the list.

In practice, [Damien] first implemented a sieve (the same concept as the Sieve of Eratosthenes for finding primes) that starts with a list of all possibilities and removes those that don’t contain a matching timing between the two channels. Keep doing this, and eventually, you’ll whittle your list down to one possible channel order.

This certainly worked, but there were timing issues that sometimes meant you could learn the seed but couldn’t then sync with it after the fact. His second approach uses pattern matching. By measuring hops on 11 consecutive channels, he’s able to synchronize with target devices in a minute or less. From there, jamming or hijacking methods come into play. The randomization of this scheme is really marginal. A more robust technique would have used an internal state in both devices to generate the next hopping channel. This would have been much more difficult for an attacker to figure out. From the device perspective, CSA #2 takes very little computation power which is key for power-sipping IoT devices most often using BLE.

As mentioned before, [Damien] had trouble finding any hardware in the wild using the BLE 5 standard. His proof of concept is built on a pair of nRF52840 development boards. Because it needs more testing, the code hasn’t been merged into the main version of BtleJack, but you can still get it right now by heading over to BtleJack repo on GitHub.

Open Hardware E-Ink Display Just Needs An Idea

May 12, 2019 by Tom Nardi 25 Comments

Its taken awhile, but thanks to devices like the Amazon Kindle, the cost of e-ink displays are finally at the point where mere mortals such as us can actually start using them in our projects. Now we’ve just got to figure out how to utilize them properly. Sure you can just hook up an e-ink display to a Raspberry Pi to get started, but to truly realize the potential of the technology, you need hardware designed with it in mind.

To that end, [Mahesh Venkitachalam] has created Papyr, an open hardware wireless display built with the energy efficiency of e-ink in mind. This means not only offering support for low-energy communication protocols like BLE and Zigbee, but keeping the firmware as concise as possible. According to the documentation, the end result is that Papyr only draws 22 uA in its idle state.

So what do you do with this energy-sipping Bluetooth e-ink gadget? Well, that part is up to you. The obvious application is signage, but unless you’re operating a particularly well organized hackerspace, you probably don’t need wireless dynamic labels on your part bins (though please let us know if you actually do). More likely, you’d use Papyr as a general purpose display, showing sensor data or the status of your 3D printer.

The 1.54 inch 200×200 resolution e-ink panel is capable of showing red in addition to the standard grayscale, and the whole thing is powered by a Nordic nRF52840 SoC. Everything’s provided for you to build your own, but if you’d rather jump right in and get experimenting, you can buy the assembled version for $39 USD on Tindie.

Scratch Built Smartwatch Looks Pretty Darn Sharp With 3D Printed Case And Round LCD

May 1, 2019 by Lewin Day 30 Comments

These days, if you want a smart watch, you’re spoiled for choice. The major smartphone players all have devices on the market, and there’s plenty of third party manufacturers vying for your dollar, too. You might think it’s impossible achieve the same finish with a 3D printer and a reflow oven, but you’re wrong. [Samson March] didn’t quite fancy something off the shelf, though, and instead build an amazing smartwatch of his own.

The beautiful case is printed in a woodfilled PLA — consisting of 70% plastic and 30% sawdust. This allows it to be sanded and stained for an attractive final product. Printing artifacts actually add to the look here, creating somewhat of a woodgrain effect. There’s a round LCD for a more classical watch look, which displays various graphics and even contact photos for incoming messages. Like most smartwatches on the market, it uses Bluetooth Low Energy for communication, and has a rechargeable lithium battery inside. Estimated battery life is approximately one week, depending on the frequency of use, and the recharging base he fabricated is as beautiful as the watch itself.

It’s a tidy build that shows off [Samson]’s design skills, and files are available on GitHub if you’d like to make your own. Laying out the full design in Fusion 360 prior to the build enabled the watch to be optimized for size constraints, creating an attractive and comfortable piece. With that said, if you’re a fan of a more hardcore electronic aesthetic, perhaps something 8-bit might be more your speed.

[via reddit, thanks to Aliasmk for the tip!]