summaryrefslogtreecommitdiff
path: root/pages/hackabike.en.md
blob: 2e77948b15ae903f9f555da1091dfc1d5f6294d6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
title: hackabike
date: 2009-11-02 01:04:00 
updated: 2012-02-19 18:24:46 
author: erdgeist
tags: deutsche bahn, hack, bike, call, avr, hackabike
previewimage: /images/01.jpg

Ever needed to get somewhere quick but you had no car, too late for public 
transportation and a bicycle could solve your problem? In Berlin and other 
big cities in germany the german railway company 'Die Bahn' offers a solution 
with the "Call-A-Bike" service. Read about the backdoor we put into nearly every 10th bike,
which gave us all the free rides we needed.

<!-- TEASER_END -->

## **Short introduction to the CallABike system** {#short-introduction-to-the-callabike-system .notification}

The customer calls the CallABike control center and transmits the four
digit bicycle number via touch-tone. Another four-digit number, the
rental code that opens the bike, is then submitted by the control
center. The customer gets a verification call after his initial
transmission which he doesn't have to pick up. The last four digits of
the calling number are the rental code again.\
\
From now on you have to pay six Eurocents per minute (customers with a
discount card issued by the german train company Deutsche Bahn only pay
four cents). The bike can be parked and locked while shopping or
visiting a restaurant by selecting 'don't return bike yet' in the menu
of the lock box at the bike's rear wheel and opened again with the
issued rental code you received initially - this procedure can be
repeated indefinitely. The bike meter keeps running of course.\
\
Returning the bike is easy as well: the customer simply has to lock the
bike and select 'return bike' on the menu - the bike now gives you the
return code, which you have to submit to the control center via phone,
to prove that you really locked the bike. Additionally, you have to
leave the address of the street corner where you parked the bike on the
answering machine. This ends the period of rental.\
\
It's also possible to rent or return up to four bikes with one call at a
time. If there is no bike near you, you can call the control center to
ask for the next bike. A call center agent then consults the
CallABike-database and submits the location of a nearby bike.\
[Company Summary in english](http://www.callabike.de/i_english.html)\
\
"...There are of course other people, which have, for sportive reasons,
tried to test the robustness of the hardware or the electronic principle
of the built-in microchips and processors. They tried their luck with
screwdrivers and usual ordinary allen-wrenches. they even tried to use a
crowbar, a sledge hammer or a motor angle grinder. or totally smart:
with a laptop and some decrypting-tools, as well as some trick questions
to the maintainance staff. but without luck!". again reth is smiling,
who once took the first trip on a green puky-bike and looks at himself
no more as a postmodern urbanite than as bicycle freak. he smiles and
says: "this technology makes us to the premier station-independant
city-bike-sytem. the code is unbreakable and we are really proud of"...
An excerpt from a DB technician interview in the Mobil Magazine which
featured the CallABike.

## Article:

In November 2003 a bike reached us that hadn't been locked properly.
This bike was subsequently objected to heavy testing. Most of us had
suspected the existence of GPS or a similar tracking device in the lock
box, but after opening it with a simple torx screwdriver, nothing like
this could be seen. To power the electronics, three 1.5 V batteries are
provided in another box on the other side of the rear wheel. Both boxes
are connected through a clamp, containing a six-pole power cable and two
coils. This detects if the lock was closed properly by the last customer
using the bolt, or just a generic piece of metal.\
\
The box with the display contains the motor that opens the lock, two
micro switches and a capacitive 5x2 touchpad. The main logic board is
located directly under the display. It is secured through a metal plate
which has openings only for the cables connecting it to the display. The
electric motor with its eccentric shaft and the locking mechanism are
thus protected from a brute force attack on the display.\
\
The whole board is dowsed in black silicone which had to be scraped off
before we could continue exploring. Apart from the matchbox-sized logic
board which incorporates an [Atmel
AT90S8535](http://www.atmel.com/dyn/products/product_card.asp?family_id=607&family_name=AVR+8%2DBit+RISC+&part_id=2000)
(8-bit RISC Processor, 4x8 IO-Pins, 8KB flash, 512 bytes EEPROM and 512
bytes RAM), a few red, green and IR LEDs and an IR-receiver, the box
also contains a few electrical components (motor, switches and a
beeper). There is also a slope sensor, but it is never addressed in the
code. With this simple setup, it became clear that the bike couldn't
possibly contain a device to track or locate us. We made a few pictures
of it all, but then the hardware went into a corner for about two months
before we managed to boot the bike. It took us a while to notice that
the system had to be initialized by an IR-signal after booting. This
discovery was more or less coincidence.\
\
Our workplace was lighted by a normal lightbulb. We noticed that the
device seemed to be beeping erratically when subjected to the light. As
we discovered later, the IR part of the emitted light was sufficient to
trigger the IR-receiver and finish the booting sequence. Receiving an
IR-signal while booting is a part of the systems check that happens
during every booting sequence of the electronics. In the process of
professionalizing our research, the light bulb was replaced by an
infrared photon light. The next steps of our analysis consisted in
reverse engineering the Atmel chip to get an approximate wiring scheme
(see picture). The data sheet for this Atmel chip was found on the
Internet.\
\
It wasn't until January that one of us finally thought of a way to carry
on with hacking the bike. We had noticed an unused six-pole plug that
turned out to be the Atmel's ISP (In System Programming) connector. This
connector was plugged into an Atmel-Developer-Board
[STK500](http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735).
For reading the data we used the free
[UISP](http://savannah.nongnu.org/projects/uisp/) (a tool for AVR
microcontrollers which can access many hardware in-system programmers).
Since the 'Intellectual Property' lockbit of the Atmel was undefined, it
was possible to read out the 8KB firmware of the flash.\
\
The next few weeks were filled with understanding and documenting the
assembler code obtained from the bike. For this purpose we used AVR
Studio and [IDA Pro](http://www.datarescue.com/idabase/). We recognized
the initializing code because we knew the motor was turning twice during
initialization. The scramble code (that calculates the rental and return
codes) was also found pretty quickly, because it featured a lot of
rotate and shift commands.\
\
Our discoveries were always checked for correctness on our prototype.
The rental and return codes are generated by a scrambler, which is
called upon by a 16 bit counter of the bike and a current-state-value.
An even counter value generates the rental code, an odd value the return
code. The scrambler uses the counter and the current-state-byte to
calculate an offset on a 1024 bit array. This array is unique for every
bike which can (possibly) be called an explicit identifier for any given
CallABike. From this offset, 4x4 bit are used to represent the four
digits of the rental and return codes respectively. The counter's 16 bit
are used unwisely though, because the calculated codes repeat themselves
after only 1024 iterations. This results in only 512 different rental
codes per bike, because there are only 512 even offsets that can point
to a key (1024 bit).\
\
Bikes that had been opened by us but couldn't be read out because of the
lockbit being set were reset 511 times with the help of a script (the
reset increases the counter by two). This restored the original
condition and the bike was again 'in sync' with the control center.\
\
The character set of the display is proportional to its size. For this
there is a table in which character length and position are saved in the
flash memory. An 'i' and an 'l' use only one byte, whereas a 'w' uses up
seven bytes. The big logos and the input matrix are available as 400
byte bitmaps. The big black line in the CallABike logo symbolizes the
field intensity of the coil in the lock. This we found out by code
auditing.\
\
Our primary goal was to adapt the source code coming from our
disassembler to the original binary, so that after assembling it with
the tool [Avra](http://avra.sourceforge.net/) (Assembler for the Atmel
AVR microcontrollers) we would get a binary exactly identical to the
original.\
\
On the basis of this reference, we could finally begin to make changes
and start to flash the bike with our own code. We couldn't find any
vulnerabilities or backdoors which could be used to exploit the device
without unscrewing it (every bike has its own key saved in the EEPROM),
so we conceived the idea of programming our own backdoor into the code.
Sounds easy, but wasn't really.\
\
First, we had to optimize the original code to create the space for the
insertion of our backdoor code, since we also wanted to add our very own
HackABike logo as 400 byte bitmap to the 8kb flash memory. The garbled
code which can still be seen above our new logo is the backdoor code.
This alone saved us about 150 bytes.\
\
We decided that it shouldn't be possible to 'steal' parked (locked but
not returned) bikes from paying customers with the backdoor code. This
required a few more lines of code. We also ascertained that with the
backdoor code it's not possible to park a bike, because the user knowing
the backdoor wouldn't pay anything and would therefore not be motivated
to take care of the bike (for example not locking it properly), thus
preventing paying customers to rent the bike. To differentiate a
HackABike from its untreated fellow bikes even from afar, we taught it a
different blinking sequence and removed a sticker on the lock box.\
\
During our further analysis of the code we discovered that a bike can
transmit several status messages, depending on its technical condition,
to the control center using its return code. It can inform about its
dying batteries, for example, or about its motor not being in the
correct position for the lock anymore. After the lock button being
pushed seven times without the clamp being inserted beforehand, a valid
return code is generated which nonetheless commits the information about
an unsuccessful locking event to the control center.\
\
All in all there are 52 of those codes (a matrix of 4x13). The backdoor
allows to open a modified bike with a certain rental code assigned by
us. After locking and thus returning the bike, it is again rentable by
paying customers. Even the rental code of the paying customer before
shows up on the display. The control center won't notice the backdoor -
apart from the fact that the bike surfaces at another part of the city
than indicated in the database. After a paying customer has rented and
returned the bike, the database entry for this bike is corrected again.\
\
To transform a CallABike into a HackABike, we had to unscrew six screws
on the inside of the box containing the display and plug the STK500 into
the ISP-connector of the logic board. After that we started a script to
read out the flash and the EEPROM area. The EEPROM is then again flashed
with a reset counter and the code including our backdoor. To ensure that
nobody could discover our tampering by reading out the firmware again,
we set the lockbit. It took a practised hacker about 12 minutes to turn
two CallABikes into two HackABikes at the same time. We flashed nearly
10% of the 1700 bikes which are distributed in the city of Berlin.\
\
UISP didn't support the setting of the lockbits correctly at first, so
we had to put that in before we could continue. To do this, we sniffed
the AVR Studio output with a serial sniffer, looked for the
corresponding commands of the STK500 and put this into the UISP code.\
\
Finally, we have to admit that the technical design of the CallABike is
very good. The only way to tamper with the bikes is probably the route
we chose, namely to open and reflash the EEPROM. The only thing that was
missed was to set the lockbits that prevent the firmware from being
read. Our attack is probably worth the purchase price of a few dozen of
these CallABikes, seeing the time and manpower that went into
accomplishing it.

    EEPROM Content:

    0x0000 - 0x0001 unused
    0x0002          lock_sensor_calibration
    0x0003 - 0x0019 unused
    0x001A - 0x001B 16bit counter (scrambler)
    0x001C          unused
    0x001D - 0x001F CallABike Number
    0x0020 - 0x009F 128 Byte Random (Key)
    0x00A0 - 0x00A2 first three bytes of key again
    0x00A3 - 0x00AF unused
    0x00B0 - 0x01FF textmessages for display
                    

    bikecounter: 0x015E
    EEPROM belongs to bike 3856

    Counter 0x0162:  3042 9843 5360      <-- rentcode

        -00- -01- -02- -03- -04- -05- -06- -07- -08- -09- -10- -11- -12- -13-
    00: 8584 7572 6970 4597 9119 4285 2144 0277 3197 0072 5545 6487 6341 9664
    01: 5244 2345 5463 6065 9493 2971 9352 5402 5519 4579 8355 9533 9245 4926
    10: 6615 7508 8159 7355 8125 3632 2920 4348 0484 7784 0084 6154 8905 6742
    11: 6234 7953 4741 7386 8181 2930 6280 8658 6805 5432 4092 7161 2070 8554

    Counter 0x0164:  7240 7043 9766      <-- rentcode

        -00- -01- -02- -03- -04- -05- -06- -07- -08- -09- -10- -11- -12- -13-
    00: 1542 5463 4821 7206 8181 5293 5100 8370 7662 7831 6561 1071 9350 7554
    01: 8480 7640 5094 4420 7470 5025 6472 0596 9260 5499 4274 0341 7092 7363
    10: 6369 3545 6991 9042 0121 7702 7931 5600 6755 8264 9063 9596 6918 8761
    11: 4254 0960 8294 7529 9793 4954 5455 9345 0183 3995 4992 5949 4392 9538

    Here you see the open and close pins of the bike 3856 with
    the counter at 0x0162
    At first the Customer gets the open pin 3042. When the customer
    closes the lock and everything is ok he gets the return code 8584.
    When for example the battery (-01-) is exhausted he gets the return code
    7572.
                    

    The following commands are possible via infrared:
    0x5B read bikenumber
    0xCE calibrate coil
    0xC5 read RAM from 0x00AD

    after transmit of the first 32 bytes of the key
    0xCA enable watchdog (reboot)
    0xC8 write and read the key of the EEPROM
    0xCD write and read other parts of the EEPROM
                    

    //code to generate the open and close pin

    unsigned char g_key[4];

    void scrambler(uchar param, long counter)
    {
         long bitoffset;
         uchar r21 = param, r28 = 1;
         short r27_26 = counter, short r31_30;
         r28 <<= r27_26 & 7;
         r27_26 += r21;
         r27_26 &= 0x3ff;
         r31_30 = r27_26;
         r27_26 <<= 5;
         r27_26 -= r31_30;
         r27_26 &= 0x3ff;
         r27_26 += r28;
         r27_26 &= 0x3ff;
         bitoffset = r27_26 & 7;
         r27_26 >>= 3;
         r27_26 += 0x20;
         r27_26 &= 0xff;
         fillkey(r27_26,bitoffset);
    }

    void fillkey(long address, long bitoffset)
    {
         uchar r16;
         long fullkey;
         fullkey = eeprom[address++] << 16;
         fullkey += eeprom[address++] << 8;
         fullkey += eeprom[address++];
         fullkey >>= bitoffset;
         r16 = fullkey          & 0xf;
         if(r16 >= 10) r16 -= 10;
         g_key[3] = r16;
         r16 = (fullkey >> 4 ) & 0xf;
         if(r16 >= 10) r16 -= 6;
         g_key[2] = r16;
         r16 = (fullkey >> 8 ) & 0xf;
         if(r16 >= 10) r16 -= 10;
         g_key[1] = r16;
         r16 = (fullkey >> 12) & 0xf;
         if(r16 >= 10) r16 -= 6;
         g_key[0] = r16;
    }

    //the key from CallABike 2883
    unsigned char eeprom[ ] =
    {
        0x5A,0xD5,0xAD,0x6B,0xFD,0xD7,0x34,0x78,
        0xB3,0x03,0x22,0x13,0x61,0x23,0xAD,0xFE,
        0x51,0x6E,0xAA,0xA2,0xD4,0xB7,0xBA,0xC0,
        0x78,0x9A,0x84,0x55,0x2A,0xB9,0x6E,0xBC,
        0x33,0x15,0x2C,0x97,0x33,0x98,0x4B,0x78,
        0x43,0xE5,0x20,0xD5,0x1C,0x1C,0x75,0x12,
        0x2A,0x91,0x17,0xFC,0x0C,0x61,0x31,0x31,
        0x50,0x6D,0xFD,0x5C,0xC5,0x60,0x8D,0xE0,
        0x0A,0xF2,0x85,0xF1,0x3B,0xA3,0xBD,0x74,
        0xF3,0xD4,0x9E,0xBB,0x45,0x95,0x69,0x24,
        0x79,0x36,0x9A,0xA6,0x66,0x96,0xFB,0xE8,
        0x5D,0x38,0x34,0x28,0xC0,0x51,0x3B,0x18,
        0x46,0xCA,0xD9,0xE3,0xD7,0xC8,0x86,0x01,
        0x11,0x60,0xF2,0xF0,0xA4,0xA4,0xEF,0x16,
        0x3E,0xBE,0xB9,0x1F,0xA8,0xF9,0x61,0x0B,
        0xD6,0x7F,0x75,0xE7,0xF4,0x31,0x3F,0x6B
    };