 injection on a modern multi-core system. It's going to be awesome, by the way. We've got some hardware here. So take it away, Sergei and Ronan. Oh, cool. Great. That's my mic work. Can you hear me? No? Great. Thank you very much. It is very nice to be here first times at MCH. It was a lot of fun. Thank you for coming on Sunday, hot night. We're going to talk about fault injection and we're going to talk about modern hardware, how fault injection works, and what is fault injection. So all that, we're going to talk in a minute who we are. We work at RISCure. My name is Sergei. I like software, hardware, playing with things. And yeah. And with me, Ronan, today. Work at RISCure for a number of years now. I like software stuff, hardware stuff, where they meet low-level fault injection. Everything. Okay. So before we go into what is fault injection or what is modern SOC or does it work, we first talk about physical attacks a tiny bit. So what are physical attacks? Imagine you have a device, you have it in your hands, you can do whatever with it. You can take it to the lab, you can hook in any hardware, you can put a scope to it, you could do anything with it. And you want something from this device. So for example, there are some secret vendor keys and you want to get them. Maybe it's illegal, not talking about legality of things. Let's say you really have to get them. Or there are user keys. Maybe you're an attacker, you're somebody, you stole the device, you want to get the keys out, you want to attack this user. And for these things, fault injection or physical attacks in general are quite useful. Another use case is getting firmware. These days, often maybe if you're networking, you can see that a lot of OTA updates, they're encrypted. You cannot easily just see what the update is or what kind of code is running on the device. So having the device in your hands and doing physical attacks can give you these secrets or giving you the firmware with the transfer device to other attacks you want to do in the future. So that's why physical attacks are quite relevant to a number of different devices. There are two main types of physical attacks when we talk about it. There is on the left, side channel analysis. This is passive attack. So we don't really affect the target that much. We try to avoid that. We want to make sure that the target operates normally and we observe all kind of side channels. So not the output the target produces, but the data you can get. Maybe you can see the power trace or you can see the scope data. You can see EM produced by the target and so on. So this is one type. We're not going to talk about it. We're going to talk about fault injection or also known as glitching. So that's the moment when you want to make sure that the target you have does not behave as it should. So you try to introduce a fault. And hopefully bypass some security features of the device. So yeah, what are the types of fault injection? When we talk about it, there are different types. There is quite a bit of literature on this. A number of presentations talking about different possible fault injection methods. For example, clog glitching. So you have, if you have external clog of your target, you can affect it in a way. You can affect the outputs of the target or voltage glitching. So you can disturb the voltage and observe the effects. Also another type is electromagnetic fault injection. So you introduce a pulse into the target and you try to affect it that way. Other types could be laser or even temperature in some cases. And what do we achieve by introducing glitches? So quite often what we see is that we can corrupt data. So instead of having you can think of like you have some code running on the target and there's a variable and it has some value. And instead of having that value, if we introduce the glitch in the very right moment, we can corrupt it to another value. For example, to zero or to FF or to dead beef, which would be quite rare, but nonetheless possible. So glitches are normally not fully random. We cannot just get any value when you glitch. It's often something quite specific. So for example, zeros are quite often. Another option we could corrupt an instruction. So instead of executing one instruction, we execute another one. Or as a subset, we can skip an instruction. So you have some code running. At some moment, maybe you have a new statement and if you skip this instruction, this check was not executed. And if it was security check, it might have very big effect on the security of the whole device. Just to give a bit of more intuition of why this is happening, for example, you have your device and you introduce voltage glitching. If you have your chip and you know that it's supposed to run at 1.8 volts, that's what your vendor tells you. In the data sheet, it will say it should be 1.8 volts, maybe 10% tolerance. But after that, device not supposed to operate in this range. So what happens if the attacker is changing the voltage provided to this chip for a split second? So if it happens for too long, the device likely resets. So you just disconnect and power cycle the device. But if you do it for a very short moment, you might affect the behavior of the chip. And the reason behind that is, of course, because in software, we think about binary things. We think about zero and one and nothing in between. In real life, there is a lot of different physics happening and we might misread a value, a signal which is supposed to be as 1, as zero, when we introduce a glitch or other way around. So these kind of effects are quite possible. So yeah, that kind of makes sense. It's easy to understand that, yeah, we can affect the way the chip behaves. But of course, we cannot just know what kind of code executes where. So for example, we're on our chip, this is power trace. We just measure with the scope the power consumed by the device. And we see something like that. But it's very difficult from that, map it back, even if you know the code, say, exactly there we have the if statement, which I want to skip. And this is the first problem. And the second problem, there is also quite a bit of jitter quite often on targets. So your clocks are not perfect. When it's eight megahertz, it's never exactly eight megahertz. It floats, temperature changes. So you will always fluctuate around. And for that reason, fault injection is never very rarely 100% successful. So sometimes you will be more successful sometimes less. And sometimes you need to search quite a bit of a parameter space to find this exact spot when you want to introduce the glitch. And you will have some probability. Sometimes it's very high. Sometimes it's not that high to be successful, introducing the glitch in this exact moment. So that's one of the problems you have always when you do a fault injection. That's something you have to figure out. And yeah, we're not always fully blind when we do this. So for example, this is another example. We have a power trace. We send the command. And then we introduce the glitch in the red. And then we see the power cycle. So likely what happened, the glitch was too hard and we caused the chip to reset. So and we can often see it on the scope. And we know that maybe this is too much. We need to try to be more careful to affect the chip, but not to reset the chip. And this kind of information is always useful for us. So hopefully all this makes sense. And you think, yeah, you can definitely do this in the lab when you control everything, when you know the code, when they have datasheets, when you have everything you want. But does it actually work in real life? And yeah, it definitely does. There are quite a few examples when it was used. So maybe one example of what we've done in the past is glitching Bitcoin hardware wallet. So it runs a simple microcontroller. It has a STM32 chip. And we used EM fault injection. So for this device, it was open source code. So we could look at the firmware, which is always very nice. Even when you do physical attacks with hardware, it's nice to know what software does. And the weakness was is that they have a single if statement checking is being correct. And if it's correct, allow access to the user. And for us, when we see it, we know if it can affect this if statement, we can bypass the main security feature of the device. And yeah, that was a successful attempt. You can look it up online if you're interested more in this research. So that's nice. But indeed, if you look into research, which is published like the one before, this is a STM32 simple microcontroller, which runs at 200 megahertz. There is more other research, for example, this is published at Cardis a few years ago, which started in depth a lot of different possible effects of laser fault injection on 80 mega 328p chip, which is 8 bit microcontroller from AVR, which is very simple. And this is a common situation because a lot of research focuses on simple chips, which are easy to get. So you don't want to focus on something you cannot put your hands on, you have to have it in your lap. And yeah, you rather have something simple to be able to understand what's happening. But that's why quite often, it happens that a lot of people raise a question, will it actually work on modern devices? If you have a smartphone, can you bleach that because it runs quite quickly, has lots of cores. It is quite different from microcontroller. And yeah, can we bleach when it's faster than one gigahertz? Is it even possible? Is it too fast for us to have meaningful effects on the device? And that's something we wanted to discuss in this presentation. So first of all, what's the difference between a simple microcontroller and a system on a chip like something, a main computing unit in your smartphone? Well, the difference is one of them is very simple. Another one is not so much. So there are a bunch of different features you could look at and pretty much everywhere, you can say microcontroller is just way too simple. So you have single core quite often. It is not rare to see 8-bit microcontroller. These days you can see 32-bit and more. Feature size on the silicon is also often quite much bigger than you would have on your latest smartphones. Microcontrollers are often quite generic, so you don't have a lot of specific acceleration. Sometimes you would have crypto operations implemented, but not always. And it has very simple packaging. So it's a small chip and everything is easy. With a system on chip, you often have a lot of cores. So it can be 4-8 cores. Sometimes you have clusters, you have big and little cores if you would talk about smartphone socks. And it's 64-bit most of the time. Feature size is very small. So the chips are huge. Manufacturers go a long way to make the silicon as small as possible. So it's quite different technology behind it as well. It has a lot of dedicated engines. So you have your crypto engine which does a lot of different crypto. You maybe have AI module which does a lot of AI acceleration and so on. So there's a lot of specialized hardware. And to make it even worse, often you have package on package. So you would have your chip, your CPU, and there is on top you have DDR. So you cannot easily access the chip. This is not the case in our example. But Ronan, we'll talk in a minute what exactly we've done our research on. Yeah, so Sergey has now introduced all the parts that we're interested in. Water sox, what system on chips, why are they interesting, what is fault injection, all of this sort of stuff. And can it be used in modern, fast processors and stuff? So that's what we decided to look at. And for this work, we decided to use this board that you see on the right, which is a Pine 64. It's a relatively modern system on chip. It's by a manufacturer called Allwinner. It's their A64 SOC. It runs above one gigahertz. It's multi-core. It's relatively recent. And this is basically just a single board computer. So as a Raspberry Pi, just a development board, quite cheap, quite easy to obtain. And we were able to talk publicly about this. So this fitted all the boxes for being a nice target to have a look at. So yeah, now we know what we want to glitch. How do we actually go about doing this? So this that you can see here is quite a generic EM, so electromagnetic fault injection setup. You can see the various parts here in the bottom left. This PCB with the wires coming and going is the target itself. The big yellow box that you can see above it is the EM probe, which is the thing that actually delivers the glitch. So it's just got a lot of capacitors and stuff inside it. It builds up a charge and then discharges it very quickly through a metal coil, which is situated right on top of the chip. You have this big table that it's all mounted on is basically just for moving the probe physically in space over the body of the chip. That's just very simple. It's just three motors in each of the three axes just so you can control where in space you are. On the right hand side, you can see at the bottom is an oscilloscope, which we use for debugging the setup, verifying that everything's working as expected. And the yellow thing on top of it is a spider is basically just for controlling the EMFI probe and reading data from the target itself underneath. So that basically just says, when do we want to glitch? And it controls the rest of the hardware, which is quite dumb. But yeah, so that's one of the major things with EM fault injection. It's about where specifically. So you have the chip underneath the probe. And of course, with a modern sock with any sock, different parts of it will be located in different areas on the silicon. So you might have different effects, whether you're above the CPU above the memory above what are there other components. So this allows us to yeah, control all those parameters, search through them, see where we're seeing interesting stuff. So okay, we have a target that we can control, we can run code on it, we have our setup, everything's good. The first thing we then will do is just implement a very simple piece of code. This is just something that's running on the device, which will just have two variables reading and writing from memory, one counting up one counting down to some number that we decide. And so we use very simple things like this as a very first step often to just get an idea for how powerful you need your glitch to be where in space. So where above the chip needs to be just a very core screen scan to reduce some of these parameter ranges that we're interested in. And so we run this initially for a while you can see on the left hand side, the ones highlighted in green, this just as you can see returns the up count and down count. The green ones are expected responses meaning the glitch did not affect the device at all. So you see the 50 and zero. The results you can see on the left highlighted in red are ones where we have successfully modified the code executing on the device without crashing it. So we've done a transient glitch on it. And so you can see, for example, the first one, the 51 is the up and the down. This is very likely caused by us skipping. As Sergey was talking about skipping this decrement, the decrement of the down counter. Similarly, with the 49 zero, it's skipping one of the increments of the up counter. And then you have other ones like if you know a bit of C programming, this big four billion number might seem familiar to you. It's the maximum value you can store in a 32 bit thing variable. So basically this is saying that we've modified one of the decrements to not decrement by one, but instead to decrement by three, I think it is in this case. So it just shows we can have all sorts of varied results for what we're doing. And this sort of very simple test is a nice easy way to just see where is good to glitch how powerful just to get an initial idea of the parameters that you want to use for your testing. So it might not be so easy to see here, but this is basically just a representation of the many glitching attempts we have done. The back, the darker part is just an image of the packaging of the dye itself. And we basically just divided that whole space into whatever grid size this is. And we can see all of the green spots are where we have had no effect on the device at all. So it's just returned exactly what it should return. We didn't modify anything. The pink spots, if you can see, are not so interesting. They're a different error with the setup itself rather than the device being modified. But what we're most interested in is the ones that we call a red here. So all of the ones that are red are we have changed the way the device is operating, but it is still operating in a normal way otherwise. So we've had a useful glitch without crashing the device. And yeah, generally what we're trying to do is change all of our parameters, be it where on the chip we are, how powerful we are, all the various things we ought to control to get the most reds because we generally think they're the most useful ones. The device still works, but it's done something it shouldn't have done. And all of this is just running at the default clock speed of the A64 sock we mentioned, which is 400 megahertz. Yeah, just to get an initial feeling for how the chip reacts. So then if we wanted to go into a bit more detail, which we did, to be able to see a bit more fine grained effects and just to understand things better. One of the things we did is implement what you can see on the left here is just a simple function in assembly, which will take a fixed known value that we can see up here the a five a five a five and just read it and write it to and from memory and do nothing else. So in the case where the device is operating normally, you have not done any fault injection, it will just give you back at the end that exact same a five a five, which is an arbitrary choice of constant. And then using the hardware setup we showed earlier, we will basically deliver our glitch at some point during this loop, which is just reading and writing that variable. So then what we want to see is can we affect and how can we affect the operation of the device in a way that's useful to us. Yes, so similarly to before we can see on the left, the results that we some of the results that we obtained, the normal response as I mentioned the green stuff on the top is just that a five a five a five constant. And then in the red part below we see some of the more interesting ones that we saw. So we said we were interested in seeing can we have precise single bit flips on the data that's being used or the instruction stream itself. These are sorted. This is a selection which is sorted on how often we saw the results. And all of these top five ones are single bit flips away from this a five a five constant. So you see they're all very similar, but they differ by one bit in the binary. So that is saying the data that was being read or written to memory, we have been able to modify it in only one bit. So one bit precision. But the device has not seen it. So it's still useful for us. Another result that we saw quite a bit was instead of this full a five repeated four times being returned, we would get just a single a five. And that is basically the way the arm 64 assembly is encoded. The instruction that loads the full 32 bit value versus the one that returns just a bite. They are also one single bit flip different from each other. So what we've seen there is that we can affect both the data and the instruction itself which loads the data. And then we see also on the bottom some other different results which are very hard to reason about because there's a lot of stuff going on on the chip. It could be that it's corrupted one of the addresses to somewhere random. It could be a data corruption. There's many possible explanations. And it's hard to say given the control that we have. So that shows some of the point the single bit flip stuff that we wanted to look at. And here what we're looking at is similar to the previous picture. It's just the results of each attempt overlaid on the chip body itself. I mentioned there's a number of different parameters we want to control time, space, power, etc. One of the things we are interested to look at is how the operating frequency of the underlying chip affects the ability to be able to have successful glitches on it. So what we're looking at is on the top left the current multiplier there's basically just there's an extra step in telling the chip how fast to run. So the top left is the slowest speed which is I think 140 megahertz roughly. And the bottom right is the fastest speed that we were looking at which was 1.2 gigahertz. And so we can see by the number of greens the number of reds and yellow which is not relevant for us. There is a very clear correlation between how fast the chip is running and how easy it is to have a noticeable effect on the chip without crashing it. So something that could be useful from a security point of view. Yeah, so that already shows two things we can have this nice single bit flips that we're interested in and actually possibly counterintuitively the faster it is the easier to glitch it is for some and then this just basically shows on a graph simply what we've just seen before. For each of the frequencies we were interested in there was roughly 90,000 attempts at each frequency here and you can see there's a clear correlation between the chip running faster and the chip being more susceptible to fault injection. So this just shows the same thing. So then one thing that you might think about is why why would it be that the faster you run the more easily glitched you are the more susceptible you are to fault injection. So this is one possible explanation if you see at the top is a representation of a power trace or a trace of the device when it's running at a slow speed 600 megahertz and the same operation when it's running at a faster speed 1.2 gigahertz. Obviously you can see in time and the x-axis is time in time the same operations are clearly much more compressed. So the way the hardware that we're using works is the amount of time it takes for the coil to discharge fully so to deliver the glitch that is fixed that's a constant. So and that's this 52 nanoseconds you see at the bottom. So you can see that as the amount of operations in that time is way higher there's way more potential chance to affect one of them because you're inducing the current while all this is happening. The more things that are happening the more chance there is something can go wrong. This is a very hand wavy explanation but it's one that's quite easy to understand. So that's one of the explanations. And yeah so we've seen for fault injection we can do it. We can affect all sorts of codes sometimes security sensitive code. So naturally you might ask how can you defend against this because even with perfectly programmed software you can still introduce faults which can introduce bugs. So yeah there's some stuff that you can do in the hardware itself so bake into the silicon of the sock. So these hardware sensors you can do things like detect when you're operating outside of your normal voltage range that you expect and if you see that you're outside of that reset the chip or stop executing so stuff like brownout detection as well. For laser fault injection that Sergei mentioned earlier you're shining a laser onto the chip. You can also have light sensors in the silicon itself which detect if I'm seeing too much too many photons like too much light at this point in time at this point in space then yeah reset do something like that. So this that's at a hardware level at a software level you can also follow various like programming practices patterns to defeat to make these sorts of attacks harder. Some of them for example this random delays as Sergei mentioned there's there can be jitter there can be all sorts of changes in the timing of the program which you as an attacker need to be able to precisely say I want to go here if you start introducing just random delay loops that changes where in time the interesting operations are. So that's one you can do redundant computations so do the same computation twice if you see a differing result and that means likely there's something has gone wrong be a fault injection be a whatever and then again early out. You can do stuff like control flow integrity checking so just making sure you are executing in the order you believe you should be executing in and you're getting functions called for example from the place that you think they should be called. And then there's also some other stuff about using certain whenever you need magic values true false using ones that are hard to flip using fault injection so hard to turn from one to the other. And yeah so everything we've shown so far is very in a controlled environment we have full code execution on the development board we have all this nice fancy equipment that's precise and expensive and everything. But then it comes to the question so how about when you want to do that on the cheap how about when you want to have some fun and not need expensive equipment can we still do this sort of stuff. And that's what Sergei is going to tell you about. Yeah so for the demo we thought about bringing our setup from the lab show you how it's done. Tiny problem with going to mch with the equipment from the lab there was 100% chance we're going to spill beer on it somewhere in our tent. So we didn't do that. But we still wanted to show how glitching could be done. So here's Nils our colleague he brought his equipment. This is hobbyist tool picker MP a similar idea. So you also have a coil you can see the bottom and you can introduce a glitch also you have glitch and we got this nice page from the organizers which can run a lot of different software and we thought and it has a lot of different chips if you looked at the schematics or at least at the back of the chip there's a lot of different stuff so we thought it might be fun to try it. And so what Nils did the first day he got it he wanted to try he looked at this picker chip and it controls a few things for example the backlight of the screen and that's a bit of a video if it works we can show you. Yeah it works. So yeah you can see the coil in the lab we use a nice XYZ station with a micrometer precision here Nils has a nanometer precision and he can put the coil exactly in the spots to be close enough to the picker chip and you can see the screen here he presses the button he introduces the glitch and the backlight so the chip likely resets and yeah it just the light is goes off and on. There are also some other effect you can see it shows restarting or some other things so yeah we can affect the chip it's not very nice glitch it unlikely as an attacker you really want it to come close to the user press the button and make sure he is backlight doesn't work but yeah it's it's a something we can do here we thought maybe there is something else and graphic we could show on the badge is nice target for us so we found this nice app great to have a lot of different ones it says it runs on FPGA so there's also a PGA chip on the target it's Mandelbrot it shows you these two nice sets you can with a button switch between those two so you click the button have that one you click the button again you go back to the original screen so these two screens you're supposed to have and nothing else should happen well you can zoom in and out but that's it so we started to glitch first of course FPGA chip is on top a nice target when we get close to it it resets we can see that the screen is just the graphics goes back to the original position so to the screen so if you zoom in and out or move around and glitch the chip it will just reset back to this so we glitched around what often also happens with fault injection instead of targeting the chip itself you often can for example introduce a glitch in a capacitor next to it and affected through the voltage introducing first EM and then causing voltage change in the capacitor so we found that if we target this area marked in red we can really affect the chip and get different outputs then Nils looked it up in the schematics it was very nice from organizers also to our open source everything on github so we could see that this is voltage regulator which produces a 1.2 volts which eventually goes into the FPGA board so that's plausible we hit the voltage regulator and something happens with the FPGA with the graphics so what did we get this one was one of the first glitches this is totally not what you're supposed to see so what you're supposed to see you remember those two and that's the output and the interesting thing is we could affect the chip we get totally different graphics on the output the chip still runs perfectly and these features of switching the graphics the Mandelbrot set and zooming in and out still works so the chip operates perfectly we can do operations on this and get different graphics and there are a few others which are totally different but also very different from what you expected to see on the screen so you see this is zoomed in zoomed out and this is zooming in big back and it works we could also once get this glitch which is totally what you not expect from a recursive Mandelbrot set just covered the whole screen with some ASCII graphics and finally an interesting glitch we got this morning is this this is totally not what you expect we don't press any buttons we glitched it once and it just started to alternate between these two pictures back and forth again and again so that's more or less what we've done being here some takeaways so first of all physical attacks if you write software it is quite often overpowered you can do so many things it's so difficult to protect attacker can often put much more effort into trying to break your device another thing which you learned modern socks they are not much less vulnerable the hardware itself there is still hardware attacks which apply to it and even if you run very fast and as we showed sometimes it can be even easier affected so you have smaller feature size you have tiny transistors you have huge frequencies which are crazy and yeah we can corrupt a lot of things running the device and the very important the last point official mch page is susceptible to fault injection so maybe something for the next time to improve if that's the attacker model thank you very much we still have some time so we can try to fail miserably and trying to show one of those glitches you can see we have it here on stage thank you thank you very much if it actually works though okay it still runs I can maybe show you how it's supposed to work if I'm careful enough so you have these buttons you can zoom in zoom out if you can try this app so you can see something like this on the device so if we try to glitch it first I will target it's on the back then yeah so I can show you for example the backlight if I'm successful yeah oh no so normally it doesn't happen this time we turned off the so I glitched the Pikachu and it's supposed to reset and we lose the backlight and go back on now it's persistent so if we're lucky yes so I reset now by disconnecting the wire and it goes back in and everything works and just to maybe quickly say something about the hardware this is very similar to what we described this is just a battery pack this Raspberry Pi is for controlling the logic this is the coil it just builds up a charge in here and just discharges it very quickly through that coil right beside the chip itself and that's how you're introducing the fault okay and so the first attempt was not an awesome demo we got the persistent glitch now we'll try maybe for lucky and find the spot I'm now focusing on the regulator trying to be very careful moving tiny bit at a time ideally it would be few micrometers yes and it's worth mentioning that in practice when we're doing projects and stuff we have all of this automated so that's why we have all this fancy XY stage and all these sorts of things if you maybe saw the glitch there is so that we can set it once and just forget it let it run collect hundreds of thousands of attempts where here we're clicking manually each time to do a glitch so slightly less optimized you could see tiny effects on the screen and this area is actually very sensitive so we can luckily if we're successful enough to get actually good glitch here but if it doesn't work in a second that's going to be it does it actually still operate it? yeah this area when it shows on the half of the screen that it blinks it's normally successful unfortunately this time we didn't get it if you want to try it out yourself when you come to us after the presentation you can see it that's why you should never do a demo it never works thank you very much and if you have any questions thank you so much we have a little bit of time for questions Q&A so if you want to ask a question there's I think it's two microphones so line up behind the microphones there so signal angels do we have any questions from the internet at all not seeing any so are there any kind of you know how these attacks can be used in the in the real world you know are there any I mean you mentioned about the Bitcoin wallet right is that you know are there other examples that you can kind of see yes it depends on the field that you're operating in but there's many examples so in the early 2000s for example when we used to have set-top boxes for getting our TV channels you would have a smart card that you'd put in and out one of the ways that if they detected a problem so if you were trying to do something malicious they would put it in a state that just sits in an infinite loop there was devices which were publicly available which you could basically just plug the smart card into it would do this sort of fault injection and it would recover the card so it would break it out of that loop so yeah you can recover a dead smart card which then you can use for piracy and other stuff there's other examples a lot of the attacks on more recent game consoles and stuff like for example Xbox 360 I think there's something with PlayStation utilize a lot of this fault injection stuff through various means thanks so we have a question yeah go ahead hello yes I was wondering how much something like ECC RAM could help prevent fault injection ECC yeah I mean it can be helpful it depends on the ECC algorithm and stuff you're using but yes if it's correcting single bit flips in RAM itself then yes it can be helpful but also some of the stuff we're talking about is in the CPU itself so in the like instruction decoding instruction fetching logic all of that so that might not be operating from DRAM itself so it wouldn't help against that but if you're trying to affect something in RAM then yes it could be helpful thank you Max is another question in the back there yeah go ahead so as we saw during the demo there is sometimes a persistent glitch is there anything you can tell about what the risk is of permanently damaging the device or corrupting data for example it is not that often if you know what you're doing and you don't short all the pins which is more mostly the reason why it gets permanent damage just with the fault injection when you introduce for example in this case emfi we've run the setup in the lab for millions of attempts and there was no permanent damage and that's quite often so you can repeat it again and again and everything works even here you see it's not really permanent just until the next reset it just ended up in a weird state so yeah it's quite rare to damage it with the em if you do voltage it's more often when you prepare the sample you're going to damage it or if you do laser you're more likely to cause the damage by the laser all right thanks thank you much so no more in the room anymore from the oh yeah is that a question no he's looking at me anymore from the internet I can't really see I think I'll take it as a no okay so I think you know this this hardware is gonna be here for a little while yeah this is the last talk this evening so if you want to come up and have a look at this after the talk I'm sure you'll be more than welcome to do oh we have a question great there even more actually thanks a lot for your talk and do you have a favorite fault injection method like personal favorite yeah there are one the reasons why you the em is because it is quite easy so we don't really need to do anything with a target we just have it as it is we don't need to decap it so there is no chemicals involved no polishing we just get it as it is and we can start leaching so we don't need to modify power and so on and that's what we often use because it's the simplicity okay it also depends a little bit on your use case what you're trying to do so for example if you're doing laser you can affect very specific things more easily like in space with voltage for example it's generally more and all or nothing but yeah as Sergei mentioned EM is often a good one because it requires no modification where the others both do but yeah different types for different desired effects okay and have you ever tried laser glitching from the back side like with infrared lasers yeah so that's mostly what we do with lasers so as I guess you know you have your polysilicon layer you have your metal layers above we will usually always go through the silicon because to that wavelength of light it's essentially invisible whereas if you were to try and come through the metal layers the laser can easily penetrate them there's a lot of scattering so it's much harder to do it's possible in some circumstances but usually it's backside okay thank you thank you another question hello I have a practical question while you still have the badge on the screen what happens if you glitch the die on the LCD controller that's the raspberry pie right no no no the LCD controller glass die in the front on the LCD itself if we just try to reach the screen itself yes I'm pretty sure nothing will happen we can easily do it yeah this green not that easily affected but you might have some effect if you're on the ribbon cable though you're inducing yeah looks there's some so on this part okay let's see if we get a success here okay there are some things yeah indeed that's great yeah another question yeah yeah so I understand that you by mapping with this XY gantry you can map map out spatially where you can position the EMF pulse to affect instructions or data but how do you synchronize sorry to interrupt you that's fine to show for a second you see it still works it shows totally what you know to expect to see here for the rest it's maybe even the switching button works if I can yeah and see this weirdness here just a practical question how do you because the pulse itself is like 52 nanoseconds or something how do you synchronize that temporally with because I assume you want to affect a specific like if there's an if sentence you want to affect that one and not the preceding and subsequent instructions how do you synchronize yep so that's a good question so I thought the slides are out there so what we will usually do in this case where we had complete control over the target the code running on it yes this this here the line that says trigger high that basically just sets one of the many GPI opens it just drives it high so from when we saw the setup earlier there was a box on the right that was controlling all the rest of the hardware that will wait until it sees that trigger and then it knows to after a fixed amount of time then you deliver the glitch yeah so in this case we can just set a GPIO so that's easy and that's fine in more complex targets and targets where we don't have control we can use other signals to trigger on so to say from this point in time wait that can be reading from an EMMC it can be some EMMination from another component it can be many different things but yeah that's the basic we find some operation something that's fixed in relation to what we want to glitch and then we just wait a certain amount of time after that and would you also use a trial and error method just like gather lots of data like wait yeah so exactly yeah that's one of the many parameters we need to optimize so we have our trigger we know when to start and then we will start randomizing how long in time we wait before we glitch and then from there we'll see oh if we wait a long time we have the desired effect if we wait a short time we don't so we know that we want to optimize towards the longer times like the longer wait times alright yeah thanks thanks question I think so we're at time in terms of the official kind of end of the presentation so if there's additional questions I think maybe we can do the kind of after the talk but I think for now we'll give another round of applause because this is amazing and thank you