 Because in the keynote, it was said that we should go to talks where we have no clue what the title or the description of the talk means. So I thought I can use that as an excuse to do the herald job for this, sir. And this guy will talk about reverse engineering of chips of ICs integrated circuits in a non-destructive but rather complex way of doing electrically stuff that's not in the data sheets rather randomly at times. The priest that should give us this introduction into this type of voodoo magic is, let's be excited about excite. Alright, so thanks everyone for coming out here. So title of this talk is glitching for noobs, a journey to coax out chips in our secrets. So basically this is kind of over the last couple of years I've got interested in the topic of glitching and have been trying a whole bunch of different experiments and trying to learn for myself what it was all about. So this will kind of be a chronological kind of summary of what I've been up to in the last couple of years and what my findings have been. So just the quick agenda for the talk, quick intro, background which is kind of the classroom learning about what glitching is, platforms which is some of the various hardware platforms I've come up with in the last couple of years. Some of them were epic failures, some of them were actually seemed to work. So it'll be an explanation of the pros and cons. Example will be a real-world example of a secure microcontroller where I was able to basically get some glitching results out of and maybe some food for thought, some thoughts that you guys could carry forward and how you could approach some of your own chips and then finally any Q&A section. So intro, about me, I'm an IT monkey or a consultant by day and I'd consider myself a hardware hacker by night. So some of my interests are designing and reversing embedded systems, IC security and failure analysis, arcade platforms and automotive stuff, anything electrical or mechanical or whatever is pretty cool to me. And my contact info you can see there is just my XI31337 at yahoo.com email. So let's go into the background section, the classroom section. So what is glitching? So a glitch and this is not necessarily electrical right now. The definition would be a transient which can induce alteration in a device operation. So a glitch is something that can mess up a device's normal operation. For this talk we'll talk about electrical glitching specifically and specifically clock glitching and voltage or power glitching. And there are other variants like laser, thermal, radioactive but I'm not enough an expert in those topics to give them a good speech. So if we focus on the right hand side there on non-invasive, semi-invasive and invasive types, so electrical glitching would be considered a form of non-invasive attack on a device. So this doesn't permanently alter the device's package, the physical, epoxy, black part of the chip. It doesn't permanently alter operation of the device so when you remove the glitching stimulus or you stop glitching, it should work normally again and it's repeatable which means you can start glitching, stop, go away for a little while, come back and do it again and it's not going to harm the device and you can keep repeating it. It's also surreptitious which means there's no milling or drilling or etching or things of that nature so it shouldn't look like you actually did anything to the chip physically. It should just look like normal. And another characteristic that's fairly important is that non-invasive attacks are usually cheap so you don't need an expensive lab and you usually don't need things like specialized microscopes or other expensive tools. And the kind of drawback to the non-invasive attack is that any background details you have beforehand are very helpful because they'll help to narrow the scope and what strategy you want to do when you're trying to glitch rather than a completely black box device where you have no idea where to start, you could take many wrong turns so any information you have beforehand would be quite helpful. So some examples of non-invasive attacks in the umbrella, there's three umbrellas so there'd be fault injection which would include clock glitching, voltage glitching, you can do thermal glitching which is kind of where you're trying to affect the junction temperature of transistors but really from a non-invasive standpoint you're either trying to heat up an individual pin or trying to heat up the whole chip package all at once and it's not really precise so I'm not sure if a lot of beneficial effects could come from the thermal side. There's also radioactive glitching so if you just happen to have a source of X-rays, gamma rays, alpha particles or neutrons walking around in your pocket, you may be able to sit those nearby the chip and get it to flip bits of memory or cause the CPU's instruction to latch an invalid instruction or something like that. So the next umbrella is kind of side channels so that's where there's a power analysis where you're basically studying the current consumption or power consumption of the chip which can leak operations being performed, can reveal things like crypto round keys or kind of intermediate keys that could be used to derive a full break on the encryption and it can also indicate where the CPU is, provide an indicator where the CPU is in its instruction, in its execution of the overall program. So there's timing attacks which is simply trying to exploit the fact that conditional branches, when you're checking for a password or something else, you might stop when you find the first incorrect character and it'll stop a lot faster than if it went through all the correct characters so you'd be able to exploit the difference in timing to know if your guess at a secret password is correct or not. Data remnants, that's pretty much kind of like your cold boot type attacks or if you do a reset or power up a device and it doesn't wipe its memory then there might be a secret still in memory. And then finally the third umbrella is software. So this could be simple code vulnerabilities. The authors of the secure device may not actually be that versed in secure coding practices so there may be just vulnerabilities sitting around like buffer overflows, stack overflows, things like that. Brute forcing, so you could simply try brute forcing if the key strength is small enough. The secret that gains you access to restricted memory areas, code protection, you might try brute forcing a crypto key but if it's a relatively modern implementation it's probably not going to work for you. And then finally backdoors which could be undocumented instructions in the CPU core. Could be debug interfaces, JTAG, UARTs hanging off the device somewhere, I2C, SPI, stuff like that. So those can be some of the more low hanging fruit but may or may not be present. So the second major class of attack is semi-invasive. So this is where you are altering the package of the device. So you might decapsulate, so you might etch away the epoxy packaging of the chip or you might mill the chip from the top or the bottom to gain a better access of the actual die sitting inside the chip package. It doesn't permanently alter the device operation so again you'll be able to apply or remove some sort of glitching stimulus to the chip and when you're done glitching it should operate normally. Again it's repeatable unless you're doing laser glitching where you leave the laser on too long and you burn up something that you didn't want to. It's more expensive so now you may need things like lasers, microscopes, chemicals, a mill and this class of attack may be on a single person's budget so it depends how well funded you are or not. And this kind of attack can provide background details rather than require them so you'll be able to help narrow the scoping strategy potentially for your non-invasive glitching attack and get a basic floor plan of the chip for example if you've got an optical microscope or something like that. So some semi-invasive examples glitching, you can still glitch semi-invasively so now you've got access to the chip's surface in some way so you can use things like laser flash, like a camera flash, high-intensity light and thermal glitching where now you might be able to direct a source of heat at a more precise area but still going to be probably pretty, could be fairly unreliable or you'll end up altering bits or transistor gates in a larger area. So another type of example is laser scanning so you can do it with the device being unpowered or powered and so when it's unpowered you basically have an optical beam inducing a current flow in the chip which will change the current signature like the power consumption signature and then if the device is powered on your optical beam can cause a measurable voltage change in the output of the transistor or the bus that the transistor is connected to so it may be possible to do things like read out memory bit at a time by watching the current consumption and then sweeping the beam across the different rows or columns of a memory for example and then finally there's the, you can do imaging attacks where either do from the front of the chip or the back of the chip where you mill away the back material you can do visible wavelengths versus infrared and you can do things like using optical microscopes versus electron or ion beam based workstations and this will allow you to get the floor plan of the structures and features of the chip a lot more precisely so things like ROM, RAM, flash, e-squared, configuration, security fuses things like that. So now the highest notch, the most complicated type of attack is the invasive attack so this is where you not only have the decapsulation and milling of the semi-invasive but now you also have dye alteration itself so the actual little chip part of the microchip and you can render the device non-functional with this process for example if you're trying to image the device layer by layer obviously you're removing your etching away materials so the device, once that layer is gone it's gone for good so you'll want to have many samples available so that you can image the device like that however if you don't want to do that but you want to have access to the surface of the chip for example and depending if you've got access to an FIB workstation where the device input pins like voltage, ground, clock, etc are outside the vacuum chamber or outside the chuck you can actually power the device up and run it while you're making modifications to it so like I said most of these techniques are one time especially the de-layering process whereas the FIB workstation can allow you to create edits undo edits so you can go back and forth so this class attack can be very costly so whereas the decapsulation and the readouts of the imaging of the chip can be somewhat reasonable the actual being able to edit the chip can be very prohibitive depending on if you have access to the equipment or kind of an hourly rate to get on the equipment and then finally this class of attack will pretty much provide you with complete background details so you can use all the floor plan data you can actually force certain transistors or buses circuit nets on and off and actually get a good idea of how the device operates and then you can feed this information back into the semi-invasive and non-invasive attacks to make them a lot easier because you know where on the chip to target so as I mentioned previously so some examples of invasive are decapsulation so taking the chip out of the package de-layering the actual die you could do a memory readout which if the circuit has ROM for example you'd need to get through all the layers all the metal layers down to the very first metal layer and then that's where the actual ROM transistors are formed you can do circuit edits so etching where you're removing material from the die in certain areas deposition where you're using something like platinum or tungsten to deposit conductive material on the surface so you actually create a conductive path wire bonding where you're actually taking a wire bonding machine and putting gold bonding wires from the die of the chip or from areas of the chip out to a larger more human friendly package like a very large dip or something a dip package where it's two rows of 10 or 20 pins or whatever and then you can easily work with that and then you could also purposely destroy traces or transistors at this point if they're causing some sort of functionality you don't want and finally you can do micro probing so when you've got really really tiny for example tungsten needles you can actually stick them down on the surface of the chip and either listen to what's going on or if that or drive a signal back into the core of the chip somewhere so that kind of concludes the different classes of attacks and kind of from cheapest to most expensive so back to electrical glitching so how do you actually, where do you get started how do you generate glitches so when you're making these glitch pulses that you're sending into the chip either through either on the clock lines or the power lines of the chip here's four methods that I basically came up with and some of you guys are probably really smart and can think of other ideas but these are the ones that I could think of a simple clock divider phase lock loop if your device in this example had an FPGA with a PLL use that poly pulse with modulation where you've got multiple PWM signals further apart from each other poly phase where you've got three signals that differ from each other in their phase so the first clock divider example this one's the simplest where you literally take as many D flip flops as you want and every time you go through a D flip flop you basically divide the original input signal by two when you feed the output of the flip flop back to the input 48 divide by two down to 24 divide by two again down to 12 and so now what you do is you have this multiplexer where you feed it the slow 12 MHz signal and the original system clock 48 MHz signal for example and you run the device through most of its lifetime on the slow signal and then you toggle the glitch select line down here at the moment you want to glitch and then now all of a sudden you'll get 48 MHz pulse train instead of the slower 12 MHz in this case and you can use this directly as the clock signal to the input of the device or you can use it to gate the switching of the voltage from a high value to a value that's known to cause the device issues so it gets flexible and can be used either way so this is what the waveform would kind of look like here's let's say here's a single speed clock and here's a double speed clock and then when you bring your select line high on the which is the select line on this multiplexer down here then all of a sudden you will switch the actual waveform that goes to the chip from the slow to the fast so it simply just switches between slow and fast so the second method is the phase lock loop PLL so the PLL uses integer multipliers and dividers to create a fraction an integer fraction something over something that can be used to multiply up and then divide down to get you many more different kinds of clock speeds than simply dividing by two each time so then this way you'll get for example have the PLL feed the PLL with this normal fast clock and then instead of 24 and 12 you also get 16 and 4 or whatever combination of speeds you want in between combine all those with the with the fast system clock add a couple more select lines and now you've just given yourself more choices in terms of what speeds you want to play around with so if you do this work up front then you don't have to have to keep changing your circuitry down the road it's more flexible so the third method is poly PWM so this is where you use multiple pulse width modulation blocks to generate clock signals with successively longer and longer duty cycles so now in this case instead of changing the frequency we just keep our system clock at 12 12 12 all the way through these blocks but now we have a 50% duty cycle which means 50% duty cycle means half of the waveform there's equal parts on and off in the cycle of a waveform so you'll see in the picture 70% means that the waveform is on 70% of the time off 30% of the time so the remainder between 170 and 100% and then the third one is 85% and then what you do is you feed these into a XOR gate then the output of that couple it with one more XOR so it's basically like you're XORing the two signals and then XORing in the third signal with it and then that'll get you a glitch pulse and then again you just take your select line to go between the original clock and then the shorter pulse and here's kind of how the pulse the short pulse gets generated so again the frequency is the same and then it's fixed so these things are locked if you look here right in the middle those lines all start at the same time so the phase is they're all locked with each other however when you change the duty cycle you'll see that the 60% wave is on a little bit longer than the 50% and the 70% longer than both of them and it kind of it's like a staircase effect and so what happens is when you run these through those two XOR gates the difference between the first and the second pulse gives you when you want the pulse to start so that's right this left side of it right here is when you want it to start in horizontal relation to the on part of the pulse and then this third duty cycle wave the difference between the third and the second so the 70% and the 60% gives you how long you want the actual glitch pulse to last for or how long you want it on for so this is actually a pretty flexible method and you don't need PLL hardware in your device if you want to be able to generate these wave forms and so basically you get one pulse of it whereas the kind of the fourth method that I can think of was poly phase so multi phase and this is where you generate multiple wave forms but each one is phase shifted from the previous wave form by some so many of degrees so the frequency again the frequency is the same 12 megahertz 12 12 12 so it's all 12 but now you're shifting the actual relation of the second and third waves to the first wave and again selecting when you want normal clock versus glitch clock so now the only real difference is now the waves the on time duration for example right here is the same in all three waves so it's not differing like last time but the waves are offset they're beginning when they start is further and further ahead from each other and effectively what it does is it gives you a glitch pulse on the leading the beginning edge and the trailing the end edge of the wave form so you get twice the many pulses as you did with the poly PWM so do you need it or not it all depends on your application it may help you to be able to generate them more quickly or more often but it's just another way to do that so a quick aside like I'm using Altera FPGA so you don't have to worry about reading all this big paragraph this was just an excerpt out of Altera's manual on for example in Xilinx will be similar if the FPGA has a hardware PLL how you're able to these are the steps how to instruct the PLL to actually create phase shifts from its different PLL outputs which is basically how I took those different phase shifted outputs and created the these waveforms so then it's got this specific timing diagram where you're supposed to give it these whether you want to step at one or more degrees whether you want to step forwards or backwards and phase done is just what the PLL module outputs back to you when it's done shifting so this was looking kind of complicated to get all these timings right because the FPGA I was using had a soft CPU in it so I ended up having to make a state machine because the my soft CPU was so slow in relation to the PLL's ability to shift its phase that I would say go shift by what I think is one degree and it would come back with like seven or eight degrees of shift which to be scientific about it I want to go one degree at a time so I could see the effects with each degree of shift so I just made a simple state machine that just literally when the CPU says I want you to shift one degree it goes off programs the PLL and then it exits the state machine and waits so and the CPU will still have said I want you to shift one degree and it'll be stuck in the start equals one position then finally like many many clock cycles later when the CPU because it's much slower than this PLL when it finally responds then you can tell it to put the start bit to zero and then it'll bring you back to the initial so this way allows you to shift one degree at a time so it'll get trapped in this loop until your CPU is actually able to shift so back to the kind of the classroom so what is clock glitching actually doing so basically it's a momentary burst in frequency as you can see with those little pulses compared to the normal clock pulse you all sudden you had a quick one usually greater than the max frequency of the device so simple cases if you got a data sheet look it up see what the device is rated to run at and then go even faster or many multiples faster the glitching is timing critical so the value of the program counter so where the program is and it's overall execution where the CPU is and it's overall execution of its program you need to know if at the specific point you think it's going to be doing a compare or you know it's doing a compare you have it there and then now you know that it's doing a compare where in the actual compare instruction do you want the glitch to hit so that's your offset of the glitch within a single instruction and then finally how long do you want that pulse to last which was kind of that third duty cycle or that third phase shift wave in those diagrams determined how long the actual pulse lasted for so basically what this does is it causes registers inside the device or flip-flops to latch invalid data because signals are still propagating through combinatorial logic through the device when you suddenly clock it and so basically the destination flip-flop froze so from the source to the destination as the signals propagating you clock it ahead of schedule so the device will basically latch invalid data because the correct signal hasn't propagated its way towards the destination flip-flop yet so what will actually be happening is you'll either get instructions in the CPU core will either be duplicated or mutated so what would happen with a duplication is let's say the real program had a compare and then followed by a jump so it's checking some condition in an if statement and then jumping what you'll actually get is the compare will become compare compare so that jump will actually go away and that's usually caused by a fault in the fetch stage of instruction processing so you've got usually fetch, decode, execute memory operations and register right back or typically your four or five stages of your risk CPU for example so it'll mess up the very first fetch stage the next is mutation and this is where you actually turn like a jump instruction into an ad which is probably harmless in this case it gets you what you want it bypasses an error check for example but it just turns it into an ad and usually in the fetch decode execution it's the actual execution stage that gets messed up when an instruction is mutated so the actual core is about to execute an instruction and then it gets mutated into something else so this is kind of the hardware equivalent of patching a software binary where you go into your hex editor edit an instruction to become something harmless and so technically the instruction is not actually skipped so the program counter or the instruction pointer on the CPU doesn't just skip ahead to memory locations to the next instruction it's still executed it's just it's either going to become a duplication or a mutation so it'll feel like it's being skipped though in those cases so sometimes this quick burst of clock frequency can affect your config or security fuses so they'll either fail to set in some cases or they're set incorrectly so this could actually be kind of helpful to wipe out some certain code protect fuses or things like that but it's a lot more particular in how it works depending on the device so here's kind of an overview of that phenomenon where you have the source flip-flop and the destination flip-flop then you've got a bunch of combinatorial individual and or etc gates through the middle and what you're doing is you have a clock event all of a sudden you have your glitch pulse and this pulse occurs down here well before it was expected over on the right hand side which coincides with where the actual destination flip-flop is in time and propagation distance so you clock it way ahead of schedule and now it'll clock in some garbage data here rather than the proper signal making its way all the way through so that was clock glitching so what's the mechanism of voltage glitching so this is a momentary reduction in supply voltage to the device so what you do is you drop the voltage 2 or below the transistor switching threshold and a rule of thumb is try supply voltage divided by 2 and start from there it could be lower it could be higher but it's a good starting point so what this does is this increases the propagation delay which is literally the delay of the signal propagating through the device so it gives you kind of the same end effect and why that happens is because when you decrease the supply voltage it decreases the drive strength of the transistors and this lower drive strength will cause a slower rise time so you'll actually instead of a sharp edge rate a sharp transition of signal transitioning you'll actually get a slow it'll take a long time to plateau a long time to discharge basically so that gives you that effect where it slows that propagation of the signal down and again just like clock glitching you want to be accurate to where the instruction is in the overall program where inside the particular instruction you want the offset of the glitch and then how long you want it to how long you want it to be active for so what it's doing is it's also altering the values at the memory sense amplifiers for flash E squared RAM etc and so this has the effect of corrupting data latches onto the address or data bus so you can actually have the program swing off wildly to an invalid location because you latch a bad value onto the address bus most cases it'll crash the chip but in some cases it might jump you into an area that the program was never supposed to reach and again security fuse logic in the voltage glitching mode can also latch corrupt values due to that effect where you're right at the switching threshold of the transistors so just to dispel a few misconceptions I don't recommend throwing random voltage sags and surges at the IC and seeing what happens I would recommend respecting the absolute maximum VCC and VCC for the IOPIN ratings on the data sheet if you have one otherwise you can have latch up occur which is basically kind of a short between the power rails of a device or two pins of an IC and this can cause the device to overheat or basically destruct due to overcurrent so you want to avoid latch up some 74 series logic you can you can give it very high and low voltage swings on the input pins but usually they have a current limited condition in the data sheet like specific fair child chips for example but not national semiconductor will say you can do this and that's because you have to put a giant current limiting resistor in front of the pin basically so don't throw these crazy high or low voltages at a chip unless you got a bunch of them basically and you're not randomly jarring the clock frequency to a wild extent you're specifically targeting that pulse at a certain point and you're not technically skipping instructions you're as I said you're kind of duplicating or mutating them again it's timing critical and finally if the chip unless the chip is stuck in a loop just randomly glitching like with random voltages or the clock at certain offsets randomly is usually going to be counterproductive unless the device is stuck in a loop a tight loop with a few instructions then obviously the search space that your glitch has to hit is very constrained it's very small and it's more likely you can pop out of the loop so what are some of the outcomes in general that voltage or clock glitching can or potentially any glitching can provide for you so you can make the CPU replace impeding instructions so you turn that compared jump into a compare compare which doesn't jump anymore you can truncate cryptographic operations or keys so reduce the number of rounds in a crypto encryption or decryption process you can do linear code extraction where you basically dump you walk the address space of the device address location 1, 2, 3, 4 all the way until the memory map loops dumping out the data from the device byte by byte however you do usually need an IO channel to actually get the data out so a UART pin or something of that nature you can do things like bypass boot loader and force check so you can stop the management unit or page tables from initializing if they're mapping in sections of memory over top of the boot loader to hide it or conceal it or just to save to provide more space you can stop that from happening in some cases you can prevent lockout counters from rolling so if it's a secure crypto memory or something like that where you only have so many tries before you're locked on the device if you glitch when it's recording or decrementing your try counter the try the number of tries will never change so you can just keep doing your malicious activity over and over again without the device finally reaching zero and then erasing itself or halting or something of that nature and then finally in some cases you can erase security fuses or lock bits so what this will do is keep the flash and E squared intact so then you can just take the device off the board for example plug it into a parallel or serial program and just read out the device that way so if you're looking at chips to try some of this stuff on there's pretty much your general purpose and your security enhanced categories so things like general purpose things like CPUs microcontrollers memories digital signal processors then on the security enhanced side you've got things like SIM cards smart meters military devices chip and PIN pay TV transit or metro and then automotive devices however the security enhanced side is I'm not saying like stuff's going to work necessarily there it depends on the age of the device and how smart the developers were when they made it a lot of these security enhanced devices are actually really really good so things I don't recommend is trying to trying to attack like FPGAs or ASICs simply because there's so many unknown variables and unless you know there's a certain CPU core inside that ASIC or that they've programmed a certain block of logic in the FPGA it's you'd be fishing around in the dark basically so what are some countermeasures that you could use for example a manufacturer or if you're writing code or embedded code for advice what could you do as a countermeasure you could use a CPU which halts or traps on invalid instructions however in the case of the instruction mutation where your jump became an ad the ad instruction is still a valid instruction in the table of instructions in that device so that may not even trigger an invalid instruction fault so better than nothing though you could erase volatile memory on startup or reset just no matter what a device comes up just a good best practice to wipe the memory so what you want to do is minimize the number of copies of important secrets or primitives so like for RSAP and Q or any combination of those intermediate values that could drive back to your private key keep as few of those as possible and obviously wipe them between iterations of a routine in certain parts of the program if you don't need them get rid of them so clocking when you're clocking the device you could use a device that runs off an internal oscillator so it just ignores the clock pin from the outside world so that pretty much would cut off any clock glitching attacks you could use asynchronous logic wherever you could so if something didn't need to be clocked by a clock signal then don't and finally you could use a periodic or random clock period generation which is where the actual clock period is changing between cycles so it's unpredictable in terms of the timing finally you could use obscurity which is another kind of last layer of defense it's not a not a prime defense but use a really complicated you know 48 bit very long instruction word DSP core with poor documentation in your product it would probably make it harder for you to write if you're the developer as well so it's not that great of a countermeasure finally so supply voltage use glitch or brown out detection and this can be very complicated with fans fast transient detection that actually detects and responds you could use a simple low pass filter which simply ignores and erases that quick transient as far as the chips concerned so it doesn't even see it or you could be more aggressive and reset halt or wipe the device if you detect someone is trying to mess with your chip this way so many general purpose devices have little or no design and protection so these are chips that you guys could look at in terms of interesting targets so AVR's picks TI MSP for example they do have they do have code protection so it may not be your first choice if you're if you're just starting out a learning and then at the hot at the extreme level modern smart smart cards chip cards have extensive protections so they've got glitch detectors they've got the random in a periodic internal clock which is changing in its length between cycles and you'll have two CPU cores in lockstep that are sanity checking one another so if some instruction goes wrong in one core the other core will be offset and catch it and do something like either reset the device or erase the memory etc so this will detail some of the actual hardware platforms that I made over the last couple years that that were that I used for voltage and clock glitching so the summary of this guy's basically this is an off the shelf arrow low power reference platform board that I found for really cheap on eBay like I think it was between 20 and 50 us dollars so not not crazy expensive so it has an Altera Cyclone 3 FPGA which I've put a MIPS 32 bit soft CPU inside of it that 3 PWM clock generator that I showed you before the 3 polyphase clock generator it's got a regular 16550 UART it's got some driver functionality for SRAM and flash control and then some output multiplexers to switch between your low speed normal signal and your high speed glitch signal and then this messy breadboard at the bottom is just doing voltage level shifting and signal conditioning and buffering so that the end target in the FPGA for example doesn't get blown up by if the target device is running higher voltages than the FPGA so this is a close up where you've got kind of general purpose IO pins up here you got 3.3 volts supply 5 volts supply FT32 USB to UART chip SD card which I'm not using at the moment but could probably be used for data logging CPLD which is used to program the FPGA from a PC the actual FPGA Intel flash and then some micron PSRAM which is actually DRAM wrapped with a SRAM interface so it's just easier to work with it you don't need to have all the crazy DRAM timing signals exactly right and then on the saw list breadboard there's just some these 74 the LV is important so 125 is just a buffer that takes an input signal provides an output and then it's got a beside each pair of those input pins there's an output enable pin that lets you float the signal or drive it and the LV is important because it's 5 volt tolerant so you can power the device with 3.3 but it'll accept 5 volts as input so any outputs from it will be 3.3 but let's say your device runs at 5 volts it can output its signals to the input of this as 5 and this will output them at 3.3 to the FPGA where you won't blow it up whereas if you drive it the FPGA at 5 it won't last very long so other than that just your 5 and 3.3 volt power rails and then just the pull up pod I was playing with to strengthen the drive strength of the one of the signals so here was another iteration soldered breadboard which is kind of a beefed up version of this that I thought would work with higher frequencies because it's soldered but clearly you can see from this mess of wires that my routing is amazing and so I use this board for both voltage and clock glitching and it has what I call a ghetto DAC which is basically you provide a PWM so a varying duty cycle signal of how much on time to off time into a low pass filter and the output at low pass filter will actually be a steady 0 to 5 volt range DC voltage based on the pulse width of the signal coming in so it's just an easy way for a microcontroller or FPGA to send a PWM signal and you end up getting a varying voltage rather than having a real digital to analog chip that does that in its own way so for a while I seriously considered Arduino for about 7 minutes because why not and the problem with Arduino is the crystal is fixed on board wherever it is I can't see it at the moment but anyways I think it's 16 megahertz and as soon as you go and use any of the timer or output compare registers to divide that clock down you can't actually, you can't take the 16 megahertz and provide it directly as 16 megahertz on an output pin it automatically goes through a divide by 2 as soon as you turn any of those timers so already before I even started all I could do was 8 megahertz signals out of this thing and so if your device is running at 2 or 4 megahertz that might be enough but if your device is running at 32 megahertz then obviously this isn't even going to help you so it just wasn't flexible enough so then I thought I'd make an even more feature rich boards and because I'm thrifty decided to etch it myself which was pretty much an epic failure because what happened was my transparency that you shine the fluorescent light through with your mask of the layout was slightly off the surface of the board which had the effect of being out of focus the artwork was out of focus so basically I had blurred pads and traces that didn't develop properly so you can see stuff like this probably isn't conducting too much current through it sections right here were wiped out entirely and you can see the ground plane attacked because you leave it in there to try and eat through some areas meanwhile it's starting to eat through areas you want to stay there here's another kind of example of that more failure so then what I decided to do was break down go to Osh Park and make a professional PCB because as you can see it required a few edits after the fact already and so this board was primarily designed for voltage glitching it has an AT Tiny 2313 CPU that I just had lying around and why it's not great for clock glitching is that it's obviously there's a fixed crystal on there so you only have a certain range of divisions you can do with that and it also like the other board uses the ghetto DAC and this buffer simply strengthens the output drive current so that you can actually power the device up through this buffer rather than having a weak 5, 10, 20 mA signal coming right off of one of these 74 series logic chips so here is another device my sniffer board which is just basically used as a man in the middle so this would plug into the FPGA and then this AHC 125 is just like the 74 LV 125 so it's just a 5 volt tolerant chip that can drive signals at 3.3 volts to correct the voltage mismatch between the FPGA and the target and so basically that allows for data logging and then what you can also do for a cheap and dirty data logging and logic analysis is you can use this logic block called Altera signal tap 2 in the FPGA and what this is is a logic kind of a soft logic analyzer block that can analyze almost any signal net bus external IO pins whatever you want and you can save more and more samples by using up more logic elements or slices if in Xilinx terminology of the FPGA so there's plenty of trigger options from simple low higher edge triggering to you can chain events do multiple segments of capture so it's got all sorts of triggering that and storing that a full logic and a hardware logic analyzer would have then you can export the data in plain text images or other formats so the plain text would be a time a comma separated list of the signals over time like one zero one zero and then you can pack that back into an actual parse it back into a protocol so it's equivalent it's also called Xilinx chip scope if you're using the Xilinx product so here's a quick summary of what you do you basically pick the clock that you want to clock the logic analyzer at pick which signals of interest you want and what logic levels or triggering you want the recording to kick in at and then you get a nice waveform view where it shows you what those signals did after and below before the trigger point if you want so let's roll into the last section which is the example of example device I was playing with so I had a victim IC I knew it was a secure microcontroller but I wasn't sure what the internal architecture was of the CPU core I knew that it paired with a partner device so it was a reader and then the target chip so the reader would send data to the chip and decrypt it with a key that was inside of it and then send the data back to the reader which would go off to the rest of the device so I was basically starting with a black box and so I wasn't sure what data sheets to look for even if the device was known the data sheets might not have been public anyways so what I did was basically start probing the pads of the chip of the victim chip did an initial sweep at the multimeter I've got like a little fluke meter so the little bar graph part of the meter will respond a lot faster than the actual numeric digits and then I'd come back with an actual oscilloscope for any pads that showed interesting quick moving activity so one I found one pad appeared to speak a slowish serial protocol so all I did was capture and just transcribe the beginning of that waveform because my scope had really small amount of memory, onboard memory and it was only one pin doing that so my guess was that it was some sort of half duplex communication going back and forth because I knew it talked the victim talk to the reader so then I used that sniffer board to basically man in the middle of the conversation and I used that signal tap logic analyzer software in the FPGA to export the waveforms of plain text pack those individual bits back into bytes read the byte string and I found out that after googling that I saw 7816 APDU header that I found so at that point this was good so then what I was able to do is add a UR to the FPGA and so that's 16550 so what this does was allow for hardware framing of the transmission and receive data with the victim otherwise you don't need a UR you can do it with bit banging but then you have to waste like two or three days potentially to get the timing perfect so it's just easier and then with the Altera you can use this logic block called JTAG UR to talk to the MIPS 32 bit soft CPU running in the FPGA and then the CPU can talk to the victim so then that way you just need one programming cable from the board to a USB port on your computer you don't need a cable to the victim and a cable to the FPGA so now that I had that kind of intermediate speaking going on I had the PC speak ISO 7816 smart card protocol with the victim and so the 7816 header has a length field so I proposed the theory that the victim is probably comparing the length that you send it in the length field from the device or from the reader to the max that will allow as it's buffer input usually like I'm not going to allow you any more than this because I've only set aside 64 bytes of RAM to store the commands to RAM for example and if the length is too long then issue an error so then what I was able to do the next theory was issued a whole bunch of too long commands to the victim but otherwise corrected up the checksum so that it was correct and then observed the error response from the CPU and at this point now is when you get ready to glitch so this is what I call the sucker punch which is this is a clock glitch where you see a quick pulse in time like this pulse wouldn't be here normally in the normal speed of the device so you can do a one two punch which is simply two pulses one after another and you can try any variation of this one two three four five different periods so this is clock glitching and glitching during the suspected victim's command handler so where the victim would be accepting commands and checking the length on them the length of the packet so what I do is try different pulse offsets and durations to try and narrow down when it was executing for example the compare instruction that would be checking the length of the packet you're sending it and so you know you've hit a milestone when the victim instead of when you give it these length these packets that are very long but with correct check sums and it normally errors out all of a sudden it doesn't error out and it actually processes the command even though it's called all these garbage bytes at the end of it to make it way longer so now you know that you've probably hit the compare or the jump instruction with your glitch and you've stopped the device from issuing an error so at this point if you're already sure there's usually Motorola 6805 based cores or Intel 8051 cores or the majority of smaller 8 or 16 embedded devices so use that as your guess so as I said you pad more and more data to the end of the command and then wait till the victim crashes or does something weird so you might if so as you're padding more and more data eventually if it crashes so now you've sent in a too long value but you make it even more longer that's not good English but whatever so eventually you'll stack the smash but it could be hard to notice if there's a hardware watchdog that notices that all of a sudden the CPU flew off into no where land and then reset it but basically that's what I was able to get to the point where I knew where the stack pointer was gone beyond it and overwrote the return address so now that you know now that you know where the return address is you can actually start writing programs for this device because now you control a return address so you can write minimal a tiny little program that tries to write to low address special registers so like Motorola 6800 for example port which is the output pin value pin which is the input pin DDR which is your data direction register start playing with those and see if you can get your IO pin or one of the important pins on your victim to toggle all of a sudden change because now you know where the address now that you know which that those pins exist and how they're mapped into memory so here's your typical layout of the victims memory space but yeah so your next milestone is where you do actually have the output pin chain one of the pins on the device either the IO pin that you're talking to it on or a different pin that might be bonded into the chip that you're talking to and you know where the address is value now you've confirmed code execution your architecture guess is probably pretty good because you wrote a little program in that target architecture of a few bytes to write to that low area and it's probably von Neumann or modified hardware Harvard that lets you do that so now you're getting really close you the next thing I did was write more code in that architect in the 6805 that loads a dummy and then you know you're going to have to you're going to have to you're writing bits into a register like yeah so a on the 6805 for example then sweeps jumps into address space so what that's doing is I'm searching for the serial transmit routine software the address and software because this thing the victim bit bang the output so it didn't have a hardware you are it had to jump to a software address when it wanted until I got my byte back that I sent in and now I knew I found that the serial transmit handler and software of the microcontroller so now all you have to do is make a code loop that starts wherever you want wherever the current execution is or maybe it jumps to 000 loads the data from 000 address 000 into a register jumps to the serial transmit routine which will echo that data byte out the serial port increment the address pointer and then keep going over and over again moving to the next memory location and you have to be prepared to empty the FPGAs receive you are buffer quickly and regularly because basically the entire codes and data space in this particular chip will be dumped out in an endless loop it'll just keep mirroring and wrapping over the the address space and this is kind of what's known as linear code extraction so the summary so now that you've got this whole dump of the code and data space you can try to figure out the memory map if you're still not sure of it analyze the dump for any mirroring of the address space so you know where the overall dump starts repeating because it's going to be in an endless loop so eventually it's going to be a finite bounds of where the memory map is try poking values into certain memory locations see if they change if they are you're probably dealing with RAM or maybe e-squared or flash depending but usually e-squared and flash have more complicated write routines and now you're back in familiar territory so you can disassemble that code dump you have or write a disassembler if you don't have one on hand you can search for crypto secrets or keys in that dump serial numbers seed keys whatever and you can discover any code vulnerabilities that were it was just poor craftsmanship on the creator of the code where you can just find volumes so conclusions electrical glitching can be a viable attack vector against a variety of ICs except for security hardened purpose built security ICs can be cheap to perform you don't need a big lab or expensive lab it's usually non-destructive in nature so it doesn't affect the device and it's another tool in the your arsenal when other approaches have failed so that is everything and I guess I'm not sure if we can get a couple questions or yeah I think we have some time for maybe three or four questions if you have questions please line up at the microphones down here up there there are no microphones for questions and while you pile up we hear a question from the internet signal angel thank you first question how many chips do you destroy on average until you successfully break in some devices where you only have one device you have to be very careful with how you proceed so in those ones like I said with the absolute maximum ratings of the device you do not exceed them you play it very safe other devices where it's a more general purpose microcontroller whatever you got a whole tube of them then you can throw 17 volts out of 5 volt chip or whatever you want and in some cases you'll blow up 10% of the devices like very quickly but the other sorry you'll blow up 90% of your devices very quickly but 10% of them might actually latch something advantageous and do something you want before they blow up thanks there is somebody at microphone one please ask a short question I was just wondering how reproducible the glitches are like if you find a particular offset and length once you find the offset depending on the timing drift of your own hardware that's pretty much the limitation you will be able to hit that compare instruction every single time will it nearly always do the same thing every time usually yeah like if it is a compare or a jump right after it from a conditional branch it will stop the branch from happening or cause the branch to happen with very good repeatability other than the drift in your own clocking hardware are there any more questions yes microphone number 4 please yes is it possible to glitch through a PLL almost impossible oh to glitch an actual PLL device or one that's clocked behind a PLL that I haven't actually tried I would assume it would be a good defense but I can't comment too much more I haven't actually tried specific hardware devices like that no more questions for now