An Introduction To Fault-Injection For Exploiting Bug-Free Code In Embedded Systems

right today I'm going to be talking to you about how you can exploit uh embedded systems that have no logical flaws in their code so it's fault injection attacks um it's a local attack on Hardware uh which does require physical access so obviously that's a limiting factor in uh this type of attack um this talk is intended as an introduction to the subject so uh I'm not expecting anyone to have any prior knowledge although I can see some people in the audience who definitely do um so what we'll cover uh who I am to a certain degree uh what fault injection is uh the different types of fault injection attacks uh why and where F

injection attacks are used um How fa injection can compromise security goals uh I'm going to try a live demo on stage what could go wrong uh it's not guaranteed to work and it's not guaranteed how long it might take so yeah um then I'll talk about some mitigation techniques and standardization if there's time and finally some uh other Hardware attacks so who am I so I work for a silicon vendor who sells microcontrollers for using cars uh industrial Control Systems iot devices sort of thing uh and my job is focused on uh Hardware P penetration testing so basically uh I lead the red team for uh security testing uh so it's um we're trying to emulate you guys the hackers

um basically we're trying to break the chips before you get a chance to uh so the sorts of things that we are testing are claims about uh secure boot flash read protection uh debug protection and side Channel analysis which I'm not going to focus on on this talk uh yeah this talk does not represent the views of my employer that's an important one um so what is Fault injection um f injection is a class of Hardware attacks uh where we stress the device in some unusual way and try and get it to malfunction try and get it to do something it shouldn't um there are different types of fa injection attacks so uh the common

ones are voltage and electromagnetic fa injection so here we are uh causing the chip to hopefully go wrong uh by the use of uh changing either the power supply or uh putting different voltages on pins or using electromagnetic fields to cause some internal thing to to change within the device uh clock speed so if the device is using an external clock uh then that becomes uh in scope um other fa injection methods are temperature uh and light with things like laser fult injection uh and ionizing radiation but I'm not going to focus on those so uh types of fa injection attacks um let's focus on voltage fault injection so uh here you can see uh

Homer switching on and off the the power uh and basically what that does is causes the chip to operate out of specification uh so if you're switching the power off very briefly uh and switching it back on before it completely resets maybe you can get it to go wrong in a a new and interesting way that's useful to an attacker uh sometimes board modifications are needed for this to work uh removal of capacitors and that sort of thing which tend to stabilize the power supply and uh make your faults less effective uh there are ways to do this very cheaply so I have some very expensive equipment but you can also do this uh with things like a Max 4619 this

is a kind of like an electronic relay uh so it's a switch and here we can run the power through this switch uh and have that uh very precisely controlled timing wise from something else to be able to switch between supplying power and maybe shorting the target power to ground uh another way is using mosfets where this is this is known as crowbar glitching where you're acting in contention with the power supply so you're you're not disconnecting the power supply but you're giving it another path to ground um that isn't going through the chip uh and uh slight modification to that is sometimes you're not targeting the input power supply uh in some chips you might have access to

uh the core voltage on a pin uh as you will see in the demo later so what does it actually look like and what are the glitch parameters so we have uh at the uh at the top left we have some kind of trigger input signal so this could be by uh monitoring Communications U or USB or it could be uh time from uh release of reset so that could be your trigger for when you start and then we have a programmable glitch DeLay So This is a period of time we wait before we activate the glitch and then a programmable glitch length um so the duration of the glitch and you can see at the bottom uh the purple Trace uh

so this was the nominally 1.1 volt Rail and during the glitch period it dips and then it it recovers and overshoots quite a lot and then we get some ringing afterwards and in fact it's that overshoot and ringing that can also produce some very uh wild and interesting effects so it can be tricky to find the right glitch parameters uh find that goldilock zone so um that can take a long time and there's a difference between uh the time it takes to uh find that those parameters that work and how long it takes to to run that again subsequently uh so identification versus exploitation so here in this graph we're uh comparing uh glitch length versus

glitch delay to look for patterns uh so visually we are color coding the results uh according to what happens with the chip so green is the normal operation of the chip so it didn't notice that we were trying to glitch it uh gray is the uh it's it's glitched too hard effectively so there was no response from the chip in this case and red is where we were successful in whatever definition of success was uh if we just remove the green and gray and zoom in a little bit and just see the Reds we can see that there are sort of distinct time periods on the delay uh where we see the successful uh glitches uh these parameters are

affected by a number of things uh so different boards can be different uh board capacitance uh the length of power wires uh the length of the wires that you're connecting to it with um and temperature and all other factors can cause some drift in these parameters so moving on to electromagnetic fult injection so this is where we put a coil uh very close to the chip but not touching it necessarily um and here we see the uh new AE chip sh chip shelter um from colino Flynn's company uh this is a a a very nice tool it's uh about £35,000 worth uh but very very capable and by the way that is the lower cost end of the uh professional

tools Market um by about a factor of five at least um so yeah this is slightly out the reach of the hobbyist um but basically all we're doing here is we are charging up some capacitors to uh somewhere between 150 and 500 volts uh allowing that to flow through the coil uh and that causes uh an electromagnetic pulse which can induce some effect within the chip um there are different uh different Co that you can use different diameter coils uh you can have different coil winding directions um and here we also have a positional dependency so in addition to the uh glitch delay and the glitch length we've also got uh x y and potentially Zed position uh as well as

uh the coil voltage to consider so for this uh I using a uh cheap 3D printer an Ender 3 uh so couple of hundred pound worth of printer as a XYZ stage I also have a a much more sensitive one at work which is somewhere of uh over1 15,000 worth um but for fth injection this is perfectly adequate the other one is really for side Channel analysis um new AE also sell a kit called the PCO EMP which is uh about I think $60 on their site um which is a put together yourself kit uh obviously a lot less powerful uh but still it's possible to uh uh create glitches using that very cheap unit um it's much slower

in terms of repetition rates and so there are some disadvantages obviously you you you obviously pay for what you get uh but it's yeah very capable so um why and where are fault injection attacks used so let's consider what assets we're trying to protect here so uh what's what's inside an embedded microcontroller that an attacker might care about or that the device owner uh or designer might care about uh so intellectual property uh device firmware uh that's useful for an attacker maybe they want to uh recover the firmware and analyze that for logical flaws so for injection can often be the sort of foot in the door that leads to a remote attack later on um more and more these days AI models

so companies are uh spending a lot of money on developing their AI models and maybe they don't want some uh competitor from maybe another region in the world from being able to steal their IP and reuse it uh and Trade Secrets there's sometimes undocumented protocols and things that happen within embedded devices and yes that's security by obscurity but security nonetheless um so manufacturers often don't want those to be discovered cryptographic keys so there are signing keys in some uh devices which can be useful for an attacker to be able to then sign their own messages uh root keys for Hardware root of trust um mainly if that's symmetric though uh obviously asymmetric is a little more uh robust against that

key installation keys for uh user keys for whatever the end application is using and sometimes backend API Keys uh the other reason that people might want to attack it is access to the hardware so they might want to avoid limits on uh software software limits on features so perhaps uh oscilloscopes for example they might sell exactly the same Hardware at many different price points depending on what you pay for they'll unlock certain features some people don't like paying for those features and will find ways around those restrictions and similarly DRM avoidance uh on uh games consoles particularly that sort of thing uh and arbitary code execution if you can gain uh access root access effectively to that device then uh you

may be able to get that Hardware to do something that's useful to you or indeed use the keys that may be stored in the device maybe you can't extract the keys but maybe you can utilize those keys they might be in a secure storage area uh and as I said before yeah binary analysis once you've uh obtained the firmware uh can can lead to discovery of other flaws in the in the system so secure boot bypass uh let's have a look at that one so it's it's great having uh strong cryptography uh for secure boot so secure boot is where it will check the signature of the image before it will execute it uh and there's

a a key that's stored in the device that it uses to to check that with but what if we instead of try and subverting the actual uh complex signature verification itself what if we try and attack the uh the part where we check what that result was so that can often result in uh following maybe the wrong code path and executing that code that should not be

executed so another example here real life example leonnard Walters uh was able to successfully uh uh hack the uh the uh SpaceX starlink user terminal uh he was able to generate a mod chip that we see here uh and this mod chip performs voltage F injection on this automatically and it was quite a clever solution because actually I mentioned earlier about removal of capacitors um in this instance removal of those capacitors was necessary for the glitch but would cause the the the later stages of boot to not work so this actually switches in and out those capacitors

automatically so uh another example of secure boot bypass was uh the Nintendo switch uh for running custom firmware for whatever purposes people may wish to uh run custom firmware on a Nintendo switch and read protection is another uh bipass another Target for attackers so this was uh yanlu was successful in dumping the ROM So reading the the ROM out of the PlayStation VA uh using the new a chip Whisperer so same company as the chip shelter um using the chip Whisperer to perform voltage F injection um this was after Sony had put a lot of effort in after previous failures on the PSP and the PS3 uh this obviously was then used later for analysis for other La

also and then we get on to uh the the big money items um don't look at the front row um you might see a familiar face here uh so Joe Grant um was uh employed to sure what's going on with the video here uh employed to uh recover $2 million worth of theta cryptocurrency from a Traer one Hardware wallet uh this was uh with the permission of the owner who had forgotten their past phrase um so this was using voltage Vol injection and there's a fantastic video which is linked um so yeah the financial reasons are a strong incentive for people to attack devices uh and you have to remember sometimes the attackers are the

owners of the devices say games consoles and all sorts of things like that so how does fault in fault injection compromised security goals uh generally it's a transient fault that it generates so that's something that's only existing During the period that you're glitching but sometimes this can lead to more permanent faults if it was perhaps writing flash at the time that it was glitched um so the most prevalent effect that we see is instruction skipping so there uh the code is supposed to logically go next instruction next instruction and we give it a glitch and sometimes it skips one or a few or many instructions um so just think about that if you're writing code how you protect

against that if you've got an if else and it skips over it or yeah if the signature was validated verified um oops we've skipped over it and we we're starting to run that code without that check um data and flight corruption so if we're reading data so maybe we've asked for a a value from The Flash uh and it misreads that so that can be for a number of reasons uh it could be that we've Disturbed the bus so although it put the right data on the bus it was uh corrupted in transit um and that can be the the data value or it could be that in the request the request was modified and maybe it's

read from the wrong flash address for example uh out of order operation so uh if we issue that read request SATA Flash and suddenly there's an an erroneous clock that's induced by some sort of external stimulus perhaps it completes that read operation before the flashes has had time to actually do the read and put the result back on the bus so again there we we're using wrong data values and which can cause the code to make uh different decisions through the code about what it is allowing you to do uh the Jungle Jump so this is where the program counter gets set to some seemingly random but it's not necessarily random address it jumps to

somewhere that was unexpected and unintended um this is often the result of op code Corruptions so where you've got an instruction uh CPU instruction if that gets corrupted if maybe it flips a bit in that so zero goes to a one or a one goes to a zero um maybe that uses the wrong operand and uses a different register or maybe a move becomes a jump a branch instruction so there are a wide range of effects that can happen and trying to prove exactly how a glitch works is a lot harder than making it glitch in the first place so onto the live demo fingers crossed um how you can try this for yourself sorry about the screen jumping

around here so uh this wasn't in the plan when I submitted this talk and I heard that this talk of being accepted about 6 weeks ago and panic set in at that point uh and with the help of uh a friend who will be referred to just as asfw um this PCB was generated um I had very little to do with the actual uh layout of the PCB uh this PCB basically has two Pi p2s on it um on the not on the left apparently because the video is gone um when it comes back uh uh on the left uh there's a control Pico and this is the one that's actually running the attack and on the right we

see the victim PCO which is the one that's being attacked and just below that there is a a mosfet which is the uh thing that's actually um causing the voltage F injection to happen uh so we will connect to the uh the control PCO just with a a USB wire which sets up a USB serial port and so we can see the results um I will say this yeah this I'll just remind you of the uh the parameters so we have the glitch delay and the glitch length and we're trying to cause the 1.1 volt line to change in some way uh so we're shorting that to ground briefly uh so in terms of what I'm

trying to do instead of just showing you an instruction skip or something easy like that I thought this is bides why not put myself under some pressure so what I'm going to try to show here is a differential fault analysis so this is doing uh the victim board is running an AES encryption and spitting out the cipher text to the control board and if we manage to get exactly the right timing uh what I'm hoping it's going to show is is that if we can affect uh the end of round eight of that as 128 encryption uh and we can just change the value of one bite and no more uh then that one bite will lead to four bytes of

corrupted Cipher text and by repeating this uh and comparing this with the normal Cipher text um we're aiming to recover the key now for that the there are actually four different 4 byte patterns that can come out from this and we need to have at least two from each of those four bite patterns before it will be successful so fingers crossed can you see this [Music]

no no okay we'll go a different way then hang

on ah maybe ma done it so I'm going to start the demo I'm just going to accept all the default parameters it's hidden behind the uh video feed there um we have LEDs on this board um the one that's flashing right now is just so it's running and there are some at the top of the board uh by whether USB connector is that show the result so we're again using green for normal operation and red for the success given this isn't uh deterministic on time or even success let's run it uh so red here you'll see that we've got some results coming up so anytime you see the the big long text that's R that's where we hit one of

those four by patterns um uh 4 byte error patterns and we're looking see you got the four groups we're trying to get two for each of those groups you see we've already recovered 50% of that key now uh 75% now so that would be brute forceable at this point and there we have uh maybe scroll um uh We've recovered the key bsid London

2024 so switch back to the presentation

want to move on so I did have a video demo just in case that didn't work uh I just want to point out this is not a new attack and it relies heavily upon other people's work so uh Philip tuen uh doox uh I'm using his uh Phoenix AES Library here to do the the hard maths bit of the this uh attack uh i' I'd make a couple of minor tweaks just to get it to run in micropython uh which I've submitted a poll request for but uh yeah yeah this is uh prior artart it's nothing novel it's just to demonstrate that you can actually generate some very precise faults with some very cheap Hardware so mitigations and

standardization what can we do to mitigate this sort of attack so uh software mitigations um we can do things like there's obvious things so make sure your init your your default values are initialized to the fail State not the success state if you're talking about something like a a secure boot or something like that so um don't allow uh skipping over something to give you the successful result uh avoid trivial values for your constants that represent things like true and false so don't use zero and one for representing true and false because those are very easy to glitch um maximize the Hamming distance the the the number of bit flips that you need to change between your

States um repeat your checks for comparison so go back to the secure boot EX example uh you could either run that uh signature verification multiple times and check each one or or or and and uh you could save that result and then check that result multiple times in case you're U seeing a glitched result and obviously putting those into some sort of loop or multiple checks you can detect if the chip is being attacked um check that your Loops have completed the correct number of times if you've got a for Loop that's copying memory around um and it's expected to go around the loop 100 times um check that it did indeed complete when it exits

your Loop because exiting from a loop is a very easy effect to to achieve with FAL injection and the thing that would make my life harder is randomized timing delays because that affects both the discoverability or the parameter narrowing phase where I want to zoom in on the just the parameters that work um and also makes it much harder for me to find parameters that are able to be repeated and uh exploited later on another another device or the same device later uh control flow Integrity checks so I talked about the the Jungle Jump um if we've got a a security sensitive piece of code maybe it's setting a Security State uh escalation of privilege you deliberately within the

the uh the system um it would be a good idea to make sure that your code has actually gone through all the prerequisite parts of the code before it got there that it didn't just land there by accident and so you can have uh a variable that you're adding uh constant adding values to as it goes through all the parts that you're expecting it to and you check that that is the value that you're expecting before you do your security sensitive operation uh riscure uh a Dutch company have a great white paper on this that goes into uh 11 fult mitigation patterns what it doesn't talk about so much is the cost and the cost here of course is

a a trade-off between Cod code size and performance uh and reliability uh particularly if you're talking about uh in a automotive environment or something like that you you don't want false positives um plus of course code complexity maintainability and development time uh it is really tricky to write code that will fail when the hardware fails uh so Hardware techniques is the other way of attacking this uh and they're not mutually exclusive you can use both uh glitch resistant internal power circuitry um so again there are costs involved in extra silicon and particularly things that involve capacitance on chips uh glitch detectors so glitch monitoring circuitry um we can do this in a variety of ways we can have

oscillator based detection where we have some kind of ring oscillator or something similar or multiple ones and it's doing some kind of comparison um Honeypot logic paths so these are all methods of finding the the chip is under attack and then you can raise an interrupt or reset the chip or allow that to the uh the the uh the person who's writing the code to decide what to do upon that that event um memory protection units can also be used uh so they're often in the chips already so it's not necessarily extra Hardware but uh back to the the good old example of secure boots uh maybe make your the area uh that your image is stored in non-executable until

all your checks have passed so even if it lands in that area before the checks have passed it can't execute that's quite an effective method and of course shielding if you're trying to protect against electromagnetic uh F injection uh emfi uh of course this is a manufacturing change and comes with a cost and people don't necessarily want to spend more on their chips and control flow Integrity mechanisms so you can have other Hardware mechanisms Shadow stacks and a variety of other uh ways of uh implementing that so mitigation techniques uh earlier this year the RP 2350 as used in the Raspberry Pi pco2 in the demo here uh was released and there was a £10,000

$10,000 bug Bounty uh for being able to recover uh a secret that's stored in OTP uh so they employ a an oscillator based glitch or a flip-flop based glitch detector um which is uh you can variable sensitivity on it uh and in September they doubled the bug Bounty from $10,000 to $20,000 so I thought I'd have a look at that so I I got out the chip shelter and attacked it with the emfi so here we see a scan or a plot of the results again green being no effect uh red being a successful glitch and some others uh blue was if the device rebooted in this case and S if there was some other

corrupted response that wasn't useful so this was just uh performing a nested Loop so a very simple thing to attack um checking that it's the right value at the end of that and seeing if I could influence the chip to come up with the the wrong value uh so this was with the glitch detectors switched off I'll just zoom in on that um so you can see that there were successes across mainly one corner of the chip uh so the next step is what happens if we switch on the glitch detector and we'll see that this is actually quite effective and so those yellows are where the glitch was detected so you see here a sea of green

and yellow um but I don't give up that easily so that's what it looks like uh with it enabled after another week of efforts uh I was able to uh find some specific values that allowed me to fly under the radar and successfully glitch that although it's a simple uh effect um successfully glitched that uh I did have to use a smaller coil and a reduced power which does limit the sorts of effects that you'd expect to see so all in all I would say the glitch detector in the ppo2 is very effective but not 100% it's not the end of the story though so I have spotted that there is an upcoming talk in a couple of weeks

time at at 38 C3 the C Computer Club conference um where someone is claiming Aiden Cullen is claiming to have defeated these protections and I'm presuming that he's going on to to claim that bug Bounty so I shall be watching that with uh uh slight jealousy and uh interest uh I did give it a good go but uh it was not an easy task and that glitch detector is not the only security mechanism that's in play in the ppk2 there are a bunch of other things that that are protecting the the OTP read so uh standards and certifications so these can uh have an effect on you know which devices get made what security choices there are um so common

criteria has been around for a long time this is the standard that uh that smart cards are evaluated against um you've got to have a have Deep Pockets to be able to play that game so if you want your chip to pass a common criteria certification you're well into the six figures um and then some uh it's expensive to comply with uh nists uh fips 1403 is for cryptographic modules specifically uh that has some uh stipulations for for injection um resistance the one that I've seen have a large effect is uh the automotive standard ISO SAE 21434 from a couple of years ago um three years ago apparently um that basically forces uh Automotive manufacturers to consider these attacks

it doesn't mean they have to protect against them but they have to be in their threat model and um I have witnessed some um big changes as a result of that particular legislation it's not really legislation but if you want to sell parts to the automotive automotive industry you'll need to be compliant um voluntary schemes uh certification schemes such as rpsa and sesip uh have multiple levels so you can start with something that's just basically self- Declaration of what you've what measures you've taken to protect against a variety of security issues and at the higher levels of those they introduce um resistance to for injection and side Channel um and we've also got the EU cyber

resilience act which is uh pretty much yeah coming into Force very soon um this will enforce strict in uh product instant response reporting and I suspect that that might also uh alter some security decisions that are being made in uh product development teams so I said that I would mention some other attacks and seeing as the demo works so quickly I've got some time um so other invasive attacks uh so decapsulation of the Chip And Optical readout of the ROM uh so if you're relying upon the uh the top of the chip to protect your data then maybe that's not such a good bet if someone is determined and again these these tools it can be done by a hobbyist um with a

microscope and some acid uh and there's there's variety of Open Source software that assists with that um micro microprobing allows you to um connect so after you've taken the top off the chip uh with either laser or uh acid hch um to connect to internal lines that would not normally be exposed uh and indeed you can use focused ion beam to even make changes to the internal circuitry but that's lots of money um and body bias injection so this technique again requires decapsulation of the chip uh and actually uses a needle to inject voltage directly onto a ground plane and this produces a very localized effect very similar to emfi um whereby you get just parts of the chip being affected um

and this works by raising the voltage of the ground plane up and so the potential difference between ground and say VCC the normal high level is reduced and so maybe it reads that as a zero rather than a one um side Channel analysis is something else that we do in my team um so here we are aiming to recover cryptographic keys by detection of tiny changes to power that are data dependent so as it's processing uh maybe an encryption operation decryption operation um processing ones and zeros takes different amount of power or the switching power required to switch between different states internal states in the chip uh can leak information about the key and so here we see this is

a a Langer probes a a German company called Langer um this is a very effective um magne electromagnetic aerial effectively uh and this can detect these tiny changes obviously for this it's it's rarely a One-Shot deal you collect thousands hundreds of thousands millions of traces perhaps and then perform a bunch of statistics on that to perform some kind of correlation normally to to make guesses for the key bites and see which which ones correlate closest to what you see so conclusions it's hard and and costly to protect against physical attacks uh because the hardware if people have access to the hardware how do you protect your code for example if you're writing code against this sort of

attack um these attacks are becoming much more widely known and uh much cheaper the tools are becoming cheaper um there's a lot of information out there how you can do this with tools that you build yourself um and sometimes very very cheaply um glitch detectors uh they them along with other mitigations are a fantastic way of uh reducing the uh the chances of someone exploiting your chip or your IP maybe that's in your chip um yeah there's a lot more effort going into hardware and software protections now because of the increase in Awareness there uh particularly customers asking lots of questions about whether the chips protect against these sorts of attacks and uh of course system

design that avoids storing Secrets don't don't neglect that one if you can use a symmetric scheme where for for example for a signature check where you don't have to store a key that's private key then that will mean that there isn't a result there's no asset there for someone to attack um avoids storing your API keys in your embedded system that sort of thing um so code credits uh so I put together the code for the uh the P COD 2 it is published on GitHub uh it's a bit of a mess because it was done in a rush and did intend to come back and tied it up and time ran away with me on

that one um but it does work uh the DFA key recovery Li the main library for that was Phoenix a from pH Tu then um and as well there was AES Keys schedule by Marcel nagala and uh yeah the PCB design uh by asfw and the uh chip shelter emfi probe is from Colin olyn UAE technology and of course incredible patience from my wife whilst I Was preparing for talk so yeah everything is published on GitHub uh that probably isn't a rick role no defin definitely isn't it rick R um feel free to find out um and that's me on uh Blue Sky if you want to ask anything else or I can take questions

now if there are any there's a mic just coming your way just hold it there's a mic coming

so you mentioned variable time and delay being a good mitigation to some of this stuff even where that's present um sometimes on a Power Trace there'd be like an artifact that's a fixed distance from where you want to glitch but that's not always um triggerable with like a simple trigger how would you go about dealing that and using that as a point to trigger an attack yes so I don't know if people heard the questions about uh if you've got random delays um yeah is there some other signal that you can use to trigger to you don't care about when that happens um so yes you can use side Channel analysis to trigger something so

you can have uh maybe monitor the power consumption of the device and set a pattern that is recognized on that using um a sum of absolute difference or a corridor uh sort of uh pattern that it recognizes and produces that trigger so I said uh in my example there for the the the glitch parameters that um you know that trigger could be comms or whatever it could equally be a side Channel um Trace um the other way that you can defeat uh randomized timing delays is to attack it maybe earlier on when it's setting up that random number and sometimes that can actually mean that your random number is effectively zero and it's then a predictable delay

or multiple glitches so you can um yeah have a single glitch early that that disables that and then a second glitch that is is then the attack thank you

thank you I have uh three questions for you uh one is about the content of the talks the the glitching you mention emfi and voltage glitching I'm completely new to verm metal attacks but I'm trying to learn so my question is if you have to pick one over the other because of effess on your experience like which is the one that you have to try first because seems more more productive let's say I'm going to give you you asked multiple question you say you have multiple questions I'm going to give you multiple answers um so if you're starting out I would say start with voltage P injection for learning about it because there are fewer

parameters um my go-to attack my favorite attack is emfi because that is a legitimate magic wand all sorts of weird and wonderful Behavior can happen with the mfi but you've got positional dependency you've got the coil voltage you've got Which choice of coil there's there's a lot more parameters to explore so for for starting out I would say voltage full injection for getting the results that you want uh sometimes it does require mfi particularly voltage for injection can also be tricky because of the capacitance on the board and removal of components and things like that so if you're talking about attacking a very low power device that's less of a concern um the capacitance is

generally Less on the the power circuitry on that um so if you're you're looking to learn something like a p Pico is great to be able to attack um yeah I I would say yeah start learning with voltage P injection and progress to emfi okay great uh my second question is about one of the additional attacks you mentioned like chip decapping and Optical rate of the ROM my understanding is that this is effective if you have the the actual fuses borned like you have ones and zos right but I was recently learning about something called antifuse technology where you can achieve the same but you cannot see the the the physical ones and zeros so in

that world you know top of my mind uh top top of your mind sorry uh what is the instead of physical um Optical rate of the room what should I do in that type of scenario let's say I Decap a chip and I don't see the physical zeros and and ones is there like a well-known technique or set of techniques to recover that rum do do you have a scanning tunneling microscope at home at all no well the company has a laugh for that so perhaps I can I can try the there may be other ways of being able to um read the the levels that are stored in some other technology it depends on the

technology as to what okay great thank you and the last question a little bit opportunistic you have any SP budges for sale because I'm interested in buying one I have a couple of these available here um and I've got some pcbs that are not fully populated so some of these don't have um p2's on um and I've got some plain pcbs so okay great thank you that's those were my

questions hi thanks thanks for the talk um I guess my question is like you you gave some examples where like protections have been put into like the pco2 and yet you are still able to do so get past the the the glitch detection does that kind of thing scale up to sort of more high-end things like infini and Sams I've read like their marketing material and it sounds impossible but like it's is that practical to like go after like Sams and things like that and TPM gips with these kind of techniques I I'm not going to talk about any particular uh manufacturers um yeah let's just say marketing claims are sometimes not the same is the

reality so I I have looked at a variety of chips um and compared with their marketing claims and the two don't always match up right so so worth looking into don't just assume because they say they've got like two chips running in there comparing things it's it's fine you shouldn't even bother yeah even if you've got um even if you've got multiple chips and you know clock offset and everything um sometimes Two glitches can actually hit both of those and have the same effect obviously your success rate is going to be much lower um you're going to spend a lot more time waiting for results and parameter narrowing is going to be much harder so it it will

definitely increase the difficulty it's raising the bar um but I don't know how effective any particular one is I couldn't but without going to the point where you're buying like Nano fibs and things like that you can still potentially things use things like chip huskys to do this if you got lucky you think sorry the chip whisper husky yes so if you had something like a with the Husky you still think you might be able to get a working glitch out of an Sam I'd certainly give it a try um thank you cool I think sorry we're out of time so uh just pleas me to say thank you to B for the talk and much