Decoding the MetroCard, Part 2: Research and Past Attempts | Hacker News Reader

Decoding the MetroCard, Part 2: Research and Past Attempts

blog.woodruffw.us

50 pointscodezero38 comments

This post actually puts to rest (and confirms) a theory that my coworker had when I thought I had a truly unlimited metrocard.

Basically, I bought an unlimited monthly pass from a machine. By the third day of using it, I noticed that every day I used it, the expiration date displayed at the turnstile would advance a day. Obviously, I thought I had somehow become the owner of the golden metrocard that would work forever (I was admittedly optimistic, hoping it would be true).

Several days later, when I had confirmed that it wasn't a fluke and shared the story of my fortunate acquisition of the "golden metrocard" my coworker suggested that perhaps the expiration date stored on the card was null, and the default behavior of the turnstile was to always show an expiration date 30 days out.

Sure enough, when thirty days passed, the card stopped working, and I apparently blew the booth attendant's mind when I asked why the card wasn't working (something about a negative balance or some such, she'd never seen such a thing before).

My coworker was absolutely right, the expiration date was cached on the card (as a null or some other invalid value in this case) and it was then checked against a list of actually expired cards over the network.

Do you happen to still have that card? I'd love to see a dump of it (and line it up with known fields circa 2006 on tracks 1 and 2).

I'm afraid not. I'd intended to hold onto it, but it fell through the cracks during a move.

Oh, wow. I just came home and found this on the front page.

I'm a little embarrassed, since that post had been sitting on my drive for over a year. It's not very well written, and it doesn't do the prior research justice.

After living in NYC and now living in San Francisco, I wonder why the MTA hasn't switched to contactless cards yet similar to what Boston or SF has. As someone who has missed many a train trying to swipe my metro card, it seems like this would be an easy win for them and less wasteful than a disposable paper card.

From what I understand, not having contactless cards is the least of the MTA's modernization issues.

http://www.slate.com/blogs/future_tense/2015/07/30/convertin...

http://www.theatlantic.com/technology/archive/2015/11/why-do...

It mostly seems to boil down to budgeting woes and bureaucracy. And in having one of the oldest subway systems in the country with a ton of technical debt to deal with.

Expensive.

Expensive expensive expensive.

They would have to replace all of the turnstiles (for some reason I doubt they could retrofit them) which is a ton of turnstiles. The MTA subway is BIG (as far as I know, bigger than SF and Boston, in terms of number of stations).

They would need dedicated central servers to handle everything, unlike they have now, which the article says "complements" the existing system but which is not required for operation.

MetroCard came out over a decade before CharlieCard (Boston) so they have tons of infrastructure that would cost an absurd amount of money to replace. I imagine they figure it isn't worth it, especially when there are so many other subway projects that need money.

Central servers are not required for contactless cards. The card itself holds the current balance inside a tamper-proof secure element, and it's updated with every ride.

A central server can be used for things like web-based reloads and auditing, complementing the system... but it's entirely possible for a terminal to remain in offline-mode and just check-in at the end of the day to get any pending messages and upload logs. This is why it takes longer to reload/unblock a SF Clipper card using a reader in a bus (offline mode) as opposed to at a BART turnstile (online mode).

> ...tamper-proof secure element...

It doesn't even need to be held in anything secure, you just need to sign the balance when writing and check the signature when it's used.

If your turnstiles can't talk to a server, they can't check key revocation lists, and I tend to imagine that in a city the size of New York somebody's going to leak a key every now and again - it's been known to happen with physical keys; why not digital ones, too?

But they don't need to have a realtime revocation list -- it's fine if a broken card works until the end of the day, or even the end of the week, as long as it stops working faster than keys are leaked or cracked.

So a bus turnstile can do transactions when it returns to the garage, and turnstiles in locations where it's hard to run data for whatever reason can get a plug-in every so often on a regular maintenance run.

What's your replay attack mitigation strategy?

NYC subway system has over double the stations of Boston and San Francisco combined. All of which in a densely populated city, and operating 24 hours a day. Doing any work in NYC costs huge amounts of money. Many of the BART and MBTA are in suburban density areas as well, unlike the NYC system that does not enter suburbs or Staten Island.

>this would be an easy win

It'd be far from easy. The cost and magnitude of a project like this would be enormous for the entire subway system, and the MTA is not without bureaucracy. As others have pointed out, the subway has far more pressing modernization issues that rank higher than this.

I lived in London for several years before moving to NY this year and the failure rate of swiping my MetroCard is about the same as touch issues with my Oyster card / contactless debit card in London. While it would be a great advancement technologically, there really isn't a pressing need to replace the swipe card anytime soon.

There are definitely many advantages to contactless cards, but I'd rather the MTA focus their efforts on something with much more of a benefit. E.g., real-time train information, something that also requires a huge infrastructure change, but one that would have a greater benefit to travelers.

There's a $450 million RFP out for it:

http://www.theverge.com/2016/4/12/11416362/mta-nyc-fare-paym...

So, considering how gov software projects tend to go, it'll probably cost $1.5 billion and come out in the early 2020s.

I heard some rumors about NYC looking into buying the oyster card tech, which is used on the London tube

http://www.nydailynews.com/news/world/london-contactless-oys...

1) NYC is the biggest metro system in the world (in terms of number of stations) by a fairly large margin.

2) The MTA is a perpetually underfunded, poorly governed monstrosity whose construction projects cost many times more than any other comparable metro system.

3) The MetroCard still works, as clunky as it occasionally is.

If I remember correctly, the MTA has had a (sizable) surplus for the past few years. It's more chronic mismanagement (and graft) than underfunding.

They're working on it http://www.nydailynews.com/new-york/mta-warned-ending-metroc...

I think they'd have to get around to replacing the Token Ring network that sends this data between stations first.

The MTA spent a lot of money in the very early 90s getting the system installed only for Ethernet to take over pretty much immediately.

At least the MTA kiosks are fast and reliable unlike the VB6-ish crap running on the NJT TVMs that can't do anything but display a spinner animation if the network is degraded.

Fun fact: The MVMs (MTA Vending Machines) run OS/2 Warp/EComStation (or did until a few years ago). I've also seen some running what looked like NT 4, although I'm not certain.

Considering how old that software stack is, it's remarkable how well the MVMs run. In 19 years of buying MetroCards and riding the subway, I don't think I've ever had one break down on me. I've had my fair share of scanning errors and bad cards, but I'm more inclined to blame that on the quality of the magnetic strip and normal wear.

I don't know the language used by the kiosk software itself, but the OS used by the kiosks is definitely still Windows NT 4 - predating VB6 by several years.

Here's a recent bluescreen - only the second I've ever observed.

https://twitter.com/nycdotnet/status/750737744356319232

I used the same sources a couple years back to develop a MetroCard balance checker for iPhones. It used a cheap headphone jack magnetic stripe reader from China. Never got around to actually doing anything with it though.

Interesting! Do you happen to still have your source and/or research? I'd love to add it as a bullet on the post.

It's a good system. The fact that the hacker crowd hasn't even figured out the basics yet is amusing.

MetroCards are validated by both the station computer and the central data center. Once a card has been used, it can't be used again for 18 minutes. This makes copies of cards almost useless. There's a lot of mutual mistrust designed into the system. The MTA isn't stupid.

> Once a card has been used, it can't be used again for 18 minutes

I'm not sure what you mean. I've used mine twice in quick succession to pay for a friend.

That limit does not apply to prepaid MetroCards at the same station. What the OP is referring to is that one cannot clone an unlimited weekly or monthly card while having it be useful. They have a 18 min lock out. Using a prepaid card repeatedly will just drain the value of that card.

That's unfortunate. There were definitely times when I lived in NYC (pre-Metrocard) when I took two rides within 18 minutes (take short ride, jump out of station for quick errand, come back in for next part of journey). Are you saying that would not be possible?

Nope, that's only for the same station. Assuming you swipe into station A, exit station B, and swipe again at station B, you're fine.

If you swipe into station A, realise you got into the wrong entrance, you can usually just walk to the 24-hour booth and ask them to let you in the gate.

Also you can walk to another station.

Thanks for clarifying.

Its 18 minutes at the same station. Not that I would, but you could give it to a few close friends without it ever being an issue. You might need an additional, non-unlimited card, for when you meet up with them some where in the city.

I'm not sure whether MTA is smart enough to catch on to that or not.

     Despite being over a decade old, these slides 
     (and accompanying 2600 articles) still represent 
     the best publicly-available research on the MetroCard format.

Isn't that an endorsement of Cubic Transportation Systems'[0][1] security by obscurity work quite well in this case?

[0]: https://youtu.be/YSmqwJmKh2E?t=1833

[1]: https://en.wikipedia.org/wiki/Cubic_Transportation_Systems

I think it's worth keeping in mind that that presentation (and accompanying papers) came out in the spring/summer of 2006. Google Patents didn't appear until December of that year [0], and the USPTO certainly didn't have an online search or API back then (it does now [1]).

The information was always there, but it's only become easily accessible in the past few years. To me, that speaks tremendously towards Battaglia's research.

[0]: https://en.wikipedia.org/wiki/Google_Patents

[1]: http://assignment.uspto.gov/

Interesting read, but somewhat disappointing. I expected something like a demonstration of a card reader dumping the contents of the card, and an Arduino-controlled magstripe spoofing it. Excellent writeup nonetheless!

I actually have dumped MetroCards using a reader, but I'm saving that for a third post ;)

I take it that if you figure out you can write a stripe that overflows the scanner firmware in a way that unlocks the gate you won't post it until you're done using it...

If you're asking whether I'd exploit it, the answer is a firm no. I'm not the biggest fan of the MTA (nobody who lives in NYC for any substantial amount of time is), but the personal benefit would be minuscule compared to the consequences.

More to the point, making a public display of weaknesses in the MetroCard might finally get the MTA off their ass and onto that modernization project they've been promising for the last 15 years ;)

Reply on news.ycombinator.com