 Welcome everybody to our next talk, it's the talk wallet fail. As you all know, when you have something valuable, you put it somewhere safe. But as hackers also know, there is no place that is really safe. And our three speakers, Thomas Dimitri and Josh, are now going to demonstrate in the next hour the art of completely breaking something apart. So please give a big round of applause for Thomas Dimitri and Josh and have a lot of fun. So just to start, I'm curious how many people here actually own cryptocurrency. Raise your hand. And how many of you store it on a hardware wallet? So we're very sorry to everyone who has their hand up. So it's not just me, it's me, Josh and Thomas. So we're all hardware people. We do low level hardware stuff in varying degrees. And we got into cryptocurrency and so I can recommend to everyone sitting in this room, if you're a security person, there's not a lot of people doing security and cryptocurrency as much as that's painful to hear. So yeah, I mean, a lot of this is based on reverse engineering. We love cryptocurrency. I mean, for us, crypto also stands for cryptography, not just cryptocurrency. But no offense to anyone with this talk. It's just something that it's a category that we looked at. And so the results kind of speak for themselves. And again, this wouldn't be possible alone. So we have a lot of people to thank. I'm not going to go through all of them individually. Just be known that we're thankful to everyone on this slide. So yeah, so we started this about six months ago. So we wanted to take a look at cryptocurrency because we own some cryptocurrency ourselves. And we saw that everyone's using cryptocurrency wallets. It's more and more the thing that you do. So we started a group chat, as you do nowadays. And we have 50,000 messages now and 1,100 images. And I had my son in the meantime as well. So it's a really long time that we spent looking at this, et cetera. So what do we want to achieve though? Because people don't give the kinds of attacks that you can actually perform against cryptocurrency wallets and of credit. So first attack is supply chain attacks, where you are able to manipulate the devices before they get to the end customer. For more vulnerabilities, where you find a vulnerability in the firm rank and somehow either infect or do something else with the device. Side channel attacks, of course, I think that's one of the more obvious ones that people are familiar with. And also chip level vulnerabilities. So we were able to find one of each of these. And so that's the talk that we're going to talk about each one of these individually. But first, what's a wallet, just in case you are not 100% familiar with them? So a wallet and in general cryptocurrency, how do you do this? It's just asymmetric cryptography. So you have a private key and a public key. The public key, basically, it gives you the address. You can derive the address from this. The address is nothing other than the public key of the wallet. And you have the private key. And you need this to send transactions, so to actually operate with the cryptocurrency. So the private key is what needs to be kept secret. The public key is something that everyone can know so that they can send cryptocurrency to you. But it kind of sucks to have a separate for each cryptocurrency pair or for each wallet. Maybe you want multiple wallets. It sucks to generate a new cryptographic pair for each one of them. So the wonderful people behind Bitcoin have thought of something for this. And it's called Bip32, Bip44. And so what it is, is you have a cryptographic seed and you can actually derive the accounts from a single seed. So you basically store one seed and you're able to implement and do unlimited amount of wallets. So basically you do key derivation. You add some data, do key derivation. And you can have an unlimited amount of wallets while storing a single seed. And this is what you're using when you're using a hardware wallet. Of course, for each key derivation, there will be a new private key and a public key, but it'll be generated in a predictable manner and you only need to store one secret seed. So you only have to store the seed. You can write it down and that's the advantage. But it's difficult to write down because it's binary data. So come Bip39, which is what you're most used to, which is a format in which you can take that cryptographic seed, that binary data, and actually convert it to a set of dictionary words that you can then easily write down on a piece of paper and store it at your mother's house or store half of it at your mother's house and half of it at your grandmother's house. And that way somebody would have to go into both houses simultaneously to get your words. So, yeah, so what's a hardware wallet? So we just talked about what's a wallet. So why do you even need a hardware wallet? Well, the problem is, of course, computers can get backdoor, have malware running on them, and this is what you want to prevent against. How do you do this? You have a secure device. You store your seeds externally. Usually this is a USB connected device that you store your crypto on. And so you can trust this even if you can't trust your computer is the idea. So what happens is the computer sends the transaction to the device. The device gets the transaction. It can actually confirm or deny the transaction. It also displays the transaction. So before you do any cryptographic signing, you can see, is that actually what I was doing or was my computer owned and is it initiating the transaction for me? So you sign the transaction, and also, yeah, the seed never leaves the transaction, but the hardware signs the transaction for you. You send it back to the computer, and the computer can actually take that and send it to the internet, okay? So that's the quick rundown of how hardware wallets work. So the first thing that we looked at was supply chain attacks, which is where Josh is going to pick up. You have a mic. Do I need to pick up? Oh, sorry, yeah. Okay. So the three big things I want to leave you with as we go through the supply chain attacks are stickers are for laptops. They're not for security. So we're going to be talking about stickers today. They're for laptop decorations. They're not for security. Supply chain attacks are easy to perform, but they're quite hard to perform at scale. And the last takeaway that I hope you leave you with is that the vendor's threat model may not actually be your threat model. So security stickers. So some of the wallet vendors are using them. I have seen them on other products. They seem to be quite popular. I have a friend and colleague named Joe Fitzpatrick. He also likes stickers. So the stickers that he makes are the same as we find on a security product. They have holograms. They have unique serial numbers. And they leave you with that nice, warm, fuzzy security feeling. And so Joe makes some funny ones. You can get a Fitz 140-2 proof sticker. So you don't have to pay all the money for the Fitz one. Just get the Fitz one. So the first device that I looked at was the Trezor One. And so the Trezor One actually has two levels of protection on the packaging. There's the hologram sticker. And then the actual box is enclosed with an adhesive. So it's supposed to be that you actually have to rip open the box to get into it. But if you use a hot air gun or a hair dryer, it's actually quite easy to remove. And so if you see on the left there, that's the original package. And on the right, this is a box that I opened and put everything back into. And if you look closely, there is a little bit of a gap there. The sticker has a little bit of break, but this was a first try and it's pretty close. So trust me, taking a sticker off is not very hard. Now, if you remember this picture of the sticker, because we're going to come back to it. So, but for the vendor, this is actually a real problem. So Trezor did put a blog post out that one of the challenges they face is that they're facing counterfeiting of their devices. So this is from their blog post. They say, hey, you know, we've noticed that there's counterfeit devices. You have to look at the stickers to see that they're legit. So I said, remember, I'll look at that sticker. So I bought that case about a year and a half ago for my previous stuff con talk. And it's the same sticker that they're saying is fake here. So then on their wiki, it's very confusing because there's three sets of stickers. So basically, yeah, stickers are very confusing. They cause problems for end users. And I was not even sure if I bought a real Trezor or a clone one. So this morning, I got out a new case. And just to make sure I took off the sticker using very sophisticated equipment, including a very expensive Dyson hairdryer that was included in the Airbnb. And I was able to remove the sticker. So it comes off without any zero residue. So yes, stickers do not provide any security. On the Trezor T, they switched it from the box. So now the box can be opened easily. But now there's a sticker on the USB-C port. Again, as you would expect, you use hot air and you can easily remove it. Pro tip, don't set the hot air rework that high. I had it set for lead free reworking and I actually melted the enclosure. So if you're going to do this kind of supply chain attack, maybe set the heat a little lower. But if you just Google how to remove stickers, the same attack methods work. So this causes a bit of confusion because the ledger device has a very, I will say in your face, piece of paper. When you open the box, it says there are no stickers in this box. However, I combed through about 251 star Amazon reviews. And a lot of them have to do with confusion about the stickers. So some of them are actually quite funny. So this one started out note to wallet hacker. So I was really into this. So I was like, OK, I pro tip, what's this guy have to say? And basically, he was complaining that there's fingerprints on the device. So that's how he knew it was hacked. Another one complained that the fingerprints were on the wallet and there was a hair underneath. So if you're doing supply chain attacks, be sure to remove any evidence via fingerprints or hair. So anyway, stickers don't work. That's all I want to say about that. Once you get through this enclosure, though, you then have to have the challenge of actually opening the enclosure. These are three different wallet devices, Leisure Nano on the left, the Trezor One, and the Trezor T on the bottom, all of which actually open pretty easily. So the Trezor One even... So I'm still not sure if that's the counterfeit or the real one. But again, on the real one today, I was able to pop open the enclosure. So it is ultrasonically welded, but you can pry it in there and open it. The Leisure Nano opens very easily, without any equipment. But once you do this, what do you do once it's opened? So the attack basically is you take the microcontroller and you rework it. So you remove the microcontroller from the printed circuit board and you put on a new one that you bought from a distributor. Once you've done that on the Trezor devices, you can put your compromise bootloader on there. So this is... I did not go as far to make the compromise bootloader by de-confirming that once I switch the microcontroller, I can connect with a debugger over a SWD and I have free access to the chip. So some of the parts got blown off when I was reworking, but the SDM runs fine. So yeah, so you just rework, reflash, and then you put everything back together. So next I want to talk about hardware implants. So you may remember the story that came out. There was this big hack by Bloomberg about hardware implants. I wanted to make a hardware implant. I also wanted to have a little bit of fun with this. So we are in honor of the Bloomberg story, which may have some issues with it. I were about to talk about the Bloomberg-er, which is a super micro-fun implant. So the goals for this implant is I wanted this implant to happen after receipt. So it's both a supply chain attack and a physical one, like a red team can perform this, a malicious insider could also perform this attack. Zero firmware, because more fun. It has to fit inside of a hardware wallet, so it has to be small. It has to also bypass a core security function, otherwise it's not in the plant. Very few components. I have a thousand of them with me, so I wanted to be able to for makers and the DIYers to participate in the hardware implant fund. So what kind of implant did I end up with? Well, I decided to do basically an RF triggered switch. And so the idea is on these devices, there's a button. And the button is the last line of defense. So all the vendors assume that the host is going to be compromised. They just assume that's going to be easy because that's software. And so once you have a compromised host, you have to send it to the device. And then the human, so humans are still needed, humans have to look at it and say, is this the right transaction or not? They have to say yes or no. So now with this implant, I can through RF, I can trigger the yes button. So a human is not required to send transactions, I can remotely trigger it. Basically the RF comes in through the antenna. It goes through a single transistor, which is the main component and it pulls the button up. And I'm sorry to say that the bill of materials is quite expensive at $3.16. $2.61 of that is this potentiometer I had to use. So it's a little bit expensive, I'm sorry. Also, why is this so big? I mean, this is an American dime, I can fit two on them. What's the deal? Why is it so big? Well, I optimized it for hand assembly, so it would be more fun to use. But you basically put the antenna in and then there's an alt button and like I said, I have a thousand with me. So just for scale, this is how it fits on the Ledger Nano. This is how it fits on the Tresor. It is also, because breadboard friendly is the thing, so we made it breadboard friendly. So you can also play along very easily at home. So then the last challenge with an RF implant is how do you design an antenna to fit in there? And so the big thing there with an SMA connector is the first prototype I did, experimented with a few antenna designs, but remember it all has to fit inside the Ledger. So that's actually quite easy because the Ledger Nano has plenty of room to insert extra circuitry. And so it quite fits easily in the Ledger Nano. And then, so I did the implant and then I started to go through the wallet process. I got to a check that said, is the Ledger device genuine? And here I actually got a little bit nervous because it wasn't working. And so it wasn't working. I was like, maybe they're checking this. You know, how do they detect it? Don't worry, it was only Linux. So it just doesn't work on Linux. So that was no problem. I did this on Windows and it did no problems. The device is genuine. I was able to move on. So the thing is, this is a very crude receiver, but the attacker can always use more power. So here I have, this is my antenna set up in the basement. And with a 50 watt transmitter, I could remotely trigger the button at 11 meters. And at this point, I'm just limited by my basement size. I'm pretty, I'm very confident that I'd be able to remotely trigger this thing further. Yeah. So here we're going to see a demo of what it looks like. And so the other problem you have with hardware implants is how do you know you have the implanted device? So you have to label it some way. Ledger has this kind of Latin phrase that scrolls I want in my own Latin phrase. And so this is how I know this is my implanted device. So what you're going to see is that the transaction screen is going to show up. This is, and I'm, and basically I'm going to trigger this remotely. So I'm going to show the radio come in and then it's going to approve the transaction without any hands. So this is the transaction. There's the screen going. This is what you're supposed to verify. There's the radio coming at 433 megahertz. And then it's going to proceed to the next screen without me touching the button. There you go. So this is remotely triggered and that would have sent a transaction. So if you think about the context that you have a malicious software implant that sent it to a wrong address, the attacker now can remotely accept that and bypass the security model. So yeah, on the recaps, security stickers are for laptops, not for security. Supply chain tax are very easy to do at a hardware level, but they're quite hard to do at scale. And when the vendor says that the device is genuine, that may mean different things, so. Yeah, to second to the next part, so six months ago, Josh Delcoe said something that I found kind of funny and it's almost correct. If you put funny constants in your code, they will end up on DEF CON slides and they won't be laughing with you. Small mistake, they won't end up at DEF CON, they will be at CCC. And so introducing the food babe vulnerability. It's a bootload of vulnerability in the Ledger Nano S. We did not come up with this constant. It's literally in the code, as we'll see later. So the name was not ours, but we like it. So we also bought the domain foodbay.be. The Ledger Nano S is a very simple wallet. It simply has a small display, it has a USB port and two buttons. That's really all there is. And if you take it apart, you see it's just some pieces of plastic at the display and the PCB. And looking at the PCB, it kind of has an interesting architecture where you have an STM32, which is just a general purpose microcontroller and an ST31, which is a secure element that is, for example, used in pay TV and so on. And it's regarded as a very high security chip, basically. And if you turn the PCB around, you see that they were nice enough to leave the programming port for the STM32 open to us. Enabled. And this has been suspected by other people, we verified it, but you know, you have to go through it. And obviously, Ledger is aware of this. And so let's look at the security model that the Ledger Nano S has. The basic idea is that if we look at this device, we kind of have this schematic of the STM32 being on the left and the ST31 on the right. And as you can see, all peripherals are connected to the STM32. That is because the ST31 does not have enough pins to connect peripherals. It literally only has a one pin interface, which is for the smart card protocols, basically. And so all the heavy lifting is done by the STM32. And Ledger splits this up into the unsecure part and the secure part. And the idea is that the STM32 acts as a proxy. So it's basically the hardware driver for the button for the display for the USB, similar to a Northbridge in your standard computer. And when you take a computer and want to make a transaction, you create your transaction on the computer. It goes through USB to the STM32. And the STM32 then forwards it to the ST31. The ST31 then says, oh, a new transaction. I want to ask the user to confirm it. So it sends a display command to the STM32, which in turn displays it on the screen. And then you press the yes button. Again, it goes the same route to the ST31, which then internally signs the transaction. So the seat never leaves the device. And our signed transaction goes back through the STM, through USB to the computer. To us, this means if this chip is compromised, we can send malicious transactions to the ST31 and confirm them ourselves. Or we can even go and show a different transaction on the screen than we're actually sending to the ST31. And Ledger is aware of this and will talk about how they try to mitigate this later. But first we have to find an exploit because while we do have debugging access to the chip, hardware access is sometimes kind of buggy, no offense. So we wanted to have a software bug. And so we started reverse engineering the firmware upgrade process. And when you look at the bootloader, the bootloader for the Ledger used to be open source. And back then they didn't have any verification of the firmware. So if you could basically boot the device into bootloader mode, flash whatever firmware you want, and then it would run it. After someone, Salim in this case, wrote about this, they changed it. And they changed it to do some cryptographic measure. And we were too lazy to reverse engineer that cryptographic measure because it's very time consuming, very hard. So we looked more at the parts surrounding it and how we can maybe find a bug in the bootloader to break it. And it turns out then when you try to upgrade your Ledger, it accepts four different commands. One is select segment, which allows you to select the address space at which your firmware will be flashed. One is the load command, which allows you to write data to flash. And then you have the flash command, which is basically like fsync on Linux and writes your changes to the non-volatile memory. And you have the boot command, which verifies the flash code and starts booting it. So to us, the boot command is the most interesting because it provides all the verification and attempts to ensure that no malicious image is booted. And it turns out that if you issue the boot command, it compares the whole image to whatever cryptographical function they use. And if it's successfully verified, they write a constant to the address 0x800 3000. And that constant is footbabe. And so to not have to verify the entire flash on each boot, they just do this once, so only after a firmware upgrade. So basically if you boot up the Ledger, it boots, it waits 500 milliseconds, it checks if you have a button pressed, if yes, it goes to bootloader, otherwise it loads the constant at 0x800 3000. And if it's footbabe, it boots the firmware. So our goal is to write footbabe to that address. First attempt, we just issue a select segment command to exactly that address. We just write footbabe to it, flush and reset the device. Didn't work unfortunately. So we had to do more reverse engineering. And it turns out that they use an interesting approach to ensure that you don't accidentally flash over the bootloader. So they basically blacklist a whole memory region. So if you try to flash from 0x800 four times zero up to 0x800 3000, it returns an error. If you try to directly write to footbabe, they thought about it and they have a very specific code path to prevent that. So they memset it to zero and you're screwed again. And then finally it writes assuming you didn't error out. But it turns out that the STM32 has kind of an interesting memory map. And on a lot of chips, you can not only map your flash to one address, but you can also have it mapped to another address. And in this case, the flash is indeed also mapped to the address zero. And so the bootloader uses a blacklisting approach. So it only excludes certain memory areas, but it doesn't use white listing where you could only explicitly write to this memory region. So they do not like writing to zero X zero profit second attempt. We just select the segment at 3000, which maps to 0x800 3000. We write footbabe to it. We flush, reset, and we can flush custom firmware. Awesome. So what do you do when you have a device that where the display is not big enough to run doom with a custom firmware? So in this case, it's an original ledger, press the button, put it into bootloader mode, which is part of the normal operation. And if you want to play a bit of snake, come by later. So how are they protecting against this? I've mentioned before ledger is aware that you can reflash this STM32 and they put in some measures to prevent you doing malicious stuff. And basically what they do, and this is very simplified and we did not bother to fully reverse engineer because we didn't need to basically. When the chip boots, it sends its entire firmware to the ST31, which then performs some kind of hashing or so, verifies that the firmware is authentic, and it also measures the time it takes to send the firmware. This is to prevent you from just running a compression algorithm on the STM32 and send it very slowly. How do we bypass this? So our idea was because we don't only have flash, we also have RAM. So what if we create a compromised and compressed firmware that copies itself to RAM? We jump to it and then it writes its entire compressed firmware to flash and compressed in that case. And then we just call the original code on the secret element. It will verify the firmware, it will run with a real timing and boots up regularly. And so we attempted this, it took quite a while to achieve because basically you can't do zip, you can't do LZMA because even if you compress the image, you don't have enough space for a complex compressor. So our attempt was to find duplicate bytes, squeeze them together and make space for our custom payload. And basically we just have a table that says, okay, now you will have six zeros or something. And our each table entry only takes a single byte. And it's only like 10 instructions in a sampler to run this decompressor. So you don't have a large code base, it's very easy to use. And it turns out that even with a very simple detector, like in this case we run the script to find the longest duplicate data. And you can see on the first try we get like 260 bytes of space for our payload, which is enough for a lot of things, let's say. And we have a working proof of concept of this and we would go into a lot of details but we only got an hour. And so we were released after this talk a non-offensive example of this that you can look at, how does it work, what can you do, even if you're from where it's attempting to be verified. And we also, and this is very exciting, we are working with YouTuber Life Overflow and he created a 20 minute video on walking through this entire food babe vulnerability, how the verification works and how to bypass it to a certain degree. We don't want to weaponize it so we did not, we will not release the full thing, but yeah, very excited for this. Stay tuned on our Twitter and we'll link it for sure. As part of this, we also have a lot of software that we will release. So public release will release the snake firmware. So hopefully this evening you'll be able to play snake on your ledger. If you bought some Bitcoin at 20,000 and now a bankrupt, you can at least play snake. We will open source the compressor and the extractor. We built a logic analyzer plugin for the smart card protocol and we built a software that analyzes the communication between the STM32 and the ST31 on the ledger specific data and you can just dump it. So if you guys are interested in, for example, trying to break into the ST31, please have a go. And ledger has a second device which is called the ledger blue. We assume the reason it's called the ledger blue is because it contains Bluetooth, but they never enable Bluetooth. So it's basically just a regular ledger with a color display and a big battery in it. And we call this part fantastic signals and how to find them. Because when we open up this device and we were chatting, we have this nice telegram chat room where we are chatting 24 seven while doing this. And we open up the device and the first thing like literally five minutes after opening it, I saw that you have the secure element on the left and the STM32 on the right. You have some other stuff like the Bluetooth module and so on. The trace between the secure element and the microcontroller is pretty long and contains a pretty fast signal. So what is the long conductor with a fast changing current? Anyone got a clue? Correct, it's an antenna. So I pulled out my Hacker F software defined radio. This is just a more sophisticated RTL-SDR so you can just sniff arbitrary signals with it. I got a random shitty telescope antenna on Amazon and I have my ledger blue. And so on this screen, you can see the blue thing is the radio spectrum around 169 megahertz. And if we start entering our pin, we can see that there's a weak signal. You guys see where this is going on the radio. Unfortunately, that signal is pretty weak. Luckily, they included an antenna. They call it a USB cable, but I'm not so sure about it. So this time with USB connected and we do the same thing again, you can see like crazy radio spikes and this is right next to each other, but even if you go a couple of meters, I was limited as Josh by my living room space. You get a couple of meters of decent reception. So our goal was to find out what is this signal? And if we just look at the recorded amplitude of the signal, we get this. And if you do a lot of probing and so on, you immediately see, okay, there are spikes and there are 11 of them and then there's a pause and then there's more spikes. So this is probably some kind of protocol that first sends 11 bytes of data, then pauses and then sends more data. So we looked at the back of the device, started probing everything, connection and try to figure out is this the CQ element, is this, whatever and it turned out to be the display bus. So we can sniff information on what is sent to the display remotely. And if we look at the signal that gets sent in blue is the signal that gets sent when you press the letter zero on the pin pad and an orange when you press the letter seven. So we can see a very clear difference at certain points on the signal which confirmed our suspicion. But building software for this is kind of boring, like digital signal processing is not really my thing. So what do we do? And we wanted to increase the password load in our talk a bit. And so we are hacking blockchain IoT devices using artificial intelligence in the cloud. So our idea was we record training signals, we use some kind of pre-filtering, we train an AI on it, profit, literally. Problem is getting training data really sucks because you don't want to sit there for 10 hours pressing the same key on a pin pad. It really doesn't sound like fun. And so this needs automation. So we took an Arduino, we took a roll of masking tape, a piece of acrylic glass, and then we put it in there. We put the masking tape, a piece of acrylic glass, a PCB device, and this is a Huawei pen for the extra amount of Chinese backdoor. And we let this run for a couple of hours. And you can actually see that every time it presses down, you can see that the digit that you pressed is highlighted. And the difference in the signal we saw earlier is probably the extent why coordinate of where it highlights the button. And that's the difference. We can see in the trace. And so we had a lot of recorded data now. We created a training set, we created a test set, pre-processing, TensorFlow, AI model. It's really easy, surprisingly. And we tried our test set, did a prediction, and so the big question, how accurate is it? And it turns out, so this is the result of a cut of the test set. And if we zoom in on this, this basically tells you we have the signal, this gray thing is just a picture representation of the signal. And it tells you how sure it is what digit it is. In this case, it's seven with 98% likelihood. So pretty good. In our test set, we only have one wrong result. And overall, we get around 90% accuracy. And to move this in the cloud, we are hosting this on the Google Clouds as the ledger AI for you guys to play with and we'll publish it online with a limited data set that is trained on a very close base. So you cannot do something super malicious with it, but it's nice to play around and see how this was done. And this brings us to the next part. Glitch me if you can, thank you. So now we're going to talk about the silicon level vulnerability, glitching attacks, fault injection. So to review, we'll be talking about the Trezor One. And so I just want to go over very quickly what the architecture is of the Trezor One and some previous work that was done. So the Trezor One is quite a simple embedded device. It consists of only a few components. It has a OLED display, it has some buttons and has a USB connector that are all externally facing internally. It has its main brain, if you will, is the STM32-F205 microcontroller, which controls all the other operations on the Trezor, the display, the USB and the two buttons. So last year, we gave a talk at DeathCon, breaking big-core hardware wallets. Here, we use the chip whisperer to mainly do the glitching attacks. The conclusions from last year is that the F205 was vulnerable to fault injection. But it was inconclusive if we could do an exploit via the fault. So this year, we have a different result, but the output of that work was this board, was called the Breaking Bitcoin Board. Basically, it was a Trezor clone that just made it easy to attach wires and probes. And so we made this board. The design schematics are all online. That's open source hardware. Now, this is the chip whisperer setup that we were using. So we made the board specifically to fit on the chip whisperer target board. And this is just what it looks like when you use the chip whisperer GUI to perform the glitch. And here we were doing application level code. So it was very different. But I gave that talk, and then I meant to meet you, Thomas. Yeah, so fortunately, we had Josh to do the talk last year and to kind of exhaust a lot of the firmware vulnerabilities that were actually hardware vulnerabilities in the firmware that might have been there. So we immediately knew that we could exclude this. And so you can start looking at the underlying microcontroller. So in this case, it's the STM32 microcontroller that they use inside of it, and it controls everything. So compromising the STM32 microcontroller means that you can compromise the device. So there's a couple of papers that have covered some of the vulnerabilities in the STM32. Specifically, there's one which describes a UV attack which lets you downgrade the security on the STM32s. So we determined that paper, unfortunately, does not apply to our result because the trizor is smart enough when it boots to check the value stored in Flash, and if it has been altered in any way to set it correctly. So they actually even protect it against this kind of attack, but nevertheless, you can see that there's some vulnerabilities. So there's another paper which unfortunately has not been published yet and we couldn't get in touch with the authors yet. That should be coming out in January, hopefully, which describes glitches against the STM32 F1 and the STM32 F3. So now we have the F0, the F1, and the F3. And so basically, here's the product matrix. So three of them are already vulnerable. So, but we're looking at the STM32 F2 and potentially the STM32 F4 if we're talking about the trizor model T. So those, we do not have vulnerabilities for yet. So let's take a look at how it works really quickly. So the way that STM implements security on the STM32 is that they store an option byte. And the option byte, the thing to remember is on a Cortex M3 or M4 microcontroller that you don't have anything other than Flash. So even though they call it option byte or refer to this as fusing or being permanent and hardware, it's still stored in Flash just like the user application is stored in Flash. So it's the exact same non-volatile memory that's otherwise used. So basically, when you get a new STM32 it's shipped in a state where you have full access. So that's how Josh was able to rework a board and flash it with new firmware. And there's the ultimate security is what's called RDP2. So there you have no access. But you can see that basically if you have a value other than AA or CC which correspond to RDP0 and RDP2 respectively then you have what's called RDP1. And this is interesting because it doesn't give you access to the Flash which is actually where the cryptographic seed is stored on the trizor. But it gives you access to RAM. It gives you access to the registers. But it doesn't give you Flash access like I said and it doesn't even give you single stepping as well. So connecting a debugger in this mode will actually cause the hardware to hard fault which we'll see in a second. So basically what we wanna try to do is to downgrade RDP2 which is what the trizor is set to and we wanna be able to access the device at RDP1 which is a somewhat vulnerable state. So this, so I should say that this is the correct way to approach this and it's great for doing an educational talk. But in all honesty, there's three of us and so we did this completely in the dark over three months trying different parameters on our glitch setups which I'll show later and we're able to find this but I'm here to explain it to all of you so that it's easy to reproduce. So if you actually watch the STM32F2 boot you'll see that it's relatively slow and it's only this slow after you power cycle the board. So it takes approximately 1.8 milliseconds to boot which is in microcontroller terms pretty slow. So you can see there's the power supply, there's the IO pin and that's approximately how long it takes to boot the firmware. So you can see that's where the IO actually toggles so 1.8 milliseconds later. So we just wrote some firmware to basically toggle one of the pins, measured it within a oscilloscope now we have the timing of how long that takes. So that's not super interesting because that's not really a trigger and each one of these microcontrollers internally it has a boot ROM so it has some ROM read only memory. It's not non-volatile memory, it's not the flash. It's literally a ROM which is inside the chip itself. It's hard coded, it cannot be fixed or patched that gets executed first. So we wanted to actually attack that because anything else is the user application and that's what Josh did last year. So you can kind of start to fiddle this down so you see that 1.4 milliseconds of the reboot nothing actually happens because this is now the reset line and so the reset line goes high after 1.4 milliseconds. So you can ignore the first 1.4 milliseconds after you cycle the power. So now the next step that you can actually do is you can connect what's called a shunt resistor. So oscilloscopes are there to measure voltage and so you want to actually measure current to be able to know how much power consumption, I mean how much power is being consumed by the device so you do what's called a shunt measurement and that's what I have on this slide right here. So the blue signal is now actually the power consumption and so now you can actually look and see what's happening. So the first thing that happens is we have the execution of the boot ROM so you can see in the power consumption curve you can clearly see this moment in time. Then you have basically where the flash and option bytes to actually get read somewhat at least within the boot ROM and finally the third distinctive moment in time is where the application actually begins to execute. So now we've taken this 1.8 milliseconds which is a relatively long time and reduced it to 200 microseconds that we're actually interested in. And not only that, we know that we're actually interested in having slightly higher power consumption than the normal execution of the boot ROM rather and this is somewhere between let's say 170 microseconds and 200 microseconds. So this is the time at which we actually need to glitch and this is also reasonable parameters if you're trying to reproduce this at home. So what do you need to reproduce this thing? So I, the greatest thing that came out in the last couple of years is these cheap Chinese power supplies where you take a cheap old wall wart from one of your old Linksus routers, you plug it in and then you actually have a controllable power supply with voltage and current and you can adjust this and control this. And so that's what we're using here. The second thing that I have on the, I mean, the second thing that I have to actually control the timing is an FPGA. I mean, I use FPGAs for everything and this is something that was easiest to put together with an FPGA because FPGAs have constant timing. So finally we have a multiplexer there as well and the multiplexer is actually switching between two voltages, between ground, so completely cutting the voltage off and the normal operating voltage of the microcontroller. And finally we have a debugger, the J-Link, which is highly advised if you want to ever do JTAG stuff. So it's just a JTAG debugger and basically what happens is you let this run for a while and it looks like this. It's not really super, super eventful. So you can see that the voltage, the yellow signal is actually the voltage and you can see we're just dipping the voltage at different points in time and simultaneously we have a Python script checking if we have JTAG access or not. And so pro tip to all the new dads, if you do this at home, you can turn your oscilloscope towards the door so that when you get up at night because the baby's crying, you can see if it's still running or not. So it's highly advised. So now Thomas is gonna tell us how to get the seed into RAM. Yes. So we had this thing running for three months roughly across three continents because Josh is in America, Dimitri is in Russia and I'm in Germany. And so it took us three months to get a successful glitch and even then we didn't believe it at first because we exhausted everything basically. And the only reason we finally got it working is that we did a mistake where we mistook 70 microseconds with 170 microseconds and had it run for a longer time. And that's how we found out that the boot ROM is actually super slow to boot on this device. But, and so once we had this downgrade from RDP2 to RDP1, we were able to read the RAM but we cannot read the flash which actually contains the seed. And so how do we find this? And our idea was we start reviewing the upgrade procedure because on the Trezor, the way the boot loader works it doesn't require your PIN or anything to upgrade the firmware, which makes sense because let's say you have a bug in the PIN function, you want to somehow be able to get rid of it, right? And the other thing is if you flash a fully valid firmware it retains the data, it retains your seed. If you flash a non-genuine one it actually will erase your seed and so on. And the big, and they do a really good job on the firmware verification. We reviewed it for days and days and days and didn't find anything. But so how does this upgrade procedure work? How is the seed retained? And so when you review the relevant code you see that there's a call to backup metadata which sounds like it's going to retain somehow your data. And indeed you can see that it's literally a mem copy from the data on flash we are interested in into RAM. And so our basic procedure was we go into bootloader, we start a firmware upgrade and we stop it before the RAM gets cleared. Because if you finish the upgrade procedure the treasure actually clears its memory again which is a very decent way to do it. But we found a way to retain it in RAM. So it turns out that when you start the firmware upgrade process it eventually asks you to verify the checksum of what you just flashed. And it turns out that at this point in time the seed is still in RAM and we can read it out via RDP2. And this is relatively simple to do once you actually manage to glitch the device. You basically just run open OCD dump image, you get an image of the SRAM and you have the whole RAM contents. And so how? What are we gonna do Thomas? What are we gonna do Thomas? What high tech hacking tool will we be using today to extract the seed? So we actually, before we were successful we had hours of talks on how do we, how is the seed stored and so on. But we found this super sophisticated seed extraction tool that only runs on POSIX and POSIX-like systems. It's called Strings. And so basically it turns out that when you have a firmware dump, if you have a RAM dump as we do now and we go to, we just run Strings on the dump, we get a couple of really nice words and I don't know if you remember the intro, but this is your seed. And you might be wondering what this little number is, this is your pin to the device. That was a great day. And so Josh or one of Josh's employees took all this mess we created on all desks and made it into this nice device, which is basically a socket where you put in your chip and then we can read out the seed and so on. Yeah, and so all of this stuff including the board design, the FPGA code, so the Verilog code that we used, I mean, if somebody wants to, they can apply it and do the same thing with one of the ice sticks or one of the more open source friendly FPGA boards. This just happens to be the one that we all had lying around and could reproduce the work with. You can go ahead and do it. I mean, we suspect, I think Thomas said, we suspect you might be able to do with an Arduino as well because the actual glitch pulse is only approximately 60 microseconds, or sorry, six microseconds in time. So it's a relatively slow signal as well. So it should be relatively repeatable even with something cheaper than this, but this is a way to automate this even better and to not have dangling wires or any of the small soldering that was required to do it in CEDO in the device, which we had on the previous slide. So all of that we're gonna have on GitHub. And so I think the final thing. One more thing before we are sorry. One more thing. So this breaks a lot of the Trezor security, but there is a way to protect your seat against this. So if you use a passphrase on your device, the way we understood it, it basically doesn't allow somebody with hardware access to steal all your funds. So if you add a passphrase to your Trezor, a good passphrase, and your machine is not already owned, you can somehow, you can somewhat protect against this. But a lot of people don't. So we are really sorry. We didn't mean any harm. I mean, yeah, that's the conclusion, I would say so. So yeah, I mean we, so all this stuff we're gonna put online, I guess I said, so you can follow us for the links on the online. So wallet.fail, it's a domain name. Believe it or not, fail is a TLD. So you can go to github.com, wallet.fail, twitter.com, wallet.fail. You can follow me, Thomas and Josh on Twitter as well. And like I said, we'll be releasing all this stuff. So it'll go up slowly just because I think when we set out six months ago, we did not expect us to have 100% success in everything that we were planning to do. So that's a first for me at the very least. The saddest part is that we have more vulnerabilities to other wallets, but only one hour. And so we also have some stuff to give out. So we have the hardware implant PCBs. We have a thousand of them if you want to get some. Talk to Josh. Yeah. We even have components for them for like 100 devices. So hit us up and we can do something. Thank you. Amazing talk. I feel really inspired to break things apart in a very creative way. We have some time left for questions. So if you have questions, please line up at the microphones. But first, we are going to start with a question from the internet. Thank you. My proxy two related questions from the internet. First one, how hard did you guys know when Bitfi announced that their Android-based wallet was unhackable? And the second question, have you ever tried to attack larger processors like ARM-based processors? Yeah, so maybe let's start with Bitfi. So we only talk about somewhat secure wallets. We didn't want to use a Chinese phone in this talk. So we laughed pretty hard and we ordered some, but yeah. Yeah, and I mean, this was covered extensively. So another guy who you should follow on Twitter, Cyber Gibbons, gave a talk at hardware.io on the topic of the Bitfi. He was summarizing research that he did in conjunction with a bunch of other people as well. So if you're interested in the Bitfi, you should go look at them. So the second question was about ARM-based controllers. I mean, all of these were ARM-based. Every single chip, as far as I know, that we looked at was ARM-based in one way or another. And so if you're interested in this, look at glitching the Nintendo Switch, where they glitch the TACRA used in the Nintendo Switch, which is very interesting and will give a lot of inspiration in that regard, basically. Thank you. A question for microphone four, please. Hi, I'm Professor Sinti Okio. First, thank you for the talk. And we were fixing the issues as soon as I read the microphone. And if anyone is interested in hacking hardware wallets, we are really interested in working with the provider, Hacker's Community, and we have a responsible disclosure program. You mentioned problems with supply chain attacks, but now we'll build solutions. So let me give you one, like Trezor is open source hardware, so you can build your own from locally sourced components. And if you are paranoid, I don't want to deal with all these kind of attacks. But my question is, is there any other solution except for building your wallets, or inspecting the port one and tearing it apart, basically? So maybe first off, thank you. One thing we should mention is that when we looked at the Trezor code, the reason we had to end up glitching this chip for three months is that we couldn't break the firmware otherwise, so they do a great job and it's really awesome. So I mean, yes, the firmware on the Trezor is something to look at. I mean, I recommend that, I mean, we all do consulting work as well, and so it's something that I recommend that people who are interested in looking at how to prevent certain due mitigations in hardware, it's an excellent project to look at, and so Trezor should be commended on that. But at the end of the day, it doesn't mean that the chip that the Trezor uses is secure against these kinds of attacks, and that's where we had to fall back to looking for silicon vulnerabilities against a chip like the, or sorry, a wallet like the Trezor. I would say on this hygiene side, this is a very difficult problem. Governments especially have this issue. You can do cryptographic on this issue, as you saw with the legend, that the applications can help verify the device is genuine against the hardware. So there's been talk about X-ray and forward and stuff, but I think this is still very much an open problem in here with security. Another question from microphone three. Actually, I have a suggestion. Make it short though, because usually we just take questions. One sentence. A few MCUs actually have JTAC connected via hardware fuses, so this might be used to at least slow down glitching attacks, right? I agree, but these are not Cortex-M microcontrollers. I can tell you that with 100% certainty. It has to do a lot with the fact that the microcontrollers that are being used in these devices, they're built to spec, to the spec that ARM specified, that ARM thinks would be a good set of features for this class of device, or rather for the CPUs for the class of device that they ended up getting put in. So anything Cortex-M is gonna have vulnerabilities that are more or less like the silicon vulnerabilities that we had. It's just a, I mean, if you ask me, I think it's a matter of time just to sit there. I mean, fortunately, we had something like three months of just glitching to be able to find these bugs, but if you can apply that much to find a silicon attack, you might be able to find this kind of vulnerability as well in other Cortex-M products. Only three minutes. Oh good, another question from microphone four, please. So obviously as part of your work, you analyzed the firmware of these devices. Did you find that the firmware was in any way obfuscated or encrypted? So basically, on these chips, you cannot really encrypt the firmware. On the ST31, you can encrypt it, but we didn't have to look at it because the ST31 is not something you have to break. But so no, there was no real obfuscation that we could see. But we also don't have the code in the case of ledger, so I just stared at Ida Pro for hours and yeah. The next person on microphone four. Hello. Did you look at the entropy that generates the master seed on both of these hardware devices? And what's your take on that? I mean, so we already covered how the Trezor works. So there's only one chip and it's the ST32. So I know that there was a known issue with Trezor back in the day where they weren't seeding basically the RNG correctly, but this was fixed. But for our attacks, this wasn't an issue. I mean, if you were concerned about how strong these are, how strong the random number of generators are for creating a seed, you could actually create a BIB39 wallet outside of any one of these and then just use them for their hardware features and I mean, get the seed from outside. And if you have a question, do move to the microphone if you're able to. But first, we have another question from the internet. Thank you. Did you guys see the Dinosauria Hip Hop Zero monitor? No, but if you send it to us, we are happy to look at Dinosauria. Oh, you did? Yeah, we did. Oh. Thank you for the kind of trick of the measurement. So the design of the Dinosauria Hip Hop Wall was a Trezor clone that we looked at last year to help you with your big report. So, I mean, otherwise partially it was a Trezor clone, but we saw all of the instructions from Dinosaur Hip Hop deep in the region, if we forwarded it, it would carry out the results. I mean, and maybe on that note, I would say that in terms of looking at what wallets are actually being used, you'll find that, I mean, so the ledgers of a very popular wallet, the Trezors of a very popular wallet, but since the Trezor is open source, there's a lot of clones and forks of the Trezor and when I say that, not all of them run the latest security patches that have been applied to the Trezor code base. So that's also something that you can do is basically diff the projects and see which ones are staying up to date and which aren't. Your question is to be the very last one today. Please speak directly into the microphone. Even closer to the mic. Seeing as this is the first CCC for many of us and some of us might not have much experience in hardware hacking. Do you have any tips for beginners? Yeah, lots of them. So buy an Arduino, learn what mistakes you do with it and learn how hardware works basically. Watch a lot of online videos and I think you gave presentations, you gave presentations, I gave some presentations. So just watch talks, watch Life Overflow, Life Overflow, great YouTube channel on exactly this stuff and yeah. And also don't hesitate to reach out to us. If you have a question, always contact us, info at walletfail, on Twitter, wherever. We are happy to talk to you. It might take a while, but yeah. It's funny though, it was hard fun or either for you. It was a free material, just all the time it's work and how it gets started. It's not security related though, it's very good real time. But I'll say I started with Arduino too. I mean, I didn't even mean it. All right, thank you guys so much for the very nice questions and you guys for the amazing and inspiring talk. Thank you so much.