 Let me pose another question to the audience. If you hand a hacker a device that has a screen and two to four buttons, what is the first question that every hacker will ask? Does it random? Exactly. That's the question everyone asks if such a thing appears somewhere. So please welcome on stage for the talk, Payment Terminals as a General Purpose Game Computer, Thomas Rensmann. Check, check. Yes, cool. Yeah, so thanks everybody for coming in here quite late, this late also in the event. But I hope you enjoy, you will enjoy this. There will be hopefully, if all goes well, a demo in the end, so. So a quick table of contents, I will first start with a couple of small disclaimers and give an introduction of myself. Then I will give kind of a short overview of the device itself that we will be talking about from a hardware perspective and then also from a software perspective. Then I will mostly kind of chronologically go through the process that I went through when I got this device from the moment I got it up to, yeah, basically the process I followed to get in code execution. In order to explain that, we will have to go a little bit into how the bootloader works and the main operating system. Once we get to the point of having code execution on the device, there's the problem of turning that into something practical, so we need to build sort of a tool chain in quotes as you'll see. Once we have a tool chain, so we are able to build C or C++ to run on this device, we can of course port doom. So quick disclaimers, there will be no new vulnerabilities in these slides in this presentation. This is purely using an already patched vulnerability actually, so it's also good news for anyone who owns a shop who has one of these things. If you connect to the internet, hopefully it should be updated and patched. The other thing is that I will mostly be ignoring all the kind of sketchy payment related stuff, so of course this thing is secure because it needs to protect payment assets, payment keys, whatever is going on in there. This is kind of a whole kind of worms I don't want to open, so I'm just interested in, as the title said, using this as a general purpose computer, seeing what it takes to run my own code on there, or, well, someone else's code, John Carmich's code. So, a little bit about me, I work as a security analyst at a company called Codian. We build tooling for security analysts, basically trying to make security analysts live as good as possible, and there I mostly focus on software security analysis, so code review, pentesting, and this is also my main background, so I'm really a software guy, not really a hardware guy, and I do have, in my previous job, a little bit of experience with the payment world, but this was mostly a soft pause, so basically a terminal like this, but implemented in an Android application, so I know a little bit, I have some context of the payment world, but not that much, and definitely not from a hardware perspective. However, kind of as a hobby, I've been getting more into embedded security, and I guess this is a form of embedded security, and really, I like tackling these things from a logical perspective, so from a software angle, so we will be looking at the PCB and stuff, but yeah, I'm not really using that for anything. So, a bit of context, I guess for most of you, the reason is clear, you just want to run Doom, why would you do this? Well, because you can, I just was bored and I was looking for a new target, basically, and I wanted something that was kind of cool, so yeah, you may actually have seen this at the bar, for example, here, so these are quite commonly used in the Netherlands and worldwide, I think, so I was looking for a device like this that also nobody had ported Doom to before, and it seemed to be from some Googling nobody had done this one, and also, this is a bit of an older device, so I figured if there are any exploitation mitigations, they are probably not that strong, so I should be able to build an exploit if needed, yeah, so I ended up with this device, there's also a bunch here that you can maybe see afterwards, this is the VX820 payment terminal, as I said, it's also here at the bar, it is, yeah, it's made by Verifone, very popular, POS or Payment Terminal manufacturer, yeah, most of you will probably recognize it, so I got my second hand of Markplatz, yeah, so here's a picture I took yesterday at the bar, yeah, so why a payment terminal, so I thought it would be interesting to run Doom or anything similar, specifically on this device, as it seems so overpowered, right, why does this device have so much power, it only needs to display a couple numbers, read a card, maybe do some crypto, so yeah, I thought it would be interesting to use it to its full potential, and it has all the needed peripherals, right, it has a screen at least four or five keys, yeah, and as I said, it ticked all the boxes basically, so a little bit about this device, it is, yeah, it has a pretty strong or powerful, at least for its time, 400 megahertz arm processor, it has quite some flash, which is useful to store Doom levels, it has enough RAM for us, it has a color LCD, which is also a touchscreen, not so useful for Doom, maybe for other games, as we'll see, and it has actually quite some peripherals, so there's not a lot of ports on there, but you can connect a dongle, hopefully show this in the demo, that then exposes an ethernet port, USB host, USB client actually also, and just plain old RS232, and then of course it's a payment terminal, it has a smart card reader, it has NFC, it has Magstripe still, and actually it has a couple more internal smart card readers, if you're into having access to many smart card readers, it has, from a software perspective, it's running an operating system called Verix, from what I can tell this is a proprietary operating system, only used on this generation of Verifone payment terminals, and it's actually quite cool from what I've seen of it, so it's very Unix-like, it has support for multi-applications, multi-threading, it has sort of a concept of environment variable, so you can set key value pairs, which are then used by the operating system and also by applications for various configurations, it has a regular file system, with some level of access control, it has also separation of permissions between multiple applications, and then it also exposes all kinds of peripherals as devices under slash dev, and it has all the normal syscalls to access those, it's like Linux basically, but with some weird dos names, so it's slash dev slash con one, so I wanted to very quickly show the hardware a bit more, for people who are maybe more interested in this, and it's just fun to look at it, if you don't really know what you're looking at, so this is the bottom side, and there's this little flap that you can take a screw out, you can take it off, and you'll see that, this actually does not trigger the tamper detection system, so if you're not familiar with these devices, they are supposed to be tamper evident, tamper proof, I don't know to what degrees exactly, but they should detect the fact that you're opening it up, but this flap, actually you're supposed to open this up to, as I said, these are the smart card readers, so you might want to change those secure modules, I think these are maybe four cards with private keys from acquirers, but I'm not sure, and then there's also this proprietary connector at the top where you can connect this dongle basically that exposes all of the rest of the peripherals, but then when you actually take the back cover off, you will see this, and now I did trigger the tamper warning, you can see here, this is the first tamper detection system that is triggered, this is just some contacts on the PCB that are normally touched by a little conductive pin on the back cover, and actually I think this is also the thing that sometimes accidentally triggers the tamper warning, so if you google the name of this device, space tamper warning, or tamper detection, you will see many people who just drop the device, or I don't know, maybe it's an earthquake or something, and it triggers this because it disconnects quickly, we'll get into that more later, so there's this, you can see there's this funny green PCB here, as I said I'm not a hardware guy, but this seems to be doing some fancy tamper detection prevention stuff, I think it has a bunch of internal layers, and you can't really see it here, but there's a big male socket here, I don't know, a whole bunch of pins that plugs into a female socket, and it's connected to this whole battery thing, actually to switch out the battery you need to take this whole thing off as well, and this is basically I think protecting all of the sensitive parts that you might want to tamper with, so the main system on the chip, the external memories I suppose, and this is the smart card reader, so I guess this is also quite sensitive, they can see the header, and some other funny stuff that I think is not common in normal embedded devices, like very squiggly lines everywhere, either to prevent RF emanations, maybe someone knows about this, can tell me afterwards, but thought it looked interesting, and you can take it apart further, and you can see here the NFC coil around the screen, and then if you lift that there on the kind of top middle or top left area, there's another tamper detection thingy, so it's kind of detecting all the steps you're taking to take it fully apart, and I'm not sure actually what implications that has, from a software side I only found the 01 Boolean basically, so going a little bit back in time, I want to kind of as I said tell the story of what I did with this device, so when I bought this thing second hand, I actually got it in a pair like this, so this is how you will often see it here in lots of small shops where the device on the right is the device on the merchant side, so it also has the receipt printer, this is where you actually start the payment, and that's basically the host for this device, so our target device is really acting like a slave where it just receives commands from the main merchant device, so this is how it was configured in this case, and this was a bit annoying for me, so it was running actually software from CCV, which I think is quite common with the blue background you see often, so both devices were running CCV software, and it was our target device was running in the slave mode where you really couldn't interact with it, so I couldn't find any key combination for example to do something with it, so normally there's a way to jump back to the kind of a management menu, but this was also locked down, so I couldn't do anything with it, except really start payments with it through this merchant side device, so I figured it's really the merchant device that sends commands that do interesting stuff, so yeah this is really, this picture really doesn't make anything clear, but this was my janky setup of basically man in the middle in this, or capturing the data that was being sent from the merchant side device to this target device, and then the response is being sent back, and you can see in RJ45, but that's just the cable they use for Serial, for RS232. So based on all of the communication I actually quite well, not that quickly, a couple of evenings I figured out this protocol, and remember this is a CCV specific protocol, this is not related to this device, it's related to the software running on these devices, but I was able to figure it out, or at least some basic commands in the checksums to be able to send my own commands, and then you can do some fun stuff like this, very funny, but doesn't get us any closer to Doom, right? So I thought, okay, so now I can kind of control this, this user land application, but what if I want to have control over the device itself, get my own application on there? How do we kind of escape this application? So I realized well, if you open them up, and I didn't really explain this yet, but when they detect one of these tamper attempts, they will wipe all sensitive data, so that's the point you're really not supposed to access, I don't know, transaction logs, payment keys, whatever is sensitive, and they will also wipe everything, including applications. So is this just an easy way to kind of clean the device? What if we just open it up a little bit, screw it back together? Well, then you get this, actually. So this is the login prompt for the system management menu, which you need a password for, and now it's specifically the tampered version of that, so this tamper message will be flashing. Luckily, this password is publicly known, you can just Google Fairphone system menu password, this is the password, if you can see, 166831. So if you ever have one of these, press seven and enter, at the same time, should go into this screen and enter this password, you're in management mode. However, application vendors can actually tell the system to use a different password, but in most of the devices I got, they kept the default password. So then, okay, cool, we can enter the system menu, but it's still in this tampered state. Luckily, just Google, or actually on YouTube there are tutorials how to clear the tamper flag, as I said, people just drop these things, they want to keep using it. Turns out it's just kind of a cheat code. This is the main menu. You kind of have to navigate to the next screen, and there's this option five, key management, and there's an option called IPP key load. Okay, cool. Then you get to this screen, which apparently is doing something over serial, receiving keys, and it tells you press one to end, but what it doesn't say is that you can press two to clear the tamper flag. So press two, device reboots, tamper message clear. This feels a bit sketchy to me. I guess it's fine because all of the sensitive data is cleared, but what's the point of the tamper flag? I don't know, but for me, this was perfect because now we have kind of a clean device, no more applications that we don't really care about. It's no longer tampered. Okay, what to do now? So it gives kind of two important hints, download needed, and no go variable, or star go. So this go variable is one of these environment variables I talked about, and this is basically the one that defines, you set it to an application name, and that is the application that will start when the device boots. So if it's not set, it doesn't know what application to run, but this is easy. We can set that using one of the options in the system menu, and download needed. Okay, so we need to download something to it. So turns out it uses this protocol called XDL. I'm thinking this is also proprietary to Verifone, and this is a protocol where if you connect the device over serial to some kind of host machine, you can download files in one direction to the terminal device from your computer. There's no way to extract files. So you can download files, you can set complex variables like this go, for example, and there are some other commands to wipe flash or clear SRAM. And a couple of others I haven't really reversed yet. So yeah, I basically made a Python wrapper or library for this to easily do this as I kind of needed this for the main attack we'll see later, but this is just some code that sets this go variable and then also uploads the file. And this on GitHub, I will also link it later in the end. So, okay, we can just upload Doom, right? Sure, yes, we can, but we will get a different screen. So go not authenticated. So now I properly set go to the file name that I actually uploaded, and of course, I guess it makes sense, applications need to be signed. So normally you're supposed to upload a .p7s file together with your .out executable file. And this p7s file is kind of like, yeah, it's an asymmetric signature. So there's a whole, I don't know the details, but there's a PKI system, some certificate chains in there. I think the idea is that you're supposed to get some sort of developer contract with Fairphone, such that you're able to sign applications, you get the right keys from them, then this device will allow you to run those applications. However, there's some funny logic happening. So once you do this upload of a file, immediately after you upload a file, it'll reboot, or if you're done uploading multiple files. And if it sees one of these p7s files, the signature files, the kernel will start verifying the signature, see if it is a valid signature over that executable. And if it is, it will actually remove the p7s file and generate a .sig file. And this .sig file, it turns out, it's completely unrelated to any private keys or PKI system, anything like that. This is just an HMAC using a key that's on the device itself. And then later, every time you actually want to run the application, it'll just verify the .sig file. So I'm thinking that this is done for efficiency reasons, I guess it's quicker to verify a symmetric HMAC than a symmetric signature file. But this is pseudocode, but this is kind of the logic in the kernel that these are really separate functions. So the verify p7s generates .sig. So these smart guys, I'm not sure if you can read it, I will link it in the end as well, from the payment village, the DEFCON payment village, they figured out that this is how it works. And of course, maybe you already can think of this, but if we can somehow call this generate .sig function on our binary without ever supplying p7s file, there will be a valid signature file. So there's code on the device itself that can generate valid .sig signature. So this will be kind of the goal from here on out. So what these guys also found were a couple of other interesting features, bugs, not in this device, but in a similar device from the same family, a little bit older, I think. So first thing they found, which was also on my device, is kind of a hidden shell. So there's no need to upload a program if there's already a hidden program on the device that has a valid signature, which basically sponsors shell on serial port. This is pretty fun. You can traverse the file system. You can even dump files, which was very useful for me. This was a way to get files out. But apart from that, it's still some application running in user land. It doesn't give us any extra privileges. It doesn't allow us to execute new code. So this was fun. And apparently this is also patched already. But yeah, not really useful for me. Another thing they found was a buffer overflow, and they might have found a couple more, but at least one in one of the sys calls, I think it was the open handler actually in the kernel. So that's much more interesting. But they actually tested a slightly different OS version, and I couldn't quickly get this to work or something easy for this as you have to actually exploit this. It's a lot of work. So I kind of went for the third thing they found, which was also present on this device, a hidden mode in the bootloader. And this is quite a sketchy thing. So this device has a bootloader that apparently has a hidden mode if you press three keys at the same time while powering it on. It'll go into a mode where it basically accepts data over serial. And if you set the right things, it'll load this data at an arbitrary user-specified location in memory before doing anything else. Well, we'll get into this a bit more later. So actually here. Okay. So this device has secure boots. I think this is also claimed by a manufacturer. So it has a couple of boot stages. Each one verifies or loads the next one, verifies it. If it's properly authenticated, it jumps to it. And this bootloader that I'm talking about here is called SBI. And this is the bootloader that basically the final bootloader, it loads the actual operating system and verifies it. And this is the bootloader that has this secret mode if you press the one, five, and nine keys. And so in this secret mode, it also uses this XTL protocol as I showed earlier to kind of load scripts. And I think this is supposed to be like a proper secure implementation where you send it a script. And these are scripts with very low-level commands, like write some bytes to NAND flash or this very low-level bootloader stuff. But these scripts are authenticated. And it's also using, again, some kind of PKI system. But if you don't specify a script, if you don't give it like it's an actual ASCII script, if you don't give it a script, but some magic value in the beginning, and then just an arbitrary long file with at this offset an address, then it will load your file at this address. Okay, cool. So, yeah, obviously this breaks secure boots. Yeah, so to summarize, we kind of have an arbitrary write or a write what were primitive that allows for code execution. So this is kind of the implication we can write to some place that execution will happen anyway, and then it's executing our code. So in my case, I'm just overriding the bootloader code while it is running. Then we have arbitrary code execution. And it breaks secure boot. And it's still present on many devices. So I got a couple from Markplatz, different sellers. Yeah, if you don't know what you're looking at, it's this SBI version, which is all the vulnerable version. So that was very useful for me. Yeah, and this is a way in for us towards Doom, because I had a plan. So remember this generate signature function in the kernel. So this is all the way when the device fully booted in the kernel. There's somewhere there's a function that if you call it, it will generate and make a valid signature file for any binary you want. We want to call that. But we have control over the bootloader. So my goal was kind of to follow the normal boot process while kind of keeping control such that I was able to call this function once the normal operating system was fully loaded. And this was a bit convoluted. So I hope this is all readable, but if you don't follow all the details, it's fine. So I kind of have a schematic here of the memory. All of the yellow is the bootloader. You can see a little red arrow. That's our current place where we're executing code. And so at this point, we're right inside this magic download mode. And what I do here, I just basically send it a copy of this SBI file with a couple of patches. One of these patches is right after, so that's stage zero. It's right after the Verix operating system is loaded and authenticated, but just before the bootloader jumps to it. And that's actually when we call stage one, which in a bit we'll see what it does. So loading and authenticating Verix always kind of looks like this. So at this address, 40 million or something, it'll put Verix. And this is actually not proper Verix. It is a compressed version with a little decompression routine in the beginning. But that's fine. So as you can see here, we're just before stage zero. So what happens when we execute stage zero? Well, it jumps to stage one. So we execute stage one, which then actually makes another patch. So it patches something inside this code that was just loaded. So it inserts a small patch called stage two inside the compressed version of Verix OS. So just before the compressed LCMA blob, but just after the decompression routine. Okay. So at some point, our modified version of SBI actually jumps into this hex 40 million or something address. And as you can see, we actually execute this clone functionality. So what it does, it clones itself basically to a much higher address and actually also transfers control flow there. And it does this such that it can then actually decompress back to this original address, which we see here. Stage two actually. Oh, this is just before stage two is executed. This is when decompress is executed. We can see that the normal decompressed version of Verix is on the right there. And then, so here we're just before stage two, we execute stage two. And this is what inserts the final actual thing we want to do, which is a patch inside the normal kernel image, the fully decompressed kernel image that calls that kernel function that generates the signature file for us. Okay. Cool. So now we can run our own code. But let's take a little step back. So how did I do this hello world? We need to actually supply an executable file. But how do we make one of these? Well, it has a specific format. So you might be familiar with elf. This is much, much simpler, luckily. And I didn't reverse engineer the full thing, but it's, yeah, we don't need to understand the full thing. There are some magic flags. So I took this shell.out that was already on the device as a nice example for my program. And it has all the things you might expect in an executable file header, like address of your main function, the start of the text segment or the equivalent, start of the data segment, and the stack size. And there's also a way to specify which system libraries should be loaded when it loads this application. And there's a system library called sys.lib, which is kind of the libc equivalent in Verix. Actually, not using that, but we'll see you later. So, yeah, this format seems pretty simple. We can deal with this. So to kind of build a quote unquote tool chain, this is why I put it in quotes before. It's just a hacky make file. I used a linker script, which was new technology for me, but it's pretty cool. You can kind of give the linker the script and it'll tell it how to arrange some stuff in the actual file and in memory at runtime. So you can give it a starting address and kind of the order of the sections. And this order then will also be followed in the elf file. So when you then turn the elf file into a raw binary with up your copy, you kind of get what you actually are saying in this linker script. So this is how I was able to get things in the right order that Verix expects. And then after making this just raw binary, I just concat this header file I took from this other binary and patch in the right sizes. Okay, cool. So we can now generate, we can take c code and make proper executables for this device. But what do we call? Well, we need to call some functionality that's in the kernel or we can call functionality that's in maybe this libc equivalent. But for some reason, I couldn't get that to work. Maybe there's some initialization functionality. I don't know. But to me, I was reversing the kernel code anyway, so it was easier to just call syscalls right away. And they're quite familiar. So you have, as I said, open, I think a syscall1, read syscall2. And it's just kind of what you would expect. Literally reading from the keypad is reading from slash dev slash console. Yeah, and there's also some public documentation of the functions in this sys.lib, but this gives a really good hint about the underlying syscalls. So that was quite useful as well. So now it was really a matter of engineering. So as you can see here, this is some hacky c code. Well, this is the proper, the only way to do it, but to actually do this syscall here, you can see the syscall instruction, but I wrote these wrapper functions for all of the syscalls. I might need such that I could just call it from c or c++ code. So now we can actually start porting doom. And this is where I want to give a demo. So let's see if everything works well. Let me quickly show my terminal, and then afterwards we can switch to the video. So the first thing I will do is start my script, which uses this Python xdl implementation I talked about earlier. And this script, I can zoom in more. This script will do two things. So it will send over the actual application. So this executable with the doom code inside. This is normal. There's nothing, there's no exploit there. We're just using the download functionality. And then after that's done, it will kind of pass us. And when I tell it to, basically, it will assume that we're in this secret bootloader mode and it will send this payload. And in the meantime, we will have to enter this bootloader mode. So I will trigger it. Now it's just waiting for the download mode to start. So if we can switch to this camera, perfect. So I kind of have a setup here to explain the situation. So this is the dongle that exposes, like, a bunch of things. There's actually ethernet port as you can't see. This is just a serial port. It's RJ45, but it's just serial. And then I have a serial to USB adapter here. And a button here. That's the main reason why this is a whole setup, because I need to cut the power, because this thing doesn't have an off button. So I will turn it on now. See my script is still running? Yeah. You should probably be able to see the screen in a bit. So this is it just normally turning on and my script triggered. So you can see here the cool thing is about this XDL protocol, there's also a command for sending a message on the screen. And with some form feeds and backslash R and stuff, you can actually delete all of the normal text that's on the screen and do some nice ASCII animation. So I made a progress bar. So this is just after every little chunk of the program it sends, it sets a new message on the screen. Okay, now we're just restarting. And then once it's restarted, we should see not doom yet, but this message that I had in the slides before. So now we have, I actually uploaded the binary and sent over the or set this environment variable, this go variable. So it actually found this go variable and tried to load the program, but it figured out that it was not authenticated. Okay, but this is what we have the exploit for. So I will cut the power, I will trigger the second stage or just the actual payload now. This is a bit tricky as I have to hold the right buttons. So it's one, two, or one, five, and nine, sorry, never done this upside down yet. So turning it on now, actually looking at my own screen. Okay, you can't see anything here because the boot loader doesn't do any I.O., but now we're actually uploading the payload. And now it's done. So now we're running the payload. So this is now going through all the stages I mentioned before. And the indicator that it's done is when the LCD turns on. So this is when, here we go. So now we know that it's done. And actually my code kind of freezes the operating system because I didn't properly, yeah, my patch is a bit messy, but it doesn't really matter as this signature file is now just stored on the file system. So we only need to do this once. So now I'm just cutting the power again. And now if we turn it back on, we just boot it normally, no weird key combination. And it's a bit slow to boot. And here we go. Doom. So let me get it to the right orientation. Okay, so it's actually already going through the demo. But we can actually start it. So yeah, the screen orientation is a bit annoying. So I actually mapped the buttons that way. So it makes sense. But not really if you're on the other side of the screen, but I will try my best. So we can start a new game. Let's do easy or medium. And then wait. Okay, so we can turn left. We can turn right. We can, wait, what is shooting? We can shoot. You get the idea. Okay. That's Doom. And then there's another demo I wanted to give. And I think we have some time left. So let's do that. And this, let me put this aside. So as I said, we can also do whatever we want, right? Why Doom? Why not just some other games? So I actually ported some other stuff. There's a couple more of these. All goes well. They should have power. Yeah, let's kind of... So one of these is running a Gameboy emulator. One of these is running a Game of Life implementation. Let's wait for them both to boot. Here you can see the Gameboy emulator. I didn't really do proper display scaling yet as the resolution is not a proper multiple of the 144 pixel width of a Gameboy emulator. But yeah, so there's no sound, sadly. It does have a beeper. It's kind of a PC speaker. I guess you could map some of the Gameboy sounds to that. But yeah, exercise for the watcher. What is my key mapping? Well, I guess you can believe that it works. And then here, this is actually my own code. I kind of promised running your own code. So I wrote some of my own code. This is using the touchscreen to play quote unquote Game of Life. So I can run it. It's just Game of Life. I can pause it again. Do some more stuff here. And well, the rest is just up to your imagination. Yeah, this is where I was out of time. Thank you. Are there any questions from the audience? If there are, please line up at the microphones in the middle and we'll take your questions. Unfortunately, we do not have any questions from the interwebs. So anyone in the room interested in any details of these wonderful hacks? I have a bonus if there are no questions. If you can switch back to the camera. Could we get the camera back, please? The suspense. If the colleague is second. Ah, cool. Thank you. Okay, so I said this is a whole family of Pharaophone devices. Well, this family is actually quite, oh wow, there's a lot of fingerprints. Sorry about that. This family kind of reaches to quite modern devices. So I have this device as well. It's a mobile one. So this has a battery pack inside. Turns out I will actually boot it now. It's running the same boot loader. It's just as slow. And the good thing is they fixed the screen orientation. Yeah, they made the viewing angle worse though. But you get the idea. Yeah, so I would say for sure if you're interested actually playing with this, I will leave some of this stuff here and we can see afterwards. I also have one device here that is kind of taken apart if you want to see the insights. Right. Any more questions? Any questions? While you think about those, please do not go down to the bar and hack the payment displays there to play around with you. So I checked with the Aachen people, even though I think it's not actually them responsible for this part, but the boot loader should be up to date. We have a question, please. Have you looked at the NFC interface? Well, not really, but this is for sure if you're interested in messing with smartcards. This is the perfect device for it. I'm not sure if there's anything specific about it, but yeah. So there's some functionality in the kernel, I guess what you're getting at that does some of the low-level logic in the smartcard interface, the contact and the NFC one. I guess this will also be interesting to audit for sure. But no, I haven't looked into it. Another question. Thank you very much. Have you taken a look at ROM boot loader? So many devices have several stages of boot loader the first boot loader being in ROM and unpatchable and some later layers can be patched with an update, but the first player can't be patched because it is physically in ROM and you can't change it without replacing the device. Yeah, so I only looked at this boot loader and only because these guys from the Dev Compayment Village found this vulnerability in this second stage boot loader. Actually, I think this is the third stage, but I'm assuming the S and SPI stands for second stage. No, so I did not audit anything besides that, so for sure, if you find a vulnerability in the actual ROM code, yeah, that's a much bigger issue with these devices. Do we have any questions from the interwebs? No, okay. Any further questions from the audience? Last chance. Anybody? No. Well, if not, please enjoy the evening and before you go, give a very warm applause to Thomas Rinsma and Payment Thomas as General Personal Game and Computer.