hackabike

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.

Short introduction to the CallABike system

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

"...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 (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. For reading the data we used the free 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. 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 (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
};