Heartbeat packets of LKV373

Audio, Not Video Over The LKV373 HDMI Extender

[eta] found herself in a flat with several LKV373 HDMI extenders. Find the corresponding transmitter, plug it into your device, and you’ve got a connection to the TV/sound system, no fussing with wires behind the TV. However, [eta] wanted to get rid of the need to plug in a laptop and start sending packets directly to play music. As her flatmate [dan] had already reverse-engineered the receiver, she tested her prototype against their virtualized receiver, de-ip-hmdi.

The actual sending of images was surprisingly straightforward — just a JPEG sliced into 1024 bytes chunks and sent over. However, early testing showed nothing on the receiver. The end of a frame needed marking by setting the most-significant bit of the chunk number to one. Now de-ip-hdmi showed the image, but the actual hardware would not. With something missing, [eta] returned to Wireshark to scan packets. Noticing some strange packets on port 2067, she analyzed the pattern to reveal it sent another packet just before a new frame and included the frame number. With this tweak, it was still not enough. Ultimately, heartbeat packets sent every second synchronize things, but compared to the noise of the video packets, they were easy to miss. Now [eta] had some functioning video streaming rust code.

In theory, audio for the LKV373 followed the same thought process as video. Two channels of 32-bit big Endian integers at 44,100 hz chunked into 992-byte sections and sent as a packet formed the audio stream. With only 992 bytes, two streams, and 4 bytes per sample, each packet only held 2.812 milliseconds of sound. The first tests resulted in no audio output or distorted crunchy sound. Of course, this was every audio engineer’s worst nightmare: jitter. With a spin loop and an efficient ring buffer, the audio packets were soon slinging across the network reliably.

The code is available on a hosted version of GitLab. It’s a beautiful journey through reverse engineering some obscure but relatively cheap hardware. Along the way, there is nicely annotated Rust code, which makes it all the better.

Closing In On A PC Enabled PSVR2

When the PlayStation VR2 headset was released, people wondered whether it would be possible to get the headset to work as a PC VR headset. That would mean being able to plug it into a PC and have it work as a VR headset, instead of it only working on a PS5 as Sony intended.

Enthusiasts were initially skeptical and at times despondent about the prospects, but developer [iVRy]’s efforts recently had a breakthrough. A PC-compatible VR2 is looking more likely to happen.

So far [iVRy] is claiming they have 6 DOF SLAM (Simultaneous Localisation and Mapping), Prox sensor, and stereo camera data.

Most of the juicy bits are paywalled behind [iVRy]’s Patreon.  We’re hoping the jailbreak process will eventually be open-sourced.

The PS VR2 headset is quite unlike a PC VR headset in a number of ways, and it has not been historically easy to work with Sony’s products from a reverse-engineering perspective, whether it’s an attempt to improve the user experience of an annoying headset, or an attempt to understand the not-even-remotely-sanely-designed protocols behind the Sony Memory Stick. Getting the PS VR2 headset to work in a way it wasn’t intended was expected to be an uphill battle.

It’s not a finished job, but judging by the progress regularly shared on [iVRy]’s Twitter account, it might only be a matter of time.

Root, On An Amazon Echo Dot

The Amazon Echo has become an indispensable device for many people unconcerned by its privacy implications. It’s easy to forget that it’s not quite a new product anymore, with the oldest examples now long in the tooth enough to no longer receive security updates. A surprise is that far from being mere clients to Amazon cloud services, they in fact run a version of Android. This makes old dots interesting to experimenters, but first is it possible to gain root access? [Daniel B] has managed it, on a second-generation Echo Dot.

In a sense, this is nothing new, as root has previously been achieved on an Echo Dot through means of a patched kernel. Echo devices use a chain of trust boot process in which each successive step must verify the Amazon signing of the previous one. The kernel patch method breaks the ability to reboot the device with root access. [Daniel’s] method bypasses that chain of trust by using a custom pre-loader injected over USB through an exploit.

As an example, [Daniel] created a web server on his Dot, which can serve audio captured by the device. Don’t panic just yet — an analysis of the other security features suggests that this is not the dangerous exploit it might seem. It does however open up these powerful but now pretty cheap devices as potentially usable for other purposes, which can only be a good thing.

We’ve previously brought you [Daniel]’s work freeing the WiFi details from a Dot.

Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

It sometimes seems like there are two kinds of cheap hardware devices: those dependent on proprietary software that is no longer available and those that are equally dependent but haven’t been abandoned just quite yet. But rest assured, abandonment is always on the table, and until then, you get to deal with poorly written apps that often suffer from a crippling lack of essential functionality.

Such was the case for the wireless game camera that [Chris Jones] scored on the cheap, but rather than suffering with the original software, he decided to reverse engineer the camera and turn it into something more useful. The eBay description was promising — Bluetooth LE! WiFi! — but the reality proved less so. To save the batteries, WiFi is off by default and can only be turned on by connecting to the camera via BLE using a janky and crash-prone Android app.

[Chris]’ first step in reverse engineering the camera was to snoop into the BLE by capturing the Bluetooth packets to a file and running them through Wireshark. This revealed a write command with the text “BT_KEY_ON” — very promising. After verifying that this command turned on the camera’s access point, [Chris] got to work capturing WiFi packets using PCAPDroid and analyzing the results, again with Wireshark. Using every function available in the OEM app eventually revealed the full API on the camera, which gives file system control, access to individual images, and even putting the camera into live video mode.

Continue reading “Reverse Engineering Reveals Hidden API In Abandonware Trail Camera”

Sniffing Passwords, Rickrolling Toothbrushes

If you could dump the flash from your smart toothbrush and reverse engineer it, enabling you to play whatever you wanted on the vibrating motor, what would you do? Of course there’s no question: you’d never give up, or let down. Or at least that’s what [Aaron Christophel] did. (Videos, embedded below.)

But that’s just the victory lap. The race began with previous work by [Cyrill Künzi], who figured out that the NFC chip inside was used for a run-time counter, and managed to reset it by sniffing the password with an SDR as it was being transmitted. A great hack to be sure, but it only works for people with their own SDR setup.

With the goal of popularizing toothbrush-head-NFC-hacking, [Aaron] busted open the toothbrush itself, found the debug pins, dumped the flash, and got to reverse engineering. A pass through Ghidra got him to where the toothbrush reads the NFC tag ID from the toothbrush head. But how does it get from the ID to the password? It turns out that it runs a CRC on a device UID from the NFC tag itself and also a manufacturer’s string found in the NFC memory, and scramble-combines the two CRC values.

Sounds complicated, but the NFC UID can be read with a cellphone app, and the manufacturer’s string is also printed right on the toothbrush head itself for your convenience. Armed with these two numbers, you can calculate the password, and convince your toothbrush head that it’s brand new, all from the comfort of your smartphone! Isn’t technology grand?

We’re left guessing a little bit about the Rickroll hack, but we’d guess that once [Aaron] had the debug pins on the toothbrush’s microcontroller, he just couldn’t resist writing and flashing in a custom firmware. Talk about dedication.

[Aaron] has been doing extensive work on e-paper displays, but his recent work on the Sumup payment terminal is a sweet look at hacking into higher security devices with acupuncture needles.

Continue reading “Sniffing Passwords, Rickrolling Toothbrushes”

Tesla Door Phone Decoded (Not That Tesla)

[Danman] has digital door phones manufactured by Tesla — or at least, a Tesla, as they’re not to be confused with the carmaker, though. The problem is if someone comes to the door when no one’s home, there’s no remote indicator. The answer? Reverse engineer the protocol and fix it.

A quick dump on a storage scope showed the data clearly, but it wasn’t obvious what protocol it was using. After a little analysis, it proved the datastream used 4 PWM pulses as symbols with three symbols: one, zero, and stuffing sequence.

Once you can read the bits, it is easy to determine that each frame consists of a 16-bit destination and source address, along with a command byte and a checksum byte. Each station can have an ID from 000 to 999 although you can only dial up to number 323. Some nodes are special, and there are ways to address particular units.

Connecting to the hardware took a transformer for isolation. Honestly, unless you have this exact hardware, this isn’t likely to be something you can directly use. However, it is a great example of how you can figure out a specialized device and bend it to your will.

We love reverse engineering projects. In some cases, it is easier if you have a CT scan.

How Does Your McDonald’s Burger Get To You?

Table service and McDonalds sound as though they should be mutually exclusive as a fundamental of the giant chain’s fast food business model, but in many restaurants there’s the option of keying in the number from a plastic beacon when you order, placing the beacon on the table, and waiting for a staff member to bring your food. How does the system work? [Whiterose Infosec] scored one of the beacons, and subjected it to a teardown and some probing.

The beacon in question has the look of being an older model judging by the 2009 date codes on its radio module and the evident corrosion on its battery terminals. Its Bluetooth 4 SoC is end-of-life, so it’s possible that this represents a previous version of the system. It has a few other hardware features, including a magnet and a sensor designed to power the board down when it is stacked upon another beacon.

Probing its various interfaces revealed nothing, as did connecting to the device via Bluetooth. However some further research as well as asking some McD’s employees revealed some of its secret. It does little more than advertise its MAC address, and an array of Bluetooth base stations in the restaurant use that to triangulate its approximate position.

If you’ve ever pondered how these beacons work while munching on your McFood, you might also like to read about McVulnerabilities elsewhere in the system.