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.
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.
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.
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.
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.
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.
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.”
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.
Data is sent in the USB packets in groups of four characters on the ATmega-based boards, but the entire string is put in a packet on the Due board. If you look under the hood, the answer is hiding in plain sight. While the Arduino family of boards connect to your computer using a USB virtual serial port, the ATmega ones have an actual serial connection on-board. For instance, on the Nano there is an FT232RL between the USB connector and the microprocessor (on an Arduino Uno board, a small ATMEGA8U2 is used instead of an FTDI chip, but the concept is the same). On the Arduino Due, the USB connects directly to the SAM3X8E processor.
This concept doesn’t apply only to Arduino boards, of course. On any serial connection between two computers, when a virtual USB device is used on both sides of the link (no actual serial signals involved), the serial baud rate is a fictional thing — data transfer speeds depends on USB alone. We are curious why the packets contain four characters in [Andrew]’s ATmega Wireshark captures — why not 1, 2, or 10? Is this something that can be controlled by the programmer, or is it fixed by the protocol and/or the FTDI chip? If you have the answer, let us know in the comments below. Continue reading “Arduino Serial Vs SerialUSB”→