wireshark

32 Articles

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

February 6, 2024 by 10 Comments

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

Heartbeat packets of LKV373

Audio, Not Video Over The LKV373 HDMI Extender

August 2, 2023 by 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 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 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 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.

Inspecting a SIM card via MTM

Diving The Depths Of Ma Bell

December 27, 2021 by 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 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]!