1 00:00:09,930 --> 00:00:15,840 Herald: Alright, well thank you for your patience and now we are starting our talk: 2 00:00:15,840 --> 00:00:21,040 "My journey into FM-RDS" - radio data system by Oona Räisänen. 3 00:00:21,040 --> 00:00:27,850 Please give her a warm round of applause! *applause* 4 00:00:27,850 --> 00:00:34,510 Oona: Thank you! Sorry I brought my MacBook Pro. 5 00:00:34,510 --> 00:00:40,570 My name is Oona I'm a signals hacker and electronics hobbyist 6 00:00:40,570 --> 00:00:44,200 and I do this thing only for hobby. 7 00:00:44,200 --> 00:00:52,500 And let's see my slides here. Some of you may 8 00:00:52,500 --> 00:00:55,520 remember my blog or have read it. 9 00:00:55,520 --> 00:01:00,990 And you may have seen this one, 10 00:01:00,990 --> 00:01:09,840 that I also made - the dialup diagram. 11 00:01:09,840 --> 00:01:14,440 This talk is not about that, just to give you some context. 12 00:01:14,440 --> 00:01:18,710 Okay, so, into the story: 13 00:01:18,710 --> 00:01:22,250 One night in 2007 I was listening to my radio 14 00:01:22,250 --> 00:01:28,680 just an FM channel and some music going on. 15 00:01:28,680 --> 00:01:32,810 And I was looking at the spectrum of course 16 00:01:32,810 --> 00:01:38,810 on my PC while doing that. And I noticed, 17 00:01:38,810 --> 00:01:42,250 I see the audio, that's normal, then above 18 00:01:42,250 --> 00:01:46,630 the audio, at about 19 kHz something weird 19 00:01:46,630 --> 00:01:51,490 is going on. There is a persistent sinusoidal tone. 20 00:01:51,490 --> 00:01:54,850 And something, looking like sidebands, 21 00:01:54,850 --> 00:01:58,690 on both sides of it. And I wanted to find out, 22 00:01:58,690 --> 00:02:06,900 what could it be up there? Actually I have 23 00:02:06,900 --> 00:02:15,510 some audio on my other computer: 24 00:02:15,510 --> 00:02:23,970 [Audio: rds-mixdown.wav] This is just a radio channel played, 25 00:02:23,970 --> 00:02:26,610 and I'm shifting the frequencies down to here, 26 00:02:26,610 --> 00:02:31,200 what it sounds like up there. 27 00:02:41,130 --> 00:02:44,190 Now at the moment it just sounds like a very piercing [Sounds from the radio] 28 00:02:44,190 --> 00:02:47,920 tone of 19 kHz. That's the tone, 29 00:02:47,920 --> 00:02:50,670 and I'm not actually hearing just yet 30 00:02:50,670 --> 00:02:56,390 whats around it. Let's turn it down a bit further. 31 00:03:04,460 --> 00:03:07,030 Now this is one of this sidebands that you 32 00:03:07,030 --> 00:03:10,230 are seeing there. 33 00:03:10,230 --> 00:03:13,663 I'm also now filtering out the music 34 00:03:13,663 --> 00:03:16,589 to make it clearer. 35 00:03:20,289 --> 00:03:22,360 It sounds very periodic. 36 00:03:22,360 --> 00:03:25,607 So it means it could be data of some kind. 37 00:03:25,607 --> 00:03:29,568 And it also brings up the memories of modem sounds. 38 00:03:29,568 --> 00:03:33,398 So, I started to investigate this matter 39 00:03:33,398 --> 00:03:35,128 a bit further. 40 00:03:39,248 --> 00:03:47,480 I knew already that in the FM signal there 41 00:03:47,480 --> 00:03:58,620 is the RDS data, that is used to send to car 42 00:03:58,620 --> 00:04:03,420 radios the station name and the program currently 43 00:04:03,420 --> 00:04:07,210 running on it and also some other information 44 00:04:07,210 --> 00:04:12,410 like alternate frequencies [AF on the slide] 45 00:04:12,410 --> 00:04:14,230 that this channel is broadcasted on, 46 00:04:14,230 --> 00:04:18,850 CT which is clock time, and something else, 47 00:04:18,850 --> 00:04:20,970 information about other programs 48 00:04:20,970 --> 00:04:25,730 and other frequencies and the program type, 49 00:04:25,730 --> 00:04:29,840 radio text, traffic announcements, 50 00:04:29,840 --> 00:04:34,546 and something called TMC or Traffic Message Channel. 51 00:04:34,546 --> 00:04:40,830 So I thought, could this be it? So I downloaded 52 00:04:40,830 --> 00:04:43,360 the 200 page RDS Standard, 53 00:04:43,360 --> 00:04:47,840 or RDBS, as its called in the United States 54 00:04:47,840 --> 00:04:51,980 and started to do some analysis. Actually I 55 00:04:51,980 --> 00:04:54,870 spent nights reading this, 56 00:04:54,870 --> 00:04:56,540 and many times I fell asleep reading it. 57 00:04:56,540 --> 00:05:00,380 *laughter* If you suffer from insomnia, 58 00:05:00,380 --> 00:05:04,960 I suggest you read something like this. 59 00:05:04,960 --> 00:05:10,270 And, what I found - well it was very well documented, 60 00:05:10,270 --> 00:05:13,040 the protocol, there was for example this diagram 61 00:05:13,040 --> 00:05:15,840 about an example receiver for RDS. 62 00:05:15,840 --> 00:05:18,216 There's all the parts out there: 63 00:05:18,216 --> 00:05:23,720 The FM signal is coming in, the audio is taken out, 64 00:05:23,720 --> 00:05:27,720 and we are mixing it with some frequencies 65 00:05:27,720 --> 00:05:30,500 to get out the RDS signal 66 00:05:30,500 --> 00:05:38,830 and all that stuff. So, well using this information 67 00:05:38,830 --> 00:05:42,770 I wrote a decoder in Perl. Everything must 68 00:05:42,770 --> 00:05:49,495 be in perl *clapping* Thank you. 69 00:05:49,495 --> 00:05:52,480 And I came up with this. Its showing a lot 70 00:05:52,480 --> 00:05:55,729 of the information going on on the frequency. 71 00:05:55,729 --> 00:05:58,520 And whats special about this is that it's only 72 00:05:58,520 --> 00:06:02,840 decoded from the signal you were hearing on 73 00:06:02,840 --> 00:06:07,990 the 19 kHz band. And it turns out this is actually 74 00:06:07,990 --> 00:06:09,750 an error in the working of my radio. 75 00:06:09,750 --> 00:06:13,999 Because I dropped it on the floor when I was moving, 76 00:06:13,999 --> 00:06:17,840 and it started behaving weirdly. And I - it 77 00:06:17,840 --> 00:06:19,730 was then when i got this weird signal on 78 00:06:19,730 --> 00:06:22,890 the 19 kHz band. And it turns out that 79 00:06:22,890 --> 00:06:26,310 the stereo decoder in my radio has somehow 80 00:06:26,310 --> 00:06:33,170 started not to filter anymore the stereo signal, 81 00:06:33,170 --> 00:06:38,800 which is near the RDS signal. So this is actually 82 00:06:38,800 --> 00:06:41,280 being decoded from the audio, from the line 83 00:06:41,280 --> 00:06:45,360 out of my radio. Nothing else was involved 84 00:06:45,360 --> 00:06:49,830 in this. But then, well, its a bit noisy, 85 00:06:49,830 --> 00:06:54,420 its near the 16 bit quantisation noise limit 86 00:06:54,420 --> 00:06:57,750 of my soundcard. So I was thinking of better 87 00:06:57,750 --> 00:07:01,520 ways to decode it with less noise. 88 00:07:01,520 --> 00:07:03,820 And I started to look at my radio - 89 00:07:03,820 --> 00:07:05,570 the schematics of my radio 90 00:07:05,570 --> 00:07:08,140 and I found there is actually a decoder circuit 91 00:07:08,140 --> 00:07:11,610 for RDS that it uses to display the data on 92 00:07:11,610 --> 00:07:13,970 the screen, just the station name 93 00:07:13,970 --> 00:07:18,230 and updates its clock. And unlike in todays 94 00:07:18,230 --> 00:07:20,730 receivers the RDS chip is actually on its own 95 00:07:20,730 --> 00:07:25,260 chip and its not a one-chip-wonder receiver. 96 00:07:25,260 --> 00:07:31,580 So I found the 4 pins that I needed for data, 97 00:07:31,580 --> 00:07:35,840 clock signal and ground and just a quality bit, 98 00:07:35,840 --> 00:07:41,430 that I'm not actually using. And I did some 99 00:07:41,430 --> 00:07:43,820 ugly soldering work because I didn't want to 100 00:07:43,820 --> 00:07:50,630 remove the RF shielding from this chip to hook 101 00:07:50,630 --> 00:07:57,621 some cords to the decoder chip. 102 00:07:57,621 --> 00:08:01,750 And then I used my soundcard to sample that. 103 00:08:01,750 --> 00:08:05,140 Because it happens that the voltages that soundcard 104 00:08:05,140 --> 00:08:07,830 is using are very close to the logic voltages 105 00:08:07,830 --> 00:08:17,050 of [?] Voltages of ICs in the 1 to 3.3 volt range. 106 00:08:17,050 --> 00:08:20,830 So I actually used a sound card to sample 107 00:08:20,830 --> 00:08:27,240 the logic coming out of there. And its 1 kbaud 108 00:08:27,240 --> 00:08:33,850 so its not even very fast. And this is what 109 00:08:33,850 --> 00:08:38,159 I was getting - at first. Well, 110 00:08:38,159 --> 00:08:41,519 it looks like some bits, kind of. 111 00:08:41,519 --> 00:08:43,610 Then after some filtering 112 00:08:43,610 --> 00:08:47,180 and resoldering this is what i got. 113 00:08:47,180 --> 00:08:50,950 Red is the left channel in the soundcard that 114 00:08:50,950 --> 00:08:54,380 I hooked up in the clock signal output. 115 00:08:54,380 --> 00:08:58,840 And green is what I hooked up to the data signal. 116 00:08:58,840 --> 00:09:02,548 And its very clear that the data can be decoded 117 00:09:02,548 --> 00:09:07,650 with no errors from this. 118 00:09:07,650 --> 00:09:17,140 Afterwards I also made a raspberry pi version of all this, 119 00:09:17,140 --> 00:09:19,860 so the perl code is actually running on my 120 00:09:19,860 --> 00:09:22,590 raspberry pi and displaying it on an little 121 00:09:22,590 --> 00:09:29,580 lcd next to it. But then - okay this is fun, 122 00:09:29,580 --> 00:09:32,850 I can actually see more than my radio is displaying there. 123 00:09:32,850 --> 00:09:36,550 I can see the radio text, I can see a numerical 124 00:09:36,550 --> 00:09:40,850 code for each station so I can log the stations 125 00:09:40,850 --> 00:09:45,340 and I only need to decode the number to know 126 00:09:45,340 --> 00:09:48,840 what I'm listening to. But there was something 127 00:09:48,840 --> 00:09:53,780 more on the frequency. I was getting an application - 128 00:09:53,780 --> 00:09:58,480 some application running there that I didn't 129 00:09:58,480 --> 00:10:03,230 recognize right away, but reading the standard 130 00:10:03,230 --> 00:10:07,090 it became apparent that this TMC that is used 131 00:10:07,090 --> 00:10:12,500 in these car navigators to just send information 132 00:10:12,500 --> 00:10:15,350 about traffic jams and construction works 133 00:10:15,350 --> 00:10:18,650 and things like that. And of course, 134 00:10:18,650 --> 00:10:26,230 for the fun, I had to see whats going on there. 135 00:10:26,230 --> 00:10:29,550 Now it turns out that in Finland the RDS signal 136 00:10:29,550 --> 00:10:34,610 is encrypted, for reasons of commercial stuff. 137 00:10:34,610 --> 00:10:38,500 I mean its a business model, they encrypt 138 00:10:38,500 --> 00:10:41,480 the signal and they sell the encryption keys 139 00:10:41,480 --> 00:10:45,170 along with these navigator devices 140 00:10:45,170 --> 00:10:47,040 and what they tell about the encryption in 141 00:10:47,040 --> 00:10:49,510 the standard - they actually tell everything 142 00:10:49,510 --> 00:10:55,260 about except the keys there. But one sentence 143 00:10:55,260 --> 00:10:58,270 especially caught my mind there: 144 00:10:58,270 --> 00:11:01,990 The encryption is only light, but was adjust 145 00:11:01,990 --> 00:11:04,280 to be adequate to deter other than the most 146 00:11:04,280 --> 00:11:14,314 determined hacker." *laughter**clapping* 147 00:11:14,314 --> 00:11:19,644 Yeah, and obviously for hacker this is like an challenge 148 00:11:19,644 --> 00:11:23,770 *laughter* so I got to work. It was textually documented, 149 00:11:23,770 --> 00:11:26,950 there was no encryption diagrams 150 00:11:26,950 --> 00:11:29,020 or anything like that, but this is what I came 151 00:11:29,020 --> 00:11:35,099 up with: It's a pretty simple cipher. 152 00:11:35,099 --> 00:11:38,570 The location is a 16 bit database reference 153 00:11:38,570 --> 00:11:42,400 to a database of locations that can be obtained 154 00:11:42,400 --> 00:11:47,804 from the manufacturer of the navigators. 155 00:11:47,804 --> 00:11:52,940 The keyspace is 16 bits, and different parts 156 00:11:52,940 --> 00:11:57,230 of the key are used to like parameters for 157 00:11:57,230 --> 00:11:59,990 the different operations in this cipher. 158 00:11:59,990 --> 00:12:04,660 It's an easy enough cipher to be used on paper also 159 00:12:04,660 --> 00:12:12,510 so when cryptanalyzing it I made some tests 160 00:12:12,510 --> 00:12:17,390 on paper. So, how do I begin? I checked I can't 161 00:12:17,390 --> 00:12:20,860 just brute force it - knowing nothing about 162 00:12:20,860 --> 00:12:24,765 the transmission. So I made some assumtions: 163 00:12:24,765 --> 00:12:28,520 The bandwidth is very low, several hundred baud, 164 00:12:28,520 --> 00:12:33,530 so it must be some kind of filtering with this locations. 165 00:12:33,530 --> 00:12:36,120 I was thinking, it could be that they are sending 166 00:12:36,120 --> 00:12:39,950 only the locations - I mean only the announcements 167 00:12:39,950 --> 00:12:42,930 that are near the transmitter like 100 miles 168 00:12:42,930 --> 00:12:47,350 range or something. I looked at the location database, 169 00:12:47,350 --> 00:12:49,690 that I by the way obtained by telling 170 00:12:49,690 --> 00:12:52,000 the manufacturers that I'm an engineer 171 00:12:52,000 --> 00:12:54,160 and I want to do some tests 172 00:12:54,160 --> 00:12:57,340 and maybe some development of RDS-TMC-Software 173 00:12:57,340 --> 00:13:05,050 - and now I have the database. So I started mapping, 174 00:13:05,050 --> 00:13:10,714 actually listening to the annoucements. 175 00:13:10,714 --> 00:13:14,950 I took one announcement and I figured 176 00:13:14,950 --> 00:13:17,390 one announcement is used for several days in 177 00:13:17,390 --> 00:13:19,030 an row - actually several weeks, 178 00:13:19,030 --> 00:13:21,060 because when there are roadworks on it 179 00:13:21,060 --> 00:13:24,390 could last for months, weeks or something. 180 00:13:24,390 --> 00:13:29,890 So, one day, I get the announcements 181 00:13:29,890 --> 00:13:33,080 and I get the key-ID, which they are sending 182 00:13:33,080 --> 00:13:36,370 in cleartext - thats how they signal which 183 00:13:36,370 --> 00:13:38,740 key is in use today, because its a changing 184 00:13:38,740 --> 00:13:42,520 key scheme and there is a different key for 185 00:13:42,520 --> 00:13:49,000 every day. And then they send the encrypted location. 186 00:13:49,000 --> 00:13:52,890 So I listened for several weeks in a row, 187 00:13:52,890 --> 00:13:56,490 documenting the encryption key id 188 00:13:56,490 --> 00:14:00,930 and the location and then I just bruteforced 189 00:14:00,930 --> 00:14:05,220 through the whole vast 16 bit keyspace to find 190 00:14:05,220 --> 00:14:11,480 all the keys that decrypt into locations that 191 00:14:11,480 --> 00:14:17,150 are near the transmitter. And eventually I 192 00:14:17,150 --> 00:14:21,230 came up with all the keys. And here they are - 193 00:14:21,230 --> 00:14:24,240 and because wouldn't want to get into any more 194 00:14:24,240 --> 00:14:30,440 trouble with this, well, yeah, I ended up finding 195 00:14:30,440 --> 00:14:34,430 all the keys. And here is a prototype receiver 196 00:14:34,430 --> 00:14:40,160 I wrote. Its receiving the messages 197 00:14:40,160 --> 00:14:46,666 and showing a little map of the announcements. 198 00:14:46,666 --> 00:14:51,012 So then I published this in a blog, 199 00:14:51,012 --> 00:14:55,670 and I got an interesting reply from someone 200 00:14:55,670 --> 00:15:01,447 who is involved in developing this: 201 00:15:01,447 --> 00:15:04,460 Sad to request, but can you take this offline? 202 00:15:04,460 --> 00:15:18,882 It is kind of our service you hacked." *laughing**applause* 203 00:15:18,882 --> 00:15:19,970 I had promised in 204 00:15:19,970 --> 00:15:23,670 the beginning of my blog post, that if anyone 205 00:15:23,670 --> 00:15:25,620 of the involved parties requests to take this 206 00:15:25,620 --> 00:15:28,340 offline I will take it offline. But of course, 207 00:15:28,340 --> 00:15:31,940 there are, well, my definitions of an involved 208 00:15:31,940 --> 00:15:39,580 party are quite strict. And I replied by requesting 209 00:15:39,580 --> 00:15:43,680 just the same message, but signed with their 210 00:15:43,680 --> 00:15:47,700 cryptographic signature and preferably I could 211 00:15:47,700 --> 00:15:52,560 fetch their public key from under their company domain. 212 00:15:52,560 --> 00:15:55,860 And they never replied, so the blog post is 213 00:15:55,860 --> 00:16:06,975 still on. *laughing**applause* 214 00:16:06,975 --> 00:16:09,280 And actually while this conversation was going on, 215 00:16:09,280 --> 00:16:11,900 it was of course being copied around 216 00:16:11,900 --> 00:16:15,740 the world, in cryptome also, so there was no 217 00:16:15,740 --> 00:16:18,120 point in replying anymore. So yeah, 218 00:16:18,120 --> 00:16:25,580 this is the first part of my adventure into RDS-Subcarriers. 219 00:16:25,580 --> 00:16:29,160 Then I heard an rumour when presenting about this: 220 00:16:29,160 --> 00:16:32,950 That the Bus-Stop-Displays in Helsinki also 221 00:16:32,950 --> 00:16:40,474 receive their data about the next buses on the RDS-Signal. 222 00:16:40,474 --> 00:16:43,600 So I started to look a bit more in the applications, 223 00:16:43,600 --> 00:16:46,480 but there was nothing in the application list 224 00:16:46,480 --> 00:16:52,760 about bus stops or anything else than TMC. 225 00:16:52,760 --> 00:16:58,840 For reference these are the displays I am talking about. 226 00:16:58,840 --> 00:17:02,090 So they are displaying the busnumber 227 00:17:02,090 --> 00:17:04,510 and the minutes and where it is going 228 00:17:04,510 --> 00:17:07,589 and it's updating live. And these are battery-operated 229 00:17:07,589 --> 00:17:11,445 and they are not connected to anything by wire. 230 00:17:11,445 --> 00:17:13,608 So there must be some kind of a radio protocol. 231 00:17:13,608 --> 00:17:17,770 But yeah, this was a nice clue. 232 00:17:17,770 --> 00:17:20,600 So i started googling about this - there was 233 00:17:20,600 --> 00:17:22,770 not very much information about it, 234 00:17:22,770 --> 00:17:26,700 except for the finnish communication authorities 235 00:17:26,700 --> 00:17:31,180 internal magazine. They were telling about 236 00:17:31,180 --> 00:17:35,780 all kinds of - sorry about my finnish text 237 00:17:35,780 --> 00:17:39,660 of course - they were telling about all kinds 238 00:17:39,660 --> 00:17:42,090 of everyday radio signals, 239 00:17:42,090 --> 00:17:45,230 and they confirmed my guess, that its being 240 00:17:45,230 --> 00:17:48,900 transmitted on the FM radio and they even told 241 00:17:48,900 --> 00:17:50,970 the channel, but that's all they told. 242 00:17:50,970 --> 00:17:53,820 They were just telling it's being transmitted 243 00:17:53,820 --> 00:17:57,200 on "YLE 1" frequencies. No protocol. 244 00:17:57,200 --> 00:18:02,850 Nothing about RDS. So I fired up my other radio, 245 00:18:02,850 --> 00:18:06,570 which can do a larger spectrum. Which is of 246 00:18:06,570 --> 00:18:11,050 course the realtek rtl-sdr packaged in an aluminium 247 00:18:11,050 --> 00:18:20,093 tin here. *applause* 248 00:18:20,093 --> 00:18:30,803 So I demodulated the "YLE 1" station signal on a bigger bandwidth. 249 00:18:30,803 --> 00:18:34,020 And here is what I saw. On the left is 250 00:18:34,020 --> 00:18:43,315 the audio, here is the obnoxious tone you just heard. 251 00:18:43,315 --> 00:18:47,020 Here is the stereo seperation signal that tells 252 00:18:47,020 --> 00:18:49,380 the relation of the left channel 253 00:18:49,380 --> 00:18:53,230 and the right channel. Here is RDS where it 254 00:18:53,230 --> 00:18:56,800 actually should be, but for some reason it 255 00:18:56,800 --> 00:19:00,760 was aliased to around the pilot tone in my 256 00:19:00,760 --> 00:19:06,090 older radio. And this fourth harmonic of 257 00:19:06,090 --> 00:19:10,090 the pilot tone contains obviously some data, 258 00:19:10,090 --> 00:19:12,890 on a very wide bandwidth compared to 259 00:19:12,890 --> 00:19:16,850 the RDS. 260 00:19:16,850 --> 00:19:22,280 What could it be and how could I ever find out? Well, 261 00:19:22,280 --> 00:19:26,250 it's centered around 76 kHz on the demodulated signal, 262 00:19:26,250 --> 00:19:31,500 the composite signal. So I started by googling 263 00:19:31,500 --> 00:19:36,710 for 76 kHz, and I found something called DARC 264 00:19:36,710 --> 00:19:40,660 or "Data Radio Channel". It's not to be confused 265 00:19:40,660 --> 00:19:44,850 with RDS which is the Radio Data System of course. 266 00:19:44,850 --> 00:19:48,528 These are very imaginative names. 267 00:19:48,528 --> 00:19:51,450 I found out that it is a very much more complex 268 00:19:51,450 --> 00:19:59,960 modulation scheme. It uses QPSK which is a 269 00:19:59,960 --> 00:20:04,500 four phase modulation scheme. Well I'm not 270 00:20:04,500 --> 00:20:07,380 a engineer, I'm not an DSP specialist, 271 00:20:07,380 --> 00:20:12,490 I am a DSP hacker, but I don't know much about 272 00:20:12,490 --> 00:20:17,730 demodulating QPSK. So I decided to treat it 273 00:20:17,730 --> 00:20:20,980 as an FSK signal, because that is possible 274 00:20:20,980 --> 00:20:30,020 with QPSK. It is suboptimal, but it works - 275 00:20:30,020 --> 00:20:37,610 I can get the data out. The upper part is 276 00:20:37,610 --> 00:20:42,350 the DARC signal filtered. Here is the DARC 277 00:20:42,350 --> 00:20:47,750 signal using two band-pass filters that are 278 00:20:47,750 --> 00:20:53,380 on 76+4 and 76-4 and superimposed in red 279 00:20:53,380 --> 00:20:59,600 and blue, like an FSK. And here is just blue 280 00:20:59,600 --> 00:21:02,770 minus red, or the other way around, 281 00:21:02,770 --> 00:21:14,990 which is actually binary data. So I had to 282 00:21:14,990 --> 00:21:16,680 treat the error correction 283 00:21:16,680 --> 00:21:19,550 and error detection, and it was very complicated. 284 00:21:19,550 --> 00:21:24,700 And I had to write general CRC subroutine in 285 00:21:24,700 --> 00:21:30,940 Perl because I had to deal with such large 286 00:21:30,940 --> 00:21:34,260 numbers that I couldn't use just integers - 287 00:21:34,260 --> 00:21:37,550 I had to actually use string magic. 288 00:21:37,550 --> 00:21:40,920 So I'm actually concatenateing strings of ones 289 00:21:40,920 --> 00:21:44,180 and zeroes. And using this kind of general 290 00:21:44,180 --> 00:21:50,570 CRC routing for calculating the error correction 291 00:21:50,570 --> 00:21:56,570 and detection. So, this is DARC 292 00:21:56,570 --> 00:21:58,830 and I actually getting packets out, 293 00:21:58,830 --> 00:22:02,107 but I have no idea what the packets mean. 294 00:22:02,107 --> 00:22:05,020 So I started looking for any human readable 295 00:22:05,020 --> 00:22:08,020 data out of there, because there is no documentation 296 00:22:08,020 --> 00:22:17,290 about this. For example, this was one type 297 00:22:17,290 --> 00:22:22,640 of packet that I've found: RUSKEASUO BRUKAKĂRR, 298 00:22:22,640 --> 00:22:26,400 that means something for finns - that's a place 299 00:22:26,400 --> 00:22:32,730 in helsinki, where the bus 23N happens to go. 300 00:22:32,730 --> 00:22:36,010 So I figured this could be a packet telling 301 00:22:36,010 --> 00:22:42,317 something about, just generally about buses. 302 00:22:42,317 --> 00:22:46,020 And actually I went so far as to label all 303 00:22:46,020 --> 00:22:49,980 the fields in the end, because I collected 304 00:22:49,980 --> 00:22:52,660 so many of them. And I found out, 305 00:22:52,660 --> 00:22:57,420 the system is sending one of these packets 306 00:22:57,420 --> 00:23:01,710 to every display once a day. So it's updating 307 00:23:01,710 --> 00:23:05,190 the information about all possible buses that 308 00:23:05,190 --> 00:23:11,427 are passing this bus stop today. 309 00:23:11,427 --> 00:23:13,930 It's using such low bandwidth that updating 310 00:23:13,930 --> 00:23:18,338 all the displays takes one day. 311 00:23:18,338 --> 00:23:20,920 Then I found another type of packet, 312 00:23:20,920 --> 00:23:27,800 with no actual strings. But I found definite 313 00:23:27,800 --> 00:23:33,200 references to the above packet. And I found 314 00:23:33,200 --> 00:23:35,750 this is the packet used to update the minutes 315 00:23:35,750 --> 00:23:38,440 information in these displays. It's being sent 316 00:23:38,440 --> 00:23:47,210 very fast, 3 times per minute, to every display. 317 00:23:47,210 --> 00:23:55,450 It contains minutes for 8 buses per packet, 318 00:23:55,450 --> 00:24:00,480 and information about whether they are actually 319 00:24:00,480 --> 00:24:05,320 GPS located or if it's a guess based on time tables. 320 00:24:08,110 --> 00:24:13,340 And I used all this information, I had a functional goal: 321 00:24:13,340 --> 00:24:18,010 to build my own display, because the tram stop 322 00:24:18,010 --> 00:24:19,830 is 200 metres from my house, 323 00:24:19,830 --> 00:24:27,200 and I want to know when the tram is actually coming. 324 00:24:27,200 --> 00:24:29,740 Because this information is actually 325 00:24:29,740 --> 00:24:34,810 the GPS located information. So this is what 326 00:24:34,810 --> 00:24:45,331 I built *applause* 327 00:24:45,331 --> 00:24:51,306 Its just a basic HD77480 display 328 00:24:51,306 --> 00:24:53,560 controlled by a Raspberry Pi, 329 00:24:53,560 --> 00:24:59,280 decoding the signal from the RTL-SDR. For some 330 00:24:59,280 --> 00:25:02,560 reasons I blogged about it 331 00:25:02,560 --> 00:25:04,300 and it became very popular in Finland, 332 00:25:04,300 --> 00:25:07,980 in Helsinki especially, and there was an news 333 00:25:07,980 --> 00:25:14,550 article about it. And a representant of 334 00:25:14,550 --> 00:25:16,830 the bus company was saying that "OK, 335 00:25:16,830 --> 00:25:19,690 she can decode the signal, but transmitting 336 00:25:19,690 --> 00:25:27,250 will be difficult. " *laugther* 337 00:25:27,250 --> 00:25:31,570 I haven't actually done it yet. But he was saying that 338 00:25:31,570 --> 00:25:34,830 it's difficult because you have to shout louder 339 00:25:34,830 --> 00:25:37,080 than everyone else on the frequency. 340 00:25:37,080 --> 00:25:41,290 And even then it becomes mangeled, because 341 00:25:41,290 --> 00:25:44,990 it becomes a mix of those two signals. 342 00:25:44,990 --> 00:25:47,880 I don't think he really knew what he was talking about, 343 00:25:47,880 --> 00:25:52,050 because there is something called the FM capture effect. 344 00:25:52,050 --> 00:25:56,890 That if you send stronger than another FM transmission 345 00:25:56,890 --> 00:26:00,020 on the same frequency, only the stronger signal 346 00:26:00,020 --> 00:26:07,877 becomes captured and the weaker becomes actually attenuated. 347 00:26:07,877 --> 00:26:13,380 That is a very useful phenomenon. Right now 348 00:26:13,380 --> 00:26:18,220 I am actually in the process of making my own 349 00:26:18,220 --> 00:26:30,500 display updater. *laughter**applause* 350 00:26:30,500 --> 00:26:33,080 Possibly for showing all kinds of funny stuff on 351 00:26:33,080 --> 00:26:37,320 the displays. Someone at the bus company actually 352 00:26:37,320 --> 00:26:41,390 donated one of those displays to me after this, 353 00:26:41,390 --> 00:26:44,160 so I have something to test it on. 354 00:26:44,160 --> 00:26:46,640 Because obviously I'm not going to transmit 355 00:26:46,640 --> 00:26:52,460 any high-power signals with this ever. 356 00:26:52,460 --> 00:26:53,990 But right now, I'm building it. 357 00:26:53,990 --> 00:26:56,060 The only problem that I'm having right now 358 00:26:56,060 --> 00:26:59,510 is that my soundcard that I am using to generate 359 00:26:59,510 --> 00:27:04,510 the signal fully digitally of course is to slow. 360 00:27:04,510 --> 00:27:09,040 The DARC signal is 76 kHz, so i need at least 361 00:27:09,040 --> 00:27:12,920 162 kHz soundcard, i mean DAC, 362 00:27:12,920 --> 00:27:18,400 to create my analogue signal. I only have a 363 00:27:18,400 --> 00:27:22,930 96khz soundcard right now, so I only can generate 364 00:27:22,930 --> 00:27:27,910 the stereo signal. Perhaps in the future, 365 00:27:27,910 --> 00:27:31,970 that will be the next project. Thank you. 366 00:27:31,970 --> 00:27:47,880 *applause* 367 00:27:47,880 --> 00:27:50,200 Herald: Well, thank you very much, Oona, 368 00:27:50,200 --> 00:27:52,970 I think we're all impressed with hacking a radio, 369 00:27:52,970 --> 00:27:55,940 I never thought about this opportunity. 370 00:27:55,940 --> 00:27:58,110 Now we have time for questions from 371 00:27:58,110 --> 00:27:59,780 the room. If you want to ask questions, 372 00:27:59,780 --> 00:28:02,900 could you please line up at the microphones 373 00:28:02,900 --> 00:28:07,380 right here. In the mean time, let me ask our 374 00:28:07,380 --> 00:28:09,310 signal angel if he has a question from 375 00:28:09,310 --> 00:28:11,840 the internet. Could you tell us please? Signal Angel: Yeah, 376 00:28:11,840 --> 00:28:14,300 so the internet wants to know: Is there any 377 00:28:14,300 --> 00:28:16,950 open hardware radio receiver that you can recommend 378 00:28:16,950 --> 00:28:19,590 for tinkering at home? Oona: Yeah, 379 00:28:19,590 --> 00:28:25,300 the RTL-SDR is a very good piece of hardware to start with 380 00:28:25,300 --> 00:28:28,270 I think I have one of those with me right now, 381 00:28:28,270 --> 00:28:31,110 I mean the one I showed with the Hello Kitty 382 00:28:31,110 --> 00:28:35,070 tin around it. I've using a tin to attenuate 383 00:28:35,070 --> 00:28:38,590 any local interference. But its just a DVB 384 00:28:38,590 --> 00:28:47,400 digital tv stick some wise guy on the internet 385 00:28:47,400 --> 00:28:49,930 found to be possible to hack 386 00:28:49,930 --> 00:28:58,090 and tune to any frequency from 30 to 1.700 MHz 387 00:28:58,090 --> 00:29:01,690 And it's very useful. Doesn't go higher 388 00:29:01,690 --> 00:29:03,800 than that, doesn't go lower than that, 389 00:29:03,800 --> 00:29:07,750 but it is a good start. Herald: Okay. Questions from 390 00:29:07,750 --> 00:29:13,030 the room? Mic: I've just a bit of input on 391 00:29:13,030 --> 00:29:17,270 the transmitter thing. There is a project that 392 00:29:17,270 --> 00:29:21,190 uses the raspberry pi DMA controller, 393 00:29:21,190 --> 00:29:23,370 where you can use to send signals at about 394 00:29:23,370 --> 00:29:28,320 140 MHz on the GPIO pins, so maybe that could 395 00:29:28,320 --> 00:29:31,060 be used. Oona: Ooh, thanks for the [?] That will 396 00:29:31,060 --> 00:29:33,660 be very useful. I've been thinking about 397 00:29:33,660 --> 00:29:36,640 the GPIO but it's unfiltered of course. 398 00:29:36,640 --> 00:29:42,150 Mic: The raw DMA controller output gets dumped on 399 00:29:42,150 --> 00:29:47,340 one of the GPIO pins. As far as I know it's 400 00:29:47,340 --> 00:29:50,490 good enough to transmit FM stereo audio. 401 00:29:50,490 --> 00:29:53,960 Oona: Okay, yeah. It would be worthwhile testing 402 00:29:53,960 --> 00:29:56,850 with RDS first maybe. Thank you for 403 00:29:56,850 --> 00:30:00,270 the tip, yeah, it's very useful. Herald: So maybe we 404 00:30:00,270 --> 00:30:02,220 could buy them at the next congress, 405 00:30:02,220 --> 00:30:03,600 right? *laughter* Oona: Could be, 406 00:30:03,600 --> 00:30:09,730 could be. Herald: Go ahead please. Mic: Thanks for the interesting talk, 407 00:30:09,730 --> 00:30:18,120 I've two questions. You said that you can decode Q-PSK as FSK by 408 00:30:18,120 --> 00:30:21,700 a simple trick. How much less quality do you 409 00:30:21,700 --> 00:30:25,270 get? 3db, 6db, what is it? Oona: I'm not sure 410 00:30:25,270 --> 00:30:28,720 about the details, but well it just crossed 411 00:30:28,720 --> 00:30:34,140 my mind that you can do it. It's actually MSK 412 00:30:34,140 --> 00:30:37,690 but its a sort of an Q-PSK signal. 413 00:30:37,690 --> 00:30:41,240 So its a minimum shift keying. And essentially 414 00:30:41,240 --> 00:30:46,570 its being generated in the transmitter as FSK, 415 00:30:46,570 --> 00:30:50,580 but thats a special form of FSK, 416 00:30:50,580 --> 00:30:53,390 so thats why it can be decoded as FSK. 417 00:30:53,390 --> 00:30:55,500 Mic: Okay, and a brief second question: In 418 00:30:55,500 --> 00:30:58,630 the picture where you took the signal from 419 00:30:58,630 --> 00:31:01,530 your digital radio, it was a Sangean ATS 909 420 00:31:01,530 --> 00:31:09,390 or what radio you used? I've got one of those 421 00:31:09,390 --> 00:31:11,290 and I was wondering if I could pick up 422 00:31:11,290 --> 00:31:15,700 the signals in there as well. [...] 423 00:31:15,700 --> 00:31:19,660 Oona: The Radio is a Sangean ATS 909, 424 00:31:19,660 --> 00:31:22,530 I've modified it a bit, you can take a look 425 00:31:22,530 --> 00:31:26,500 if you want. Herlad: Any other question from 426 00:31:26,500 --> 00:31:29,270 the internet? Oh, our signal angel has nothing, 427 00:31:29,270 --> 00:31:32,630 then lets go ahead right here please. 428 00:31:32,630 --> 00:31:35,030 Mic: Have you considered what [...] 429 00:31:35,030 --> 00:31:38,550 going to be beyond transmitting the signal. 430 00:31:38,550 --> 00:31:41,960 What are you going to be next challenges you're 431 00:31:41,960 --> 00:31:44,160 taking out? Are you going to look at other 432 00:31:44,160 --> 00:31:47,360 wireless services that are around there in 433 00:31:47,360 --> 00:31:50,690 terms of utilities, because traditionally there 434 00:31:50,690 --> 00:31:52,030 are many. Oona: There are many, yeah, 435 00:31:52,030 --> 00:31:56,750 it's an very interesting world. And I'm actually 436 00:31:56,750 --> 00:31:58,970 listening to serveral signals at the moment 437 00:31:58,970 --> 00:32:04,240 in my home right now. Mic: Mind telling us a little 438 00:32:04,240 --> 00:32:07,290 glimpse? Oona: There is the local taxi company 439 00:32:07,290 --> 00:32:11,800 that is using the frequency range from 40 to 440 00:32:11,800 --> 00:32:17,430 70 MHz, they send information about next clients 441 00:32:17,430 --> 00:32:22,120 and also locating all their cabs, 442 00:32:22,120 --> 00:32:25,540 and I'm trying to decode whats it's about. 443 00:32:25,540 --> 00:32:30,590 Perhaps I'll make a map of all their cars. - 444 00:32:30,590 --> 00:32:32,740 Of course there is also TETRA. 445 00:32:32,740 --> 00:32:35,980 Not many people know that TETRA is not encrypted, 446 00:32:35,980 --> 00:32:38,020 it's usually encrypted, but not always. 447 00:32:38,020 --> 00:32:42,480 And many applications in TETRA are in clear text. 448 00:32:42,480 --> 00:32:46,210 You can listen to it, if you really want to. 449 00:32:46,210 --> 00:32:52,660 Mic: Which sort of teases me now to ask a question: 450 00:32:52,660 --> 00:32:55,990 What's the legal situation for you in finland 451 00:32:55,990 --> 00:32:59,150 when it comes to decoding such transmissions 452 00:32:59,150 --> 00:33:01,170 when they are not encrypted. Herald: You have 453 00:33:01,170 --> 00:33:03,200 the right to remain silent. Mic: Yeah, 454 00:33:03,200 --> 00:33:06,470 you don't have to answer that Oona: Well, 455 00:33:06,470 --> 00:33:09,470 I believe that it its legal to decode them. 456 00:33:09,470 --> 00:33:19,060 I don't care if it's not *laughter* *applause* 457 00:33:19,060 --> 00:33:21,920 Yeah, of course, actually making an FM transmitter would be illegal 458 00:33:21,920 --> 00:33:28,600 if its an high enough power. 459 00:33:28,600 --> 00:33:32,440 Herald: Okay, over there. Let's go, please? Mic: Could you 460 00:33:32,440 --> 00:33:36,520 maybe elaborate a bit about the bus stop packet contents, 461 00:33:36,520 --> 00:33:38,250 so currently they are not encrypted, 462 00:33:38,250 --> 00:33:42,380 is there any signature to verify its an legit 463 00:33:42,380 --> 00:33:45,160 packet? Oona: No they aren't using any encryption 464 00:33:45,160 --> 00:33:48,560 or signature overhead, because its so an low-banded channel. 465 00:33:48,560 --> 00:33:53,140 So you can spoof it. I guess it should be trivial. 466 00:33:53,140 --> 00:33:55,220 Actually the are some types of packets that 467 00:33:55,220 --> 00:33:58,590 I don't know the meaning of. But they are non changing, 468 00:33:58,590 --> 00:34:01,890 so they obviously can't be anything [?] 469 00:34:01,890 --> 00:34:07,740 or anything like that. Herald: Okay, go ahead please. 470 00:34:07,740 --> 00:34:10,699 Mic: I wanted to add some information on 471 00:34:10,699 --> 00:34:13,980 the situation in Germany: We have two types 472 00:34:13,980 --> 00:34:16,159 of radio stations, the public radio stations 473 00:34:16,159 --> 00:34:20,949 broadcast RDS that are unencrypted, so if you 474 00:34:20,949 --> 00:34:25,110 get the RDS data, you can get the raw location codes. 475 00:34:25,110 --> 00:34:30,470 And the TMC messages are usually sent by private 476 00:34:30,470 --> 00:34:34,100 radio stations. The fun thing is, 477 00:34:34,100 --> 00:34:37,740 that you get both the unencrypted location 478 00:34:37,740 --> 00:34:40,550 codes and encrypted location codes. 479 00:34:40,550 --> 00:34:42,580 So if you listen to two radio stations in 480 00:34:42,580 --> 00:34:46,920 the same area, you can actually cross-correlate 481 00:34:46,920 --> 00:34:50,719 these and try to figure out the key. 482 00:34:50,719 --> 00:34:52,480 And the other thing I wanted to say: 483 00:34:52,480 --> 00:34:55,719 If somebody is just interested in RDS, 484 00:34:55,719 --> 00:34:59,480 there are relatively cheap usb sticks that 485 00:34:59,480 --> 00:35:01,290 will do all the decoding for you. - 486 00:35:01,290 --> 00:35:09,010 Oona: Yeah, FM Radio sticks. 487 00:35:09,010 --> 00:35:14,950 Mic: Is there any book you can recommend in getting started for processing 488 00:35:14,950 --> 00:35:17,110 of digital radio transmissions. Oona: Well, 489 00:35:17,110 --> 00:35:21,380 I've read a few chapters of the - I don't know 490 00:35:21,380 --> 00:35:23,990 the name actually - but the DSP [?] guided 491 00:35:23,990 --> 00:35:28,160 commerce[?] - The engineers guide to DSP, 492 00:35:28,160 --> 00:35:33,410 It's a blue book, thats all I know. 493 00:35:33,410 --> 00:35:39,020 Its freely available online, try it with google. 494 00:35:39,020 --> 00:35:46,280 Mic: Thank you. Herald: Any more questions, 495 00:35:46,280 --> 00:35:50,565 or from the internet? Nothing right there. 496 00:35:50,565 --> 00:35:52,170 Well, Oona, thank you very much. 497 00:35:52,170 --> 00:35:54,229 That was a very interesting talk, 498 00:35:54,229 --> 00:35:56,188 and we look forward having you next year 499 00:35:56,188 --> 00:35:57,728 with more signals. 500 00:35:57,728 --> 00:36:02,124 *Applause* 501 00:36:02,124 --> 00:36:11,722 subtitles created by c3subtitles.de