Screwdriving! It’s like wardriving but instead of discovering WiFi networks, the aim is to discover Bluetooth Low Energy (BLE) devices of a special kind: adult toys. Yes, everything’s going to be connected, even vibrators. Welcome to the 21st century.
Security researcher [Alex Lomas] recently found that a lot of BLE-enabled adult toys are completely vulnerable to malicious attacks. In fact, they are basically wide open to anyone by design.
“Adult toys lend themselves to being great testbeds for IoT research: they’re BLE, they’re relatively cheap, they’re accessible and have companion apps for the full spectrum of testing.”
Yes… great test beds… Erm, anyway, [Alex Lomas] found that there is no PIN nor password protection, or the PIN is static and generic (0000 / 1234) on every Bluetooth adult toy analysed. Manufacturers don’t want to go through the hassle, presumably because sex toys lack displays that would enable a classic Bluetooth pairing, with random PIN and so on. While this might be a valid point, almost all electronic appliances have an “ON/OFF” button for input and some LED (or even vibration in these cases) that allow some form of output. It could be done, and it’s not like vibrators are the only minimalistic appliances out there in the IoT world.
Although BLE security is crippled by design (PDF), it is possible to add security on top of flawed protocols. The average web-browser does it all the time. The communications don’t have to be clear-text where you can literally see “Vibrate:10” flying around in packets. Encryption could be implemented on top of the BLE link between the app and the device, for instance. Understandably, security in some devices is not absolutely critical. That being said, the security bar doesn’t have to be lowered to zero — it’s not safe for work or play.
Humans don’t survive long without water, and most people walk around in a chronic state of mild dehydration even if they have access to plenty of drinking water. It’s hard to stay properly hydrated, and harder still to keep track of your intake, which is the idea behind this water-intake monitoring IoT drinking straw.
Dehydration is a particularly acute problem in the elderly, since the sense of thirst tends to diminish with age. [jflaschberger]’s Hackaday Prize entry seeks to automate the tedious and error-prone job of recording fluid intake, something that caregivers generally have to take care of by eyeballing that half-empty glass and guessing. The HydrObserve uses a tiny turbine flowmeter that can mount to a drinking straw or water bottle cap. A Hall sensor in the turbine sends flow data to a Cypress BLE SoC module, which totalizes the volume sipped and records a patient identifier. A caregiver can then scan the data from the HydrObserve at the end of the day for charting and to find out if anyone is behind on their fluids.
There are problems to solve, not least being the turbine, which doesn’t appear to be food safe. But that’s a small matter that shouldn’t stand in the way of an idea as good as this one. We’ve seen a lot of good entries in the Assistive Technology phase of the 2017 Hackaday Prize, like a walker that works on stairs or sonic glasses for the blind. There are only a couple of days left in this phase — got any bright ideas?
So, you buy an Internet of Things light bulb, it’s a fun toy that allows you to bathe your environment in pretty colours at the touch of an app, but eventually you want more. You start to wonder how you might do more with it, and begin to investigate its inner workings. Then to your horror you discover that far from having bought a device with a convenient API for you to use, it has an impenetrable closed protocol that defies easy access.
This was the problem facing [Ayan Pahwa] when he bought a Syska Smartlight Rainbow LED bulb, and discovered that its Bluetooth Low Energy interface used a closed protocol. But instead of giving up, he proceeded to reverse engineer the communication between bulb and app, and his write-up makes for an interesting read that provides a basic primer on some of BLE’s workings for the uninitiated.
BLE allows a device manufacturer to define their own device service specific to their functionality alongside standard ones for common device types. Using a handy Android app from Nordic Semiconductor he was able to identify the services defined for the light bulb, but sadly they lacked any human-readable information to help him as to their purpose. He thus had to sniff BLE packets directly, and lacking dedicated hardware for this task he relied on a developer feature built into Android versions since KitKat, allowing packets to be captured and logged. By analysing the resulting packet files he was able to identify the Texas Instruments chip inside the bulb, and to deduce the sequences required to control its colours. Then he was able to use the Bluez utilities to talk directly to it, and as if by magic, his colours appeared! Take a look at the video we’ve placed below the break.
Many of us may never need to reverse engineer a BLE device. But if we are BLE novices, after reading [Ayan]’s piece we will at least have some idea of its inner workings. And that can only be a positive thing.
Continue reading “Reverse Engineering A BLE Service To Control A Light Bulb”
Mass production means that there’s a lot of great hardware out there for dirt cheap. But it also means that the manufacturer isn’t going to spend years working on the firmware to squeeze every last feature out of it. Nope, that’s up to us.
[deqing] took a Bluetooth Low Energy / USB dongle and re-vamped the firmware to turn it into a remote keyboard and mouse, and then wrote a phone app to control it. The result? Plug the USB dongle in, and the computer thinks it sees a keyboard and mouse. Connect the phone via BLE, and you’re typing — even if you don’t have your trusty Model F by your side.
[Deqing] points out that ergonomics and latency will make you hate using this in the long term, but it’s just meant to work until you’ve got SSH up and running on that headless single-board Linux thing. If you’ve ever worked with the USB or BLE specifications, you can appreciate that there’s a bit of work behind the scenes in making everything plug and play, and the web-based interface is admirably slick.
[Stefan]’s Mini WiFi/BLE 4WD robot platform (seen next to a matchbox above) packs an impressive capability into a tiny rover. It’s based on a SparkFun ESP32 Thing, a very compact way to add wireless control to your project. Compare it to some giant old UNO with a WiFi shield, these boards are small but powerful, as well as an easy adoption for Arduino fans.
[Stefan] beefed up the robot with a BNO055 module to determine orientation, an APDS-9930 proximity sensor, as well as four CNY70 IR proximity sensors on the bottom, used for line-following. A pair of 6 V motors move the robot, with a DC-DC step up converter boosting the LiPo’s 3.7 V. It’s impressive how many components [Stefan] crammed inside the shell; they’re all packed in there snugly.
The concept behind the robot is that it’s a generic platform that could be customized as needed, and [Stefan] has versions with a LEGO dart gun as well as a camera. The robot’s code resides on GitHub and the custom 3D-printed chassis is up on Thingiverse.
If you like ESP32 projects you should be sure to check out the Monster Board and the Hamster Tracker we posted recently.
For most of us, a memory lapse is as harmless as forgetting to bring the garbage to the curb, or maybe as expensive as leaving a cell phone and cup of coffee on the roof of the car before driving off. But when the toddler sleeping peacefully in the car seat slips your mind in the parking lot, the results can be deadly.
We have no doubt that child detection systems will soon be standard equipment on cars, like backup cameras and trunk-escape levers are now. Not willing to wait, [ayavilevich] came up with his own car occupancy sensor for child seats (Update: We originally linked to the Instructable but [ayavilevich] wrote in and mentioned this is actual Hackaday Prize entry and he’s looking for more people to get involved in the project).
Dubbed Fochica, for “Forgotten Child in Car Alert,” the system is clearly a proof of concept right now, but it has potential. The Arduino Uno senses Junior’s presence in the car seat with a homebrew capacitive sensor under the padding of the seat and a magnetic reed switch in the chest harness buckle. An Android app on a smartphone pairs with a BLE module to get the sensors’ status, and when the phone goes out of Bluetooth range while the seat is occupied, the app sounds an alarm. Simple, but effective.
We like how well [ayavilevich] thought this through. Systems like this are best left uncomplicated, so any improvements he makes should probably concentrate on engineering a reliable, fieldable device. Another hack we’ve presented in the kid-safety space is fast stairwell lights for a visually impaired girl, which might provide some ideas.
Continue reading “Smart Child Seat Aims to Prevent Tragedy”
Hardware hackers are always looking for devices to tear apart and scavenge from. It’s hardly a secret that purchasing components individually is significantly more expensive than the minuscule cost per unit that goes along with mass manufacturing. Bluetooth devices are no exception. Sure, they’re not exactly a luxury purchase anymore, but they’re still not dirt cheap either.
Luckily for [Troy Denton], it seems dollar stores have started carrying a Bluetooth camera shutter for just a few dollars (it was three bucks, perhaps the dollar store actually means divisible-by). The device is designed to pair with a smart phone, and has two buttons allowing you to control the camera from afar. The fact that it works at all at that price is a small miracle, but the device also has potential for hacking that adds to its appeal. Continue reading “Hacking a Dollar Store Bluetooth Device”