What’s on a CharlieTicket magnetic stripe

Boston’s CharlieTicket by rekha6. This image is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic license.

I recently received 4 CharlieTickets from a very helpful person on the Stripe Snoop forums and took some time to read them and analyze the data. My interest in the CharlieTicket had been sparked by a presentation from a group from MIT students on security vulnerabilities in the MBTA ticketing and security systems. Here’s what I found:

In the MIT students’ paper, “Anatomy of a Subway Hack“, they describe on page 31 some of the data stored on the CharlieTicket. Here is a space-separated example of the data fields they present (on page 30), omitting the names of the fields (which are shown on page 31):

EC901 0402AC9D 000000005B8 00C8 0150342 248 A84EBD 132 BE 1 028 0002 000000002025D0000 FD60

Their information was fairly detailed, but left out a few critical points. Where is this information stored on the card (track 1, 2, 3)? How is this information stored (ASCII, ALPHA, raw bits)?

I swiped one of the CharlieTickets I received and these are the raw bits it had:

Track 1:
0000111011001000000000000000000000000000000000000
0000000000000000000000000000000000000000000000111
1111110110000111011001000000000000000000000000000
0000000000000000000000000000000000000000000000000
000000111111111011000000

Track 2:
0000111011001000000000000000000000000000000000000
0000000000000000000000000000000000000000000000111
1111110110000111011001000000000000000000000000000
0000000000000000000000000000000000000000000000000
000000111111111011000000

Track 3:
0000111011001001000000010000010001011100111000100
0010000000000000000000000000000000000000101101110
0000000000011001000000000101111111010010001010001
0010010001011111110100100110100001001101001101101
0101110100000001010000000000000000010000000000000
0000000000000000000000000001110101111110000000000
0000001111110110010000111011001001000000010000010
0010111001110001000010000000000000000000000000000
0000000001011011100000000000011001000000000101111
1110100100010100010010010001011111110100100110100
0010011010011011010101110100000001010000000000000
0000100000000000000000000000000000000000000001110
1011111100000000000000001111110110010000

Then I converted the bits into hexadecimal using GNU bc by entering obase=16 then ibase=2 and pasting in the binary string. This could also be done using the Hex and Bin options in the scientific modes of gcalctool or the Windows Calculator. Here’s what I got:

Track 1:
0EC800000000000000000001FF61D9000000000000000000003FEC0

Track 2:
0EC800000000000000000001FF61D9000000000000000000003FEC0

Track 3:
0EC901045CE210000000005B80064017F48A248BFA4D09A6D5D01400010
000000000EBF0000FD90EC901045CE210000000005B80064017F48A248B
FA4D09A6D5D01400010000000000EBF0000FD90

Here we see that Track 3 starts with EC901, just like the data the MIT students collected (shown above). This suggests that the data they collected comes from Track 3, answering my first question. Less interestingly, we see that Tracks 1 and 2 contain the same data. In fact, the data on Tracks 1 and 2 is the same on all of the 4 cards I tried so it is probably not card-specific information. So Track 3 is the most interesting one for us.

If you look more closely at Track 3, you will see that it actually contains two copies of the same information. So we will just take one of those copies and analyze it, breaking it into the same fields the MIT students used:

My card:
EC901 045CE210 000000005B8 0064 017F48A 248 BFA4D0 9A6 D5 D 014 0001 0000000000EBF0000 FD90

MIT students’ card:
EC901 0402AC9D 000000005B8 00C8 0150342 248 A84EBD 132 BE 1 028 0002 000000002025D0000 FD60

The data seem to be in the same format so I’ve answered my second question: the data is stored in raw bits on the card and was converted into hexadecimal for presentation in the MIT students’ paper (pages 30 and 31).

Looking at the paper, we see that the second field should be the ticket number. Converting 045CE210 into decimal gives me 73196048, which is indeed the number printed on the front of the card in the lower right-hand corner (with 00 prepended).

Some interesting next steps would be to figure out the checksum computing algorithm, which is alluded to in “MBTA published checksum info in court filings“, and to determine how the time is represented in the time fields.

In case you’d like to take a look at the data yourself, here is the complete data from the 4 cards I have, listed by card number:

Raw bits:
0073196048
0073196049
0073196050
0073196051

Hexadecimal form:
0073196048
0073196049
0073196050
0073196051

All files:
charlieticket_00731960_data (1864 bytes)

The MIT students’ paper is linked from MIT’s newspaper article about their DEFCON talk.

If you want to read magnetic stripes yourself, you can connect a magnetic stripe reader to your computer using my “USB magnetic stripe reader instructions” article or Stripe Snoop‘s Hardware page. Help and magnetic stripe reading discussion can be found in the Stripe Snoop forums.

If you can wait a couple months, I will be selling a USB magnetic stripe reader based on my “USB magnetic stripe reader instructions” article. If you send me your e-mail address via my contact form, I will notify you when it’s available for sale.