A home-made hand-held Ethernet wiretap

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 one 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

A straightforward way to echo traffic going in one direction is to use an Ethernet repeater, better known as a hub. They 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.

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). 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. 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 and it works perfecly.

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.

Summary

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.

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.

Easy

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.

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

Difficult

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.

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.

Results

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.

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:

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 2¹⁶ and the encryption algorithm consists of three permutation operations:

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:

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.

~/koodi/redsea - zsh ×

1919 windy@pentti~/koodi/redsea ) ./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.

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.

---

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.

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.

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.

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:

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

How I discovered RDS

One stormy night in 2007, I was listening to local FM stations while viewing a live spectrogram of the audio on the computer, through the radio's Line Out. Nearly all stations seemed to have a persistent sinusoid tone at 19 kHz, on the edge of human hearing. Turned out it's a pilot tone that the receiver uses to regenerate various subcarriers at their correct phases. The most prominent of these is the stereo subcarrier at 38 kHz, used to transmit the stereo difference signal.

But something else is also visible on the spectrogram, mirrored on both sides of the pilot tone. It's a quiet signal that has a strange repetitive pattern, almost like binary data of some sort. Let's listen to a gradual downconversion I made on an FM station, revealing how the mystery signal sounds. Here I tune the heterodyne from baseband to 19 kHz.

It definitely sounds like data. I knew FM station names are transmitted alongside the audio, and that it's called RDS (Radio Data System). Could this be the RDS signal? Why does it appear at 19 kHz when the specification says it should be on the third harmonic of the pilot tone, a 57 kHz subcarrier? Just a weird aliasing/mirroring artifact? It's so close to the audio band that it actually gets interfered by some of the highest audio frequencies. But the symbol rate indeed seems to be close to 1187.5 bps, which is the RDS baud rate.

How exactly did the data end up there from 57 kHz? It could be a complex mechanism. Afterall, what I'm getting out of Line Out is not the raw FM demodulated radio signal, because the sound would be monophonic. If I switch the radio to mono reception, the data disappears altogether. So the data is probably being leaked by the stereo decoder, and is somehow related to the way the decoder applies the difference signal to the monophonic main signal. The manufacturer just didn't want to go through the trouble of filtering the artifacts out, because they're near-ultrasonic and thus practically inaudible. The mono/stereo switch probably just switches the stereo decoder off and feeds the actual demodulated baseband audio to Line Out instead.

Being the signals geek that I am, I just couldn't leave it at that. I read the 160-page specification and wrote a complete RDS demodulator and decoder to solve this mystery. And I was right! Here's a station called YLE Radio Suomi, running Radioterapeutti. The data is being decoded live from the quiet artifacts in the Line Out audio.

But it's so much more than just a station name. There's RadioText that often contains a description for the currently running programme; there's a numeric station identifier that can be decoded from even faint signals; there's information about what's currently on on other stations and what are their frequencies; and so on. Also the traffic messages displayed by car GPS navigators are transmitted to cars over RDS. And there are options for pager systems, emergency messages, and whatnot.

All this led me to make modifications to my radio and also embed all this onto a Raspberry Pi.

Portable TV, Raspberry-Pified

Recently I entered the era of video-capable portable music players. About time, too. My device of choice is this Action-branded Taiwanese gem from 1988 with a 5-inch CRT display (B/W), AM/FM radio, television receiver, and cassette player (mono, no rewind). It takes 9 D-sized batteries.

The batteries inside were leaking quite a bit so I removed them in favor of a DC adapter. They actually occupied roughly half of the casing. After removing them the device looked very empty and was unbalanced because of the heavy CRT. So I had to come up with something to fill the space with.

Then it struck me: it's a perfect video terminal and tape drive for the Raspberry Pi!

The screen

The Action has a 5" black-and-white CRT display and a television tuner. The receiver is on an AN5151N integrated circuit. Now, the Raspberry Pi outputs composite video. Someone else has tried injecting composite video onto the AN5151N before, with results that didn't look very successful to me at first sight, so I just ended up buying a cheap RF modulator. It modulates a TV-frequency carrier with the composite signal, and that can be fed into the aerial input of the TV to be demodulated again.

Aerial input to the TV is via a miniplug, so I had to improvise an adapter for coax. It works almost perfectly, except that the CRT crops out the extremes of the display.

The battery compartment before and after refurbishing:

The tape

The cassette player of this device is pretty simple. It does not have stereo, rewind, auto-stop, or any of the other hi-tech functions that many modern-day Walkmen have. It doesn't even stop automatically when Eject is pressed. But it works.

I've written a little Perl program that can write data onto cassettes and read it back using a sound card. For this project I removed the sound card step. The way I've written the data onto the tape is such that when amplified with the tape player's U821B chip, the voltage can directly be used as a binary 3v3 GPIO logic level. I wouldn't recommend this though, unless you know what you're doing, because the GPIO port is essentially a direct connection to the CPU and there's no overvoltage protecti... blast, I've just fried my RasPi!

A moment of silence. And a screenshot honouring the memory of its last words over ssh. Here, a logic "1" is low voltage, and "0" is high.

~ - zsh ×

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111110110011Write failed: Broken pipe 2204 windy@pentti~ ) █

Anyway, I also modified the TV's power circuitry to supply power to both the CRT and tape player at the same time, and installed a switch to silence the speaker when reading data. If it weren't for the aforementioned overvolt accident, this would now be complete. Cassettes could be used to store e.g. Vectrex games; also reading C64 cassettes will be supported.

Moral of the story: The GPIO port is not 5V tolerant! Assuming there will a second attempt some day, I'll just use a transistor to pull the GPIO pin high when there's a high on the tape. Or use a sound card.

Rendering PCM with simulated phosphor persistence

When PCM waveforms and similar function plots are displayed on screen, computational speed is often preferred over beauty and information content. For example, Audacity only draws the local maximum envelope amplitude and (what appears to be) RMS power when zoomed out, and when zoomed in, displays a very straightforward linear interpolation between samples.

Here's the startup beep of my Kenwood TK-2302, rendered by Audacity:

Analogue oscilloscopes, on the other hand, do things differently. An electron beam scans a phosphor screen at a constant X velocity, lighting a dot everywhere it hits. The dot brightness is proportional to the time the electron beam was directed at it. Because the X speed of the beam is constant and the Y position is modulated by the waveform, brightness gives information about the local derivative of the function.

Of course, PCM is all about "dots" as well, so we could possibly mimic this behavior digitally. I'm going to simulate an electron beam by first oversampling the above waveform by an insane amount – at 1,099,961 Hz, to be exact. (It's a prime number as well, hopefully minimizing aliasing artifacts.) Downpass filtering follows, with a cutoff frequency at the Nyquist frequency of the original PCM. Now, a program reads in the processed PCM and for each sample will make the corresponding dot on the XY plane a little brighter. (Actually each sample will affect 4 image pixels because of bilinear interpolation.) This method gives us a much more interesting rendering:

Now how cool is that? It looks like an X-ray of the signal. We can see right away that the beep is roughly a square wave, because there's light on top and bottom of the oscillation envelope but mostly darkness in between. Minute changes in the harmonic content are also visible as interesting banding and ribbons.

At very high zoom, Audacity doesn't even bother reconstructing the actual waveform but just thinks of it as a "connect the dots" puzzle. This is computationally feasible, of course. Oversampling at 3,000,017 Hz and downpass filtering at the original Nyquist frequency, on the other hand, results in an apparent reconstruction of the analogue wave:

Finally, the soprano section of the Finnish Radio Chamber Choir singing a D note in a piece by Einojuhani Rautavaara:

Relevant code for scientific interest in this Gist.