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.

Linux Fu: A Little Bit Of (Network) History Repeating Itself

April 26, 2021 by Al Williams 5 Comments

These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.

General Idea

You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.

While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”

Continue reading “Linux Fu: A Little Bit Of (Network) History Repeating Itself” →

A Crash Course On Sniffing Bluetooth Low Energy

March 23, 2021 by Tom Nardi 19 Comments

Bluetooth Low Energy (BLE) is everywhere these days. If you fire up a scanner on your phone and walk around the neighborhood, we’d be willing to bet you’d pick up dozens if not hundreds of devices. By extension, from fitness bands to light bulbs, it’s equally likely that you’re going to want to talk to some of these BLE gadgets at some point. But how?

Well, watching this three part video series from [Stuart Patterson] would be a good start. He covers how to get a cheap nRF52480 BLE dongle configured for sniffing, pulling the packets out of the air with Wireshark, and perhaps most crucially, how to duplicate the commands coming from a device’s companion application on the ESP32.

The first video in the series is focused on getting a Windows box setup for BLE sniffing, so readers who aren’t currently living under Microsoft’s boot heel may want to skip ahead to the second installment. That’s where things really start heating up, as [Stuart] demonstrates how you can intercept commands being sent to the target device.

It’s worth noting that little attempt is made to actually decode what the commands mean. In this particular application, it’s enough to simply replay the commands using the ESP32’s BLE hardware, which is explained in the third video. Obviously this technique might not work on more advanced devices, but it should still give you a solid base to work from.

In the end, [Stuart] takes an LED lamp that could only be controlled with a smartphone application and turns it into something he can talk to on his own terms. Once the ESP32 can send commands to the lamp, it only takes a bit more code to spin up a web interface or REST API so you can control the device from your computer or other gadget on the network. While naturally the finer points will differ, this same overall workflow should allow you to get control of whatever BLE gizmo you’ve got your eye on.

Continue reading “A Crash Course On Sniffing Bluetooth Low Energy” →