French hacker [akila] is building up a home automation system. In particular, he’s been working with the “SmartHome” series of gadgets made by Chinese smartphone giant, Xiaomi. First, he started off by reverse-engineering their very nicely made temperature and humidity sensor. (Original in French, hit the translate button in the lower right.) With that under his belt, he opened up the PIR motion sensor unit to discover that it has the same debugging pinouts and the same processor. Almost too easy.
For a challenge, [akila] decided it was time to implement something useful in one of these gadgets: a ZigBee sniffer so that he can tell what’s going on in the rest of his home network. He built a USB/serial programming cable to work with the NXP JN5169’s bootloader, downloaded the SDK, and rolled up his sleeves to get to work.
While trolling through the SDK, he found some interesting firmware called “JennicSniffer”. Well, that was easy. There’s a demo version of a protocol analyzer that he used. It would be cool to get this working with Wireshark, but that’s a project for another day. [Akila] got far enough with the demo analyzer to discover that the packets sent by the various devices in the home network are encrypted. That’s good news for the security-conscious out there and stands as the next open item on [akila]’s to-do list.
We don’t see as many ZigBee hacks as we’d expect, but they’ve definitely got a solid niche in home automation because of commercial offerings like Philips Hue and Wink. And of course, there’s the XBee line of wireless communications modules. We just wrote up a ZigBee hack that aims to work with the Hue system, though, so maybe times are changing?
As if you needed any reason other than “just for the heck of it” to hack into a gadget that you own, it looks like nearly all of the GSM-to-IP bridge devices make by DBLTek have a remotely accessible “secret” backdoor account built in. We got sent the link via Slashdot which in turn linked to this story on Techradar. Both include the scare-words “Chinese” and “IoT”, although the devices seem to be aimed at small businesses, but everything’s “IoT” these days, right?
What is scary, however, is that the backdoor isn’t just a sloppy debug account left in, but rather only accessible through an elaborate and custom login protocol. Worse still, when the company was contacted about the backdoor account, they “fixed” the problem not by removing the account, but by making the “secret” login procedure a few steps more complicated. Which is to say, they haven’t fixed the problem at all.
This issue was picked up by security firm Trustwave, but they can’t check out every device on the market all the time. We may be preaching to the choir here, but if you’re ever wondering why it’s important to be able to break into stuff that you own, here’s another reminder.
Wow. [Dmitry Grinberg] just broke into the SROM on Cypress’ PSoC 4 chips. The supervisory read-only memory (SROM) in question is a region of proprietary code that runs when the chip starts up, and in privileged mode. It’s exactly the kind of black box that’s a little bit creepy and a horribly useful target for hackers if the black box can be broken open. What’s inside? In the manual it says “The user has no access to read or modify the SROM code.” Nobody outside of Cypress knows. Until now.
This matters because the PSoC 4000 chips are among the cheapest ARM Cortex-M0 parts out there. Consequently they’re inside countless consumer devices. Among [Dmitry]’s other tricks, he’s figured out how to write into the SROM, which opens the door for creating an undetectable rootkit on the chip that runs out of each reset. That’s the scary part.
The cool parts are scattered throughout [Dmitry]’s long and detailed writeup. He also found that the chips that have 8 K of flash actually have 16 K, and access to the rest of the memory is enabled by setting a single bit. This works because flash is written using routines that live in SROM, rather than the usual hardware-level write-to-register-and-wait procedure that we’re accustomed to with other micros. Of course, because it’s all done in software, you can brick the flash too by writing the wrong checksums. [Dmitry] did that twice. Good thing the chips are inexpensive.
The Amazon Dash button is now in its second hardware revision, and in a talk at the 33rd Chaos Communications Congress, [Hunz] not only tears it apart and illuminates the differences with the first version, but he also manages to reverse engineer it enough to get his own code running. This opens up a whole raft of possibilities that go beyond the simple “intercept the IP traffic” style hacks that we’ve seen.
Just getting into the Dash is a bit of work, so buy two: one to cut apart and locate the parts that you have to avoid next time. Once you get in, everything is tiny! There are a lot of 0201 SMD parts. Hidden underneath a plastic blob (acetone!) is an Atmel ATSAMG55, a 120 MHz ARM Cortex-M4 with FPU, and a beefy CPU all around. There is also a 2.4 GHz radio with a built-in IP stack that handles all the WiFi, with built-in TLS support. Other parts include a boost voltage converter, a BTLE chipset, an LED, a microphone, and some SPI flash.
The strangest part of the device is the sleep mode. The voltage regulator is turned on by user button press and held on using a GPIO pin on the CPU. Once the microcontroller lets go of the power supply, all power is off until the button is pressed again. It’s hard to use any less power when sleeping. Even so, the microcontroller monitors the battery voltage and presumably phones home when it gets low. Continue reading “33C3: Hunz Deconstructs the Amazon Dash Button”→
If you want to eavesdrop on GSM phone conversations or data, it pays to have deep pockets, because you’re going to need to listen to a wide frequency range. Or, you can just use two cheap RTL-SDR units and some clever syncing software. [Piotr Krysik] presented his work on budget GSM hacking at Camp++ in August 2016, and the video of the presentation just came online now (embedded below). The punchline is a method of listening to both the uplink and downlink channels for a pittance.
[Piotr] knows his GSM phone tech, studying it by day and hacking on a GnuRadio GSM decoder by night. His presentation bears this out, and is a great overview of GSM hacking from 2007 to the present. The impetus for Multi-RTL comes out of this work as well. Although it was possible to hack into a cheap phone or use a single RTL-SDR to receive GSM signals, eavesdropping on both the uplink and downlink channels was still out of reach, because it required more bandwidth than the cheap RTL-SDR had. More like the bandwidth of two cheap RTL-SDR modules.
Getting two RTL-SDR modules to operate in phase is as easy as desoldering a crystal from one and slaving it to the other. Aligning the two absolutely in time required a very sweet hack. It turns out that the absolute timing is retained after a frequency switch, so both RTL-SDRs switch to the same channel, lock together on a single signal, and then switch back off, one to the uplink frequency and the other to the downlink. Multi-RTL is a GnuRadio source that takes care of this for you. Bam! Hundreds or thousands of dollar’s worth of gear replaced by commodity hardware you can buy anywhere for less than a fancy dinner. That’s a great hack, and a great presentation. Continue reading “GSM Sniffing on a Budget with Multi-RTL”→
To a casual observer it might seem as though our community is in the news rather a lot at the moment. It’s all about hacks on our TV screens in the soap opera of Washington politics, who hacked this, whether those people over there helped that lot hack the other lot, or even whether that person’s emails could have been hacked on that server. Keeping up with it as an outsider can become a full-time job.
Of course, as we all know even if the mainstream journalists (or should I refer to them colloquially as “hacks”?) don’t, it’s not us they’re talking about. Their hackers are computer criminals, while we are people with some of the hardware and software skills to bend technology to our will, even beyond what its designers might have intended. And that divergence between the way we use the word in a sense of reappropriation and they use it in disapprobation sometimes puts us in an odd position. Explaining to a sober-suited businessman as the director of a hackspace, that no, we’re not *those*hackers can sometimes feel like skating on thin ice.
Furbys have been around for a while and they are an interesting (if annoying) toy that will teach the kids to be okay with their eventual robotic overlords. In the meantime, the latest version of the robotic companion/toy/annoyance uses Bluetooth LE to communicate with the owner and [Jeija] has been listening in on the Bluetooth communication, trying to reverse engineer the protocol in order to run code on Furby.
[Jeija] has made a lot of progress and can already control the Furby’s actions, antenna and backlight color, and change the Furby’s emotional state by changing the values of the Furby’s hungriness, tiredness, etc. [Jeija] has created a program that runs on top of Node.js and can communicate with the Furby and change its properties. [Jeija] has also discovered, and can bring up, a secret debug menu that displays in the Furby’s eyes. Yet to be discovered is how to run your own code on the Furby, however, [Jeija] is able to add custom audio to the official DLC files and upload them into the Furby.
[Jeija] points out the all this was done without taking a Furby apart, only by sniffing the Bluetooth communication between the robot and the controlling app (Android/iOS device.) Check out a similar hack on the previous generation of Furbys, as well as a replacement brain for them. We just hope that the designers included a red/green LED so that we will all know when the Furbys switch from good to evil.