A home-made hand-held Ethernet wiretap

[Image: An array of Ethernet ports on a PCB, one of them with a cable connected.]

Sitting in a conference room at work, waiting for others to arrive, I noticed that all Internet traffic to laptops is routed through a classic Ethernet hub in the middle of the table. So I started thinking how easy it would be to eavesdrop everyone in the conference by just innocently plugging myself into the hub. And due to its innocent appearance, could a hub be used as an general eavesdropping device?

Trusting the network

As you know, an Internet user is often warned by her browser that a web transaction is unencrypted and "could easily be read by a third party". So who's the third party? And how can anyone possibly listen in on traffic that's being transferred over a wired network?

To illustrate this approach, I put together a simple device to silently capture traffic from one end of an Ethernet cable, echo it into a laptop to be recorded or analyzed live, and retransmit it into another cable, unmodified. For as you probably know, Internet traffic will be almost guaranteed to go through Ethernet cables and routers at some point along its path. (Acquiring physical access to network infrastructure is beyond the scope here.)

Battery-powered hub

Ethernet hubs were widely used to build home and enterprise networks still in the late 1990s, but have now been largely obsoleted by switches and similar "smarter" devices. But one can encounter them even today, as I did.

A hub receives packets in one of its ports and repeats them to all the others, regardless of where they're going. They operate at the lowest OSI layer, the physical layer, which makes them transparent to other devices in the network (save for the speed limitations and data collisions). Plus they visually look like useful parts of the network. All this makes them perfect wiretapping devices. Furthermore, this used hub cost me about €3.

Hubs come in handy sizes and look pretty innocent. But they need an external power source, because Ethernet doesn't carry power like USB does (edit: at the time). And it's not always easy to quickly find an outlet with your hoodie on and all that. This hub happens to have a 5.0 V low-dropout regulator right after the main fuse, so I just replaced the 7.5 V wall adapter with four AA batteries (totaling 6 V nominal) and it works perfecly.

[Image: A device labeled 'LINKSYS(R) 5-Port Workgroup Hub' with several indicator LEDs, labeled 'Link/Activity' (5 indicators, 1 lit green), 'Collision' (unlit), and 'Power' (lit green). The device is connected to a battery holder with VARTA AA-sized batteries, and to an Ethernet cable going outside of the picture.]

The feat

Disconnecting a cable from a router and rerouting it through our malicious hub only takes around ten seconds, and if done in a relatively low-traffic part of the network, need not even noticeably disrupt connections. This could be done anywhere along the path of the traffic. We could quickly unplug our laptop from the hub if needed without affecting the monitored router; the hub would still continue to redirect the traffic.

If we wanted to be really sneaky, a Raspberry Pi or similar could be used to record the traffic. It could be left recording and we could physically leave the site, perhaps commanding the RasPi to transmit interesting bits over the air. Sadly, I could not test this as I had fried my RasPi during a previous incident.

Video proof

On this film, an anonymous hacker inflitrates a building and plugs the evil hub into a connection wherewith an innocent user is listening to a podcast. The innocent user is using the gray laptop on the left, and the black one on the right obviously belongs to the eavesdropper. The "router" to be compromised can be seen in the background, between the laptops. Observe how the stream automatically comes back on like it was just a little glitch in the connection.


Never trust the network. Use encryption.

Descrambling the voice inversion scrambler

Voice inversion is a method of scrambling radio conversations to render speech nearly unintelligible in ordinary radio receivers. As the name implies, it inverts the audio spectrum of a signal, making the lowest frequencies the highest and vice versa. It is not considered encryption; it's merely a sort of Pig Latin on analogue signals. Several voice scramblers utilize it, like the Selectone ST-20.

Update 09/2017: I've later released a simple descrambler tool called deinvert.

[Image: A spectrogram of speech, with a cut labeled 'voice inversion' in the middle of the time axis, after which the spectrum appears to be flipped upside down.]

Voice inversion is cancelled by reapplying the inversion, i.e. inverting the audio spectrum again. Here I'll present some least-effort digital descrambling methods for the voice inversion scrambler that may be of interest to hobbyist listeners. The examples are written in Perl.


In a digitally sampled signal, whole-spectrum inversion can be achieved very easily in the time domain by multiplying every other sample by −1. This is equivalent to amplitude modulating a Nyquist frequency carrier with the signal; the upper sideband will get inverted and nicely overlaid with the lower because of symmetric folding.

my $bandwidth = 4300;

my $fc = $bandwidth * 2;

# Using SoX for resampling and decoding/encoding WAV headers
open my $inf, '-|', 'sox scrambled.wav -r '.$fc.' -c 1 -t .s16 -';
open my $outf, '|-', 'sox -r '.$fc.' -c 1 -t .s16 - descrambled.wav';
my $sign = 1;

while (read $inf, my $sample, 2) {
  # Simply multiply every other sample by -1
  print $outf pack "s", (unpack "s", $sample) * $sign;
  $sign *= -1;

Because the whole spectrum is inverted, a sampling rate has to be chosen to (approximately) match the signal bandwidth. Slight distortion will still remain, unless the chosen Nyquist frequency perfectly matches the inverted zero frequency of the signal, or the "inversion carrier" as Selectone calls it. But speech will nevertheless be much more intelligible than in the original scrambled signal.

For example, consider a scrambled piece of audio that seems to have its highest frequency components at 4300 Hz. We would need to resample the audio at a rate of 8600 Hz and multiply every other sample by −1 to get intelligible audio.

To make things simpler, the Selectone ST-20B supports eight discrete carrier frequencies, namely 2632, 2718, 2868, 3023, 3196, 3339, 3495, and 3729 Hz, which they claim to be "the most commonly used inversion formats".


If resampling is out of the question, we can also multiply the samples with a sine wave oscillating at the seemingly highest scrambled frequency. This will produce two sidebands; the lower will be our descrambled audio and will be conveniently at baseband. The upper sideband contains the inverted signal, but at such a high frequency it should not significantly impede intelligibility. We could improve the audio further by silencing the upper sideband using a lowpass filter.

# Sample rate
my $fs = 48000;

# Carrier frequency
my $fc = 3729;

# Optional filter - comment out to disable
my $filter = " sinc -$fc";

my $fc = freq($fc, $fs);

# Using SoX for resampling, filtering, encoding/decoding WAV headers
open my $in, '-|', 'sox scrambled.wav -c 1 -b 16 -e signed -t .raw -';
open my $out, '|-', 'sox -r '.$fs.' -c 1 -b 16 -e signed -t .raw - ' .
                    'descrambled.wav' . ($filter // "");

my $phase = 0;
while (read $in, my $sample, 2) {
  $phase += $fc;
  $phase -= 0x10000 if ($phase > 0x7FFF);

  # Multiply signal with sine wave
  print $out pack "s", (unpack "s", $sample) *
                       sin($phase / 0x7FFF * 3.14159);

sub freq {
  return int(.5 + $_[0] * 0x10000 / $_[1]);

A word about split-band scrambling

Some scramblers, like the PCD4440T, use a split-band inversion where the audio is split into two frequency bands that are then inverted separately and combined. The split frequency is user-adjustable. This is not a significant improvement; it would only require us to do the digital deinversion in two parts with different parameters.


And here's a demo of what it sounds like. We begin with a (fake) scrambled message. Then the easy descramble comes on with a 1000 Hz error in the selected sampling rate; then the easy descramble with an error of 300 Hz; and the difficult method with a spot-on carrier frequency and with the upper sideband also audible. In the end, we also filter out the unwanted upper sideband.


Update 09/2017: I've later released a simple descrambler tool called deinvert.

A determined 'hacker' decrypts RDS-TMC

As told in a previous post, I like to watch the RDS-TMC traffic messages every now and then, just for fun. Even though I've never had a car. Actually I haven't done it for years now, but thought I'd share with you the joy of solving the enigma.[disclaimer 1]

RDS-TMC is used in car navigators to inform the driver about traffic jams, roadworks and urgent stuff like that. It's being broadcast on a subcarrier of a public radio FM transmission. It's encrypted in many countries, including mine, so that it could be monetized by selling the encryption keys.

A draft of the encryption standard, namely ISO/DIS 14819-6, is freely available online. Here's an excerpt[disclaimer 2] that reads blatantly like a challenge:

"After calling for candidate proposals, the submission from Deutsche Telekom was judged by an expert panel to have best met the pre-determined criteria the task force had established. The method encrypts the sixteen bits that form the Location element in each RDS-TMC message to render the message virtually useless without decryption. The encryption is only 'light' but was adjudged to be adequate to deter other than the most determined 'hacker'. More secure systems were rejected because of the RDS capacity overhead that was required."

TMC messages consist mostly of numeric references to a static database of preset sentences and locations; no actual text is being transmitted. The database is not a secret and is freely available. The location information is encrypted with a key that changes daily. Every night, a random key is picked from 31 pregenerated alternatives. The key is never transferred over the air, only its numeric ID (1–31). The keys are preprogrammed into all licensed TMC receivers, and they can decrypt the locations knowing the key ID.

The size of the key space is 216 and the encryption algorithm consists of three permutation operations:

[Image: A cipher diagram beginning with the 16-bit hex words C1A0 and F3D5, labeled 'location' and 'key', respectively. The 'location' word goes into a bitwise right rotation block, controlled by the first nybble of 'key'. The third and fourth nybble of 'key', taken as a single byte, go to a bitwise left shift block controlled by the second nybble of 'key'. Outputs from these two bitwise blocks are XORed. The result is the hex word 85E9, labeled 'encrypted location'.]

The algorithm is simple enough to be run using pen-and-paper hardware, and that's just what I did while creating the above crypto diagram:

[Image: A pink, heart-shaped Post-It note with a hand-written columnar XOR calculation in binary. One of the operands is shifted left from the alignment. The result is 85E9.]

The tricky part is that I don't know the keys. But there's a catch. To save bandwidth, only regional messages are transmitted. This limits the space of possible locations, giving us a lot of information about the encrypted data. Assuming all messages are from this limited region, we can limit the number of keys to a very small number, in the dozens.

The next day, we have an all new encryption key again. But there's another catch. Many messages persist over several days, if not weeks. These would be messages about long-lasting roadworks and such. We just need to wait for messages that we heard yesterday that only have their location code changed, and we can continue limiting the keyspace by collecting more data.

Once we've limited the keyspace to a single key, we can decrypt all of today's messages. When the key changes again, it is trivial to find today's key by knowing yesterday's key and comparing the locations of persistent messages; this is known as a known-plaintext attack or KPA.

Here's some encrypted data straight from the radio.

$ ./redsea.pl | grep TMC
══╡ TMC msg 00 1828 4400
══╡ TMC sysmsg 6040
══╡ TMC msg 00 1828 4400
══╡ TMC msg 07 8264 0294
══╡ TMC msg 07 8264 0294
══╡ TMC msg 07 8264 0294
══╡ TMC sysmsg 0021
══╡ TMC msg 07 5964 72ca

A little Perl script then decodes everything and even plots the affected segment on a little map. The screenshot is from a few years back.

[Image: Screenshot of a GUI with the title 'RDS-TMC'. It's divided into three sections. The first one, labeled 'TMC Service', tells that the service provider is 'MMN TMC+', we're using location table 6/17, and the data is encrypted with key number 5. The second section, labeled 'Received messages', shows a scrollable columnar list of traffic messages received, with a one-word description, an icon and rough location. The third section, 'Message', shows the selected message in detail. A map displays the affected road segment. A long event description is printed in Finnish, along with the road name, exact coordinates, speed limit, time of expiration, and the last time the message was received.]

Now I just need a car. Well, actually I prefer motorcycles. But I guess it would work, too.

Tools used: Ordinary FM radio, sound card, computer. All data is from public sources. RDS was decoded from intermodulation distortion in the radio's Line Out audio caused by the stereo demuxer circuitry.

Update 2014-07-27: Some news seem to highlight that I was the first one to break this joke of a cipher. This could be true; I don't really care. In any case, the often-referred-to 2007 work by Barisani and Bianco (PDF 13MB) was done on unencrypted RDS-TMC and no cryptanalysis was involved; "encryption is supported for commercial services but irrelevant to our goals". I encourage you to read it, it addressed some of the real-world security implications of injecting crafted TMC messages into cars.

Disclaimer 1: I will take this post down on the first appearance of any complaint from any party, of course. My intent is not malicious and I'm not even publishing any keys or code.

Disclaimer 2: This use of the above excerpt of the ISO standard is not an infringement of copyright as it is being used here under the doctrine of "Fair Use" of the United States Copyright Law (17 U.S.C. § 107), seeing as this blog is hosted on US soil.

Tomy Electronic PUCKMAN

Today it was time for some flea market shopping again. I found a pleated denim skirt for €4.50 that's a perfect fit, but that's not really the subject matter of this blog. I also found a Tomy Electronic PUCKMAN for €2.00, which will be further examined below.

[Image: A circularly shaped, brightly colored toy with 6 buttons, a small display and the text 'TOMY ELECTRONIC PUCKMAN'.]

It's an electronic game that obviously has a lot to do with Pac-Man. As sources have it, Puckman was the original name of the famous game. It has a display, a D-pad sort of controller, on-off switch, and a difficulty switch that lets the player choose between AMA and PRO.

[Image: Close-up photo of the unlit display, revealing that it is a 8x5 grid of small pictures of the game characters and the scene, and a 7-segment, 4-character number display.]

The display is a bright vacuum fluorescent display, or VFD, that has all the possible positions of the sprites pre-printed onto it. There's also a score counter of some sort.

[Image: Close-up photo of a microchip on a PCB, with the etchings 'NEC JAPAN, D553C, 8228EK, 160'.]

The main processor (or what appears to be one) is marked D553C-160. I couldn't find any info about it online, just googlespam by companies that claim to sell similar chips and lie about having the datasheet (shame on them!).

The device takes four C-sized batteries, totalling 6 volts, or an AC adapter. I happened to have a 6-volt DC adapter so I hooked it up to the battery terminals, and yay:

[Image: The display with parts of it glowing brightly, namely the walls of the scene, the main character in one corner, power-up pills everywhere and three ghosts near the middle. The score counter is showing zero.]

The sound it makes is very loud and nasty. But it is indeed the actual Pac-Man theme. Video below.