Security Vulnerabilities In Modern Cars Somehow Not Surprising

As the saying goes, there’s no lock that can’t be picked, much like there’s no networked computer that can’t be accessed. It’s usually a continual arms race between attackers and defenders — but for some modern passenger vehicles, which are essentially highly mobile computers now, the defenders seem to be asleep at the wheel. The computing systems that control these cars can be relatively easy to break into thanks to manufacturers’ insistence on using wireless technology to unlock or activate them.

This particular vulnerability involves the use of a piece of software called gattacker which exploits vulnerabilities in Bluetooth Low Energy (BLE), a common protocol not only for IoT devices but also to interface a driver’s smartphone or other wireless key with the vehicle’s security system. By using a man-in-the-middle attack the protocol between the phone and the car can be duplicated and the doors unlocked. Not only that, but this can be done without being physically close to the car as long as a network of some sort is available.

[Kevin2600] successfully performed these attacks on a Tesla Model 3 and a few other vehicles using the seven-year-old gattacker software and methods first discovered by security researcher [Martin Herfurt]. Some other vehicles seem to have patched these vulnerabilities as well, and [Kevin2600] didn’t have universal success with every vehicle, but it does remind us of some other vehicle-based attacks we’ve seen before.

Stadia Says Goodbye With Bluetooth And Crap Game

In just a few days time, Google’s Stadia game streaming service will finally shut down for good. But not for any technical reason, mind you. Microsoft has managed to demonstrate that streaming modern games over home and even mobile Internet connections is viable with their immensely popular Game Pass Ultimate service, and NVIDIA is making similar inroads with GeForce Now. No, like so many of Google’s failed experiments, they’ve simply decided they don’t want to play anymore and are taking their proverbial ball home back with them.

But not all is lost for those who shelled out money for Stadia’s wares. Not only will Google be refunding any money players spent on games, but a company representative has also announced they will be releasing a tool to unlock the latent Bluetooth capabilities of the service’s custom controller — hopefully stemming a surge of e-waste before it starts.

Thanks for playing, chumps.

In a forum thread titled “A Gift from the Stadia Team”, Community Manager [DanFromGoogle] explains that information on how you can enable Bluetooth on the controller will be coming next week. In the meantime, he also announced the immediate release of “Worm Game”, a tech demo that staffers apparently used to test out capabilities of the streaming service before its public release.

That this ridiculously simple game, which looks all the world like something a kid would crank out during an after-school programming class, will be the final title to officially release on Stadia is a stunningly insulting epitaph for the fledgling service. But then, Google seems to have developed a special affinity for mistreating their most loyal cattle users over these last few years.

Enabling Bluetooth on a game controller might not seem like such a big deal, but in this case, it will potentially give the piece of hardware a second chance at life. The Stadia controller is unique in that it uses WiFi to communicate directly over the Internet to Google’s streaming service, so once those servers stop responding, the orphaned device will end up being little more than a curiosity. Although it does technically work over USB, being able to use it wirelessly will not only provide a more modern experience, but help justify its internal batteries.

The last time we mentioned the Stadia controller, it was to document one user’s attempt to rid it of an internal microphone they didn’t feel comfortable with. Now that the service is being put to pasture, we wonder if we’ll start to see more hacks involving the admittedly interesting peripheral. We’ll certainly be keeping an eye out for them, but if you see anything we miss, you know where to send it.

Web Tool Cranks Up The Power On DJI’s FPV Drone

Apparently, if the GPS on your shiny new DJI FPV Drone detects that it’s not in the United States, it will turn down its transmitter power so as not to run afoul of the more restrictive radio limits elsewhere around the globe. So while all the countries that have put boots on the Moon get to enjoy the full 1,412 mW of power the hardware is capable of, the drone’s software limits everyone else to a paltry 25 mW. As you can imagine, that leads to a considerable performance penalty in terms of range.

But not anymore. A web-based tool called B3YOND promises to reinstate the full power of your DJI FPV Drone no matter where you live by tricking it into believing it’s in the USA. Developed by the team at [D3VL], the unlocking tool uses the new Web Serial API to send the appropriate “FCC Mode” command to the drone’s FPV goggles over USB. Everything is automated, so this hack is available to anyone who’s running a recent version of Chrome or Edge and can click a button a few times.

There’s no source code available yet, though the page does mention they will be putting up a GitHub repository soon. In the meantime, [D3VL] have documented the command packet that needs to be sent to the drone over its MODBUS-like serial protocol for others who might want to roll their own solution. There’s currently an offline Windows-only tool up for download as well, and it sounds like stand-alone versions for Mac and Android are also in the works.

It should probably go without saying that if you need to use this tool, you’ll potentially be violating some laws. In many European countries, 25 mW is the maximum unlicensed transmitter power allowed for UAVs, so that’s certainly something to keep in mind before you flip the switch. Hackaday isn’t in the business of dispensing legal advice, but that said, we wouldn’t want to be caught transmitting at nearly 60 times the legal limit.

Even if you’re not interested in fiddling with drone radios, it’s interesting to see another practical application of the Web Serial API. From impromptu oscilloscopes to communicating with development boards and conference badges, clever developers are already finding ways to make hardware hacking easier with this new capability.

[Thanks to Jules for the tip.]

The Mystery Of A Particular ATtiny85 Fuse

First-timers playing with 8-bit micros such as the AVR and PIC will at some point in their lives, find themselves locked out of their MCUs. This is usually attributed to badly configured fuses that disable certain IO functions rending the device unprogrammable via conventional ICSP methods. [Uri Shaked] shares his story of how his ATtiny85 got locked and became the subject of a lengthy investigation into fuse bit configurations.

[Uri]’s journey started when he accidentally left some pins of the device connected to a second board while he was flashing the firmware. He quickly researched online for a solution for the problem and it turns out, there are a number of recipes to resolve the issue. As it turns out, his problem was not so straight-forward and warranted more digging. [Uri] ended setting up a High Voltage Programming serial programming setup and then probing the communications. He discovered that the chip refused to reset its fuses and would reject attempts to set fuses.

Further investigation of the fuse bits and reading them proved useful in understanding that the memory protection features were preventing alteration of the device. The quick-fix was to erase the ATtiny and things were back to normal thereafter. [Uri] details his pursuit of reading and comparing fuse bits from the impacted chip against a fresh device which is where he makes the discovery. The write-up is a case study in the investigation into the idiosyncrasies of device programming and will be a great resource for many and reduce hair loss for some.

Once you get your hands on an ATTINY, there are a number of small experiments to be done to cure boredom. Be sure to share your experiments and stories with us to inspire the masses.

Unlocking SIM Cards With A Logic Analyzer

[Jason Gin] wanted to reuse the SIM card that came with a ZTE WF721 wireless terminal he got from AT&T, but as he expected, it was locked to the device. Unfortunately, the terminal has no function to change the PIN and none of the defaults he tried seemed to work. The only thing left to do was crack it open and sniff the PIN with a logic analyzer.

This project is a fantastic example of the kind of reverse engineering you can pull off with even a cheap logic analyzer and a keen eye, but also perfectly illustrates the fact that having physical access to a device largely negates any security measures the manufacturer tries to implement. [Jason] already knew what the SIM unlock command would look like; he just needed to capture the exchange between the WF721 and SIM card, find the correct byte sequence, and look at the bytes directly after it.

Finding the test pads on the rear of the SIM slot, he wired his DSLogic Plus logic analyzer up to the VCC, CLK, RST, and I/O pins, then found a convenient place to attach his ground wire. After a bit of fiddling, he determined the SIM card was being run at 4 MHz, so he needed to configure a baud rate of 250 kbit/s to read the UART messages passing between the devices.

Once he found the bytes that signified successful unlocking, he was able to work his way backwards and determine the unlock command and its PIN code. It turns out the PIN was even being sent over the wire in plain text, though with the way security is often handled these days, we can’t say it surprises us. All [Jason] had to do then was put the SIM in his phone and punch in the sniffed PIN when prompted.

Could [Jason] have just run out to the store and picked up a prepaid SIM instead of cracking open this wireless terminal and sniffing its communications with a logic analyzer? Of course. But where’s the fun in that?

Ask Hackaday: Are Unlockable Features Good For The User?

There are numerous examples of hardware which has latent features waiting to be unlocked by software. Most recently, we saw a Casio calculator which has the same features as its bigger sibling hidden within the firmware, only to be exposed by a buffer overflow bug (or the lead from a pencil if you prefer a hardware hack).

More famously, oscilloscopes have been notorious for having crippled features. The Rigol DS1052E was hugely popular on hacker benches because of it’s very approachable price tag. The model shipped with 50 MHz bandwidth but it was discovered that a simple hack turned it into the DS1102E 100 MHz scope. Tektronix has gotten in on this action as well, shipping modules like I2C, CAN, and LIN analyzation on the scope but requiring a hardware key to unlock (these were discovered to have a horribly insecure unlock method). Similar feature barriers are found on Rigol’s new reigning entry-level scope, the DS1054Z, which ships with protocol analyzation modules (among others) that are enabled only for the first 70 hours of scope operation, requiring an additional payment to unlock them. Most scope manufacturers are in on the game, and of course this is not limited to our tools. WiFi routers are another great example of hardware hosting firmware-unlockable features.

So, the question on my mind which I’d like to ask all of the Hackaday community is this: are unlockable features good for us, the people who use these tools? Let’s take a look at some of the background of these practices and then jump into a discussion in the comments.

Continue reading “Ask Hackaday: Are Unlockable Features Good For The User?”