 Gweld i'r meddwl, yn ymherwydd. Dyna'r hynny'n gwneud o'r cyflogau sydd wedi'u gweld eu modd, yn ymherwydd ar gyfer gweld y cyflogau, nad oedd yna'r cyflogau a'r ysgrifennu yn ymherwydd. Ond nid oedd er mwyn o'r gweinidol o'r ddechrau. Oherwydd mae'n rhan o'n ddod i'r gweinidol. Felly, mae'n rhan o'n ddod i chi'n ddod i chi'ch gweinidol o phirgrifennu ymherwydd, Usually, mostly what you will, you'll probably find useful if you're trying to tackle a similar project yourself. I'd love to, if it happens to be anyone in the audience who's worked on this thing, I would absolutely love to hear from you. My email address is going to be up at the end. Or you can by all means, try and find me at the camp. So as I said a minute ago, I'm Phil Pemberton and my day job, I'm an embedded software engineer. I'r cwmenni iddyn nhw'n maen nhw'n meddwl yn y gallu'r swydd. felly rydw i llwydo'n cwmenni'n ffordd Hygrif shadow yw holl o bob cwmenni aurelchwch hyd yn haf o bob cwmno. Roeddwn i'n fwylo brydyn i'r digwydd i'r pwysig am y Cymru i'r adael dweud gallu sy'n mlynedd i unig P.C. a pwysig am y этотill taeth na'r amhwytoedd yno, pan mae'r amgylledau rydw i, a yn gallu cyflawn ar y cymaint gydyn nhw am bobl pleidio am ddano. I also do a lot of other things as well that are up on the slide there as well. Quick introduction, what is or was data track? Well the short answer is it was a land based radio navigation system. So you say navigation system, the first thing that springs to mind is obviously GPS. Which is a satellite based navigation system that works in a very similar way. The big difference with data track is it uses land based transmitters. So big radio masks, 50 watts a piece transmit power. Versus GPS it's quite hard to jam, but also it's quite an expensive system to keep up and running. It was partly why it went south, obviously GPS taking up that market. It was developed in the 1980s by Securico after a spate of armored van thefts. So obviously if you're moving large amounts of cash you kind of want to know where those vans are, where they're going, if they're still on route or if they've been taken so you can let the police know and hopefully catch the criminals that have done that. But later on it was released to the public in the form of a package called Trackback, which was notably installed from the factory in a lot of Ferraris. Before I say anything else on that the current model of these receivers doesn't use the low frequency network anymore. They're GPS and GSM. What I'm talking about today is up to about the 2010s, so 2011 when it was finally shut down. So this is the receiver. I found one of them on eBay and then the seller emailed me afterwards to say he'd found another five in his shed. So I relieved him of all six of them and then later found another one that had the return transmitter on there. So there are two radios in these. There's the long wave receiver, which is used for navigation, and then a UHF transmitter, which is used to send the location data back to the base. And then as a separate network of the UHF receivers, these base stations dotted around the country that pick up the signals from the vehicles that are transmitting. Only one of the units actually had that transmitter board and the program ROM that enables it. So it seems like there's two hardware versions. One can just do navigation and will spit the location out of the serial port every now and again. A bit like a GPS receiver, and then there's the second version, which is the stolen vehicle recovery version, the trackback version. There's actually quite a powerful device for its time in terms of CPU power. There's a 10 megahertz, 68,000, Motorola 68,000. You might be familiar with that. It was used in the Atari ST, the Amiga. It's got, depending on the hardware version, I have a 128K or 256K of RAM. Either half or all of it is battery backed again depending on the hardware version. And it has a little plug-in card, which contains the program ROM, the firmware that it runs. And it also has a little 8031, which runs as a co-processor and talks to the radio modem. It handles all the UHF transmit tasks, so the 68,000 doesn't have to deal with it. So the 68,000 concentrates on doing the navigation work, doing all the IO, and then basically says to the 8031, hey, can you send a location on the network the next time my time slot comes up? Two serial ports and then this almighty hell spawn of a custom ASIC. This thing is the bane of my existence at the minute, as far as this project is concerned. It's a TI gate array that was custom designed by Datatrack. Basically, far as I can tell, they handed the circuit diagram for this off to TI, and TI designed them a chip. It does quite a lot. So it's doing all the CPU interface stuff, all the address decoding, all the CPU signal work. It's got part of the navigation receiver on there. So the way the navigation works, I'll get on to the basics of that in a minute, but you have the local oscillator that tunes the radio. And it also has the phase measurements of a time of flight measurement. It's measuring the time of flight of radio signals to figure out where it is in the country, basically. And then just for extra measures, there's some GPIOs that can talk to a serial e-square prompt, and there's some octocoupler inputs that are on there as well that are used for things like a... There's a status keypad that could be mounted in the cab of the van, and the guy driving the van could push a button and say, I'm on my break, I'm on my way, I'm delayed, I'm stuck in traffic, et cetera. Obviously there are other companies using this than Securico, so you could have, for instance, on the way to a job, that kind of thing. So the drivers base or office can keep an eye on what he's up to, how far he is for his rounds, et cetera. So it handles those inputs. So it's a pretty interesting piece of hardware. My goal originally, when I found this thing, was to try and turn it into a PSK31 receiver for the ham radio low frequency bands. Still kind of a goal, but given the way it's designed, it's probably a bit of a blue sky goal. So when I first got this, I kind of formulated a bit of a plan of attack. I obviously powered the thing up to see if it works. There's no point putting effort into it if it's broken. I might as well break it down for spares if it's broken. But it turned out they worked. So I went on a bit of a research job, started googling around, asking people for information, trying to find people who worked on it, names of people who worked on it, found some technical papers that covered the system, then decided to go in, go out, reverse engineered the firmware, did some work on the hardware and eventually wrote an emulator for this thing. I did want to build a signal generator for it. I've got an Arduino hooked up to an analog device's DDS chip, sat on my desk at home. Unfortunately it doesn't quite work. The signal quality isn't quite good enough for the locator to lock onto. So first step, hook it up to power. Does it work? It turns out it was dead easy to work out the pin out. It's a free pin XLR plug. It's got ground which connects to the case. So that's nice and easy to find. It's multi-meter to the case. There it is. So there's two remaining pins. One of them is going to be power. One of them is probably going to be the ignition signal to tell the thing to turn on and off. You obviously don't want this thing running while the engine isn't running because it will run the battery down. Cheetah's way, connect both of them to 12 volts. It works, but it turns out that they're colour coded. Red is 12 volts, white is. The ignition switch. Did a little bit of signal tracing. There were two Max 2.3.2 chips. As soon as you see one of those, it's like there's a serial port here. The serial port pin out doesn't match a PC pin out, but it turned out to be easy enough to figure out what was going on by watching it on a source scope, by following the tracks and buzzing it out with a multi-meter. Eventually it got what's on screen there out of there. So it's booting up, identifying the software version and doing some basic kind of setup. The LP line, incidentally, it actually records the last position. It's found itself in my powers on, and there's an Ordnance Survey grid coordinates, so the Easting and Northing, which is as it turns out what it uses entirely internally. So there's a command line there. The obvious thing to do is hit enter a few times, and it just says eh, which is short for... I don't know what that command is. It's your bad command or file name. So I figured I'd ask it for help, which they removed to save space in the ROM. It's not going to be that easy. So I did a bit of research. It seems like the designers of this system were quite proud of it because there are about half a dozen research papers I found on IEEE Explorer and other places, talking about the network, how it's put together, the data that's flowing around, how it works, how it does navigation fixes. Obviously not in the level of, like, it wants this signal and it wants that signal, but there's a high-level technical overview that's really useful for trying to figure this thing out. And they tell you a lot in those papers. A lot more than I would have expected for something that is supposed to be monitoring the movements of armoured cashfans. Yeah, no. So I dropped a post on a couple of forums and mailing lists. Asked if anyone had any recordings of the data track signals. Turned out a few people did. Ham radio community seems to like listening into things. They were mostly recordings of the ham radio bands, but people had done, like, 200 kilohertz full spectrum captures and got the ham LF allocation plus quite a lot of the whole long wave band. So these contain the data track signals. I've not managed to decode any of them yet. If you're good with the new radio, I'd like to talk to you because maybe you can help me. But I've got the recordings. I've got the documents that explain what the modulation looks like. I know what the receiver... At this point, I know what the receiver is expecting to see on the radio input. So I can kind of power it on. I can generate something like that, and it kind of locks and then complains that the signal isn't good enough, which is kind of true. But nobody had any actual hardware information on this thing, which is kind of to be expected when it was designed in 1993. Or at least a firmware version is 1993, sorry. It's quite an old thing. It's about 30 years. People are going to forget, and these documents probably don't even exist inside of the successor company to Data Track anymore. When it was up and running, the network was 13 transmitters, covered 95% of the road area of the country with a typical accuracy of 50 metres or better, but a worst case of 100 metres. Basically what it's doing is a time of flight measurement. You have two transmitters. One transmitter sends a signal, the other one receives it, and then sends its own signal back. What the receiver is doing is measuring the difference in time of arrival between them. If you have a receiver on this line here moving left and right, you see that transmitter A or B is getting a little bit closer, and that's the measurement. And you get these, you see the red and green lines on the graph, on the chart there, are the lines where you get this, the same time of flight measurement. So what you do is you do the time of flight measurement for two transmitters, and then you add a third transmitter, and you've got the green lines versus the red ones, and they intersect, and you find the points where they intersect. You need four transmitters to do this really. When you have four, what happens is the lines cross over each other, and you get a triangle shape that's called a cocked hat, and basically your receiver is in that triangle, and the area of the triangle is the navigation error, the measurement error. So it's pretty easy to do this. The catch is there isn't really a way to go from time of flight back to a location. You have an estimated position and work from that, and calculate what the time of flight would be, and then refine your estimate. It sends a burst of data every 1.68 seconds. That's called a cycle. There are 16 navigation slots per cycle. There are a maximum of 24 transmitters in the system. There's some crazy timing that goes on to allow that to happen. Basically, the transmitter transmits on one frequency, then the other, and the second frequency is used for the so-called interleaving, which is how you get the 24, and then these 1.68 cycles. So 1.68 seconds cycles. You have 64 of those in a sequence, and then there's 65,536 of these sequences before the timing pattern repeats. So they all have a clock value that's encoded in there. That repeats roughly every 80 days. So from that signal, you do the measurements, time of flight measurements, you can figure out where you are, some data carried along there to do timing synchronisation. So I sat down, read the ROMs out. Surprisingly, you can figure out a lot not knowing anything about the hardware just by making assumptions. So I read the ROMs out, disassembled them with Ghidra. So that's the NSAs, Open Source, Debugger, disassembler, kind of IDA-like, and it's free. I'm cheap. So we can make assumptions about the hardware. 68,000 starts executing from address 0. So the ROMs got to start at address 0. We know how big the ROM is, so we know where the ROM is going to end. This piece of code on the right here initialises the RAM in the system. So it's zeroing the uninitialised data and copying what's known as the IData. So this is written in C, there's initialised data that's copied from the ROM into RAM to initialise some variables. So we now know where the RAM is in the system, the initialised variables are at the bottom, and we know how big the RAM is because we know how many RAM chips there are. So we've made two assumptions there and found out where the basic hardware of the RAM and ROM is. So that's very useful if you're trying to write an emulator or trying to run snippets of code because now you know at least the basics of what it's expecting even if not the hardware. There are a lot of text strings in the firmware as well. Function names especially are quite useful. The function names are quite short, but it still gives an idea of what the structure of the code is like. Gidra has some problems with it. It turns out the whole thing they wrote a custom real-time operating system. But I think the guy that wrote it might have been a bit of a Unix fan because it has threads, mutexes, semaphores, the usual RTOs features. It uses the 68K's supervisor and user mode so things can't generally trample memory that doesn't belong to them. But it also has character device support which seems a little bit weird for something that's running on an embedded platform. The task switching is synchronised against the navigation receiver and the signal processing is split among several threads so it's a bit of a nightmare to follow. So I didn't get much further reverse engineering of the firmware so I decided to take a bit of a different tack. I wanted to run my own code on the thing and I was sick of programming eProms and erasing them. For those of you who don't know what an eProm is, it's a programmable memory device and to erase it you have to expose it to ultraviolet light for about 15 minutes. Unfortunately the high capacity eProms, it's longer, it's more like 30 minutes. So I was very quickly tiring of that. Built this thing that has a USB port on one side a Xilinx CPLD to do all the logic and control, an SRAM, so a static RAM chip that stores the program that we've loaded into it and a bit of level translation because this is all modern 3.3 volt logic on the right hand side of the PCB. If you can see that dotted line that's literally the boundary between the 5 volt world and the 3.3 volt world. The thing I realised quite quickly was that the CPLD has access to the data and the address bus even when the 68K is accessing it so we can see what the 68K is accessing which means that we can add an extra debug port by monitoring the address bus. So there isn't a write pin, we can't just write to a port and send a byte but what we can do is look at the address bus and if the program on the 68K is accessing a certain address we send below 8 bits of that address to the PC of the USB port and we now have a debug port we can send bytes to follow what the code is doing on the real hardware without interfering with the firmware that's running because if you start poking at the UART what will happen is the real time operating system will realise that things are in a weird state that it wasn't expecting and will then reboot the nav receiver. So it is very pedantic and peculiar. The next step underneath that massive logic analyser probes and transition adapters I swear is a transition board which is soldered to a top of the 68K with a socket and allows me to quickly connect up the logic analyser and I can watch what's being executed and the logic analyser, so it's a big HP mainframe logic analyser can then disassemble what's going across the bus monitor the bus states, tell me what's going on. So if you put this together I can now run my own code on board using the emulator but I can also watch what the official firmware is doing. If you trigger on a chip select for instance the UART and then set the logic analyser to trigger on that and see what was on the bus what you will see is the address of the UART so that's how I found out where that was triggered on the interrupt pin found out which interrupt was being triggered so now I have enough knowledge there so I know where the ROM and RAM are and I also know where the serial ports are so I can now port something like Tudor or Maxbug a ROM monitor that will allow me to load my own code into RAM and execute that without having to constantly reload code into the emulator but the ASIC can also generate interrupts for the radio side there's a way to figure out which interrupt that is to you tell the logic analyser to trigger on an interrupt and then wait basically wait for one of these signals to go in see what hardware is being accessed right after if it's not the UART it must be something else, it's probably the radio so that's how I figured out where that was result being I now thanks to just poking around at things seeing which pins are changing states of GPIOs as well the chip select trick works on GPIOs you look for a state change and then the right that happened immediately beforehand was probably what caused that so from that I've got a mostly complete hardware register map with a few gaps so I know pretty closely what worst of a hardware does what most of the registers do so I decided to write an emulator as you do mostly to prove I understood the hardware as well as I thought I did but also given the failures of my attempts at signal generation the emulator is useful because I can send in raw phase measurements basically any value I like I can repeat them as many times as I like and it's always deterministic it's going to be a fully repeatable test and I can keep changing this data or adjusting it based on what I'm seeing and figure out more about how this is working I can also add some really quite specific traps in the emulator so I can look for for instance this piece of code executes then this piece of code executes and then dump a memory buffer so I can for instance say grab a piece of data like the phase measurements and see how they flow through the system see what processing is happening there and learn a lot more about it and recently I figured out how the task switching works and the task table for real-time operating system so I can even see which task is being executed and trigger for instance when one of the navigation tasks is activated is switched to so it's easier than reconfiguring the logic analyser as powerful a tool as it is it's a heavyweight industrial tool and it can be quite tricky to configure the power that has is really reflected in the user interface I've done an emulator for a 68000 base machine before I mentioned quickly at the beginning for the AT&T Unix PC so I just used the same CPU core I used for that, I know it works, it makes sense wrote my own emulator for the UART it pretends to have an infinite transmit and receive buffer with a transmit time of zero it's not an accurate emulation it's close enough for the data track firmware that's exposed to TCP ports and I just use netcap to listen to those it's sat on github there is a ROM image included with it if you want to have a play with it and it works well enough that the firmware will run and start trying to lock to the incoming signal so it generates a little bit of the signal based on what I know about it as well but I started hitting limitations in what that was telling me notably about how the radio front end works and what that's expecting in terms of signal strength so I finally decided there was no way I was going to avoid actually reverse engineering the hardware back to a schematic it's a four layer PCB it's quite a small one but it's quite densely packed and the technique I ended up using for that was to desolder all the components measure them as they came off so measure the capacitance of the capacitors resistance of the resistors where they went on the board and then sanded off the sultrin and the solder mask so the solder mask is the green coating that prevents solder from sticking where there aren't any pads and the sultrin is the white component texture is telling you which component goes where scanned the board at that point sanded through down to the copper scanned it again sanded down through the fibreglass down to the inner layers which took a long time and made my arms hurt a lot again scanned those stacked them up in gimp scaled and rotated them to align all the tracks all the pads adjusted the levels and curves to get a really good contrast image or as good as I was going to get and then changed the colour of the copper layers to match that's basically the colour scheme Eagle uses so yellow and green for the inner layers and then red and blue for the outer copper layers and then made the background transparent where the fibreglass was so I could just stack them on top of each other and follow the tracks in the graphics package so that's what the two outer layers look like it's a bit of a rat's nest but what happens is you use the you start overpainting the tracks you've what I did was I started overpainting the track side entered into the CAD system as I did them so the more tracks you do the more disappear and the easier it gets to be to follow the rest of the tracks so as far as the process goes I pulled this into CAD created all the schematic symbols of the ICs so there I've got the pin out sat in front of me without having to refer back to data sheets I know which ICs go where I know roughly what they're doing so I add them to the various schematic sheets I started adding pin numbers to the track scan so I didn't have to constantly figure out where pin 1 is which direction they count it just makes life a little bit easier and as I said earlier you just follow the tracks and enter them into the CAD package there's some little tricks there layer masks are great for saving a bit of time and being able to go back and check your work so my current state of play where I am now is I've got a partial schematic of the thing I know most of the hardware registers I know how the 68000 should be talking to the 8031 but I don't know the address it does to talk to that and I have an emulator that only emulates to 68k my next plan is to take the recordings I have decode them back into the data bus at the beginning of every cycle port a monitor ROM across to it probably a tutor ROM which is sometimes known as Maxbug across and that means I can just run my own code on the hardware port for registers and see what happens it gets a pretty poor when it locks on to the signal it gives you a lock quality figure between 0 and 100 0 is perfect sorry 0 and 1000 0 is perfect, 1000 is terrible it's currently sitting about 930 on the emulator so it's quite bad there's obviously something I'm missing as I said earlier my eventual goal is to either create a my own receiver and transmitter and play with the principles of the data track system in the amateur bands there's just enough in the amateur allocation to pull it off it's a good learning opportunity for how these systems work that was a little bit a little bit fast if you we're not doing Q&A this weekend I believe so I ask you to hold your questions if you want to find me at EMF I'm hanging out with the furries on the top of the hill with the big antenna mast with the lights on it otherwise feel free to grab a shot of that slide grab me on, mast it on Twitter, Telegram my email address is right there I'd love to talk to anyone who's played with similar systems in the past if there happen to be any data track engineers who know this thing and remember some of its secrets yeah here's hoping or equally if there's anyone that knows GNU radio and can help me decode to those recordings I'd really appreciate your help but thank you very much big round of applause please thank you very much Phil