 Hi. Hello, everybody. I hope that you are enjoying the Congress. And I hope that you enjoy my presentation. For the next 45, 50 minutes, I will talk about hardware attacks, hardware security. More specific, I will talk about fall injection. And I will talk from my experience as professional evaluator that has been using fall injection and other hardware techniques for testing products. So maybe you don't know what is fall injection. So the first thing I will do is make a short introduction to fall injection. Then I will talk about real attacks on the real world, products that have been hacked. And then I will introduce some of the techniques or some of the tests we do on the products we evaluate. And finally, I will talk about protections, how to prevent these kind of attacks. So let's start with this. Let's take a look at this code. This is a code I took from somewhere, from a product. It's kind of the code I found. This code authenticates a PIN or a password. If you take a look, there is free software vulnerabilities, free problems. So an attacker can bypass the PIN check, the PIN authentication, in three different ways. So first, here in red, I mark, there is a problem with this loop that iterates through the password, through the PIN. This loop only iterates as many bytes as the user provides. So if the user provides one single byte as password of PIN, only one byte will be checked. Then here, there is a buffer overflow. The software does not check how many bytes you provide as a PIN. So the buffer can be overflowed, and the attacker can get runtime control of the target. And finally, we have format stream vulnerability. So all these three attacks are very common, are very well known, and they are very easy to fix. So this could be a possible solution. In blue, there is the changes that could fix this software. So we fix the loop. We put a limit to the number of bytes. We get as a password or as a PIN. And finally, we format properly the string. So is this now secure? Well, from the software point of view, probably it is. I don't find a way that you can attack this code from the software point of view. I think that all the issues are fixed. But if the attacker has physical access to the device that is running the software, if he can get this device, because this is running on a smart card or an IoT or any kind of embedded device and has access to it, then the attacker can try hardware attacks. And I will talk today about one hardware attack, which is fall injection. And this code has at least four places where you can inject a fault. And you can bypass this check. So in red, here, here, here, and here. So I will explain what is wrong with these sentences and why you can bypass the check here. But before that, let me introduce myself. My name is Ramiro. And I am a technical lead at riskier security lab in China. So I work actually here in China. We have a security lab here in Shanghai. My company is specializing in hardware evaluations. We evaluate chips. We evaluate socks, embedded system, IoT devices, automotive, mostly hardware, sometimes some software as well. We also do hardware. We develop hardware for testing the security, hardware security. OK, so let's talk about fall injection, how this works. So if we check the documentation of a chip, if we have a chip that has been used to develop a device, if we check the documentation of this chip, there will be probably something like this. In the data sheet or in the manual, we will find a plot like this, which indicates what is the safe area, what is the voltage you can use to power this chip. Sometimes it's a plot like this, sometimes it's a table. But the manufacturer tells that this chip can operate between 1.8 volts and 5.5. But what happens here in this area in red? So if we try to power the chip with below 1.8 volts, or 5.5, what happens? Manufacturers will not tell you. They will only say that the behavior is undefined. So what actually is happening? OK, so it's obvious that if we power the device above the specifications for some time, we will hit the chip and we will kill it. We will burn. In the same way, if we operate the chip under voltage for some time, we will switch it off. We will put it to sleep. It will not be powered, so it will not work. But the question is, what happens when the chip is going beyond the specifications for a very short period of time? So for just a few nanoseconds, a few microseconds, we exceed the voltage limit above or below. So this is what we call a glitch. And this glitch might introduce folds in the chip. And an attacker, by doing these glitches, the attacker can get some benefits of the chip. So let's see what happened inside the chip. So this is my CPU. This is a chip. It's powered with external power supply. This CPU is composed of different modules. It has a rheumatical logical unit. It has a control unit, S-rank, gas. And all these modules are powered using a power distribution network. Inside the chip, there is a network that powers a different circuitry. If we look at this power distribution, some modules are closer to the power pins. Some modules are farther. So some power lines are longer, and some are shorter. So this power line, for example, is very close to the pin where the chip is powered. So the power distribution line is very short. And the control unit is powered with a long power line because it's farther from the pin. And because it's longer, the resistance, when the currents flow through this line, the resistance will be higher. So the different modules will have different length in the power line that distributes the power. And these different modules have different capacitance. This resistance and this capacitance creates filters. So when I inject a glit, this glit, not all the modules inside the chip will see the same way. Depending the shape of the glit, how long is the glit and how deep is the glit, what is the shape, some circuits will filter the glit, and some others will not. So in this example, I have here the Arimatical Logic Unit because it's very close to the power pin. The resistance of the power distribution line is very small. The filter is very small. So the glit, if an attacker injects a glit, it will be affected. But the control unit will not because it's farther and it's filtering the power better. So an attacker by injecting different glits with different shapes can affect different modules inside the chip. And what exactly he can get when he injects the glits? OK, so we have this effect, and the attacker can get the following. So the first is that he can disable the modules. So we saw before here, during the period of time that the glit, that we are glitching the device, the chip, during that period of time, the Arimatical Logic Unit is under power. So it's not going to work while the rest of the chip is working normally. And after the glitch, everything works and operates normally. So an attacker can try to inject glits, hoping that a hardware security module or feature in the chip will stop to work during this small period of time that the glit takes place. But something that an attacker cannot suspect when inject glits is flipping bits. Flipping bits, a story inside the chip, on the memory of the chip. So this is a flip-flop. This circuit is the standard memory cell. This is the basic unit that stores information inside a digital circuit. So any SRAM, any register in a CPU is composed of many of these flip-flops in Sirius. Yeah, it can store only one single bit. So here, this flip-flop is storing one bit, and the value is one, is what we see in the queue, output of the top right. So if an attacker injects a glit, and this glit makes the power of the gates of the flip-flop to go lower than the threshold level, the voltage threshold level for the decision of whether the gate is getting a 1 or is getting a 0, the NOR gate will see, instead of a 1 in this place, will see a 0. And this 0 will be propagated through the flip-flop. Then when the glit is over and the voltage gets normal, the flip-flop remains will keep the value of the flip-flop the value of the flip-flop. So using a glit, we managed to change the content of a memory cell from 1 to 0. But we can do the same to flip from 0 to 1. So it operates in the same way. So what else can we get with glits? So with glits, we can also corrupt the code that is being executed in the CPU. So this is the code I showed you at the beginning. And I told you that here, the red line is a place I can inject a fault. I can use glit to bypass the secure check, the pin check. So why this happens? If we take this sentence in C and we compile in ARM, for example, we have this assembly code. These three structions do the same that we have here in C. If we look at how the assembly instruction for the branch is encoded, we look at this. This is how the branch is encoded because we have a tool, which is the glitches. We can use the glitches to flip bits. If we use a glitch, and this glitch happens to flip one of the bits in the struction that is being executed, the CPU will execute the instruction in a different way. So in this example here, if we flip the first bit from 1 to 0, I will not execute a branch. I will be executing a store instruction instead. So my code changed completely. Here in the top left, you can see what is the actual code I'm executing. So with one glitch, I can change the flow of the code. I can change how the code is executed. Another example, the next instruction in assembly, the store, is encoded like this. If we glitch up and we change one of the bits from 1 to 0, the instruction is executed in a completely different way. And again, we change the flow, we change the code, how it's executed. We change the software that the chip is executing. So an attacker can inject glitches, hoping that he will flip the bits that he needs in order to change the software in the way he is looking for, to skip instructions or to corrupt instructions or to do whatever he wants. What else? An attacker, yeah, when he's trying to inject glitches, sometimes because we are putting the chip above or under the recommended voltage, sometimes we can destroy the chip. This is something as an attacker we don't want, but sometimes we will kill the chips, we will kill the CPU. But this doesn't happen too often, to be honest. OK, so this might be a bit strange for you that you can use voltage glitches to just change the code that is being executed and bypassed security protections in a hardware device. It sounds strange, but the truth is that this has been used for many, many, many years already. And there is many things that have been hacked using full injection. And now, because we have all these new IoT devices and because the security, the software security, is being increased, many hackers phone out that nowadays it's easier to hack an IoT device, embedded device. It's easier to hack using hardware techniques than using software techniques or software attacks. So for that reason nowadays, basically almost every few months, we see a new attack, somebody that is doing something with full injection and is getting some results. So I took this from Twitter a few weeks ago. Somebody was publishing. He managed to break embedded TLS using full injection. A couple of years ago in Defcom, there was somebody who was presenting how to bypass the authentication of a Tracer, a Bitcoin wallet using full injection and video game arcade machine. But 30 years ago, kids were using these lighters that have a spark, spark lighters, that when you press the button, there is a spark. So they were using this spark to shock the arcade machine or the video game machine and play for free. And this was 30 years ago, and this was a way of doing full injection or glitching. And kids were doing this even without knowing it. Funny thing is that still nowadays, 30 years later, this is a very common attack. I found this video on the internet. This is a guy who sells this device. This is a device who makes full injection, is doing glitching, not with voltage, but with EMP, electromagnetic pulses. So this small device generates electromagnetic pulse, and these pulse generate a glitch. So he's putting this device close to the electronics that counts the coins. And you can see here the counter that counts how many coins you insert in the slot machine. And it's increasing as long as he's pressing the button to glitch. And he can play. So he can just play and try to get the price of the machine. So this is another example of real world full injection attack. OK, so these attacks have been there for long. And some industries know this. So some industries like smart cards have been tested against full injection for many years already. And I have been doing this, testing against full injection for quite a long time now. So I will explain some different tests or different attacks we do on real products, on real products that we evaluate for customers. So before going through these examples, I want to introduce you the first rule of full injection, which is everything can be hacked with full injection unless you protect against these kind of attacks. And the second rule is that even if you protect your product against full injection, it might be hacked, because full injection is really difficult to prevent. And there are many ways that it can be used to attack a product. So let me show you some examples. I chose five different examples of tests we do on real products, where we use full injection to try to bypass some kind of security. So the first one is bypassing authentication. This is what I explained before here, this pin authentication. I have some demos. I brought with me some tools. So if you are interested to see this in real life, I have my tools in my back. I wanted to do some demos, but it's very hard to do demos here. So I make a video yesterday of this. This is the tool we use for injecting glitches. So the small green board is a processor. It's just a small embedded device with an ARM chip. And the green box, the green jello box, well, the jello box, the big jello box, is the tool we use to inject glitches. So this tool powers the CPU and your pyramid in such a way that you inject a glitch when you want. So I made a program that is trying to bypass authentication of this code I saw you here. So what this program is doing is sending, waiting for the chip to send you the message, insert a pin, sending 0, 0, 0 as a pin in that moment injecting a glitch and reading the response. If the glitch succeeds to bypass authentication, then I will have a pin correct. If not, I will have a pin incorrect. Sometimes I will have a response, which is random garbage, because sometimes the chip crashes. So this is the operation of this attack I made a video yesterday. So most of the times we see that the pin is incorrect because we don't succeed on glitching properly. From time to time, this will be a pin correct here. There it is. So this was one attempt. We have to try many times until one of the glitches affect the chip in such a way that bypass the software the way we are looking for. And sometimes these lines, which are empty, is because we crashed the chip, because probably the software crashes or jumps somewhere, I don't know. This kind of test, trying to bypass authentication schemes, we use this a lot on a smart card. Basically, there is no smart card nowadays on the market that has not been tested against these kind of full injecting attacks. We also test this a lot in smart meters. Smart meters, they have the bug interface, so an operator can physically go to the meter and debug it. And there is an authentication protocol to be able to debug the smart meter. We recently tested a couple of Bitcoin wallets and password wallets. Basically, any kind of device with some kind of linus, normally linus, you have a UART port with some kind of shell. And you need to know the password to go in. You can bypass quickly using full injecting. And also automotive. Yeah. It might be not trivial why or where there is some authentication scheme in a car. We use full injection to bypass UDS. UDS is a protocol, a diagnosis protocol that is implemented in most of the cars in the market or most of the new cars. This protocol allows to get locks from the car, do some diagnostics on the car. So if something is failing, you can use this protocol to see what is failing. And one of the features of this protocol is that you can extract the firmware and you can change the firmware. You can upload a new firmware. So this is very interesting from the hacker point of view. If you can recover the firmware and then you can change and put a backdoor or something like that. So how this, well, to prevent hackers to access to this protocol and get the firmware or modify the firmware, there is some kind of authentication scheme. This authentication is just basically a challenge response. The car sends a random number. The random number is encrypted with a secret password. The response is sent to the car. And if the response is correct, the cars allows you to debug using this protocol. So we can use full injection in the car or in the ECU, which is the computer of the car, to bypass this check. So probably there will be a code like this one where we check if the key that we receive is the correct one. If not, we just jump to a place that probably will reset the car or will just ignore the authentication. So we can just use a glitch to corrupt these extractions in such a way that they are not executed. OK, what else we can do? We test a lot of secure boots. So secure boots, probably you know, is a security feature that is implemented in many SOCs and many CPUs and many devices to be sure that only software that has been signed and has been authorized is running on the device, on the CPU. So normally this is ROM code that is in the chip that at boot time authenticates, calculates the signature and authenticates the signature of the software that is stored in the flash before loading into the ROM and executing the code. And normally there is a chain. So there is different phases, different stages, where we are authenticating different parts of the firmware. This is used a lot in smartphones to prevent anybody to just put any firmware or custom ROM in the phone, especially if your phone supports IoT and we test a lot of this. We test a lot of secure boots in the phones to check if they are secure. We also test a lot of pay TV systems or smart TVs. And basically almost nowadays almost any IoT device or embedded device have this secure boot. So routers or cameras, whatever. Almost every device have one of these secure boots. We test them to be sure that nobody can use full injected to bypass them. How can you bypass a secure boot with full injecting? Well, if we have a tool that allows us to skip extractions or to corrupt extractions, then it's very easy to do it. Whenever there is, well, when the secure boot is checking the signature of the necessary states, we can just inject a glitch, prevent the execution of that check and bypassing it. So this is a code of a simple secure boot that loads the flash image and then calculate the hash, check the signature, and then compare the hashes and the signature. So here in this code, we can inject the glitches in many different places. So like here or here, here. So all these red lines are different places that we can easily inject a glitch and bypass the secure boot. But the problem here is that a secure boot is kind of complex. And there are many, many, many ways to bypass it. There is many instructions that when we corrupt them, we can just skip the secure boot and bypass it. And this is something that is very complicated to protect. So I was introducing before the second rule which is that when you want to protect your device against full injection, you try to do your best. And sometimes you fail, because it's very hard to protect it. When we have many customers that try to protect the secure boot against full injection, they find the most obvious places where we can inject glitches and they protect these places. But then we test the product and we find that there are many different places that they didn't consider that you can inject a glitch and bypass the secure boot. And sometimes it's not obvious. So we develop a tool. We develop this tool which we call full injection simulator that simulates all the possible glitches on the code and tells you which ones will allow you to bypass the secure boot. So this tool is this one here. We load the secure boot or any code we want to test. And then we'll compile for the platform that this code is going to be running, ARM normally. And then we can just press the button Simulate. And it will compile the code and will try to simulate all the possible glitches on all distractions of the code. After running the simulation, well, it will take some time to find all the glitches in the right side. Here in the right side, we have the different glitches that the tool finds. It takes around five minutes to do this. It depends, of course, on the size of the code. And then at the end, we have a list of all the possible glitches. This is our assembly structions that if you inject a glitch and you flip one single bit, will allow you to bypass the secure boot. So with this tool, we can easily identify potential vulnerabilities in the code and try to mitigate those vulnerabilities. I have this tool here in my computer. If you want to see how it works, just let me know. I will be around so I can just show you the tool. So more attacks we test. We test escalation of privileges. So quite often, we are in the situation that we have a product, we have a device, and we have only restricted access to this product. And we want to break out of this restricted access and be able to execute or get full control of the box. So this happens in many scenarios, but the most two common ones are when we have a user space control and we want to break into kernel space. Or we have RE control, and we want to break and get control of the TE. So just to put an example, breaking the TE. There is a technique we use a lot. We call this a wild jump attack. I will explain how it works. This is a TE system. This is the memory segmentation of a TE system. The RE can only access to the RE memory, and the TE can only access to the TE memory. There is a CER memory, which is the mailbox. So when the RE wants to send a message to the TE, this is done through the mailbox. Put the message in the mailbox, and the TE will read it. And the other way around. So this attack works as follows. The RE, who is under control of the attacker, because maybe the attacker can run an application on the RE, the attacker puts a payload, a malicious payload, on the message box. This is the payload that he wants the TE to run. And then he expires the memory with the payload address. He expires the rest of the mailbox and indicates the TE that there is a message to read. The TE will read this message, normally using a main copy or some kind of similar function. And this main copy, what normally does is load from an address, copy to a register, and then from the register to a different address. So if the attacker injects a glitch when the address of the payload is being copied, and this glitch happens to affect the load instruction, this load instruction is encoded like this. If the glitch happens to change a few bits like this, what we have is that we copy the payload address directly into the per encounter, into the PC. So we are basically forcing the CPU of the TE to run our payload. And then the attacker gets full control of the TE. And we can do exactly the same for breaking from the user space to a kernel space. We use this kind of attacks as in all these devices I mentioned before in phones, normally in phones where there is a TE and we want to test if we can break the TE to access to the secrets of banking applications, of payment applications. We use this with Linux systems, Linux products. And we use this in Android phones or devices to see if it's possible to route these devices. And we do this a lot on any kind of device that implements arm trust on the TE. OK, something else we test. We try to recover crypto keys using full injection. This is quite complex. There are many different ways of doing this. There are many techniques. There are many papers published out there that explains how using full injections you can get keys from a system. So I will not go through this full analysis. This is called full analysis. I will not go through this because it's very complex. This basically is based on injecting a glitch on the internal state of the cryptographic algorithm in such a way that these glitches affect the internal state by analyzing how the error that you introduce is propagated you can try to recover the key. This is very complex. I will not talk about this. I will talk about something simpler, which is that many devices that are worst or operate with cryptographic, many devices that have crypto engines, they normally have a key slot. This key slot is a place in the memory or region or registers that stores all the keys. And these keys goes to the crypto engine. And normally these keys in the key slot, there are attributes. These attributes indicate which key can be used with which algorithm. So for example here, we have the key number one can only be used with AS because in the attributes, it says that it's only possible to use with AS. If somebody tries to tell the crypto engine to use the key number one with a desk, it will not work. The engine will not accept the operation because the key has no permissions to be used with this. So here we can use full injection to change this attribute table in such a way that we allow operations that we were not supposed to do. So now, for example, in this case, we change the key number one so we can use with this. Why we want to do this? Because this is very easy to break. We can brute force this. So if we can use full injection to force a key to go into the desk engine, we can then use brute force to recover this key. We use this in all the devices I mentioned before, plus white box crypto. White box crypto is a kind of obfuscation technology or kind of DRM technology. It's not the same, but kind of DRM technology. It's a way to obfuscate the crypto operations. And we use this full injection to recover the keys from this white box crypto. Finally, my final attack or final example, modifying security configuration. So if a chip or a system has security features, those features have to be initialized at some point. Normally, this happens during the secure boot or this happens at boot time. There is a software that enables the security features. Like, for example, it blocks the JTAG or enables the memory scrambling or, I don't know, whatever. So this normally happens at boot time. So because we saw how glitches can be used to bypass instructions or to corrupt instructions, we can use glitches to prevent the initialization of these security features. But there is something else we can do. After the system is initialized, after the system is running and the security features are initialized, there will be somewhere in the chip one bit that indicates that the security feature is enabled. So if we can inject a glitch and chain that bit from 1 to 0, we can disable this feature. And we can do this glitching. The thing is that if we inject voltage glitches, we use voltage glitching to try to flip this bit. We will need to try a lot of times before glitching the specific byte or, sorry, the specific bit we are looking for. So there is a different technique. We can use what we call localized fall injections. This is a tool that allows you to inject a glitch in a specific part of the chip. So if you know where is this bit that you want to flip located in the chip, just with this tool, you can just flip only that bit. So we use electromagnetic fall injection, electromagnetic pulses, like the video of the slot machine I showed you before, only that we have more precision because it's a proper tool. And we also use lasers. We use the laser to hit the surface of the chip, and the photons will open or close transistors, making the bits to flip from 1 to 0, from 0 to 1. This video shows how we use lasers to test a chip. So this chip is, again, an ARM processor. You can see here a blinking light. This is actually the laser. We are shooting with the laser on the surface of the chip. So what we are doing is we want to disable a feature. We know there is a bit somewhere that disabled this feature. So what we are doing is inject a laser, inject with the laser a pulse, try to see if the feature is disabled. If not, we go to the right. We move the laser a bit to the right, and we inject a glitch again. And we try, try, try until we find which is the place that when we inject a glitch with the laser, we flip the bit we are looking for. This is a setup of EM fall injection. Here we are using an EM transient probe to do the same on the board. OK, and I have been talking about fall injection, about attacking. I'm going to talk now about preventing. So if we want to protect our products against fall injection, we can choose hardware protections or software protections. Which one is better? The thing is that rule number three, if you want to protect your product, you have to use both hardware and software countermeasures. The thing is, the problem is that most of the times, we are just using a third party chip. We are using a chip from somebody else. We don't have control on the hardware, so we cannot make changes on the chip to protect the chip against fall injection. So we have to use only software countermeasures. Still, it will not be perfect if you use only software countermeasures or protections. It will not be perfect, but it will improve the security of your product really a lot. Really. So if we use hardware countermeasures, normally what we use is we put in the chip, we put giz sensors. We put sensors at the test when the voltage is going down or up very fast. And if we get this glitch, we can just reset the chip. Or we cannot redundancy. So we want to protect a bit that we know that an attacker wants to flip it, because it is a bit that enables or disables security features. We can add extra bits to protect this bit. We can add parity bits. So if somebody flipped this bit, the parity will detect the flip. And then the chip will, well, you can reset the chip. You detect that there is a glitch. Parity mismatch. Software countermeasures, we can use many techniques to protect your software. I am going to mention the most useful and simplest ones. And if you use this, you can improve a lot the security of your system. So this is the code I have before. And with a single glitch, we can bypass this authentication. So how to prevent this? We copy paste the code twice. So we put the code twice, so the attacker can glitch the first time. But the same condition will be checked later. So the attacker, if he managed to glitch the first time, the second time that you checked the condition, will fine. So we can copy paste the checks. Of course, the attacker can do a double glitching. He can glitch twice. But this is much more complicated than a single glitch. OK, here, if we just managed to glitch the first time, the second time that we check will detect the glitch. OK, something else we can do is software countermeasures, something else we can do is adding random delays. The idea is that the attacker needs to inject the glitch when the structing that he wants to corrupt is being executed. So if we add a random delay before this place that we want to protect, the attacker will not know when this structing is going to be executed. So he will not be able to inject the glitch. So this is a very effective way to prevent glitches. There are many more. There are many more. I have a link at the end that you can see more techniques to protect your code. OK, and to finish as conclusion, I will conclude with these three rules. Everything can be hacked. Any hardware can be hacked if you have physical access to it, as long as you don't protect this hardware against full injection. So you can put a lot of security in your device. You can do many reviews or you code. You can do many penetration testing, trying to find vulnerabilities in the code, software vulnerabilities. But then a hacker can get your device physically and use one of these hacking techniques and bypass everything very easily. So you should also make an effort to protect your hardware against this kind of hardware hacking techniques. The second rule that even if you protect against full injection to your product, you have to keep in mind that it's very hard to do it. And still, you might be hacked. And finally, remember that if you want to protect your product, you should always use hardware and software countermeasures. If you are interested in this topic, this is a list of links. All the attacks I have been describing, we wrote my colleagues and I, we wrote different papers. The first one is a paper about how to protect your software against full injection and side channels. I think it's very interesting. So if you are interested, you can read this. And finally, well, if you are interested, we are hiding. We have a security lab here in China. So if somebody of you is interested in this kind of hardware security evaluations, you can just join us. OK, thank you. Thank you for listening. And if you have any question, please. I think there is a question here. Microphone? Sure, I'll moment you. Yeah. Hey, I'm just wondering, I mean, how practical is your approach to use the, I mean, it seems like pretty much a brute force. Sorry, I cannot listen because the audio is going that direction and there is a lot of echo. So I cannot hear. OK. I'm just wondering how practical is your approach? It seems to me that you're just using brute force to try different points to see if there is any possible problem, I mean, to inject the glitch. How practical is your approach? I mean, it seems to me that you're using a brute force approach to introduce the glitch into the board. OK. And the states, yes. That's correct. So full injection is not a science. When you inject a glitch, you don't have 100% of possibilities of succeeding. So it's kind of brute forcing in the sense that you inject the glitch and you try, try, try, try until you find a glitch that flips the bits in the way you are looking for. So it's kind of brute forcing. So what we normally do is we have an idea what we want to do. We see a code that might be potentially vulnerable to full injection. We find which is the instruction we want to try to bypass. And then we try to inject glitches in this instruction and we try, try, try, try. And we might have been trying for days. Sometimes it's weeks because we need to know exactly what is the glitch, the length, the shape of the glitch that affects exactly the tip in the way that we are looking for. So it's a kind of brute forcing until you find this perfect glitch. After you have this glitch, if you repeat the same glitch, you can get, well, still you don't get 100% of a success rate. But I will be happy if I get a success rate of 100%. Sorry, 1%. So after doing what we call characterization campaign, where we're trying to find the perfect glitch that affects the tip in the way we want, when we inject this glitch, I will be happy if we have one glitch out of 100 works and break the product. But some devices are more sensitive than others. So for example, most of the small microcontrollers, you can get a success rate of 30%. So you can one out of three or four glitches you can bypass whatever you are trying to. But some very complex tips, like a small, sorry, like a big processor, like the ones that you have in a phone, it's much harder. You need to try much more. But yeah, you have to do a small brute forcing until you find the exact glitch that you need to do what you are looking for. Yeah. So is there any other question? Yes, I got a second question. Is that you just described several solutions to protect against this glitch attack. Just why is it a hardware to use some redundancy bits and also to use some software? But it seems to me that it's still the same as you are just trying to introduce some redundancy states. But since the states is already that big, the program states is already that big, you're just introducing one or two or three bits of redundancy. How much safer would that make? OK, to be honest, it's really impossible to protect a product 100%. So when you add this contra-mercer, you add redundancy, you add double checks, triple checks, what you are doing is protect your product in such a way that you reduce the chances of being glitched. But there is always a possibility of being glitched. You cannot guarantee 100%. You can guarantee 99.999%. There will be always a small chance to be glitched. The thing is that you can protect your product enough to demotivate the attacker. So the idea is not to protect your product so it's impossible to hack it. It's just that it's hard enough to demotivate the attacker, so he will not try to attack your product. But yeah, it's really impossible to get full assurance that you will never be hacked or glitched. So it's like it's never possible to be 100% safe. I mean, it's never possible to be perfectly safe. Well, from the theoretical point of view, I think no. From the practical point of view, I think yes. Because if I need one year to hack something, I will not try, right? Yes. I mean, if you are determining enough. Yeah. OK. I think there were more questions. Two more questions there. How practical is a voltage attack? Have you actually got to remove the chip from the circuit board in order to get a decent spike? Or is there enough? How do you overcome the capacitance in the power lines to prevent you inserting a spike? Sorry, again. Do you have to remove the chip from the motherboard? OK. I did not talk about the practical way to do the glitching. So yeah, because I was talking that you inject a glitch by manipulating the power. So how we manipulate the power. OK. So what we normally do, if we are going to manipulate the power to do voltage glitching, what we normally do is just we have to manipulate the PCB or leave the circuit. We have to cut some traces in the circuit so we can with our tool manipulate control the power. So voltage glitching is very easy. You only have to solder some cables in the PCB. But when we do all the kind of glitching, like a laser, when we use the laser, laser is much more complicated. You have to decap the chip. You have to open the chip with the ACID. You decap the chip, and then you can just attack the chip. There is some practical problems, but well, it's not really something that you cannot work on. I'm sorry I think that the time is up according to the screen. So maybe we can continue with these questions offline. So thank you again for listening. And if you want to see one of these demos, please ask me. And I will just show you to you. Thanks.