BSides Berlin 2023: Jailbreaking an Electric Vehicle in 2023 - Hotwire Tesla's x86-Based Seat Heater

in Germany the Germans are very very proud of their car country Germans are very proud of their car manufacturers beat Mercedes BMW or since some time now Tesla as well um I think or I am assuming strongly that our next three speakers are also very proud but not because of owning a Tesla actually I think it's because of what they did to their Tesla and they will tell us all about it so please welcome Christian Nicholas and Hans

Nicholas hi Welcome to our talk jailbreaking an electric vehicle in 201 23 and in this talk the three of us will share with you how we bypassed AMD secure boot how we activated some soft locked features on a Tesla and how we extracted Hardware bound authentication keys from Teslas this story began around one year ago when um ol approached us o owned the Tesla actually and was interested how its digital systems worked in detail but ever since Tesla switched to AMD based CPUs in their infotainment systems he wasn't able to be the king of his car anymore so he contacted us because we in the past um we work for the TU Berlin worked a lot

with AMD and especially the security of AMD processors so why would you jailbreak a car in the first place like Al you might just be curious um how the system works you might be interested in replacing the software entirely or you want to change the system in a way that you for example activate some soft locked features because the Tesla is not a mere electric vehicle anymore they sell you stuff after you've purchased the car for example rear seat heaters they are included in the car but if you want to use them you have to throw in another 300 bucks so in this talk um we will first analyze the boot and the firmware security um of the infotainment system

in the second part we will get into some electrical engineering and Nicholas is going to talk uh about our glitch attack on the infotainment system and in the third part Hans Nicholas will guide you through some crypto um how we extracted um car unique secrets from the car so if you go on eBay and have 400 bucks SP you can get one of these models three car computers it's normally located behind the glove box and if you open the top cap you will see the infotainment on connectivity ECU to give you a more complete picture this is the board that we will focus on there's some cooling chassi it's water cooled through the main water cooling

system there's some space for GPU daa board for the premium cars then there's a very interesting chip that we might want to talk about again this year it's the autopilot that's responsible for for all the um driver um driving assistant uh systems and if we go back to the IC and flip it we will see the third important chip and that's the Gateway the Gateway is um kind of the the um interface from the brains of the car like the chips you see here to the rest of the car and it acts as a hardware Fireball between the canbas um to the ethernet to the infotainment and autopilot and so on it's like in many

other car brands as well it's an nxp MPC microcontroller it's power PC based um free out based operating system and so on but most importantly it stores the car configuration and the car configuration um is the single point of Truth what your car is able to do in terms of performance terms of battery capacity yes there are Teslas which uh don't use their full battery capacity because you've you've not paid for it and the level of autopilot probably the most expensive feature you can unlock through um Tesla's app and one of them is also the rear C teachers which we were after in this research however there's another CPU that we feel much more competent for and

that's the infotainment Apu it runs a Zen one CPU um it's running a custom Linux um firmware and Recovery are on the SP I flash and the rest is on an nvme this one was previously based on Intel and even earlier on Nvidia so we're not the first ones to um to hack Teslas there was a lot of work in the past um just to show you a few and they all had in common that their threat model was that they are an outsider and they want to have um like they are either completely remote or in physical proximity and want to either open the car control the car um and so on and they all found

software based vulnerabilities um that were all fixed by Tesla over the air now our threat model is we or o owns a car owns a Tesla and we have digital and physical access to the car whatever that means in detail I show you in a bit so we want to tweak the car Beyond its normal flows to activate some Fe features and this also might help to lift some repair and regulation restrictions so we're not based to software based attacks so let's look at Hardware based attacks on this talk if you power the system on and hook up to the uart you will see how the system boots and get a better picture the x86

seemingly comes up with some core boot messages the open source um x86 form implementation and um you will see a few stages um running and at some point the core boot will load and verify What's called the Tesla OS loader the Tesla OS loader itself will run load a Linux kernel from the nvme and verify this kernel before it actually executes it and in the last step the Linux kernel will get the root file system also from the mvme and verify it uh how it does it in in particular I will show you in a bit so we have a chain of trust during boot each stage checks the next one before it executes them and if a single bit is

flipped the cryptographic signatures are invalid and the system will just not boot so how how do we get a foot in here we want a root shell how can you do that well we could either spawn a Serial shell on boot over uart we could add an SSH key to the authoriz Keys file or we add a known SSH password to an account this all requires changes to the just mentioned root file system so any change of that will break the last step of that um chain of trust so the Linux kernel will verify the root file system and see that there's an issue with that how does it actually verify the root file system

similarly to um think Android devices uses a device mapper Target called Varity Varity um every time a block is read into memory it's also hashed in parallel and then these hashes will um then along alongside these hashes you will have some intermediate hashes so you take two hashes hash them again and um you will form a Merkel tree so the whole file system and its specific State up to the last bit is represented by this root hash and this is exactly what the test low s loader checks for so we just did a um very basic patch of the Linux kernel and instead of using Verity as you can see in the bottom left we use the DM

linear Target which doesn't do anything and also we don't restart on Corruptions but we ignore Corruptions that was a seemingly simple patch but okay you've probably understood the chain of trust is now broken at a different place the Linux kernel is now um not uh will not be verified by the Tesla S loader anymore uh because the signature is broken there's several ways to fix this we again went the easiest way and looked at the Tesla or S loader in our favorite um disassembler and at some point you it will check whether um the ndme image was um verified successfully or not we'll exactly patch this conditional jump to an unconditional jump but then it always

verify so you can imagine the Tesla S loer is now the one that's not being verified anymore by the core boot we did a very similar strategy there corbut uses a library called vboot that was officially introduced by Google for the Chrome books boot security and we patched that one and now the system didn't boot uh anymore at all so why is that because of the AMD CQ processor you might have heard of it it's a dedicated rv7 microcontroller in each AMD CPU it actually comes up before the x86 CPU um does come up and it's highly privileged it has a variety of responsibilities the one that's relevant right now is it the hardware root of trust what is the root

of trust a thing that has to be trustworthy for anything else on your computer to be trustworthy and it will verify core boot's Integrity so we patched that we patched that in the offer bootload of the PSP and that didn't work because there's another boot loader inside the PSP that you can't change that will check the off bootloaders Integrity so if we focus now on the amdp there have been some vulnerabilities that would help us here in 2019 there was an offure bootloader buffer overflow that would would allow us arbitrary Cod execution therefore we could skip that check but that was fixed via firmware updates and we didn't even find a faulty image for Tesla um that

would contain this one in 2020 even juia there was a r load of vulnerability that yeah wouldn't be able to be P to be uh patched by um AMD without issuing new hardware and this one was seemingly usable for us because they only fixed it from Zen two on and the Tesla has a Zen one CPU but apparently Tesla gets special treatment from AMD here and this fix was backported to the Zen one CPU so if we step back back and compare Tesla's security from around 10 years ago to now they've stepped up their game a lot back then they had open X servers you basically were rude when you plugged in Ethernet and there was no code

signing now they have code signing firmware signing they have a chain of trust during boot whoops and um their root of trust is in the AMD sock so with this situation we had to get another weapon from our Arsenal and for that I'm going to hand you over to

Nicholas okay so I'll talk about um how we hotwired the infotainment system and for this we will first have a look at how the regular early boot verification looks like um so first there um ASP loads the AMD root key from SPI Flash and computes the hash of the this root key afterwards it uh Compares this hash to a hash that is stored in readon memory and if this is successful um the ASP loads and verifies the off chip boot loader using this root key uh what's interesting here is that Tesla has a custom root key so as an attacker we would now like to be able to replace this root key and in this case the key verification would

just fail and this uh also stops the boot process completely so but let's think about what happens if we could do something about this here okay so for this we will talk about fault injection attacks um fault injection is a method where an attacker induces fals by by altering the ic's environment and for this we could hit an IC with a laser or with the EM radiation for example but we could also try to modify the clock signal or the supply voltage um in the case of uh voltage glitching the supply voltage is lowered for a short amount of time um just as you can see on the picture below so let's consider a password check

where the user types in a wrong password um normally that check would just fail but if we inject theault into the processor um it may ignore the comparison um yeah so the comparison is ignored and the password will be just printed as correct but in most cases um we will just introduce other errors um for example system locks or system resets um that means that most fults are just useless for us and that's why we have to adjust the glitch which brings us to the three main challenges

here so first we need to figure out uh when the targeted check happens to be able to precisely trigger the glitch attack um secondly we have to find um the correct voltage drop parameters for example the steepness or the width of the voltage drop and finally um it is necessary or we need to way to identify failed attacks and retry as fast as possible okay so that's from where we are coming The Arc is replaced by our own key but its verification is going to fail so our plan now is uh to glitch the root key verification so that our custom root key is accepted um this allows us also to resign the modified ofip boot loader

which uh then will get successfully verified too and to make this happen we first need to find out when the verification takes place during boot

okay so here you can see an SPI trace of The Regular Boot uh with the original root key um the only thing we can tell about this is that the root key is loaded right here but we don't know when it gets verified so now we flipped a in the root key and captured another SPI Trace um you can see it here and with this modified um root key the SPI activity stops completely after just loading the key and that means that the root key verification must be taking place during this uh red dotted time window here so afterwards um the off put letter is loaded and verified just as explained before okay so so now we know um when we

have to trigger the glitch but we don't know how to inject the actual voltage drop and for this we will have a look at how um the AMD so is powered so there is an external voltage regulator that is connected uh via its SBI Tu bus to the sock itself and it um allows this sock to control and monitor its own voltage um there are two voltage domains namely V and VOR um vok is used to power the AMG secure processor and that case so yeah we would like to inject our voltage drop into the vsock voltage domain uh to glitch the AMD CQ processor so um our glitch setup looks like this we have a Teensy

microcontroller that is responsible for the glitch and this is uh connected to the svi TU bus so that we are able to inject arbitrary packets into that bus um it is also connected to the ATX reset line so that we are able to um to reset the Target and of course it also monitors the SPI chip select lines so that the Tey knows when it has to trigger the glitch attack and additionally we use an external PC to control the whole setup and to adjust the glitch parameters okay so this is how our wiring looks like we have we connected two wires to the sv2 bus for data and for clock and an additional wire to the

SPI chip select uh chip select line yeah to monitor the the SPI activity okay so yeah our glitch setup looks a little more Messier in real reality um yeah with all the caes and the board in the middle it's yeah it's kind of messy so um here you can see the svi two bus connection um then there is the tez mic microcontroller um and we connected some more wires to the SPI bus um so that we are able to debug the whole boot process and debug our glitch attack um yeah what's interesting is that uh Tesla uses an HDMI connector for for debugging purposes and we were able to connect the ATX reset line an additional

SPI programmer and um the serial output just through the connector so this um this additional SPI programmer is used to um read and write to the flashship directly um when the board is powered off for example okay so let's go through the actual voltage glitching steps um here you can see a logic analyzer trace of the whole glitch setup um from top to bottom the signals are um sv2 busz uh clock then there's the to data line the targets voltage um we sock and there are two traces of the SPI chip select signal one of a failed attempt and one of a successful attempt so on the first step the initial voltage is set um you can see the svi 2

package uh which is sent by the CPU and this one tells the voltage regulator to rise V so uh we use this first packet also to detect that the target begins booting um which triggers the tech logic that runs on the Teensy microcontroller um after the initial voltage is reached um the voltage regulator sends Telemetry packets and we sock becomes stable but um as we would like to be able to inject sv2 packets at any time without a packet Collision we will use the Teeny to disable the Telemetry functionality um by injecting another sv2 command just as you can see on this picture and um also the sock is adjusted another time here so in this step the AMD secq

processor awakens and starts loading data from the SPI flashh and that's why we see um activity on the SPI chip select line here um the Teensy will count all the chip select edges until it is time to actually glitch the target which is right now so for um at first the Tey injects a packet to make the voltage drop and then another package to a packet to make the voltage rise again and to find out if the glitcher ter was successful or not um the tnz monitors the chip selector and if it becomes active again we know that more data is loaded which also indicates that the attempt uh was successful and on a failed attempt um no more data is loaded

and the chip select line stays inactive and the tnz resets the target so that we can um make another attempt okay a short recap um we should now be able to circumvent this check and we should also be able to patch all boot stages using our custom key and the glitch and um for the following demo we have put our SSH password into the root file system and we have connected the infotainment system to a PC via its ethernet connection okay this is our lab um as you can see we don't have the the real car but at least we have the Monitor and the infotainment board and in this video you can see that we haven't bought the

optional rear SE heers of course and yeah so we are not allowed to activate them okay um this is a snippet from the car configuration and the rear C just have the id13 and we would now like to set this value to one but for this we first need to get a root shell um in this video we will demonstrate the glitching attack on the right side you can see the glitch script that runs as many glitch attempts as POS as fast as possible um on the top left side there is the serial console where we will see the boot lock of the infotainment board and on the bottom left left side there's an SSH console where we will log in as

root okay so now we will start the glitch script and you can see there are many attempts rushing through this one was successful and now we should be able to see the boot lock there it goes and after a while ethernet is up and SSH is up and we can lock in so yeah we should now be root on that system we will use the Gateway diagnosis command to get the value of id13 we will set this value to one and see if that worked and that worked but yeah let's see if we are now able to um activate the rear CT does so back in our lab and after reboot we should now be able to to activate them let's

see if that's possible now [Applause] okay so that worked um but yeah let's talk about persistence well um the car configuration survives normal infotainment reboots um but our voltage glitching is of course not persistent but also the infotainment doesn't reboot very often and additionally the glitching attack could be made way more convenient using a custom modchip or a PCB for example but this is more like an implementation detail which is maybe up to someone of you let's see if someone will build such a device okay so so our demo was possible because the rear seat Heats um have been an insecure configuration item that was not checked by the Gateway uh with infotainment version 20224 um the item was upgr to be a secet

one uh just like for example the full self driving feature um being root on the infotainment is therefore not sufficient anymore and we would need another vulnerability um in the Gateway firmware um to carry out the same attack um again yeah and such Gateway vulnerabilities uh were presented by Z active at last Pontoon and yeah it allowed to run unsigned firmware which which would uh what would also allow our attack again okay so we got a little bit more for you um let's see what other secrets we were able to [Applause] extract yeah thank you Nicholas uh so here's also Nicholas and I'm going to talk about extracting secrets from the Tesla so we're rude we should en should

be able to just you know copy off whatever we want but what is there even so in the first place we have the so-called car credentials which are just basically an isometric RSA key pair used to authenticate the car against Tesla servers for example in order to download new firmware for the car which Tesla doesn't usually you know provide uh to anybody so you actually need to be a car to get it and then furthermore there is user data on uh these Teslas a lot of you know locks from your connected phones or Wi-Fi um as well as actually you know tokens for session or for accounts that you've logged into like your Gmail for

example and what about security well it used to be that everything was basically in clear text there uh which yeah cost some bad press test test ah there we go so uh which caused some bad press for Tesla here you can see that yeah if you buy with your 400 uh such a car computer from eBay you can just extract data about the person whose card was and yeah so that's why Tesla has changed it and now um they actually secured this using atpm atpm is a trusted platform module it's a small cryptographic module that can hold and uh yeah make available cryptographic material like for example the car credentials or the dis encryption key for the user data

partition of the system um how's does is helping well the the TPM will for example only allow you to use the uh car credentials if you actually um U yeah it will allow you to use them if you are right running on the system but you can't copy them off of the system so uh actually whenever you want to use them you actually need to be on the car um and for the user data uh partition this encryption key it's the same you can't just like previously desolder a chip mounted somewhere else uh the nvme chip and access the data there um but as it turns out Tesla uses amd's firmware TPM implementation and uh

yeah we've just actually written a paper about hacking this uh firmware TPM so um yeah we should be able to still get access to this data and um previously we um yeah we were able to unseal some dis encryption keys but actually for our Tesla work we had to adment our previous work to actually allow unsealing arbitrary TPM objects uh which I will talk about now and yeah so spoiler alert we've used that to uh extract the car credentials from our Tesla board and also re enabling uh accessing the user data off of the uh yeah Tesla boards so in the boot process um how does this look well uh so here's a simplified version of the boot and you

see the AMD secure processor boots boots the operating system from the nvme and now we have additionally this user data petition on the nvme which is encrypted and uh we also have some more firmware running on the secure processor while the operating system is running and one of the applications that's running on there is the firmware TPM application and uh the operating system can now talk to this firmware applic U firmware TPM application request the key for the dis encryption and then use this key to unlock the user data partition um so um yeah you see okay we're rude right so we should just be able to take the key from this F TPM application and lock our dis and so on

but that's actually not the case um so um yeah to yeah let's zoom in a little bit further to understand why so first of all um this firmware TPM application has some in state right so we have some called nonvolatile data which just is the internal state of the ftpm application but that's really small and TPMS don't store all of their data in there but what they do is um for data that you might want to access they seal it using some cryptographic you know encryption seats and then um give you that data back to store yourself so actually the dis encryption key for example is stored in the dis encryption header as a sealed TPM object and then

the operating system will load the sealed TPM object uh provide it to the ftpm application to unseal and uh which it will happily do and give back to the operating system and now the operating system can again unlock the dis okay so let's Zoom a little bit in even further how does such a DPM object look like it has a public part contains a lot of metadata and so on and it has a private part and this private part in the dis encryption case contains the dis encryption key as well as some other data um which will go into a little bit later and if you start it on your dis then actually this private part will be

encrypted and integrity protected um and yeah for us now it's um interesting how this encryption is done and um if you want to use such a DPM object with your TPM you always have to have a parent object U shown here and this parent object is already loaded in the TPM and it has a in this private part there also a private seat for this parent object which is used in the uh key generation for the storage and integrity keys for your newly loaded object uh namely um yeah basically it's really easy you take the public part the seat value generate some keys and with those you can decrypt or encrypt this private part um and all

of this is well specified by the TPM specification which will come U will be important a little bit later because not everything is really well specified in the specification okay if we think about this now how um does this look in practice if um Tesla's uh firmware wants to use the TPM to unseal dis encryption key well we have a TPM object um in general this is sealed by a parent object or this could seal actually multiple objects and in general um these objects form like a key uh Forest right multiple trees of keys and at the top of these trees of uh TPM objects we have the so-called primary objects and the difference here is that these are not uh

sealed against the parent object but they're actually derived from a uh primary seed okay um and if you now wanted to access some DPM object for example down here right this is your dis encryption key then what you need to do in order to uh load or unseal it is you have to perform or walk down this hierarchy um to get to the final object being loaded into your TPM and um yeah so uh from the point of view of like the operating system the only thing that you can actually expect the TPM to have at the start is this primary seat which will which hints at the underlying storage structure because only this primary seed is actually um persistently

stored in this nonvolatile data of the firmware TPM application everything else will be derived or loaded uh at runtime okay so uh talking about this nonvolatile data um yeah I've introduced a little bit the most important thing is that it's stored on the SBI flash chip it contains these primary seats which we need to have access to in order to unseal our dis encryption key and of course it's encrypted because otherwise we could just uh you know get the uh primary seats and be done with this so uh for our paper we reverse engineered how it's actually done you don't need to look at all of this in detail just at the bottom here are the keys that

encrypt our nonv data and actually in the middle here you see that there's some data mixed into this key ation which is actually turns out is the AMD root key and now the issue is right in order to get root we actually replace this AMD root key uh to sign our own payload which then would boot The Next Step that we've modified and so on and so on and um yeah the problem is that with this modified AMD root key we now get different keys and the firm vpm will not be able to load the data the nonvolatile data and so we can't use it to unseal any of the ctpm objects that we want to get access

to okay um but we yeah okay that's why we even here so uh let's continue how can we circumvent this well we just have to leak the values before it at the very beginning of this key derivation there's a random I think 32 bit uh 32 bite value um that is used to actually generate a different key for every processor right you can't have the same keys for every processor otherwise you could just take this nonvolatile data put it in some other AMD processor and unlock it there um and we want to get access to that we can't do this actually we have to uh go one more step down in this derivation process and leak a later part of this

key derivation um here we go so how is this key derivation performed over the boot well basically uh you just have this decrypted nonvolatile data and you have the seed this intermediate value that's passed on all the way from the AMD ROM boot loader to the ftpm application and with our glitch attack right we able to uh yeah replace the off boot loader with our own payload and execute whatever we want there and so what we did is we just executed a small payload that takes the seat and leaks it over the SPI bus to the outside okay so let's take a view at this hierarchy again right remember we want to unseal this object we want to

per per form this hierarchy work and um yeah first of all uh what do we need to do all of this we have access to the CPM object because it's just stored in our dis header um any intermediate objects we assume to have also access to and um all of and also the ceiling step is actually uh well specified so we know how to do it but how do we get to this primary object well in our um paper we're actually done here because um they used some heavy or it was difficult to compute so they just cached this object in the nonvolatile data which we just showed you how we can unseal it and uh

yeah we were done but for Tesla's case actually this primary object is derived every time from the primary seat uh which we do have access to but uh we still need to do uh this derivation step and the problem here is that this derivation step is not really well specified so uh yeah we had to reverse engineer it which actually yeah took us a lot of time and uh was kind of Under Pressure because we had already announced that we were going to do a talk about this uh yeah so I'm going to skip this um how we actually reverse engineered it we reverse engineered it it was great um and um now we're at this P step here we

did the reverse engineering we did we do have access to the nonvolatile data because it's just on the SPI flash chip we have leaked the SE value which we can use to uh decrypt the nonv data and we can just extract this primary seat from here okay if you've fallen asleep during all of that now comes the Practical part where I show you how this looks in practice and um yeah this is my terminal window and you can see that we've extracted um some pem encoded data from the Tesla's file system this pem encoded data can actually only be used if you have access to the correct uh TPM module because it needs to be used with a TPM

because it is a TPM object and um but you know I've not I don't have access to the correct U firmware TPM right now but I'm on my home machine uh and I've written a python script here you can see this python script has takes as inputs actually the ftpm uh sorry the flash chip data that we extracted from the Tesla it takes the seat that we extracted from the Tesla and it takes this uh TPM object and gives us a clear text uh version of this uh um yeah of this RSA key um which we can yeah now hopefully use without any problems next thing that we uh needed to do uh right we extracted these car credentials is

actually just perform a get request um authenticated with open SSL to Tesla's production servers um we have here some uh certificate for our car credentials as well as the just unsealed car credential plain text file uh sorry clear text file and yeah this request uh successfully gave us back a lot of metadata um and yeah that was our uh yeah proof that we had actually gotten access to the correct car credentials in clear text um yeah the next thing here you can see it's a looks header for the user data partition at the bottom there's again a TPM object which you can unseal with a similar python script and finally we um can can uh Mount this encrypted

user data partition which contains a lot of user data here I've uh yeah just mostly blurred everything but you can still see that this person had some contact named Ellis in their data all right so that concludes this last part of the presentation and to we'll summarize um yeah we've reverse engineered all of the boot security of Tesla we found it to be rather good to be honest but still we're able to exploit it because U yeah the CPU that used wasn't hardened against voltage fault injection attacks and uh yeah we used that to show you how to unlock some soft lock features and um yeah important note here is actually you can't patch this by software because you would need

to patch the hardware um to because we actually right we attack the wrong bootloader you can't patch that by software and uh lastly we are able to use this attack to also leak some secrets that Tesla would rather not have us leak um the key takeaways here should be that if your threat model yeah includes the owner of the system of course being locked out from some features then you do need to uh have Hardware attacks in mind um and actually also a positive takeaway might be that using this uh actually you know well hardened open source software like cor booot or Linux seems to actually work pretty well because up until this point uh it seems like the carking community

didn't have any way to get root on the AMD based Tesla boards all of this was of course responsibly disclosed and so on and Tesla informed us about um the car configuration not being uh insecure anymore so you can't actually do the rear um seed heater um unlocking anymore uh you would need a different or a further attack and yeah with that I want to thank Christian and Nicholas and ol for their work and I if you want our code it's available on GitHub and I hope we have have some time for [Applause] questions thank you thank you so much to the three of you you can come to us yes please and yeah we do have time for

questions so yeah I already see a hand sorry thank you for the talk I really enjoyed it um as I have experienced how these uh C heting work there are connected V Lin or can so wouldn't it been much easier to just have a little bit filter device something that just wi can or L activates the cting without needing to hacking the CPU and stuff yes would be easier you could actually Hotwire it right I mean but that would be too easy okay no you're you're right it's not the easiest way to go little fun fact um because you showed the backend API of of Tesla that is called Mothership and like five six years ago

it was still possible to access that via the VPN but without any SSL client key and with just G giving the VIN you could get could get the root password for each Tesla car very cool more questions okay so I was wondering uh how do you know which contact to H wire is it documented or is it just try try and error sorry sorry I didn't understand the question uh on the main board the contacts yeah yeah how do you know which one to hot wire and which not so uh yeah that's actually a good question so these voltage Regulators um we've done this attack a a lot on AMD uh processors and these voltage uh voltage Regulators U

can be easily identified because they have a lot of like you know big uh capacitors and big uh spools what are they again yeah big inductors uh next to them and yeah you can usually then just you know have a guess this is my chip Google it and hopefully find the correct thing and if not then you can also just connect the logic analyzer look at the signals and actually the sv2 packets look a certain way we we are now pretty good at identifying

them thank you for great research and presentation uh I'm just out of curiosity how long does it take like the whole research like it was a year week two days so I mean we did the most relevant um previous research on like glitching in AMD CPU before we looked at Tesla even so that was an important uh yeah kickart in the whole project um we didn't work full-time on it but we started I think in Fall last year we got the first bought yeah and then yeah try it and sometimes when you do for examp example the parameter search for the glitch uh yeah it also takes maybe five days or a week until you find the correct delay

and duration and so on so sometimes you can't uh really accelerate the process and just have to wait but yeah thank

you um first question is how big is the glitching window um for the verific application I think it's like 50 micros 50 60 micros and the second question is um you're said you're doing a lot of glitching research on AMD CPUs um I since when are you doing this and um because it's like a big window and it's pretty easy glitch and I'm a little bit surprised that it's working on a on the platform security processor yeah we we Doo were surprised so um yeah actually this was my uh so building this glitch set up was my master CES and I think I don't maybe two years ago probably three years ago um and yeah

since then we've just you know it continues to work and we continue to think of new paper ideas for our phds so um but yeah I mean so let maybe a little bit um it was my first ever glitching attack actually to do and yeah it's a pretty inefficient setup because you know you saw the voltage go down really slow and go up really slow and you can yeah in theory it could be much improved a lot but um yeah it's just a easy thing to not you know worry about capacitors not worry about anything just connect your digital pins inject two packets um yeah and the pretty big windows so usually uh we have like one day of just

just you know going through all of the parameters and then we find one that fits and then we just spend a few more hours optimizing them actually in the Tesla we had some false positives which were really annoying so glitches did seem to work but did not work for real um yeah I don't know okay would be time for one last question yeah thank you for the great talk um what I personally most honor is your way of problem solving so to my mind it wouldn't be logical to start at the end and solve each and each it I can't simply can't just call it a step but is St you solved in that way um is it your

default way of solving problems to start at the end at the goal and I no I think it's not our default way um but you you referring to the boot security patches and so on yeah um we had to start somewhere and then I guess that's maybe the software engineering way of like you try it and then it doesn't work and fix next problem until you don't have any problems anymore maybe there was the philos there was no philosophy we just I don't know that's how we did it it maybe also so we didn't start exactly in the order that we presented it we had like code execution on the AMD secure processor as a first thing and

then made the attack work from there on uh yeah all right thank you so much for the talk um yeah [Applause]

thanks already set up your laptop

wonderful our next speaker brought some more extensive uh demonstrations so I hope it will

work all right