 talk to you about hacking train tickets in the UK. They're a bit different from train tickets in the Netherlands. You have chip cart. We don't. We have magnetic stripe things that look like this. I have quite a lot. So that's what we're talking about here. Who am I? So I'm a site reliability engineer at Worth. We have a Dutch office and a Reading office. I do lots of hackathons and stuff. I still have come to MCH 2022 in here from the EMF slide deck. Obviously, we're all here at MCH 2022, so I should remove that. And I also like design systems. So the things that you see, particularly around NS, they have a really strong design system. We don't have that in the UK. It's a bit rubbish. Everything looks a bit weird on the railway network. So why are we talking about hacking train tickets? So back in 2016, it was a long time ago, I read this article about people that were forging rail tickets. And I thought that was kind of interesting. If you can make your own rail ticket, season tickets are expensive in the UK. It's maybe 5,000 pounds, 8,000 euro, for a yearly season ticket. That's not uncommon. So if you can make your own, that's quite interesting. And if you can write the mag stripe, that's even more interesting. But it turns out that's not what they're doing. They were just printing the thermal prints on the front. So they would take it, put it through a thermal printer, Photoshop, nice. It won't go through a barrier. And that's not so exciting. So how do we write the mag stripe? Well, we can FOI transport for London, who have lots of gate lines and are a public authority. So you can use the Freedom of Information Act and ask them what's on the mag stripe, what's the specification. But they didn't want to say, because they felt people might copy them, which, in fairness, is fairly reasonable. So we have to work it out ourselves. So the agenda for today. We will do a bit of history, just because I spent a long time in the National Archives working at how all this worked. We'll have a little look at the data layout and how you actually read one of these. It's not quite so simple. And what we're doing about digital ticketing in the UK, because we don't do chip cart, as I said. Sadly, we don't do chip cart. Maybe we will in the future. But how do we do that currently? And then we'll talk about some conclusions, I guess. So these are laws in the UK. If you're going to do this, please read them, because they are relevant. And you don't want to end up getting in prison. Things like writing your own mag stripe and putting it through a barrier is apparently not legal. So I don't know. I'm not a lawyer. This talk isn't comprehensive. It's my own opinion. Please don't see me. So the history. If you don't know about the UK railways, it's all a bit weird. We had private companies. Then we had public companies. Then we have privatization again. And now that's all gone wrong, so they're nationalizing it again. We're sort of looking in the periods between 1948 to 1994, which is when these tickets were sort of designed back in the 70s. That's where the magnetic stripe comes from, the 1970s. It hasn't changed. And that's really part of the problem. Before the 1960s, before British Rail, we had these. So these were like you go to a station, you buy them, they're pre-printed, they have a serial number. But the station would just have like a massive rack of them and they would pick one off. There's no accounting. Accounting is done manually in a ledger. They write it down, which tickets they sold. It's not great. They were still using this in the 60s, even when there was some computerization. And it became a bit of a problem. So what they did do was they made it look different. They redesigned it. They didn't change anything else. So we went into the late 60s, early 70s, using tickets that were completely untraceable. The only method of security was they collected them back at the end. So if you kept your ticket, you could have another ride, which wasn't so great. And this actually continued well into the 80s, because as we'll see, the computerization was not quite so simple as they thought. But we did start to get some computerization in the 60s and 70s. So they started to look a bit like this. So these are printed by computers. They are mechanical computers, though. So they're printing very limited information, and they are doing some sort of tallying. So they collect some information about what ticket they sold, where it was sold, that kind of stuff. And then it still goes into manual ledger reporting, gets sent off to an office. They work out how much money they've made, all that kind of stuff. Still not great. And one of the real problems here was that everyone was using a different system. So you can see two types here. We have another two types here, all of them different. These all come from a ticketing manual, by the way. It's quite thick. They had to have an entire manual to tell people how to read the tickets, because there were so many of them. And we have even more here. So a huge number of tickets, huge number of systems that kind of dealt with them. And they were all going a bit wrong. By the time we got to the 80s, these machines, they were mechanical. Some of them were sort of electromechanical as well, but they were not doing so well. They were starting to fall apart. The manufacturers didn't want to support them. So the British Rail, as it was then, the train company, wanted to sort that out. So they came up with a list of all their printers they had. As you can see, quite a lot of different printing machines, quite a lot of different companies. Well, I guess four companies. And quite a lot of machines. They managed to introduce computers in other parts of the rail network, so managing the trains that ran around and all that kind of stuff. But they hadn't managed to do it for ticketing. Ticketing was still too much of a problem. So British Rail decided to do something about this. And they started an experiment. And it's called Intis, intermediate ticket issuing system. No one really knows a huge amount about this. There isn't very much about it in the archives. But some of the tickets do still exist. So they look like this. And these are fairly similar to the tickets that we have today, like this. And this is back in the 70s. It hasn't changed. The really interesting slash important thing is the code at the top right, 8355. That's called a national location code. This is a database of locations, obviously. It also includes other weird edge cases, but it is essentially a list of offices, so places that could issue tickets. And they all had a full digit code. And you can see this ticket is printed in 1984, apparently. It does have a manual here. So you can tell what everything is. Again, this comes from the ticketing manual. But this was just a piece of cart. It had no mag stripe on it. All it had was what was printed on the front. They did have a central audit functionality that they were trying out. They had a computer that was printing this, not a very advanced one, and it had a tape deck. The tape deck would get pulled out. It would get posted off, that kind of thing. It was apparently unreliable. They didn't like it. What they wanted to be able to do was have computers in all the offices. They would all talk to a central mainframe, because that was cool in the 70s and 80s. And they would not have to deal with posting tape cartridges all over the place. So they made a few hundred of these as an experiment. It was not a particularly mainstream thing. But they then decided, we have all these different ticket machines. We have all these different specifications. So surely what we need is, yeah, another one. So they made Aptis. So Aptis is the all-purpose ticket issuing system. It also has a portable version, because why not? We won't talk too much about that, because I don't actually think they made very many of them. They weren't very portable. Electronics in the 70s weren't portable. Yeah, that didn't go quite so well. So Aptis was supposed to do pretty much everything. So they would be able to take the ticket machine, put it in the ticket office. It would issue pretty much everything they sold, which was quite a lot. So you have to remember at the time, the railway company was like, they did a lot of transportation. Not just people, but also ships, also goods, also selling you food and drink, also selling you car parking tickets, all that kind of stuff. And they wanted it to all go through this machine, even international tickets. So this was actually quite a big undertaking. And they were using their knowledge from the previous experiments to try and do this properly. Not have to go back to having 50 different machines across the regions that no one understood. No one could maintain and didn't work. They really wanted auditing as well. So this is the specimen ticket for an Aptis ticket. It looks pretty much like this because it is the same specification. And this dates from the, I think this document is 1986. So, oh, it does say 1986, nice. So it's the ticket that people in the UK will recognize today. If you go to a station, you buy a ticket, you'll get one that prints out a bit like this. It won't say British Rail because the government got rid of that, but it will have all of this information on it and it will have the double arrow at the bottom. There's a comparison for you. They are pretty much the same. They also printed them in different colors because why not? And these denote different things. So Network Southeast was like a particular division and this is what you would get things like a season ticket on. You can see on the back, it does have the mag stripe on this one. We'll talk a bit about that in a minute and also like the reference number. So 4599 is the BR reference. On the back of these, it will tell you it's RSP 9599, but they are the same ticket. The future requirements was the really interesting bit. So they developed this computer system called Aptis. They made a few of them, but they had some things they wanted to be able to do. So they wanted to be able to take credit cards. So they wanted the machine to phone up the credit card company like American Express and check, do they have enough money to buy the ticket? And they also wanted to do that for checks because back in the 80s, we used checks. The 7.1.3 is issuing London Underground tickets, UIC. So being able to take your ticket, go through the barrier on the London Underground and go out the other side of London. If you've ever been on the British Railways, you'll know that most things start and end in London. So that's actually quite a big thing. And the top one, 7.1.1, was the ability to magnetically encode these tickets. And it's really interesting to think about why they actually wanted to do this because that's quite an expensive thing to do back in the 80s. You have to have the computer processing. You have to have the hardware. Mag stripe is not hugely common. It's on credit cards and stuff and on tape decks, but single-use tickets, that's quite expensive. And they saw it very much as a anti-fraud thing. Not in the sense that people wouldn't know what was written on it, but more in the sense that at that time, people were getting personal computers and personal computers come with printers. And printers can be used to print these sorts of tickets. They also thought that people might... They could use different colors on the tickets, like different color ribbons, because it wasn't thermally printed, apparently. It was a ribbon stamping through the ribbon onto the ticket. So they thought they could use different colors as well. But the main thing was just to check that it doesn't have a mag stripe on the back, because they figured people wouldn't be able to make those tickets, that they certainly wouldn't be able to write them, and that might go some way to reducing fraud. And they wanted to have these handheld verifiers as well, so you could... Someone on the train, they put it in, and it would verify the mag stripe. I don't believe that ever has existed. No one has ever bothered doing that, only at the gate line, when you get to the station. It wasn't the only reason, though. So they realized that... I know this is quite small, so you can not bother to read it. They realized that the London Underground thing was going to be a bit of a problem. So London Underground, at the time, were introducing big gate lines, and they wanted to make sure London Underground being a separate department, I guess, that people were using modern tickets. They would develop a mag stripe ticket, and it would go through the London Underground barriers. But that's all completely separate to the National Network. But the National Network still needs to use London Underground to get people across London from one terminal to another. Everything starts and ends in London. So they had to discuss with London Underground and come to some agreement. And they actually managed to get to London Underground to pay for the entire implementation of the mag stripe on these tickets. So all the software changes, they had to have a memory, they had to add the mag stripe encoder on the printer, all that kind of stuff. And they managed to get the other company to pay for it, which I think is kind of amazing that they did, but just so that people could use their tickets to cross London, I guess that's really quite important. So we come to the specification. So this is from National Archives, and this tells us actually really quite a lot of information that isn't necessarily known. I'm afraid it's imperial inches, because 1970s, 1980s. The really interesting thing about this is the data content that it tells us. So it's telling us that we have 19 bytes on there with two cock sinks. So there's some space for the cock to check that it's aligned with the data. And we have a forward direction and reverse direction and a check sum. So that's actually really, really interesting information when you're trying to actually understand what's on one of these. And the encoding density encoding standard is fairly standard, but the actual layout, how many people have a Magstripe writer that can read that, right? It's not on the edge, it's in the middle, London Underground Standard. As you can see, it has a 0.3 inch nominal track width, again, not massively standard. So very non-standard ticket, very interesting data content. So how do we read it? Well, first, we visualize the data layout. So we have a payload in the middle, the check sum I mentioned, and then the footer at the end. And some example data. So this is the interpretation of the document you just saw. So zeros at the beginning for cock sink, then the forward direction indicator, 1010, and at the footer you have the reverse cock sink and 11111. So you can put it in two ways. The machine can tell. Actually quite an important feature. So as I say, reading and writing, how do we do that? So you can't use one of these. Well, apparently you can. I'm told that people have made this work with some nasty hacks, but you can't just chop it off and stick it through a standard card reader. It just doesn't work. They're designed to read ISO standard cards, like your credit cards. They're not designed to read weird Magstripes from the 1970s. It just ain't going to work. There is this really interesting talk from, I think, about 2005, which talks about making your own with Magstripe reader with a microphone input. So you get a read head, you plug it in, you stick it through audacity or something, and out comes the data that you're looking for. You don't get a clock. In that sense, you don't get the bits that you see, so you get no clock. But this was used, I think, on the New York metro network to have a look at their Magstripe data, and it did work. But that was 2005, and I'm not sure I can be bothered with that. So I went and did some Googling. And this is the ND4020 ticket printer. It is made by Newbury Data, and it prints tickets. It also encodes them. And this is also available in eBay, quite readily, as it seems, for a hundred quid. So for a hundred quid, you can buy your own Magstripe reader, writer, it can read, it can write. It can even be extended with a massive hopper, so you can print lots of tickets. It's really quite a versatile piece of kit. And this is what it looks like. I have one of them here. This is the main board. It's a fairly standard, like, machine of its era. It's not particularly powerful. And unfortunately, the ROM is soldered, so you can't pull it off and have a look without breaking stuff, which I didn't want to do, because I wanted to use the transport mechanism that's inside it. It's a very well-made machine, by the way. So I took it along to the hackerspace, and we plugged it into the oscilloscope and put some voltages through it and tried to get it to talk on the serial, which was actually really quite difficult. There's no documentation for this thing. It's not designed to be sold to the public. You're not supposed to have it. As I say, it's readily available in eBay, but you're not supposed to have it, so there's no drivers. But you can eventually get it to talk serial. So at the bottom, you can see it's giving its version number, which is some kind of software version on the machine. So we have serial. So we can then talk to it. And it has this menu system in it. You can see the start dates around 2009. It's a Mark 2.1. And you can go through all of this. So it's got loads of cool stuff, like being able to set the clock, being able to read all of its registers. I'm sure really useful information. And the really interesting thing on this is being able to just write stuff into different registers. This is designed to be a printer. It's designed to interface with other software. So it's not designed for random people who don't have the drivers to just show up and tell it which bit of the memory you would like to write. But you could dump the entire memory location, which gives you all of the data that's in there, which is kind of interesting until I accidentally overwrote it, but I guess we can OCR it. But we don't know what any of this means. You can, I did try and have a look at what all the hexes, it doesn't seem to be anything particularly readable, unfortunately. So what we did try and do was put some random stuff through the execution. So you can execute a script on this. You can tell it, I want to execute a memory location. I want to print something. Unfortunately, that resulted in the entire thing crashing. It didn't like that because I guess we did not give it a valid function. We didn't write valid data. So I did some Googling, and the way this probably works with something called Pectab, it's a kind of markup language for airline tickets and stuff, they have some templates, they fill it with some data, they load it into the machine, and they execute it, as I say. I don't have any of that software, I don't know how any of it works. I did try and decompile some stuff, but again, it's not really very readily available. So the alternative approach is to make the machine think that you're just putting a ticket through and take the data raw off the Magstripe bus. So it's a 12-volt system, so you can just feed the motors here with 12 volts and stick a ticket in that end, and it will just run the transport mechanism when you have it turned on the right way. If you turn it on minus 12 volts, it will go the other way back. And that means that you can then get some data out because as you can see, we have some patch leads into the Magstripe reader output, and as long as it's connected to the main board, and you get the main board to the correct voltage, so it starts, it will do some magical stuff to initialize this daughter board in here, which has the reader, and you get data, which looks a bit like this. So that is looking kind of useful. We can see at the top we have the clock, at the bottom we have data, but again, how do we get that off in the oscilloscope? The oscilloscope is not very useful for 192 bits of Magstripe data. There is something called the screen capture for the Rigel scopes. It does work quite well, it gives you this, a massive CSV of voltages, but that's actually really quite difficult to interpret. What you're looking for is to align the rising edge of a clock with the rising edge of a data byte, and then the falling edge of a clock with the falling edge of a data byte. Actually quite difficult to do, and you end up with data that looks like this. It does not look like the data that we expect is not 192 bits, and it definitely doesn't really have any pattern to it. It's fairly random. This was also the point where I accidentally misread at the back of the machine, the ticket printer, and put 240 volts AC into the 24 volts DC. So it went bang quite loudly. Made a lot of magic smoke. But luckily as I say, these are readily available on eBay, so no, you can buy another one, which was the one I was holding up a minute ago. And do it again. So this one does actually have ROMs that you can take off. It's a slightly older one. It has bodge wires on the back, so I guess they're fairly low volume. And with a bit of faffing around with the microbyte at CircuitPython, literally all it does is it just checks for rising and falling edges. It's just much easier to do it on an embedded device than with a CSV of screen capture data from the scope. You can actually get data that looks about right. So this is ticket data from a random ticket that I put through. You can see that we have the coxsync bikes. We have a start forward indicator, 1001, and the reverse we have zeroes and four ones. Nice, looks good. So what I did is I put a load of travel cards through it. So a travel card is like a type of ticket in the UK. So I put them through, and you can see they kind of align, right? So we're obviously getting valid data now. You can see where stuff has gone wrong. That's, I know, the code on that is not particularly great. Sometimes it goes a bit too slow, bit too fast. Yeah, sometimes you get bad reads. But you can remove those. You can identify them fairly easily. And then you can start doing some comparisons. So here you can see, at the very bottom, we have two tickets from so Reading to Hook, they're like towns in the UK, and Hook to Readings. And you can see that one of those strings, those substrings, this is truncated obviously, is repeated in the data. It's not repeated anywhere else in that string. But that looks kind of like a start and an end. Like where I would start my journey, where I would end my journey. So presumably the Reading, that means Reading, and it's transposed there to say you're coming back. Because it's a return ticket. They're two separate tickets. And you can see here, again, we have, this is a different ticket here from Oxford. It's a return. And again, you can see in the return field that the Reading part is again set similarly. So it looks like we can actually read data. And it looks like it is actually valid data. Which is really good, because these are really difficult ticket stories, as I mentioned. And again, the inverse is true. So what do these bytes actually mean? So on the left, on the far right, you can see the national location codes for those stations. So three, one, four, nine, some zeros is Reading, et cetera. Those are the substrings extracted from some tickets. I don't quite know how they map. I think they map in some sort of proprietary way. But we will work that out at some point in the future. And when you look at this on a sort of bigger scale, looking across the whole data, you can definitely start to see patterns. I don't think this comes out very well, but the green block is all set to zeros, and the red block is some valid data for the type of ticket that they are. When you sort of start to look at this across tens, hundreds, thousands of tickets, it's actually really easy to start seeing the patterns here. And it is probably possible to reverse an engineering quite a lot of exactly what this data does. So what did I learn by doing this? This is not encrypted. It is raw data, which isn't surprising from the era. They didn't really do encryption, and there wasn't really a huge need for it. But there is this checksum. So as I mentioned at the end, there is a checksum for data validity purposes. We don't know how to calculate that. It's not public. I guess if you get enough tickets, you can work out how to do that. But it's not something that currently is public, or particularly public knowledge. As I say, pattern matching is really, really doable when you start getting a huge number of these tickets. And you could start to actually, as I say, probably reverse engineer what is going on. The ticket printers should not be on eBay. I think that they are fairly controlled items. I don't quite know how they're ending up on eBay. But when you have one of these, it is possible to just use it to write these really obscure tickets. You can just get one, read it, and write the data to another. And if you know, say, something like a season ticket, which is valid for a year, you could duplicate that on one of these. Fairly easily. It's not difficult. You don't need to know what the data is to duplicate one of those. So I don't think these should be ending up so easily on eBay, because it would make duplicating tickets really quite not difficult at all. Of course, you can't change the data without knowing how to recalculate the checksum. But that's not always a requirement. And yes, 24 volts DCN does not mean mains voltage. That causes bad things. So what can you do next with this? So if you get loads of data, you could do a better job of reverse engineering it. I did this in a couple of weeks before EMF. And then after EMF, I did planning for MCH. So I haven't really done anything else with this. The thing like the data clock alignment is a bit of a problem. It's a bit sketchy. It sits in random bytes every so often, because it's not really very advanced. Things like blast and faster, they're used for bioinformatics. They can definitely be used to align some of these strings, and particularly substrings. So when you're searching 2,000 rows of data, you should be able to use those tools if you can work out how to load the data into it in the first place, pretending it's like DNA. You should be able to use those to speed this up a bit. Dumping the ROMs is something that's on my list to do. It'll be really interesting to see the software that's on this and how exactly it's supposed to work. Again, there's no documentation for it. And writing these tickets. As I say, you can use these to write the tickets. I haven't done it yet, but it should be pretty easy. It has the hardware there. You just need to reverse the process of reading it. I have like five seconds left. So things like ISO, Itso, and eTicket are the supposed replacement for these. Itso has its own problems. eTicket, again, has several other issues with it. We currently don't have a replacement. The government has not decided on anything to do about this. They are still issuing orange tickets, orange credit card, Magstripe tickets. And they will continue to do so for the foreseeable future. As we can see, they are not particularly secure. And it's really quite easy to read and potentially write them now. The specification for these, I am told, floats around on the internet. So it is kind of public knowledge now. Yeah, I think this is probably a bad thing. I think someone should probably do something about it. Because these are common in circulation in the UK. You use an orange ticket for pretty much every journey. And they are now really, really quite easy and out of date. And yeah, I think that's pretty much it. Thank you. Unfortunately, there's no time left for a Q&A, a public Q&A here. If you have questions about this amazing talk by Hugh, you can look him up outside of the tent after this talk. Once again, give it up for Hugh. Thank you.