Audio, Not Video Over The LKV373 HDMI Extender

August 2, 2023 by Matthew Carlson 11 Comments

[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.

Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

July 18, 2023 by Dan Maloney 12 Comments

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” →

What’s That Scope Trace Saying? UPD And Wireshark

August 14, 2022 by Al Williams 9 Comments

[Matt Keeter], like many of us, has a lot of network-connected devices and an oscilloscope. He decided he wanted to look into what was on the network. While most of us might reach for Wireshark, he started at the PCB level. In particular, he had — or, rather, had someone — solder an active differential probe soldered into an Ethernet switch. The scope attached is a Textronix, but it didn’t have the analyzer to read network data. However, he was able to capture 190+ MB of data and wrote a simple parser to analyze the network data pulled from the switch.

The point of probing is between a network switch and the PHY that expands one encoded channel into four physical connections using QSGMII (quad serial gigabit media-independent interface). As the name implies, this jams four SGMII channels onto one pair.

As is common in networking schemes, the 8-bit byte is encoded into a 10-bit code group to ensure enough bit transitions to recover the synchronous clock. The decoding software has to examine the stream to find framing characters and then synchronize to the transmitted clock.

What follows is a nice tour of the protocol and the Python code to decode it. It seems complex, but the code is fairly short and also executes quickly. The output? Pcap files that you can process with Wireshark. Overall, a great piece of analysis. He also points out there are other tools already available to do this kind of decoding, but what fun is that?

Wireshark can do a lot of different kinds of analysis, even if you aren’t usually capturing from a scope. You can even decrypt SSL if you know the right keys.

Wireshark HTTPS Decryption

March 22, 2022 by Al Williams 48 Comments

If you’ve done any network programming or hacking, you’ve probably used Wireshark. If you haven’t, then you certainly should. Wireshark lets you capture and analyze data flowing over a network — think of it as an oscilloscope for network traffic. However, by design, HTTPS traffic doesn’t give up its contents. Sure, you can see the packets, but you can’t read them — that’s one of the purposes of HTTPS is to prevent people snooping on your traffic from reading your data. But what if you are debugging your own code? You know what is supposed to be in the packet, but things aren’t working for some reason. Can you decrypt your own HTTPS traffic? The answer is yes and [rl1987] shows you how.

Don’t worry, though. This doesn’t let you snoop on anyone’s information. You need to share a key between the target browser or application and Wireshark. The method depends on the target applications like a browser writing out information about its keys. Chrome, Firefox, and other software that uses NSS/OpenSSL libraries will recognize an SSLKEYLOGFILE environment variable that will cause them to produce the correct output to a file you specify.

How you set this depends on your operating system, and that’s the bulk of the post is describing how to get the environment variable set on different operating systems. Wireshark understands the file created, so if you point it to the same file you are in business.

Of course, this also lets you creep on data the browser and plugins are sending which could be a good thing if you want to know what Google, Apple, or whoever is sending back to their home base using encrypted traffic.

Wireshark and helpers can do lots of things, even Bluetooth. If you just need to replay network data and not necessarily analyze it, you can do that, too.

Diving The Depths Of Ma Bell

December 27, 2021 by Matthew Carlson 13 Comments

The modern smartphone is a marvel of sensors, radios, inputs, outputs, and processing power. In particular, some of those radios, such as WiFi and cellular, have grown fiendishly complex over the years. Even when that complexity is compressed down for the user into the one-dimensional space of the signal strength bars at the top of your phone. So when [David Burgess] was asked to look at some cellphone records of text messages and figure out where some of the more mysterious messages were coming from, it led him down a rabbit hole into the dark arts behind the glowing phone screen.

The number in question was 1111340002, sent by a phone connected to AT&T at the time, and was crucial for a legal case around distracted driving. [David’s] tools in his investigation were YateBTS (a cellular network simulator), SimTrace2 (pictured above), and old reliable Wireshark. Since the number isn’t a specific phone number and is not reachable from the public phone network, it must be a unique number inside AT&T processed by one particular AT&T SMSC (Short Message service center). The SMSC in question is in Atlanta and isn’t a typical texting center, so it must have some particular purpose. The message’s payload is raw binary rather than text, and [David] has done a pretty good job of decoding the majority of the format.

The most exciting revelation in this journey is that the phone (in the traditional sense) does not send this message. The processor on the phone does not know this message and executes no code to send it. Instead, the SIM card itself sends it. The SIM card is connected directly to the baseband processor on the phone, and the baseband polls the sim every so often, asking for any commands. One of those commands is an SMS (though many other commands have worrying consequences).

The SMS that [David] was chasing is triggered whenever a SIM detects a new IMEI, and the message lets the network know what about the previous and current IMEI. However, in the case of this message, it was unlikely that the SIM changed phones, so what happened? After some additional lab work and the deposition of an AT&T employee, [David] showed that a baseband firmware update would also trigger this SMS.

It’s a fascinating journey into the fragmented world of a smartphone’s minds and [David] does a fantastic job on the writeup. If you’re interested in sniffing wireless accessories, you will enjoy this soundbar’s wireless protocol laid bare.

Hacker Spends A Few Cycles Upgrading An Under-Desk Bike

May 6, 2021 by Kristina Panos 12 Comments

Pandemic got you way behind on your exercise goals? Us too. But not [codaris] who bought an under-desk bike to get in a bit of cycling while banging away on the keyboard. The only bad thing about this bike is the accompanying app — it’s all-around weak and requires too many steps just to get to peddlin’. It pays to know thyself, and [codaris] knows that this will be a major de-motivator and made a desktop app that does it all, including/starting up as soon as the pedals start spinning.

[codaris] built a Windows application that displays workout data in real time and then saves the stats in a SQLite database after the pedaling stops. It took a fair amount of work to get there, logging the Bluetooth traffic during a ride and comparing that with Wireshark output from a live session to decode the communication between the bike and the app. Turns out there are six commands total, and [codaris] really only needs three — Connect, Start Workout, and Continue Workout.

The app displays the elapsed workout time, speed, distance traveled, and the current RPM. We love that it starts logging and displaying data as soon as [codaris] starts pedaling, because that would be a major goal for us, too.

There’s more than one way to hack a bike. [codaris] was inspired by [ptx2]’s excellent work to un-brick a much more expensive bike with a Raspberry Pi.

Thanks for the tip, [Jhart99]!

Soundbar Bested By Virtual Android Bluetooth Sniffer

May 2, 2021 by Tom Nardi 12 Comments

Out of the box, the Yamaha YAS-207 soundbar can be remotely controlled over Bluetooth, but only when using a dedicated application on iOS or Android. Users who want to command their hardware with their computer, or any other Bluetooth device for that matter, are left out in the cold. Or at least they were, before [Wejn] got on the case.

To capture the communication between the soundbar and the application, [Wejn] first installed Android-x86 in a virtual machine on his computer and then enabled the “Bluetooth HCI snoop log” within Developer Settings. From there, a netcat command running on the virtual Android device continually sent the contents of the btsnoop_hci.log file out to Wireshark on his Linux desktop. As he hit buttons in the Yamaha application, he could watch the data come in live. We’ve seen plenty of people use Android’s integrated Bluetooth packet capture in the past, but never quite like this. It’s certainly a tip worth mentally filing away for the future.

The Pi can now control the TOSLINK connected speakers.

From there, things move pretty quickly. [Wejn] is able to determine that the devices are communicating over a virtual serial port, and starts identifying individual command and response packets. It turns out the commands closely mirror the NEC IR codes that he’d previously decoded on a whim, which helped clear things up. Once the checksum was sorted out, writing some code that can talk to the soundbar from his Raspberry Pi media player was the next logical step.

[Wejn] combined this with the Shairport Sync project, which lets the Raspberry Pi turn on the speaker and switch the input over when he wants to stream AirPlay from his phone. But of course, the same technique could be applied to whatever source of digital audio captures your fancy.

This is one of those posts you should really read in its entirety to truly appreciate. While every device is going to be different, the basic principles and workflow that [Wejn] demonstrates in this project will absolutely be useful in your own reverse engineering adventures. If you’re more of a visual learner, we recently covered a series of YouTube tutorials that cover sniffing BLE devices that’s not to be missed as well.