https:/.../30c3-5588-en-de-My_journey_into_FM-RDS_h264-iprod.mp4

Herald: Alright, well thank you for your
patience and now we are starting our talk:

"My journey into FM-RDS"
- radio data system by Oona Räisänen.

Please give her a warm round of applause!
applause

Oona: Thank you!
Sorry I brought my MacBook Pro.

My name is Oona I'm a signals hacker
and electronics hobbyist

and I do this thing only for hobby.

And let's see my slides here. Some of you may

remember my blog or have read it.

And you may have seen this one,

that I also made - the dialup diagram.

This talk is not about that, just to give you some context.

Okay, so, into the story:

One night in 2007 I was listening to my radio

just an FM channel and some music going on.

And I was looking at the spectrum of course

on my PC while doing that. And I noticed,

I see the audio, that's normal, then above

the audio, at about 19 kHz something weird

is going on. There is a persistent sinusoidal tone.

And something, looking like sidebands,

on both sides of it. And I wanted to find out,

what could it be up there? Actually I have

some audio on my other computer:

[Audio: rds-mixdown.wav]
This is just a radio channel played,

and I'm shifting the frequencies down to here,

what it sounds like up there.

Now at the moment it just sounds like a very piercing
[Sounds from the radio]

tone of 19 kHz. That's the tone,

and I'm not actually hearing just yet

whats around it. Let's turn it down a bit further.

Now this is one of this sidebands that you

are seeing there.

I'm also now filtering out the music

to make it clearer.

It sounds very periodic.

So it means it could be data of some kind.

And it also brings up the memories of modem sounds.

So, I started to investigate this matter

a bit further.

I knew already that in the FM signal there

is the RDS data, that is used to send to car

radios the station name and the program currently

running on it and also some other information

like alternate frequencies [AF on the slide]

that this channel is broadcasted on,

CT which is clock time, and something else,

information about other programs

and other frequencies and the program type,

radio text, traffic announcements,

and something called TMC or Traffic Message Channel.

So I thought, could this be it? So I downloaded

the 200 page RDS Standard,

or RDBS, as its called in the United States

and started to do some analysis. Actually I

spent nights reading this,

and many times I fell asleep reading it.

laughter
If you suffer from insomnia,

I suggest you read something like this.

And, what I found - well it was very well documented,

the protocol, there was for example this diagram

about an example receiver for RDS.

There's all the parts out there:

The FM signal is coming in, the audio is taken out,

and we are mixing it with some frequencies

to get out the RDS signal

and all that stuff. So, well using this information

I wrote a decoder in Perl. Everything must

be in perl clapping Thank you.

And I came up with this. Its showing a lot

of the information going on on the frequency.

And whats special about this is that it's only

decoded from the signal you were hearing on

the 19 kHz band. And it turns out this is actually

an error in the working of my radio.

Because I dropped it on the floor when I was moving,

and it started behaving weirdly. And I - it

was then when i got this weird signal on

the 19 kHz band. And it turns out that

the stereo decoder in my radio has somehow

started not to filter anymore the stereo signal,

which is near the RDS signal. So this is actually

being decoded from the audio, from the line

out of my radio. Nothing else was involved

in this. But then, well, its a bit noisy,

its near the 16 bit quantisation noise limit

of my soundcard. So I was thinking of better

ways to decode it with less noise.

And I started to look at my radio -

the schematics of my radio

and I found there is actually a decoder circuit

for RDS that it uses to display the data on

the screen, just the station name

and updates its clock. And unlike in todays

receivers the RDS chip is actually on its own

chip and its not a one-chip-wonder receiver.

So I found the 4 pins that I needed for data,

clock signal and ground and just a quality bit,

that I'm not actually using. And I did some

ugly soldering work because I didn't want to

remove the RF shielding from this chip to hook

some cords to the decoder chip.

And then I used my soundcard to sample that.

Because it happens that the voltages that soundcard

is using are very close to the logic voltages

of [?] Voltages of ICs in the 1 to 3.3 volt range.

So I actually used a sound card to sample

the logic coming out of there. And its 1 kbaud

so its not even very fast. And this is what

I was getting - at first. Well,

it looks like some bits, kind of.

Then after some filtering

and resoldering this is what i got.

Red is the left channel in the soundcard that

I hooked up in the clock signal output.

And green is what I hooked up to the data signal.

And its very clear that the data can be decoded

with no errors from this.

Afterwards I also made a raspberry pi version of all this,

so the perl code is actually running on my

raspberry pi and displaying it on an little

lcd next to it. But then - okay this is fun,

I can actually see more than
my radio is displaying there.

I can see the radio text, I can see a numerical

code for each station so I can log the stations

and I only need to decode the number to know

what I'm listening to. But there was something

more on the frequency. I was getting an application -

some application running there that I didn't

recognize right away, but reading the standard

it became apparent that this TMC that is used

in these car navigators to just send information

about traffic jams and construction works

and things like that. And of course,

for the fun, I had to see whats going on there.

Now it turns out that in Finland the RDS signal

is encrypted, for reasons of commercial stuff.

I mean its a business model, they encrypt

the signal and they sell the encryption keys

along with these navigator devices

and what they tell about the encryption in

the standard - they actually tell everything

about except the keys there. But one sentence

especially caught my mind there:

The encryption is only light, but was adjust

to be adequate to deter other than the most

determined hacker."
laughterclapping

Yeah, and obviously for hacker this is like an challenge

laughter
so I got to work. It was textually documented,

there was no encryption diagrams

or anything like that, but this is what I came

up with: It's a pretty simple cipher.

The location is a 16 bit database reference

to a database of locations that can be obtained

from the manufacturer of the navigators.

The keyspace is 16 bits, and different parts

of the key are used to like parameters for

the different operations in this cipher.

It's an easy enough cipher
to be used on paper also

so when cryptanalyzing it I made some tests

on paper. So, how do I begin? I checked I can't

just brute force it - knowing nothing about

the transmission. So I
made some assumtions:

The bandwidth is very low,
several hundred baud,

so it must be some kind of
filtering with this locations.

I was thinking, it could be
that they are sending

only the locations - I mean only the announcements

that are near the transmitter like 100 miles

range or something. I looked
at the location database,

that I by the way obtained by telling

the manufacturers that I'm an engineer

and I want to do some tests

and maybe some development
of RDS-TMC-Software

- and now I have the database.
So I started mapping,

actually listening to the annoucements.

I took one announcement and I figured

one announcement is used for several days in

an row - actually several weeks,

because when there
are roadworks on it

could last for months, weeks or something.

So, one day, I get the announcements

and I get the key-ID, which they are sending

in cleartext - thats how they signal which

key is in use today, because its a changing

key scheme and there is a different key for

every day. And then they send
the encrypted location.

So I listened for several weeks in a row,

documenting the encryption key id

and the location and then I just bruteforced

through the whole vast 16 bit keyspace to find

all the keys that decrypt into locations that

are near the transmitter. And eventually I

came up with all the keys. And here they are -

and because wouldn't want
to get into any more

trouble with this, well,
yeah, I ended up finding

all the keys. And here is a prototype receiver

I wrote. Its receiving the messages

and showing a little map of the announcements.

So then I published this in a blog,

and I got an interesting reply from someone

who is involved in developing this:

Sad to request, but can you take this offline?

It is kind of our service you hacked."
laughingapplause

I had promised in

the beginning of my blog post, that if anyone

of the involved parties requests to take this

offline I will take it offline. But of course,

there are, well, my definitions of an involved

party are quite strict. And I replied by requesting

just the same message, but signed with their

cryptographic signature and preferably I could

fetch their public key from under their company domain.

And they never replied, so the blog post is

still on.
laughingapplause

And actually while this conversation was going on,

it was of course being copied around

the world, in cryptome also, so there was no

point in replying anymore. So yeah,

this is the first part of my adventure into RDS-Subcarriers.

Then I heard an rumour when presenting about this:

That the Bus-Stop-Displays in Helsinki also

receive their data about the next buses on the RDS-Signal.

So I started to look a bit more in the applications,

but there was nothing in the application list

about bus stops or anything else than TMC.

For reference these are the displays I am talking about.

So they are displaying the busnumber

and the minutes and where it is going

and it's updating live. And these are battery-operated

and they are not connected to anything by wire.

So there must be some kind of a radio protocol.

But yeah, this was a nice clue.

So i started googling about this - there was

not very much information about it,

except for the finnish communication authorities

internal magazine. They were telling about

all kinds of - sorry about my finnish text

of course - they were telling about all kinds

of everyday radio signals,

and they confirmed my guess, that its being

transmitted on the FM radio and they even told

the channel, but that's all they told.

They were just telling it's being transmitted

on "YLE 1" frequencies. No protocol.

Nothing about RDS. So I fired up my other radio,

which can do a larger spectrum. Which is of

course the realtek rtl-sdr packaged in an aluminium

tin here. applause

So I demodulated the "YLE 1" station signal on a bigger bandwidth.

And here is what I saw. On the left is

the audio, here is the obnoxious tone you just heard.

Here is the stereo seperation signal that tells

the relation of the left channel

and the right channel. Here is RDS where it

actually should be, but for some reason it

was aliased to around the pilot tone in my

older radio. And this fourth harmonic of

the pilot tone contains obviously some data,

on a very wide bandwidth compared to

the RDS.

What could it be and
how could I ever find out? Well,

it's centered around 76 kHz on the demodulated signal,

the composite signal. So I started by googling

for 76 kHz, and I found something called DARC

or "Data Radio Channel". It's not to be confused

with RDS which is the Radio Data System of course.

These are very imaginative names.

I found out that it is a very much more complex

modulation scheme. It uses QPSK which is a

four phase modulation scheme. Well I'm not

a engineer, I'm not an DSP specialist,

I am a DSP hacker, but I don't know much about

demodulating QPSK. So I decided to treat it

as an FSK signal, because that is possible

with QPSK. It is suboptimal, but it works -

I can get the data out. The upper part is

the DARC signal filtered. Here is the DARC

signal using two band-pass filters that are

on 76+4 and 76-4 and superimposed in red

and blue, like an FSK. And here is just blue

minus red, or the other way around,

which is actually binary data. So I had to

treat the error correction

and error detection, and it was very complicated.

And I had to write general CRC subroutine in

Perl because I had to deal with such large

numbers that I couldn't use just integers -

I had to actually use string magic.

So I'm actually concatenateing strings of ones

and zeroes. And using this kind of general

CRC routing for calculating the error correction

and detection. So, this is DARC

and I actually getting packets out,

but I have no idea what the packets mean.

So I started looking for any human readable

data out of there, because there is no documentation

about this. For example, this was one type

of packet that I've found: RUSKEASUO BRUKAKĂRR,

that means something for finns - that's a place

in helsinki, where the bus 23N happens to go.

So I figured this could be a packet telling

something about, just generally about buses.

And actually I went so far as to label all

the fields in the end, because I collected

so many of them. And I found out,

the system is sending one of these packets

to every display once a day. So it's updating

the information about all possible buses that

are passing this bus stop today.

It's using such low bandwidth that updating

all the displays takes one day.

Then I found another type of packet,

with no actual strings. But I found definite

references to the above packet. And I found

this is the packet used to update the minutes

information in these displays. It's being sent

very fast, 3 times per minute, to every display.

It contains minutes for 8 buses per packet,

and information about whether they are actually

GPS located or if it's a guess based on time tables.

And I used all this information, I had a functional goal:

to build my own display, because the tram stop

is 200 metres from my house,

and I want to know when the tram is actually coming.

Because this information is actually

the GPS located information. So this is what

I built
applause

Its just a basic HD77480 display

controlled by a Raspberry Pi,

decoding the signal from the RTL-SDR. For some

reasons I blogged about it

and it became very popular in Finland,

in Helsinki especially, and there was an news

article about it. And a representant of

the bus company was saying that "OK,

she can decode the signal, but transmitting

will be difficult. "
laugther

I haven't actually done it yet.
But he was saying that

it's difficult because you have to shout louder

than everyone else on the frequency.

And even then it becomes mangeled, because

it becomes a mix of those two signals.

I don't think he really knew
what he was talking about,

because there is something called the FM capture effect.

That if you send stronger than another FM transmission

on the same frequency, only the stronger signal

becomes captured and the weaker
becomes actually attenuated.

That is a very useful phenomenon. Right now

I am actually in the process of making my own

display updater.
laughterapplause

Possibly for showing all kinds of funny stuff on

the displays. Someone at the bus company actually

donated one of those displays to me after this,

so I have something to test it on.

Because obviously I'm not going to transmit

any high-power signals with this ever.

But right now, I'm building it.

The only problem that I'm having right now

is that my soundcard that I am using to generate

the signal fully digitally of course is to slow.

The DARC signal is 76 kHz, so i need at least

162 kHz soundcard, i mean DAC,

to create my analogue signal. I only have a

96khz soundcard right now, so I only can generate

the stereo signal. Perhaps in the future,

that will be the next project. Thank you.

applause

Herald: Well, thank you very much, Oona,

I think we're all impressed with hacking a radio,

I never thought about this opportunity.

Now we have time for questions from

the room. If you want to ask questions,

could you please line up at the microphones

right here. In the mean time, let me ask our

signal angel if he has a question from

the internet. Could you tell us please?
Signal Angel: Yeah,

so the internet wants to know: Is there any

open hardware radio receiver that you can recommend

for tinkering at home?
Oona: Yeah,

the RTL-SDR is a very good
piece of hardware to start with

I think I have one of those with me right now,

I mean the one I showed with the Hello Kitty

tin around it. I've using a tin to attenuate

any local interference. But its just a DVB

digital tv stick some wise guy on the internet

found to be possible to hack

and tune to any frequency from 30 to 1.700 MHz

And it's very useful. Doesn't go higher

than that, doesn't go lower than that,

but it is a good start.
Herald: Okay. Questions from

the room?
Mic: I've just a bit of input on

the transmitter thing. There is a project that

uses the raspberry pi DMA controller,

where you can use to send signals at about

140 MHz on the GPIO pins, so maybe that could

be used.
Oona: Ooh, thanks for the [?] That will

be very useful. I've been thinking about

the GPIO but it's unfiltered of course.

Mic: The raw DMA controller output gets dumped on

one of the GPIO pins. As far as I know it's

good enough to transmit FM stereo audio.

Oona: Okay, yeah. It would be worthwhile testing

with RDS first maybe. Thank you for

the tip, yeah, it's very useful.
Herald: So maybe we

could buy them at the next congress,

right? laughter
Oona: Could be,

could be. Herald: Go ahead please.
Mic: Thanks for the interesting talk,

I've two questions. You said that you can decode Q-PSK as FSK by

a simple trick. How much less quality do you

get? 3db, 6db, what is it?
Oona: I'm not sure

about the details, but well it just crossed

my mind that you can do it. It's actually MSK

but its a sort of an Q-PSK signal.

So its a minimum shift keying. And essentially

its being generated in the transmitter as FSK,

but thats a special form of FSK,

so thats why it can be decoded as FSK.

Mic: Okay, and a brief second question: In

the picture where you took the signal from

your digital radio, it was a Sangean ATS 909

or what radio you used? I've got one of those

and I was wondering if I could pick up

the signals in there as well. [...]

Oona: The Radio is a Sangean ATS 909,

I've modified it a bit, you can take a look

if you want.
Herlad: Any other question from

the internet? Oh, our signal angel has nothing,

then lets go ahead right here please.

Mic: Have you considered what [...]

going to be beyond transmitting the signal.

What are you going to be next challenges you're

taking out? Are you going to look at other

wireless services that are around there in

terms of utilities, because traditionally there

are many.
Oona: There are many, yeah,

it's an very interesting world. And I'm actually

listening to serveral signals at the moment

in my home right now.
Mic: Mind telling us a little

glimpse?
Oona: There is the local taxi company

that is using the frequency range from 40 to

70 MHz, they send information about next clients

and also locating all their cabs,

and I'm trying to decode whats it's about.

Perhaps I'll make a map of all their cars. -

Of course there is also TETRA.

Not many people know that TETRA is not encrypted,

it's usually encrypted, but not always.

And many applications in TETRA are in clear text.

You can listen to it, if you really want to.

Mic: Which sort of teases me now to ask a question:

What's the legal situation for you in finland

when it comes to decoding such transmissions

when they are not encrypted.
Herald: You have

the right to remain silent.
Mic: Yeah,

you don't have to answer that
Oona: Well,

I believe that it its legal to decode them.

I don't care if it's not laughter
applause

Yeah, of course, actually making an FM transmitter would be illegal

if its an high enough power.

Herald: Okay, over there. Let's go, please?
Mic: Could you

maybe elaborate a bit about the bus stop packet contents,

so currently they are not encrypted,

is there any signature to verify its an legit

packet?
Oona: No they aren't using any encryption

or signature overhead, because its so an low-banded channel.

So you can spoof it. I guess it should be trivial.

Actually the are some types of packets that

I don't know the meaning of. But they are non changing,

so they obviously can't be anything [?]

or anything like that.
Herald: Okay, go ahead please.

Mic: I wanted to add some information on

the situation in Germany: We have two types

of radio stations, the public radio stations

broadcast RDS that are unencrypted, so if you

get the RDS data, you can get the raw location codes.

And the TMC messages are usually sent by private

radio stations. The fun thing is,

that you get both the unencrypted location

codes and encrypted location codes.

So if you listen to two radio stations in

the same area, you can actually cross-correlate

these and try to figure out the key.

And the other thing I wanted to say:

If somebody is just interested in RDS,

there are relatively cheap usb sticks that

will do all the decoding for you. -

Oona: Yeah, FM Radio sticks.

Mic: Is there any book you can recommend
in getting started for processing

of digital radio transmissions.
Oona: Well,

I've read a few chapters of the - I don't know

the name actually - but the DSP [?] guided

commerce[?] - The engineers guide to DSP,

It's a blue book, thats all I know.

Its freely available online, try it with google.

Mic: Thank you.
Herald: Any more questions,

or from the internet? Nothing right there.

Well, Oona, thank you very much.

That was a very interesting talk,

and we look forward having you next year

with more signals.

Applause

subtitles created by c3subtitles.de