Bypassing CRP on Microcontrollers by Andrew Tierney

all right guys I'm gonna stop and what I'm gonna be talking about today is bypassing code read out protection of microcontrollers and you'll find out why it's called armadillos later on you might have heard this phrase before physical access means game over it's one of those mantras that gets repeated in information security all the time the thing is with IOT and hardware the problem is that the device is already in the hands of the attacker we can just go and buy the device in lesser Bowser this is kind of changes the way that we look at things with servers with infrastructure we can't just get hold of it but with IIT we can so what we're

going to learn today we're going to learn how to get code off these devices when people don't want us to get the code of it they've got locks on them that stop us reading out the firmware we want to get access to that firmware so we can find vulnerabilities I'm not going to go into technical detail I don't want you to go away if this thinking this is a tutorial you can just go to our blog google it and find out how these attacks work I want you to get the concepts I want you to understand why it's in order and all of the vulnerabilities in this talk they're not mine one of them I kind of discovered at

the same sort of time as other people but it's kind of obvious so all of them that I'm presenting other people have found them some of them are five six seven years old some of them are only a year old but they're all vulnerabilities that other people have found we're going to cover some foundations around what is a microprocessor why do we want to do this and why is it challenging there's a important distinction to make a microcontroller which is the thing on these devices here is one package and it contains the flash the RAM and the processor all with them on physical package they've generally got a small amount of flash less than 2 Meg's so

they can't run things like Linux they can only run a real-time operating system or a very very lightweight bare metal firmware a microprocessor which is something you'll find in a phone in a computer that's where the processor the RAM and the flash are separate packages what that means is we can insert the signals between the CPU and the round we can insert the signals between the CPU and the flash that means protecting that flash memory is much much harder generally for security applications people use microcontrollers for things HSMs pin pads all those kind of devices people go for microcontrollers because you can lock them that red boundary goes around the flash and the RAM and makes

it harder to access this is what I'm talking about with an external flash read this is just an embedded device we looked at last year the blue clip you can see is clipped onto a flash memory chip it's connected through to the red box which is a logic analyzer we boot the device all of the signals as it reads the flash memory get read by the logic analyzer and we can rebuild the contents of the flash so that makes it very easy to attack them why do we want access to the flash memory well we want access to the flash memory so we contained a black box test where we've got no information about how the device

operates into a gray box or a white box test so this is just an example here TCU and telematics control unit in a car it's got all these interfaces GSM to connect out can bus Wi-Fi in USB we just look at it like a black box we don't understand how it really works and it's very difficult for us to find vulnerabilities we can propose it we can try throwing things that's it we can use a previous experience but we don't really know how it works so what we do is I'm going to change it into this grey box we want to open up that box and look inside it so we get access to the flash which allows us to get the

firmware it allows us to modify the firmware so can we put a malicious firm on the device find secret keys we can access the UART the serial port which Mark would have talked about earlier on so that gives us access to the bootloader in the OS got access to the RAM if we can access the ram secret keys decrypted data checksums all get calculated in ran and JTAG which we're going to talk about in quite a lot of depth that allows us do Fermi recovery get access to the RAM and debug access the device so if you find things like buffer overflows we can run debug on the device and actually see the registers we

can build proper exploits so you've probably come across JTAG in the past joint test action group think it's quite a misunderstood thing and in InfoSec getting JTAG access doesn't automatically mean you get access to the firmware JTAG consists of five signals TDI TDI data in data out TMS which changes the state of JTAG the clock TC and optionally Arisa when you've got access to a JTAG you get access to a thing called the JTAG controller inside the chip that gives you access then to the flash cpu ram and also something called boundary scan which allows you to toggle pins on the outside of the chip there's also a two wire variant of this called serial wire debug swd which is

very very common an ARM processors so it condenses those down into two lines it's exactly the same protocol except two lines now this is what JTAG looks like we've got top there later in later out we've got TMS for the state and then we've got the clock it's a simple synchronous serial protocol we don't really have to understand how it works we just understand it's for moving data in and out of the chip now the thing is people seem to say that you know once you've got JTAG access you've got access to the firmware and this really is a case there's only a few things though always provided JTAG so the first thing is the electrical signals we know it's

going to have four or five or two signals as I've mentioned before but that's standard and the other thing is going to have is this state machine so you can see there we've got the kind of complex flow diagram all we do is toggle TNS and we move through this state machine these are the two kind of things that JTAG always provides it doesn't really do much outside of that the rest of its non-standard but there's some things that we can nearly always say going to be their ID code that lets us read out an ID of the processor so most JTAG program is the first thing they'll do is say what's the idea of this chip

and it will spit out an ID and then we'll check that is the chip we're expecting it's got bypass where it just shifts the data from the in to the out that's for test purposes and boundary scan that control of the pins around the outside and that was generally used for testing they're almost always provided but they're not standards they don't have to be there the non-standard things are access to CPU registers that's not actually part of JTAG you've got access to the RAM and access the flash again it's not inherent in JTAG that that's there but the most important thing that's an understand that is JTAG security there is not a standard way of

locking down a tag if you say JTAG security is enabled it didn't really mean anything you can look at the data sheet for that processor what I'm going to do is go through a series of different attacks against hardware and how we get the firm so I hope everyone kind of gets the idea of why devices are locked and it means we can't get the firm off so people have done this they've looked it and they don't want us to get the firm off and we're going to work around that in a number of different ways this one's called the heart of darkness attack now this was brought out in a good few years ago the actual main part of the paper

was to about hid I class security so this is RFID and but to break the security that they needed to get keys off the little card reader door and you found a really really good bypass that allows you to get the firm off that particular chip but it turns out that that attack will work against loads of other chips so I'm going to take you through the concepts of this now the memory on the pic 18f that we're talking about here is divided up into blocks you've got a big block which holds the bootloader at the top there and then you've got the memory divided up into four separate blocks this is really really common in micro processes where

the memory is divided up like this and you'll notice it says lock code protection controlled line and it's got individual settings for each block so we can enable code protection for individual blocks we can stop it being written to we can stop it being read using these bits you can do it per block so the idea is when you turn code protection on you can lock those individual blocks what this does is it stops an attacker coming from the outside and reading that code that's what it's designed to do well it's not designed to do though so if you take this simple bit of C code here or this is doing its looping through 0 to 8000

and then it's just reading whatever is pointed to by that address so we're just reading addresses of memory really really simple that can be in the code and it can read the code so code running on the device can read code on the device regardless of if it's locked or not there are some microcontrollers that have more granular control but this is what we're looking at here now the first thing we do whenever we try to bypass code protections we pick up the datasheet we don't want to spend weeks looking for some kind of glitch attack or advanced exploit when the datasheet won't tell us how to get the market so we look here it's section 3.1 and it

what it says there it says that bulk arrays operations will also clear any code protect settings associated with the memory block arised okay so it doesn't say that it's if you raise any block it's going to clear all of the settings or erase all of the blocks so what that enables to do is it raise one block and take the lock off that individual block so we've got a lock device all five blocks a lot we can't get access to the firmware but what we can do is we can erase one of those blocks so we go to the boot up and we erase it they're like block just the notes it being blank there's no lock on it that means we can

read and write from that block without impacting the other ones so what we do that little bit of code that loop through all eight thousands addresses or hex 8,000 addresses we can put it in there in that boot block call it a dumper and it reads all of the other blocks and dump to the memory out via the serial this is a really really common exploit on these devices the problem if that is we've overwritten the boot block though so to get the whole firm or what we need to do is we need to take two devices in the second one we erase all of the blocks apart from the boot block and then we write the dumper

in the third block and that will read the boot block so we have to do it two times first time to read the the main memory second time to read the boot block in all honesty most of these devices that boot light is standard so we don't really care about this so does destroy the device it stops it working not physically destroyed but the firmware is no longer there so this is a really really really common attack a lot of different manufacturers recognize this is intact now this is from a soil abs or ember am three five nine eight chip the datasheet so what this says is that you've got to enable write protection at the same time as read

protection because if you don't disable writes someone can write a dumper into the flash memory and then read the flash memory out so read protection is really really closely linked to write protection so that's a first attack and we find this works again against a lot of different processors now the next attack is raising security fuses using UV light does anybody remember these chips yeah so cool Wow okay I've shown these before and like if people are kind of under the age of about thirty they tend not to really know these are these I mean like these used to being like BBC B micros and most if intense this is Apryl boy at prom rather so it's

erasable wrong but it's not electrically erasable so et problems what we're used to these days where you can erase it using electricity this needed UV light so the chip there has got the window over the top of it what you do is you take the chip and you put it inside a little box that had a very very bright vc lights on the top of it it would shine on it and erase the chip so this is this these used to be common they they're virtually unused now because they're expensive and awkward now there's different types of semiconductor cells used for storing memory now they don't this this is just they don't take to motionless all all of

these memories at prom a prom and flash all rely on the concept of a floating gate so that's that middle red thing there on all three of them the floating gate takes a charge and to read the memory we see if that charge is there or not to erase it with the EPROM what we do is we shine UV light on it and the charge comes off there EEPROM allows us to program the individual bits it's a bit more complex and and flash you have to erase entire pages it's quite complex but you'll notice there's something in common with those three they all look really similar despite the fact that one's electric one the two on the left

hand side their right hand side are electrically erasable so the thing is we can shine UV light at those as well to erase them so this allows us to attack close so we don't have to have access electrically to erase them what we can do with pretty much any micro processors we can decap it so that means taking the packaging off the top of it in this case it's done in a non-destructive manner so you can see those very very thin wires jumping between the dye which is the piece in the middle there and the wires going to the individual pins we can't destroy them it makes it quite a slow attack it's more awkward to preserve the

chip like that than it is just to get the dye there so we need to maintain an electrical operation where you get access to the dye then what we can do is we shine the UV light on it and they will erase it's the security bit memory that's programmed on the device it says do not allow the code to be read out if we can have raised those bits using UV light we can access the firmware but they clocked on to this so what they did was they put metal shields above those chips so this is of Bonnie's blog these things here literally metal shields over those flash bits that mean that if you shine UV

lights on the top of the chip you can't erase them it kind of works but they weren't really thinking too well so this is just the diagram we try and shine UV light on the top of it that doesn't work we take the tip chip though and tip it and shine light in at the side it still erases it now more advanced chips some of the maxims stuff has a metal shield over the top of it that has a tamper grid in it or multiple layers of metal so this doesn't work on all chips but it does work on a lot of pictures it works on stm32f4 is is quite a complex attack you've got two decap the

chip you've then got to work out where the security fuses are because you'd be showing the UV lights at the program memory decoded the firmware it will also be wiped the way bunny did it in this case was he put tape over the top of it the way other people have done is make very finely edged mask to the top of them and it's a complex attack and it destroys the chip you're not going to do this to a device in under 10 minutes in someone's house to get their Wi-Fi keys off of their reader now this is where I've got demos and we've really got a lot potential for this to go completely you're on so that's all good and you're

familiar with ARM processors so they are in pretty much every phone now there's probably some in the projectors there's probably some in the heating system they're absolutely everywhere now there's a lower grade of process it's called the cortex series generally they're not big enough to run Linux unless they're one of the bigger ones the cortex n0 definitely can't it's a very small chip it's the kind of thing that you get in alliance which is the kind of thing you get a thermostat it doesn't really have much space but the thing that we do find it is Bluetooth chip says so this is a NRF look at this this is brilliant thank you too PTP is a

great company to offer by the way and this is an RF Bluetooth chip so it's a micro processor again these are found in so many different things you know tile the little locator beacons most of those we'll have an NR f5 on a tea Turner they're really really common and but getting access to the firmware quite often helps us find vulnerabilities in these now this attack was developed by include security in 2015 I think a lot of us knew about it but we hadn't liked eloquently written it up so include definitely get the the credit with this one they write subs brilliant by the way this is a little diagram showing you the inside of the chip so we've got a JTAG

controller of the top there we've got the flash the CPU in the RAM this is an unlock device we can access the flash the registers and the RAM it's all good you turn the lock on and it stops you accessing the flash and the RAM so we can't directly read the firmware out we don't to get direct direct access to the keys but you'll notice we do still have access to the CPU the registers in the CPU and that CPU still has access to the flash and the RAM now we can't execute arbitrary code we can't load anything to round to make it run code but we can perform a trick this is where the demo

happens I'll talk you through it in nice big pictures and then we'll try and actually carry the attack out against the device so what we're going to do is use something called open OCD it's interfacing to the chip using swd as we mentioned so variant of JTAG the first thing we do is we reset the device so we've reset the device that's just like killing the power at that point you'll notice that we've got the program counter there which is the next instruction to be executed is set to 12:00 b98 so that's called the reset vector that's where the device goes to initially you've got the MSP which is the main slack point or an arm and you

can see that it's set to 2001 C 4 right so we can see these values it doesn't matter if the chips locked or unlocked we've got access to the registers in the CPU there's something that you can always take as a given with all arm cortex-m 0 processes is this memory layer address 0 is always the initial stack pointer value so at address 0 we're always going to have that 2001 C 4 a so the same flash memory in a register it will always load that the reset vector is always stored at a 0 by 4 which is 12 B 9 8 or expecting to top again we're reading that from a register pcs of register not the flash that we're

taking flash memory and we're reading it through a register it goes up and on like that but the rest of the man is predictable so what we can do with open OCD is we could type n DW 0 by 4 that means memory display word for and you can see there we've got the reset vector almost 12 B 99 so we were expecting 12 B 9 any bits going to 12 b 9 9 the reason in that last bit is one increased is for a processor that operates in the thumb mode 16-bit and 32-bit instructions the the LSB represents thumb mode so you always get this offset on quarter 10 zeros so we reboot the device and we can

look at all of the registers so we type reg in open a CD or dump all the registers so we've got our 0 through to our 12 they'll all be all FS that's the reset state of this particular processor you can see that the PC there 12 B 9 8 and you can see the MSP there mm 1 0 so that we can see they're being read from flash memory we know at this point that even though the device is locked we can still access the flash indirectly via the registers what we can also do through open OCD is we can step forwards we can move the program counter and execute one instruction at a time command for that

is step it's pretty obvious so you can see at the top there pcs 12 b 9 a we step forward and it becomes 12 b 9 a so it moves forward for every time that's the address so on this you can see before reg r3 you are showing reg r3 reset state of all FS and then we step forward and it's been modified to 1000 1014 we know that that instruction at 12 b9 8 has modified r3 so we don't have to know what the code is but we know it's modified though now if we look at turn unlock device we've moved through something called gdb the new debugger it's a it's very similar to open OCD and

what we're doing here but what it does is it also disassembles the code so if I tell it to go to 12 b9 8 and tell it to display instructions instead of memory it will disassemble them so you can see 12 b9 8 there LD which is a load register it says load into our three program counter plus 84 whatever is in that address so you can see at the end that's taking the program counter 12 b9 8 a dual 84 on to get this address and then it's loaded it into r3 we can check that address by doing memory display again so you get that 1014 there at the end so you can see

1014 there 1014 there so we've been able to infer that that was a load into our three even though we couldn't see this instruction we can see the instruction because we've unlocked it but these devices have got code protection and that code protection allows us to stop people reading the flash as we said and it's just another flash address so you set two bytes or four bytes of that to zero and it will lock it and we won't be able to access it so in that condition with this particular chip we'd lock it we reset it and we ask memory display zero zero by four and you'll see instead of getting the 12 b98 the reset vector

we get all zeros that means that slot this behavior isn't given some pictures return or left some devices return random data and in this case it's all zeros but if we go back and we think about it and we look to the next instruction at 12 b9 a the LDR R 3 R 3 comma 0 what that's saying is whatever is in R 3 go to that address and load it into R 3 can you see where the problem here is the thing is we've got control of R 3 we can set our 3 and we're loading 2 R 3 so what we do is we set R 3 to 0 by 4 step over that instruction

and R 3 will now contain the flash memory from 0 by 4 even though we've not had access to the flash memory so I'll show you that here we set the program counter to 12 b9 8 the instruction we set our 3 to before we step forward and then we look at our 3 again and look we've got the value of memory from 0 by 4 12 B 99 in this case change it so the Co protection is enabled there so there's that FF 0 0 FF that says code protection enabled we try and display it directly all zeroes program counter set are three to zero for step forward we've read flash memory this allows us to read the

flash memory from the device we can script that so we just go through start at zero go all the way to the top and we've dump the memory from the device so one thing is I will try to show you how that works so we've got my volunteer here it's connected through to one of the devices I'll just show you how simple it is so yeah this is the this is the NRF board here very very small just one chip on it there's nothing really making a couple of crystals all right stuff we've got four wires fits to the back and then we go through to this little device here which is an ST link

it's an s WD debugger they cost seven quid off eBay if you want a genuine one if you want to go on genuine and they go down to about two pounds they're not expensive so we cut back to be Bonte and I find the mouse pointer we're already connected hmm with open OCD so I can do MDW 0 and you get the 2001 C for a ND w for and I get the twelve b99 completely as expected what we can then do find the right instruction flash fill words this is writing that that value to enable code protection so I'm going to run that I'll just take a second we've now enabled code protection now something

interesting here is you have to reset the device for code protection to be enabled so if we still do MDW you'll notice it works fine we need to make sure we've reset it and then if we do n VW 4 you see we get the all zeros it's been enabled we've shown the registers but so and you can see they're all apps apart from program counter and and a stack pointer and now set r3 to be 0x4 check all three there you can see it's been set correctly well step forwards you can see how the program counter is incremented we can see that's been set to that hard-coded value from memory this instruction is not any use to us we

need to set our three again so for that we'll step again move one instruction further forwards and then look at register r3 again and now you can see we've got that 12 b9 9 so this allows us to dump the firmware it's pretty fast actually we come through to here I've script it all up they should work so this is just going through the memory reading it a single word at a time it's not exactly the fastest in the world it's quite slow it has to do a few instructions it's doing it via telnet but this allows us to dump the thermal device this isn't inherent to the arm cortex-m zero sins I mean it's quite common but it's not

forgiving right so from that we end up with a binary file so who do hexed on these sides

you'll see right at the top there the zero dress there you've got well you've got to zero it's the only neces flipped around so you again you can see the TB nine nine zero one there so it's all flipped round but you've got access to the flash room so that can it allows us to recover it let's get back to the slides

so we scripted that but you're saying how do we actually find an instruction like this if we can't read the firmware off the device so we're gonna have to do a trick I mention these things run thumb um thing about thumb is it's 16-bit instructions not 32-bit so if you want to load a direct value in a 32-bit word into a register you can't provide any instructions just not long if you can't put a 32-bit value into a 16-bit instruction so you never get direct values that are fair to do this so you see this pattern here where you do are zero and then it does program counter plus offset so we'll jump to the end of

the function and read the memory from there to load it back in this it's this any direct loading and values and it's very very common so the pattern when someone to load a particular address in memory the address will be here but we'll load that into r0 then it'll load the address of our 0 into r0 the thing is is that the default NRF bootloader that comes with these devices this is the assembly you can see there it varies from particular device but you can see it moves R 0 into R 5 it's practically a given within 10 instructions at the beginning you will find one of these vulnerable in structures so we already know to the values we reset it we can

see in the registers we get the 0 by 0 and 0 by 4 is the addresses so we know what they are so all we do is we set all of the registers to 0 we then step forwards and see how that impacts the registers so we set it to 12 B 9 a and you can see well Toby 9 C you can see R 3 is the only one that's impacted and it's the right value it's red 0 into R 3 so we think okay this is probably an instruction that works for us we then set the registers all to fall try it again and then we see the 12 b9 9 so it's just a process of trial and error

to find that it works really really well and a lot of arm cortex-m zeroes are impacted by this since Nexus has cold beach stepping again this one has been learn about for a long time it was only really given the name code be stepping last year by a couple of researchers they do or not a CRC check is or a CRC check sum slightly redundant teacher they're really common in embedded systems so alongside the firm you'll get a checksum to calculate that checksum and make sure that it's right you've got to loop through the flash image and perform a calculation on every single bite of that flash the way that's done as you can see here is you copy

data from flash into Ram to calculate those instructions so again what we've got there is the device will always copy flash into Ram when it beats this isn't a given it depends on the bootloader so different boot loaders don't do this it's not a given but it's common now look at another particular chair this is the stm32 FCO series when you apply readout level protection one what this does is it stops your accessing flash and it stops you accessing the CPU both of them are dead to us but it still lets us read the RAM of the device so if you've got access to the RAM and it's performing a checksum all we have to do so we reset the system so

we've got the device and in a unknown state we let it run for a period of time dump the RAM store that Ram let it run for more the next time I'll keep on stepping through so this is why it's called cold boot stepping one second two seconds three seconds obviously you need to bring those times down so you're only letting one cycle one at a time this can be really challenging so these devices run an eight Meg and it's already becoming quite difficult to get the resolution to read the round there and so what what we need to do first off is we need to get this timing accurate if we're going to be resetting the device

and reading the brown we could use a laptop swd over USB doing the research and everything like that but the timing is not accurate off USB is horrific Lee latent and unpredictable so what we need to do is we need to attack it with another microprocessor so that takes out the unpredictability of USB so we've got really tight control of that but even then it's still difficult if the device is running at 48 megahertz you've got to sample probably once what well 24 Meg's arm for it this is quite high so how do we work around that well we provide the clock to the device and this won't work with everything and a lot of devices when they boot will only

allow clock frequencies and they work off an internal oscillator or that only allow frequencies over a given range but on a lot of processors including these little boards here it's got a pin that allows you two o'clock you can literally make it a toggle search if you want it so you can run instructions when you want so you can slow it right down and then we can dump the RAM every time we've done a cycle and then we can see the contents so it's a really easy way if you see our season table the other thing is of course if the secret Keys stored in the RAM or anything like that you can access it now this one this is the demo

that's really probably going to go completely wrong again this this attack isn't me so this one that the paper is from is called shedding too much light on a microcontrollers firmware protection now you can guess which attack this is describing partly the one with UVC light so did this attack that one of the attacks in the paper is the UVC fuse reset against the SDM threads to have zero and but the actual interesting stuff in this paper isn't that in my opinion we've known about this problem for years with UVC this does cold boot stepping is the first attack UVC and then this race condition which I think it's the best one again you'll see

this diagram this is a slightly different situation so we locked jtag and it allows access to the CPU but the CPU doesn't allow access to the flash and RAM in this case so it's not like the time with the with the NRF five on 82 we can't access the flash amount that exploits not there you remember at the start I said that JTAG control is not standard what that doesn't how it behaves isn't part of the specification we don't know how that works and it can have bugs in it and people don't realize that let's say this is just a brilliant attack on the left hand side here we're looking at s WD how the device is being

debugged on the right hand side we're looking at the device actually booting and reading memory itself now the key thing here is the way that the device locks the flash is the first time anything tries reading the flash memory it prevents access via J target after that point so if the device reads the flash using its own code it will lock access to the flash over J attack if you try and read lash it will lock access so we've got this situation we start up swd the first thing it does and you've got to do this as it reads the ID code then it starts faffing about open OCD the spec does all these different things

is around does a bit more messing about at which point the device is booted and it starts reading the flash or it started up and starts reading the code so complete that triggers the lock of the flash so from this point onwards we can't read the flash so if at that point we try and read the flash we don't get access to it you see where this is going the thing is those messing around bits they might be in the datasheet they might be implemented by the software but we don't have to do them so we just moved the flash reader by shortening that series and we've read it so it will get locked that read will lock it but

we've read one single word of memory so we reset the system we initialize debug we set the address for reading we read the flash and as long as we're quicker than the device reading the flash will win and we'll get one byte of data back from it keep on leaping around that and this sounds ridiculous it sounds like it's not going to work but guess what it does so to talk to view the setup it's exactly the same as before the attacking system needs to be have tight control of time for it to work this is directly taken from the guys who developed it they've got two boards you've got the board under attack here and you've got

the firmer extractor board here so what it's doing is you've got these two pins here doing swd interface but we've also got control of the power so we're providing 3.3 volts to it there and we're also providing the resets it so this board can power up and reset this board it can also send swd it's all controlled via laptop so as a serial port they're going through there's a little climb that allows us to stop the firmer the brilliant thing about this attack is these boards cost 7 pounds so you can go and order them from Farnell or whoever 7 quid and the firmware that you can get is just available to download it's even pre-compile so you

can load it onto it and see it working it's a bit finicky at time to put it it does work and I'm going to demo and this is where it really got potential to go wrong so this is my setup you can see it's and it's perhaps not quite as neat as the setup they've got so here we've got the attacking board this is one there connected by USB through to my laptop and we've got the ball under attack here it's just replicating what they've done yeah it's on - - by the way what's going on there let me just shut this then the presenter camera seems to sometimes take a little bit too much okay so it's just

a client they've they've done this all for us it's an absolutely brilliant attack for learning I'm not doing piping this the last ice broke is it metal piping script the connects through to it we tell it it's dress the goatee let's see if this works the firm is really good as well because what it does is it's got secret strings and it's got a string and RAM and a strand flash so we can see when the attack works so there you go you can see this is the rate it's reading out real time this is some secret data which is stored in the flash memory together with the Firma if you can read this your attack works

correctly so that's us read firmware off a code protective device for this race condition on swd you can see down the bottom here it says attempt 6a so it's done it's tried 680 times to read that you can see success 34 failure 36 it really is a race condition we're right on the boundary of that being successful there's a lot more work to do if we speed up the clock can we get more data out of it one of the absolutely brilliant things as an attacker is I don't have to make things work particularly well if this thing is only rated to go up to 8 megahertz and there's a race condition that's just exploitable if I run it up to 12 meg and

it still lets me exploit the race condition but crashes every fifth time I don't care I'm an attacker I don't want it to be reliable I need to get access to that code Wow two demos that work this is unprecedented so yeah that's that attack the last one I'm going to talk about I'm not going to go into huge that there's anyone heard of glitching there's an attack against processors now this is the one that's kind of unpredictable and takes a long time to develop we talked about these STM's they've got different code readout levels so some of them allow you to still read certain things still program the flash so in STM's got two levels level one you can

still program the flash level two that's it game over no access to the device it's the same as some of the year and XP processes which is what this is from you've got three levels CRP level one two and three and you have to program these funds its flash they're quite specific values but what you'll notice is that there's every other option apart from those for the 32-bit word meaning there's no code readout protection on the device so if we can cause an error that changes any bit in that word then we've we've managed to bypass code reader protection interestingly this isn't exploitable on everything the the NRF board here and the en 3599 chip here

for it to be disabled it has to be a 5 5 a if it's any other value then code readout protections enabled so glitches to memory reads generally won't allow you to get access so that's one of the ways that glitching allows us to cause problems just to quickly explain glitching sometimes it really is this simple a normal clock is just a very regular pulse so we'll load instructions will execute the previous instructions loaded and step through like that if we just send the clock pulse that doesn't match up with what is expecting a bit too quickly it can cause instructions to be skipped entirely and why is that important well how would you check to see if a value is equal to a 5

5 a you'd compare the value you've read from flash to the hard-coded value of a 5 5 n and I've missed the slide oh well essentially it's quite common for this interested it literally to be compared to value if we can cause its skip over that instruction exactly the right time the bootloader will skip over the code protection and we've got access to the device sometimes these attacks can be trivial it can literally be you jabbing the power pin whilst it's booted and it with a resistor to drop the voltage of it and it will cause a glitch other times you need to spend a lot of time on it they're not very reliable which is

why I'm not today so why is it need to be secret and this is kind of the concept stuff that I think it's important to go like a higher level then these attacks are great you can go away and learn them they're all blogged it's it's nice and easy to replicate I don't know if you've heard of this same Kirchhoff's principle a crypto system should be secure even if everything about the system except the key is public knowledge it's a really common principle so the idea is that your algorithm if that was in the public it still should be secure but you can abstract that a bit further and if we say if your firm weighs in the public

talk from the key material it stood still should be secure now I get a bee in my bonnet about this sort of I get be in my body about a lot of security through obscurity is the reliance on the secrecy of the design or implementations the main method of providing security of the system I think that's a good definition because Daniel Meister said security by obscurity is part but security with obscurity isn't so if you've got a firmware that's completely secure and you stop someone being able to read it from your device you're in a better position if people can't see your firmware they can't find the vulnerabilities now I realize this is not positioned that everybody agrees

with an interesting saying here you don't have to run faster than the bear to get away you just have to run faster than guy next year I think this is so so key with IT the majority of blog posts and disclosures about IOT are low-hanging fruit there's someone connects into the serial port on a device there's someone dumping the firmware there's someone just using burp suite to fuzz the web interface it's not difficult to find stuff all we have to do is make it that little bit harder and people will move on but then there's no advantage without swimming your fellow surfaces the Sharks specifically wants to a year it's a certain market where people are going to want to target your

device and can you predict that probably not yeah this one and many eyes make all bugs shallow and I don't know does anybody agree with this do we have any open source sellers in the audience are you gonna beat me if I say bad things about lineThe and shellshock proves open sources many eyes can't see straight in the last few years had bug after bug that's existed for five plus years in code OpenSSL heartbleed had been there for a long time spectrum meltdown have been there for a long time and when you see those bugs you think how did I not notice that how good especially with Hartley how did someone not see that bug so the thing is

even if your firmware is in the open even if you open source it are people going to find problems so why would you want to protect firmware even if you weren't subscribing to there's many eyes make all bugs shallow and all this kind of stuff well intellectual property is one of the reasons and driver assistance and self-driving cars you can't place the decision logic on a server for that it's got to be in the car to allow real-time decisions to be made so if you look at a box on most cars they've got quite advanced algorithms to detect things happening those car those people want to protect the intellectual property contained within this is one reason

symmetric device white keys now in an ideal world we wouldn't have a key on a device that's the same for every single device it's clearly a battle within it and but this is from the bootloader for the 3 p.m. 3 5 9 8 here the default bootloader they provide code for has got a symmetric AES key on all devices so if you produce a device and you want to secure your firmware the secrecy of the key on this device is key if someone gets it they can then produce malicious firmware for your device that's another reason code read a protections important we've got per device secrets now the reason I mentioned this on the left hand

side here we've got the void phone now this was a specific job for a customer he works in national infrastructure and they said to us we want you to get their 802 1 X certificates for our network now it was pretty open scope we could do what we wanted so we could steal someone's laptop we know that they've got full disk encryption we know the security then the builds quite good so that probably wasn't going to work the other thing is stealing a laptop is generally someone's going to get annoyed and call the police it will be a theft that someone cares about how many of you got VoIP phones on your desk how many of

you if you came in one morning to find it would be happy you can steal a VoIP phone and no one will care now in this particular example that Polycom phone there external flash it wasn't microcontroller but we recovered the 802 1x certificate of it and yes in this particular situation it was the same one that used on the rest of their network and that was us onto their network the other one this Cisco arrow net 600 it's a home worker router the idea is you plug it into your home router it sets up a wireless access point it VPNs into your work and creates an enterprise-grade wireless network in your house but it's got VPN keys if I can go into your house

and I can get keys off that device in under five minutes without leaving any evidence you have a problem so you've got to understand there's different layers of protection there so this is where this comes armadillos does anybody remember this advert yes so crunchy on the outside soft on the inside that's what a lot of these devices are like vendors have hardened the code read a protection so we can't get access to the firmware but once we're in its absolutely ruin there's vulnerabilities at now when I was last yesterday I was looking for his arm delay feature and this is completely pointless but when I typed into Google can you eat an armadillo armadillo is

bulletproof and can you get leprosy by touching an arm and then someone thought oh oh I'm should I eat and raccoon straight after they did that idea anyway that's just as an aside so yeah we've got this big summary table now and so what I've done is I've given the different attacks here hearted darkness where we overwrite an individual block of memory UVC fuse reset the arm cortex-m zero cold boot stepping race condition glitch now the thing is is you'll notice the devices it impacts first off these attacks impact many devices it's really hard to work out which devices they impact the swd race condition is so specific this is stm32 m0 it doesn't work on this

one that however it doesn't work on sirs very very specific family it might even be fixed on later generations so you can't work out which devices are impacted so the classic bug most of these are actually caused by the silicon vendor they're out of your control their design oversights so say for example hearts of darkness the picked the pick datasheet doesn't mention you might be able to read the code out of hire this means the NRF want they haven't published an errata to say that you can do this I'll be stepping as well the only one there that I'd really say is in your control is UVC fuse reset if you buy a device that

doesn't protect against that that's your fault you can buy devices that protect against it and it will date shoot in terms of the attack you'll notice a lot of these do not damage the device some of these I can get done in seconds literally seconds against the device so we've got we've gone into the region of evil mate you know someone walking into your hotel room and the tacky and device to get keys the if we look at the esp8266 which I guess a lot of you have heard of it's a little Wi-Fi chipset it's not ten celica processor in it that's got it's got no protection on the flash memory whatsoever so it's external flash we can

read it it's got a serial bootloader that allows us to read the flash and we've done this we can do it in under a minute unplug the module from the back of your consumer device read your Wi-Fi key plug it back in and we've got your Wi-Fi key it's that a problem I don't know that's not for me to decide the mitigation you'll notice that some of these need you to change to a different device some of them can't be changed by settings or configuration some of them can this is probably the most heartwarming aspect of this and are you impacted well the problem is most of these need you to take your device and test it the only

one there that you can really read a datasheet and say is this going to impact me it's hard to darkness so that's interesting again it's outside of your control now this is an excerpt from a microchip datasheet in fact for the the one that heart of darkness impacted I just want to go through just some of the words used here just to kind of think about the attitude that silicon vendors have got towards this microchip believes that it's family of products is one of the most secure families of its kind on the markets day when used in the intended manner and under normal conditions yeah now I don't know about you but it's kind of our job to not do things in the

intended manner that's that's what hacking is it's finding those edge cases they may say there are dishonest and possibly illegal methods used to breach the code protection feature god this really annoys me when people frame things as illegal like it again if I'm doing if I'm if I wants to steal your intellectual property I'm gonna steal your intellectual property the this isn't going to stop them these methods require using the microchip products in a manner outside the operating specifications no but then they kind of bring it back a bit it says neither microchip nor any other semiconductor manufacturer can guarantee the security of their code this is important you can't guarantee the security of the code on these devices

it's a layer of security but it cannot be the only thing you do so what can you do if you're a collaborative security consultant and what I mean by that is someone like me who works with vendors to make their products better you need to teach your customers that no matter how secure they think the device is an attacker was enough time money and skill can probably get the firmware off that device but remember it's still a useful layer of obfuscation if their firm has got no problems and you can't read it then people are going to struggle to work out how it works but it also means to push towards white box testing now if you test IOT it's

still very very difficult to get a manufacturer to give you the source code they'll want you to get the firmware off the device they want me to disassemble it Deakin climate and reverse engineer now if I can get the firmware off an ARM chip I can sit there and spend weeks and weeks looking for vulnerabilities in Eider but it'd be much easier if they just gave me the firmware so they need to accept that teach them that if you're an offensive security researcher and by that I mean you're rather than just say rude words you know your your your buying quality of finding vulnerabilities learn these techniques and carry them out against devices they're very generic we see them work

time and time again be prepared for failure you will buy devices and you'll find no bypass and then a week later someone will release a paper in your girl that's really obvious and feel really stupid and you buy development boards instead of real devices the reason I at this em3 $5.99 board here is those chips are used in pretty much every smart meter in the UK now I could get that smart meter doesn't have a JTAG header on it so then I'd have to solder and tack wires over to it if I brick it I can't work out how to recover it if I brick this I just plug in you module into it it's cheap and easy so in terms

of makings people actually make things and I don't know if there's any or many of you here so you've got to realize that people going to cover the firmware but you don't know how hard or easy that will be so just accept it will happen but remember there's other ways to get the firmware we recently had an interesting situation where someone really really wouldn't give us the firmware for a white box test because they said there's no way you'll get out of this chip we couldn't get it off the chip it would have taken us months maybe to see if we could but that doesn't stop one of their developers uploading it all to get up by mistake

it doesn't stop someone hacking into them and dumping the phone you know there other ways the firmer can be gotten so relying on firmer secrecy it's not a good way of doing those so just assume your firmware is public and by that I mean don't put comments saying to do add security in your firmware I Baker Chavez principle as well assume that the keys the only secret thing about your system semiconductor vendors just accept that silicon does have bugs the race condition there is a bug in the JTAG controller except you'll make mistakes so I don't think microchip considered the heart of darkness attack it was a new attack when it was released and no

one had thought of that so just you will make mistakes be honest it's nice that mic ships saying that we can't guarantee security on the flipside they do overstate the security it provides and publish your after when issues are fixed none of the exploits here are detailed in data sheets or application notes for any of these vendors so you can't just go and download a date sheet and say yes there's a way of circumventing this and just to finish I really like this this saying if we got our toothbrushes and diamonds of equal zeal we'll all these fewer toothbrushes and more diamonds this was a guy is predates information security by a long stretch but what I'm

saying by that is if you've got a tile Bluetooth beacon does it really matter that gets hats do you want to spend an extra $2 per chip making that secure whereas if you've got a home home worker router do you want to protect those VPN keys to a better extent or do you want to take other mitigating steps to to prevent that from happening so we've got to make sure that we apply appropriate levels of protection as these devices and that's the end and I've got three of these stm32 things and they conveniently solder onto the badge here and you can do cool things with the unspecified yet but yeah if anyone's got any questions I've given away if no one

asked any questions I don't know how I'm gonna see he gets that much throwing so has anyone got any questions okay sorry God always finding a way out okay sorry yes yeah so yeah yeah just to repeat that for the video so what you're asking is like how to make tumors aware that these vulnerabilities your devices yeah I think you can kind of abstract that away from code readout protection just think about vulnerabilities . i don't have any of it with me but I bought a samsung camera and four years ago and it had a series of vulnerabilities that allowed it to be rooted local attack but you know it still still not great I mean I broke it

I went and bought another one three years on the vulnerabilities were all still there we blogged about them we disclosed them but there was no way for a consumer to know you there was Amazon reviews they weren't great but none of them said this is a terrifically insecure product I don't know what the solution is it's an awkward one vendors don't care at the moment the problem with open sourcing things is that at the moment there's just such a it's the commercial law not to leak how you do things I find it really odd I mean we we looked at a product last year that all it did was connect to a web server download a bit of Jason and then turn a

light on based on that Jason and the person looking at that was concerned about intellectual property theft okay okay that's not your threat here is it really I don't know the solution sorry so I think probably the most important thing is to make sure that you look if you're talking specifically about code readout is to protect against code reader is if you lock the device down to the maximum extent now I mentioned the stm32f4 the way it's got these different code readout levels so what we found is that developers won't enable or disable JTAG entirely they want to leave some semblance of access there you speak to them they say it's for like city you

know if they get returns working out why they're broken but then you visit them a year later and they've got a big cardboard box for the broken devices and no one's connects JTAG to see what went wrong with it you need to think I'll be actually going to use that JTAG functionality once it leaves the factory the problem is that it's very difficult for you to work out are these chips vulnerable or not it's very difficult for us to look at their volume a lot I think if you're making things that the key takeaways you've got to make sure your device is secure even if code readout protections broken yeah exactly

yeah I mean the the thing is that I mean some vendors don't actually have a way of disabling JTAG entirely you know this they do have levels of protection but you can never stop register access on some of them whereas other ones just make it trivial this is it's a register setting that's it JTAG will never work again the other thing I've seen is that manufacturers scared of locking themselves out devices and I mean yacon discus that he to occasions now I've seen people lock themselves out of remote devices you know they've it something's gone wrong that's meant that they cannot update the firm on devices in one of those situations the reason that they

put those protections in place was because of specific advice I'd given them to put that protection in place I didn't say put that protection in place and then lose the private key but that's what happened so that was before I work for PTP anyway yeah I hope that helps yeah um so in terms yes so if you're so you just for the camera again you're asking how does this impact SCADA ICS and ot and first thing I'd say generally I find the SCADA is significantly behind in terms of security anyway not in this slide that but we just say you know hacking Windows you need to know Rock buffer overflows all these things hacking ICS all you need to do is read

the manual but you know that that's typically how it rolls and the thing is is that I don't actually like the term IIT just that we have to say it because otherwise people don't listen to you I think that the same thing a device that's internet connected is maybe not the best term it's an IP connected device it can be on a private network and they suffer from the same issues and you've got bigger challenges with this card I mean if you call up Siemens and ask them for the firmware on a device they're not going to give it to you they won't even let you download it unless you've got a commercial arrangement with

it and I think ICS has got a lot further to come than IOT to be honest so kind of answer

yeah I think I mean on the whole if you if you rip open a PLC it would be using a process of this based on technology from probably 20 years ago they generally tend to be a bit more dated it's been verified as working so quite often they've got a layer of obscurity and because no one's looked at those processes because the only thing their inner switches that cost 10 times as much is domestic ethanol so it's just a layer of lower obscurity that may or may not help I'm over running so I think I need to move so the next talk can start thank you guys [Applause]