start	end	text
1920	6700	First of all, allow me to introduce myself because you probably don't know me. I work as a
6700	12500	security engineer for over eight years. Currently I'm working in Accenture Embedded System Security
12500	17100	Team that's based in Prague, Czech Republic. That's also where I come from. And I'm a big
17100	22000	open source enthusiast so the tools that I'll be showing you here today are already published on
22000	31210	GitHub and could be used by anyone. Let's have a look at what's ahead of us. We will start with
31210	35870	the description of the CAN bus. We're right next to the car hacking village so 90% people there
35870	41670	actually know that better than I do, but I'll still try. We will use this knowledge to define
41670	47590	the problem that I'd like to talk about and then I'll go into the demo section which will be quite
47590	53410	long because I have two of the demos. First demo will be using a development board and access to
53410	59010	the source code debugger and we will basically have a white box approach and we will see
59730	66050	how this vulnerability works. Then we will continue in the second demonstration and I'd like
66050	71830	to approach this one as a simulated security assessment here on stage of a real life ECU.
71870	76790	So I brought an ECU from a vehicle and I'll be doing security assessment of that. This demo is
76790	82850	quite packed. We will be using JTAG debugger, we will be analyzing firmware, we will be using
82850	89850	oscilloscopes so there's a lot to see. And then we will just wrap up the talk with just a couple
89850	95290	points about who could be affected by it and some general takeaways. At the end I hope there will
95290	101750	be still some time left for questions and answers. So without further ado, let's jump into the first
101750	107330	slide and that's the description of the CAN bus. So most of you probably know but CAN bus or
107330	112470	controller area network bus is a standard that was originally aimed at the vehicles to allow
112470	117390	multiple ECUs to communicate with each other reliably in the noisy environments such as the
117390	123730	car. To achieve this there are two wires used for this which are carrying a differential signal.
123730	128290	Differential signal means that the data being transmitted over these two lines is basically
128290	134550	identical, it's just the polarity is inverted. And each of these buses is terminated by 120 ohm
134550	140950	resistor. Typical vehicle probably contains multiple of these buses which are usually connected by
140950	146110	something that's called security gateway. If I'm to use analogy to IP networks that would be
146110	151850	like a router that decides which message can pass where. Thanks to these properties like
151850	156530	robustness, it's found its way into other industries as well. That's why the talk is
157110	162810	described as embedded devices. Because you can find CAN bus in heavy industry equipment, you can
162810	168650	find CAN bus in medical devices and on a lot of other places too. It's also important to mention
168650	173570	that there are multiple versions of the CAN bus as it evolved over the time. It started with an
173570	179750	11 bit identifier CAN bus that carried just 8 bytes of data. These have been deemed insufficient
179750	188630	so an extended CAN ID came which just increased the ID portion to 29 bits. But it kept the 8
188630	195030	bytes of the data. Then further CAN bus versions have been introduced such as CAN FD with 64
195030	201610	bytes of data. But the talk that I'm having today is only applicable to the standard CAN ID
201610	207890	frame and extended CAN ID frame. We'll discuss briefly CAN FD and CAN XL but only at the end
207890	217110	of this talk. This slide shows the message, the frame and its individual fields. In the green
217110	222190	part there is the most important field that's CAN ID. Obviously you need that. Then in the yellow
222190	228790	you can see field called DLC or data length code. This tells us how many bytes of data actually
228790	235570	follow. That could be between 0 to 8. So there is a perfect valid message in CAN bus that has
235570	240830	0 bytes of data. The meaning could be carried just inside the ID. But you can have anywhere
240830	247430	up to 8 bytes of data. Then in the blue field you can see the CRC but that's not really relevant
247430	254870	for this talk so I'm going to skip the remaining fields. For the picture at the bottom, that's a
254870	260170	capture from an oscilloscope. It shows you how it works on the physical layer. You can see the
260170	265770	differential signaling where the red line is CAN high, the blue line is CAN low. As you can see
265770	271010	the data is basically identical. It's just a mirror image between those two. We'll be playing
271010	276190	a bit with the oscilloscope later on in the demo. But for now this is just for me to show you how
276190	280950	it works on the physical layer. It's not really relevant to what I'm going to talk about.
283290	289810	If we dive a bit into the specification of the CAN bus and we look at the description of the
289810	297510	data length code field, we will find that it has to have values between 0 and 8. To express 8 in
297510	304710	binary, you need 4 bits because that's 1 followed by 3 zeros. And therefore, I got an idea like
304710	312850	what would happen if I'm going to just send DLC field with all 4 ones. First disclaimer, you can
312850	320130	never send more than 8 bytes of data in those CAN frames. Those packets would be just malformed,
320130	327090	never really received, so you'll never send more than 8 bytes of data. However, what I found is
327090	333330	that none of the hardware and most of the software actually cares about the DLC field value. So you
333330	338610	can send whatever you want there and it's still valid and it will still be passed all the way to
338610	344090	the developer. And then it's up to the firmware development team how they work with this value.
344670	350970	On the slide, you can see a hypothetical memcpy situation. And because the developers that are
350970	355250	working with CAN bus probably know that they can never receive more than 8 bytes, the destination
355250	360550	buffer would be allocated to 8 bytes because why waste memory? Then the source of the operation
360550	366230	as a second parameter would be CAN data, because that's what we want to copy. But since you're not
366230	371950	always receiving 8 bytes, but sometimes you receive 4, 3 or any other value, you can use
371950	377890	this convenient DLC field, which the frameworks you're using is giving you, to actually specify
377890	383330	how many bytes should be copied. And that's exactly where the problem comes. Now I'm going to do the
383330	389570	funny thing of readjusting the microphone. I'm sorry if I drop it, because I want to sit for the
389570	406480	demo. Sorry for that delay. We'll basically jump into our first demonstration. But before that, I'd
406480	411300	like to introduce you to the hardware that I brought with me. It's in this yellow suitcase
411300	418020	that you can see on the stage. And as you can see, it contains a lot of PCBs, wires, some displays,
418020	424060	LEDs. And I hope you like it at least as much as people at the airport security did, because I had
424060	430720	to explain to like 3 people what it is. I had to take it apart. And they basically swiped the
430720	436840	hell out of it with those anti-explosive detective papers. So it's kind of a miracle it still works,
436840	445840	but it does. In this case, I have a red board here, the red one in the corner. That will be a
445840	450540	victim for our first demo. It's an NXP board where I'll have source code running and everything.
451100	456980	The guy in the corner here, the simple Arduino, that's the attacker. It has a little button here
456980	461600	that you can't really see, but whenever I press it, a malicious message will be sent. I'm going
461600	467520	to ignore the middle Arduino for now. And this is just a power source so that it actually works.
467520	473920	So that's not really important. Now, if I'd like to show you actually how the source code looks
473920	480060	like for these boards, I'll start with the attacker one, so the Arduino. In the setup function,
480060	485320	I'll just set up CAN bus serial and the button. That's not really interesting. Then I set up the
485320	492600	message. I'll start by setting a CAN ID 600A. You'll find out in the second demo why. But the
492600	500300	most important thing, I'll set the DLC field value to F. Then I need to set some dummy payload. In
500300	505260	this case, it would be A, B, C, D, E, F, G, H in capital ASCII so that we can actually see it and
505260	510900	refer to it while we're debugging. And inside the loop, it just waits for the button press and
510900	518260	whenever that happens, we're going to send the message with this function. When I switch to the
518260	523360	victim, so the red board code, which we will be debugging, there's a main function. We just have
523360	529840	two variables. One is obviously called overwrite buffer because we're going to overwrite it. And
529840	536720	we start by setting it to value 1, 2, 3, 4, 5, 6, 7, again, so that we have something easy to refer
536720	544400	to. Then there is not really interesting CAN bus setup, which I'll just skip. And in here, I'll be
544400	552320	waiting for a message to arrive. And when it does, there is the main copy function, which is basically
552320	559080	identical to the one from the previous slide, where we're copying into the buffer. Frame DSR
559080	566860	is how MCU Expresso chose to call the data field. I'm not to blame for that. And frame DLR is the
566860	572080	DLC field value. That's how it's called in MCU Expresso. Again, in every framework, it will be
572080	578220	called differently. Since I have the board in the case, I can just hit debug, and this should run
578220	585340	it, run the code, and we should stop on our first breakpoint. If I step over this, I can just
585340	591280	investigate that the override buffer is now set to values 1, 2, 3, 4, 5, 6, 7, and ASCII terminated
591280	596960	by a null byte, which is exactly as expected. And if I run the code, nothing really happens,
596960	601180	because we're now in this endless loop and we're waiting for CAN messages to arrive.
601460	609560	To do so, I need to press this almost invisible button, and hopefully you see a notification
609560	614420	pop up here on my screen that tells me that the breakpoint was hit at this memcpy function.
615340	621620	In the data that I'm using as a source for the memcpy, you can see the A, B, C, D, E, F, G, H,
621620	627100	which we've set in the Arduino. And in the DLR, we can see value 15, which is the DLC field
627640	633000	value which we've set. I'm just going to step over this so that the memcpy finishes what it did.
633120	640920	Now, inside the buffer, I should have this A, B, C, D string. But more importantly,
640920	648000	let's have a look at what is in the overwrite buffer. I'm just going to scroll over it.
648240	653980	The very first value, I hope it's readable a bit, is value 15, which is suspicious,
653980	659300	because 15 is the DLC field we've sent. But the remaining values I don't really recognize,
659300	665560	because there is nullbyte, then 137, 172, then repeated, then another nullbyte. The final
665560	669260	nullbyte hasn't been overwritten, because we're overwriting just with seven bytes,
669260	674320	so the final nullbyte is from the original buffer. But now it would be good to see whether
675340	681300	we have some control over the data that we're overwriting with. To do that, we have to investigate
682880	688000	a structure called mscanframe. Again, this is specific to MCUXpresso framework. In other
688000	693300	frameworks, you'll find something completely different. And we'll see that the value of DSR,
693300	697220	which is the data where we started the copy operation, is actually a member of a union,
697220	701220	so that you can access the data as data words or data bytes.
701400	707420	But right after that, there is the DLR value, which is the DLC. This confirms our suspicion
707420	714920	that we are overwriting with this structure. But the remaining values, such as buffer priority,
714920	720320	type, format, and some timestamps, those aren't really in control of the attacker. So we have
720320	726600	very limited control of what we overwrite with. But nevertheless, we can actually use this for
726600	730720	some other impact than just denial of service that's in the title of this talk. I can imagine
730720	737260	situations where you overwrite local and global variables in a way that you change their values
737260	743600	from a zero to something else. Why this is important? And that's because when you program
743600	748720	in C, there's quite a common practice of doing a null check. A null check is, for example,
749320	754060	is authenticated if it is a variable. Then if it is zero, you're not authenticated,
754060	759340	and anything else would mean you are. And this way you could theoretically bypass some of the
759340	766860	controls. Although in the real life examples, this always resulted just in the denial of service,
766860	771480	usually for various reasons, but mainly by overwriting pointers to something that makes
771480	777360	absolutely no sense, and then crashing the firmware. With that, I'd like to transition
777360	784500	into the second demonstration where I'll be using an ECU from a Tesla Model 3 vehicle.
784620	788940	It's the security controller that sits between the seats where you tap your NFC card when you
788940	795380	want to drive. It's responsible, for example, for unlocking the door and the decision whether you
795380	800620	can drive or not. This is done together with the body control module. And if we do a typical
800620	809480	assessment, we first unpack the ECU and see what the PCB has to offer. In this case, we found that
809480	817280	on the bottom of the PCB, there is an SPC560B64 microcontroller from STMicro, and literally right
817280	823680	next to it are pads which are labeled STJTAG. The jackpot in this case was that this was actually
823680	828780	working JTAG interface, so we were able to dump the firmware image and proceed with the assessment.
828780	833280	And this is exactly what I'd like to do here. And we will start by dumping the image, then we will
833280	838540	analyze the firmware, find the vulnerability, exploit it, and then play with the oscilloscope
838540	846020	and have some fun. So let me just show you the unobfuscated view on the suitcase. You can see
846020	851800	the ECU, obviously the big green thing with the Tesla logo. The Arduino in the middle serves only
851800	857200	one purpose, and that is to simulate the rest of the car. So in fact, this suitcase is the smallest
857200	862860	Tesla car that you have probably seen. I'll have this again, a little black button. Whenever I
862860	868180	press it, I simulate the rest of the car so that the ECU works as if it is in. If I don't do that,
868180	875040	I can't really work with this ECU and show you it live. I talked about the debugger, so I have
875040	881500	just the JLink. I hope it's readable. In this suitcase, there are actually multiple layers. One
881500	889200	of the layers contains a JLink debugger, and I can connect with it and just type connect. I have
889200	896520	pre-selected the correct MCU, so SPC560B64. So I'll just leave everything default, because I like
896520	902800	defaults. And the CPU is now halted and I'm connected to it. This is a good time to dump the
902800	910560	firmware image. I can use savebin command for that. And as a destination, I'll choose file tmpfw.bin,
910560	915600	for example. And now I have to specify the memory range, which I want to dump. So it will be from
915600	924120	address 0 to address 17FFFF. This memory range, I've read it from the data sheet, but I consider
924120	929740	it kind of boring to open a data sheet here, so I'm just going to cheat and skip on that. But this
929740	934960	will save the binary from that section. You can find it in the memory map. There's actually no
934960	942700	science around this. Now we have a firmware dumped, and I'm going to open IDA and analyze the
942700	949220	binary. I made all fonts ridiculously large, so I hope you can read it. For me, it's quite painful
949220	957600	to work like this, but it's for the audience's sake. I'm going to choose PowerPC, because as I
957600	964440	said, I was reading the data sheet, so I know that it's a PowerPC. And from now on, I'll use my
964440	971880	beloved defaults everywhere. And this should load me a binary in an IDA. But as you can see,
971880	977320	nothing really happened, because we're working with a binary blob, and IDA doesn't really know,
977320	981500	is it the code? Is it data? Is it a mix of both? There are no entry points. What should I do?
982260	988080	Since this is a situation that we faced quite often, working with extracted firmware image
988080	993740	from a microcontroller, we made a little plug-in for IDA Pro, which is called Firm Loader. And
993740	1001500	here I just have to select the brand, the line of the MCU, and the correct MCU. And this will
1001500	1006800	start the auto-analysis. It will also create memory sections such as RAM, peripherals,
1006800	1013060	and will mark the code flash as executable and trigger the auto-analysis. If I'm to do a real
1013060	1018160	assessment, this is a starting point, not a complete analysis. I have to do a bit more manual
1018160	1025280	work to make it ideal, but we don't have time and we have to cheat a bit. So I'm going to be fine
1025280	1033280	with the analysis that it did, mainly because it already found 1700 or so functions. So we have
1033280	1038020	the binary loaded and we can start working with it. Now I'd like to show you two different ways
1038020	1044900	on how to approach firmware analysis of an MCU. The first approach is identifying standard
1044900	1052240	functions. Standard functions are things like memcpy, malloc, free, all of those libc functions
1052240	1057380	that developers use everywhere. It's good to find them, because then it's a bit easier to
1057380	1062940	uncover the custom logic in the firmware. You can use AIDA Lumina if you have AIDA for that.
1062940	1067400	It's a great tool, but I'm going to do it manually, not because I just want to scare you with the
1067400	1073540	assembly, but I just actually want to show you that it's not that hard. Let me just adjust the
1073540	1079680	view of AIDA a little bit so that we have a more comfortable view. And I'm also going to need to
1079680	1086600	set the compiler. Sorry for that delay. And this function is actually memcpy. I'm just going to
1086600	1093360	walk you through very quickly on why it is a memcpy. Again, I had to read about PowerPC to
1093360	1098820	figure out that the first three arguments to a function are passed in registers R3, R4, and R5.
1098820	1105360	Therefore, if I look at the memcpy parameters, I know that the first one is the destination,
1105360	1109440	the second one is source, and the third one is how many bytes should be copied.
1109760	1114880	So the third parameter, R5, is here first incremented, and then it's set into something
1114880	1120520	called counter register. Again, I had to read about PowerPC, unfortunately. Then this counter
1120520	1127020	register is decremented every time we execute this instruction. And if it reaches zero,
1127020	1133060	we go here to end the function. But as long as it's not zero, we will be executing this code
1133060	1139200	block in a loop. So we already know that whatever this function does, it will do it for how many
1139200	1143800	times we tell it in a third argument, which is already a good definition of a memcpy.
1144320	1150360	But inside the body of the loop, we can see that it takes the second argument, so register R4,
1150360	1158120	indexed by R0, and stores that value into R7. Then instruction after that takes that value from
1158120	1165060	R7 and stores it in the first argument, which is R3, again indexed by R0. Then the index is just
1165060	1170500	incremented and this repeats for however many times we specified. This is how you find a standard
1170500	1176780	function. Sometimes it's a bit more complicated. I admit this was one of the very easiest examples.
1177340	1181180	I'm also going to set the type of the function because I would like to show you some automation
1181180	1188640	later and for that this is necessary. Now, if I'm doing a security analysis of a firmware, I can hit
1188640	1194480	X on the keyboard and I should now theoretically go through all of these memcpy cross-references
1194480	1200240	and see if they are vulnerable or not. I'm lazy and I don't have time, so I'm not going to do that.
1200980	1205920	Second approach that I'd like to show you is a combination of static and dynamic analysis.
1206780	1212120	During the dynamic analysis I know what the ECU sends on a CAN bus. I know what it receives on
1212120	1217200	the CAN bus. So it's actually very simple to just use search for immediate values
1218680	1226000	and find the CAN ID I'm interested in. This isn't exactly working every time, but in this case it
1226000	1232740	does. So the second hit is especially interesting because it's in compare instruction and it's
1232740	1238520	comparing register R3, so first argument to a function, to the value that I know I saw on the
1238520	1243240	CAN bus. And if I look around I actually see a lot of the values that I've seen on the CAN bus.
1243240	1249200	This one, this one, this one. So this is good enough assumption for me to just rename this
1249200	1256960	to CAN handler because it appears to be handling incoming CAN messages. And now I'll end the
1256960	1262420	torture and switch to the decompiler because we need to speed up a bit. And we said that the first
1262420	1269240	one is CAN DLC, so I'm just, uh, CAN ID, sorry. I'm going to rename it to that. With a bit of
1269240	1274400	analysis that I'm not going to show you here, uh, we would figure out this is CAN data and we
1274400	1281360	would actually figure out this is CAN DLC. And now we basically went from a black box assessment
1281360	1289440	where we took an ECU from a vehicle to a crappy source code review. Uh, and again, as you can
1289440	1295040	see there are many CAN bus IDs being handled by this function. And in theory I should go
1295040	1301400	through all of them and identify whether any of these are vulnerable to some issues. Again, I'm
1301400	1306880	lazy, I don't have time so I'm not going to do that. Uh, instead I'm going to skip over and if
1306880	1312400	you remember the attacking board sends CAN ID 600A. So I'm going to just look at the handler
1312400	1319160	for CAN ID 600A. I'm going to rename it to that because I don't want to lose track. And this
1319160	1326120	function gets CAN data and CAN DLC as parameters. So let's just open it. And do the renaming
1326120	1337200	again. And now this mem copy here screams at us I'm vulnerable basically. Because as you can see
1337200	1343820	this length specifier here is CAN DLC. The source is CAN data. And as a destination there is this
1343820	1349260	weird memory address. Uh, weird memory addresses in MCU firmware are usually global variables.
1349260	1354760	They're just static places in memory which are then used to access the variable values. If I look
1354760	1361640	at it, I can find that there is between 1AF0 and 1AF7 I have preallocated 8 bytes for this
1361640	1367740	variable. And right after it there is variable called 1AF8. And if I look at the cross
1367740	1373280	references I can see that it is being used somewhere. So if I overflow this variable, I may
1373280	1379080	adjust something in the firmware and cause some undesired behavior. I'm just going to
1379080	1384760	synchronize the view because that's going to be useful if my right click would have worked.
1384980	1395650	Sorry for that. And now when we saw the CAN handler, there were many, many, many functions
1395650	1400930	that were handling CAN messages. I said I'm lazy so I'm not going to do that. But because I'm
1400930	1407410	lazy all the time, but I don't have time just right now, we created a plugin that automates a
1407790	1415670	bit a search for cross references. This plugin is called Wolfie. And to work with it, I wonder
1415670	1423690	why my touch pad doesn't work. Thanks. You just have to add certain functions. I'm sorry I
1423690	1428990	don't know how to enlarge this text so I'll just describe it. We first select some name for
1428990	1435110	the rule that actually doesn't matter at all. And then we have to use a filter to somehow
1435110	1439990	filter out all the memcpy functions we're not interested in or to just filter those that we
1439990	1445310	are interested in. To find this vulnerability, there is one precondition. The memcpy function
1445310	1451130	must not have static third parameter. If there is a static value like 2, 3, 8 in a third
1451130	1458650	parameter, this vulnerability will not work. So I'll start by saying that the not param 2 dot
1459170	1467990	is constant. I'm sorry for the syntax, it's just Python code that gets evaluated. And if this
1467990	1472490	condition is fulfilled, I can also say that I'm actually only interested in the functions that
1472490	1480290	are called from the can handler. So I can just say function, if I'm be able to type, function
1480290	1492590	call dot reachable from can handler. And this query will now take a look at all 100 plus
1492590	1497470	cross references to a memcpy function and it will only filter out those that match the
1497470	1503370	criteria I've specified. As you can see, the very first one is the one we found manually in
1503370	1511210	can handler 68, but there are five others. I'd like to specifically look at the one at 6F1BA,
1512050	1516430	which is right here. The main reason I want to look at it is if I look at the cross references
1516430	1524410	of this function, we can see it's being called at the can handler 68 here. And it's right here.
1524410	1538510	As you can see again, it gets canData, canDLC as parameters. So rename again. And now we can see
1538510	1544030	that right in the middle of the function, there is a memcpy function. It uses as a source canData
1544680	1551050	as a count of bytes. This time it's V4, but V4 is here, it's just canDLC, so it's just canDLC
1551050	1557250	through a proxy, let's say. The destination in this time is variable V7, which is a local
1557250	1564310	variable. It is an 8 byte array. So we can share again, we will be overflowing. But we will be
1564310	1569950	overflowing into something called variable V8. And if you look at what it is, it actually is set
1569950	1575250	to some constant value here from a global variable at the beginning of the function. And then it's
1575250	1582290	compared to it at the end of the function. This is a thing called stack canaries. And it is used
1582290	1588290	to protect the values on the stack against buffer overflows such as this one. So in this case, we
1588290	1593970	know that when we send this scan message, we would actually cause this stack canary to get
1593970	1598910	triggered. But we should have a look at what's going to happen. And that's in this function, we
1598910	1603930	will actually play a bit with peripherals. But more importantly, there is this endless while
1603930	1610370	loop. Endless while loops are the best indicators for fault handlers in microcontrollers. Because
1610370	1616150	while in endless while loop, the device cannot cause any harm by just doing weird things with
1616150	1622590	its peripherals. It's just executing the same instruction over and over again. Therefore, we
1622590	1628210	will cause a crash of this microcontroller. That's why denial of service. But unfortunately, it
1628210	1634710	would be through an anti-climatic overwrite of a stack canary. We have access to the debugger, so
1634710	1639170	it would be quite nice to actually see this in action and see if we actually overwrite with the
1639170	1644690	same values as we have seen in the previous demo. So to do that, I decided to torture myself
1644690	1653970	further and show you the access in the debugger. Where I can set breakpoints. First one would be
1653970	1664320	at before mem copy function. The second one will be right after it. And I'll check if the CPU is
1664320	1671100	halted. It is. I'll let it go. Now, the ECU wouldn't actually react to any kind of messages
1671100	1676660	because it's sleeping state. So I have to press this button. This will turn on one of the LEDs
1676660	1682020	that were so loved at the airport. And once it turns off, I know that the car is properly
1682020	1691200	simulated and I can start working with the ECU. The CPU still shouldn't be halted. But this would
1691200	1699600	change after I send the attacker message. And as you can see, it did. Now we're right before the
1699600	1704980	mem copy function. And we can investigate the registers. And from the beginning of the demo, we
1704980	1711900	can actually know that the register R3 is the one that holds the destination location. So I can
1711900	1718880	use mem 32 function command to dump that part of the memory. I'm also terrible sorry to anyone who
1718880	1726520	knows how to work with Jlink and these kind of commands. I'm not really good with that. But here,
1726520	1732440	these eight bytes are the legitimate V7 buffer. This is what should be overwritten with the
1732440	1739560	candata. This is stack canary, which is interestingly set to all zeros. And this is the value
1739560	1746540	that should be protected by the stack canary. And now comes the part where I'm not really good
1746540	1753060	with Jlink. Because this is how I step over break points. As I said, I'm sorry to anyone who
1753060	1761300	knows how to do that. And if I repeat the command now, we can see that these 41, 42, this is
1761300	1766960	basically the A, B, C, D, E, F, G, H string. This is the stack canary, which has been
1766960	1773760	overwritten with the can ID. So we can cheer up a bit because we are controlling quite a lot of
1773760	1779620	bytes that we're overflowing. But we can't really because if we change the can ID, this overflow
1779620	1785760	would never happen. So again, we can't really change what we overflow with in this case. Then
1785760	1790480	this is probably can DLC based on the value here. Then there are some null bytes for some
1790480	1796220	flags inside the can structure. And this D8 is from the original pointer. We haven't really
1796220	1803740	overwritten that. Now having access to the debugger is nice. And I'm not really good with
1803760	1809800	that. But sometimes you don't have that. And let me just check that the CPU is not halted. It is
1809800	1815720	not. And in this suitcase, there is a third layer underneath the J link layer and that contains
1815720	1820520	an oscilloscope. One of the oscilloscope probes is connected here to the CAN bus. The other
1820520	1828800	oscilloscope probe is hidden under this to sense the NFC field. So if I now press this simulation
1828800	1835780	button, I can go into the oscilloscope view and start tracking. The red line is the NFC field.
1835780	1841560	The blue line is the CAN bus. So when the ECU comes up, you can see NFC field is up. And if I
1841560	1849460	press the attacker button, you'll first see that... let me stop that first. You'll see that the CAN
1849460	1855460	messages have stopped being sent. That's the reset of the ECU. And about a half a second
1855460	1859940	after that, the NFC field got killed as well. This is how we initially found the vulnerability
1859940	1866240	through fuzzing and using this side channel detection. The delay between the crash of the MCU
1866240	1871120	and the NFC field disappearing is caused by the fact that the NFC controller is actually a
1871120	1876880	separate chip. And there is a communication line between the main MCU and the NFC chip. And
1876880	1882180	that's why there is a bit of a half second delay before that shuts down. I'll try to zoom into
1882180	1888140	this, but I have never found a way how to increase text here. So you'll probably not be able to
1888140	1895640	read that. But the message before this drop happens, the last message is the one we've sent.
1895640	1901640	So ID 600A. And the voltage drop is actually caused by the GPIO pins being reset into their
1902000	1908880	default state. After that, if I zoom out a bit, there is a break in CAN messages being sent. This
1908880	1913320	is because the ECU is restarting. And then it gets into the initial state where it again
1913320	1921520	waits for it to be restarted. This is just one of the side channel ways. And when I was here, I've
1921520	1927800	been actually given this invitation to a high roller cone. And quite interestingly, it
1927800	1933280	actually works as an NFC field detector. So if you don't want to use oscilloscopes, for
1933280	1941240	whatever reason, you can actually use this invitation that you can get here at DEF CON. If
1941240	1950460	placed properly, this will light up the LED here whenever it sees the NFC field. And then by
1950460	1956560	just pressing this button, you'll see that the NFC field will stop. I'm not going to the high
1956560	1964620	roller cone, by the way. I have other plans. But anyway, thanks. I like this. The other side
1964620	1970660	channel possibilities are detecting power consumption. That, however, requires soldering,
1970660	1978780	which we have done here. But you can also do it on the CAN bus. There are usually messages
1978780	1983060	that appear periodically. So you can detect the time difference in between the periodic
1983060	1988860	messages. And the easiest way is when you find an ECU that actually sends a specific
1988860	1995340	message on a reset. That's the easiest way how to detect a reset. There is a fuzzer published
1995340	1999120	for that as well. It's actually not published yet because I haven't clicked the button to
1999120	2004800	publish it. But it will be right after this call. Now I'd like to discuss who's affected by this
2004800	2009800	issue. It could be basically anyone who just blindly accepts the value of this DLC field in
2009800	2015800	some memory copy operations. We also looked at the popular SDKs and RTOSs and found that
2015800	2022580	Armabed OS, STM32Cube SDK and NXP MCU Express OSDK, they don't really care and they will send
2022580	2028640	you any value in the DLC field that you send to it. We reported this to all of them. So as of
2028640	2034000	now, this should have been fixed. But there are other frameworks, some of them commercial, we
2034000	2038940	haven't really looked at. So those might be still vulnerable. We looked also at the default
2038940	2045140	Linux kernel drivers, which are not vulnerable. So those will never ever pass you anything higher
2045140	2051080	than 8 in the DLC field if you're working with it. And now is a good time to look at other
2051080	2057580	CAN bus versions. So CAN FD is not affected by the nature of it because the data payload was
2057580	2063820	increased to 64 bytes. But the DLC field stayed at 4 bits and there is this weird translation
2063820	2070460	table where you translate into those 4 bits how many bytes follow. CAN XL is likely not
2070460	2075960	affected. I would like to wait with any judgments here because I haven't seen any real
2075960	2083340	implementation of it anywhere. But based on the specification, it should not be. Finally, I
2083340	2087560	would like to have some general takeaways from this. So first of all, if you're a developer,
2087560	2092460	regardless of the protocol you work with, you should consider the metadata of it as
2092460	2099180	entrusted, not just the data it arrives over it. It is also good to know how the libraries
2099180	2103220	you're actually working with are handling values such as length of incoming data for that
2103220	2107960	matter. And if you're on the assessment side such as me, I would like to suggest that it's
2107960	2112440	always worth looking one layer below the obvious application data into the protocol world
2112440	2117660	because there may be some interesting vulnerabilities in there as well. With that, I'd
2117660	2122240	like to thank you for your attention and ask if you have any questions. I'll try to stand and
2122240	2136070	adjust this microphone again. The high roller invitation, although I'm not sure if it's
2136070	2141630	invitation, I can give it to someone if they want. I have enough things that the tech NFC
2141630	2155900	feels at home. There's a microphone over there so that everyone can hear. Have you tried to
2155900	2162980	increase the F value to read more memory and see what happens? I'm sorry, I haven't heard.
2163440	2168140	Could you come just here? This microphone seems to work a bit better. You have a stage
2168140	2178440	time. So the question was whether I tried to increase the F value in the DLC. I can't
2178440	2184920	because there are just four bits. And if I set all four bits to one, it is up to F. I'd love to
2184920	2191320	have more than F, but I can't. Actually, in CanXL, the DLC field is 11, which can fit up to
2191920	2200740	2047. But then the specification says you can have up to 2048 bytes of data. And I don't know
2200740	2204980	how is that going to work. But I'll wait for the implementation and then I'll hack crap out of
2204980	2216740	it. I guess that's all. So thank you and have a nice day.