start	end	text
1870	8990	Hello, this is our talk from Blackbox to Automotive Ransomware.
10290	21590	My name is Nius and I have Enrico with me. We are both PhD students on DOTH Regensburg
22430	30550	and the University of West Bohemia. We are focusing on car hacking since 2016, I think,
30550	37370	and today we're going to show how to reverse engineer a body controller and to run
37910	46330	Automotive Ransomware. All right, in 2019 we gave a talk IoT backdoors in cars and basically this
46330	55690	talk is volume two of it. In this talk we showed how to exploit an OBD GSM dongle over the air and
55690	63650	how to obtain execution on the CAN bus. And basically during this talk we showed already
63650	69670	how to flash stuff on a car. You can see it here in the picture. This is like a lock from
69670	75490	the dongle where we get security access where we flash some payload and this was already our
75490	80950	exploit but we couldn't show it at this time. So today we're gonna show the car part. So what
80950	88330	we need to do to install a ransomware on the car itself. All right, so will Automotive Ransomware
88330	98050	be a thing? We don't know but we made a proof of concept to show the difficulties and to see
98050	106250	what you can do and what doesn't work. All right, so in order to make a ransomware we
107030	114550	did some theory and thought about what we need for ransomware. We figured out some components.
114650	120990	We also wrote a paper about that since we have to publish stuff sometimes. So details you can
120990	127110	find in the paper but basically some of these components that we're going to show today
127110	134470	are components for infection, for self-distribution, for persistency mechanism inside the car,
134470	140990	for malicious activity. User injection is important and some how a revert mechanism
140990	150330	that you can uninstall the ransomware after an infection. All right, today we're gonna show
150830	157510	the initial infection through an OBD donor or a repressure tester. Both is possible
158710	163330	and we chose OBD since it was the easiest way for us.
163330	170450	The self-distribution inside the car is possible but it's not part of the proof of concept.
170710	175750	But the most likeliest for this ransomware to be distributed would be through repressure
175750	183210	testers basically. All right, the persistency mechanism is done by writing to the flesh of
183210	190690	the ECU which was not trivial which we show later. And malicious activity was pretty easy for us.
190690	196270	We could use repressure tester jobs but we also analyzed the immobilizer system of this ECU
196270	202850	in order to make the car run or not run at all. And the user injection which is very important
202850	208250	for the ransomware since you want to frighten the user. We used the infotainment system
208250	216290	and sent some messages to the car. All right, let's do a plan to action.
217010	222910	We want to get ransomware on a black box ECU. First thing we need to do is we need to open
222910	229170	security access. After that we have to figure out a way to get code execution. We need to extract
229170	234450	the firmware and reverse engineer it. After that we're going to patch the firmware and run some
234450	243290	malicious code on it. And last but not least we intimidate the user. Okay, first OBD.
243850	251070	OBD is easy for us. It's available in almost every car. Soon or later every car connects to
251070	256670	repressure tester. So if your repressure or your repressure test is infected you're gonna get
256670	263110	the exploit or you're gonna get the ransomware. OBD gives us a direct access to all the CAN buses
263110	269270	and especially to the diagnostic services of all ECUs even if you have a gateway for security
269270	277590	measures and stuff. If you plug in an OBD dongle or an OBD-GSM dongle then you can get remotely
277590	286590	exploited and if one founds a remote vulnerability inside the telematic unit of this car all we're
286590	292730	going to show can also be done remotely and can be done over the air basically.
293770	302730	Okay, this is our target. It's a body controller. It acts as a gateway inside the CAN, a gateway for
302730	309590	the CAN networks. So the car we attack has two CAN networks and it runs the immobilizer code
309590	321250	and has a direct connection to OBD2. The processor is a UPD70F3558 from Renesas with a
322750	330930	V852E2M instruction set and two megabytes of code flash. Also we have 144 kilobytes of RAM.
330930	337250	We have two CAN transceivers, a single wire CAN and a high speed CAN. A high speed CAN is running
337250	345770	with 500 kilobits per second and a single wire CAN has 33.3 kilobits and besides that we have
345770	354550	many transistors and relays for body control stuff on that ECU. Okay, how to communicate with
354550	364430	that ECU? This ECU uses GMLAN and this is a combination of ISOTP and normal CAN messages.
364710	370910	It's very similar to UDS but there's some differences and the documentation for the
370910	378710	GMLAN protocol is available. And finally we wrote a SCPI module for GMLAN and we also wrote
378710	387210	an ISOTP module, a CAN module, a CCP, OBD2, a UDS, ENET and some IP for SCPI. So check this out if
387210	395070	you like SCPI. We try to support as much automotive stuff as possible here. Okay, to get security
395070	401390	access let's look into the documentation. It's quite easy. We have a sub function where you can
401390	408910	specify to get a seat or to send a key. An even number is requesting a seat, an odd number is
408910	416510	sending a key and then we have two bytes like a high and a low byte for the key. Again two
416510	426630	bytes of key. This is 16 bits of entropy so not that much for this car. To get security access
426630	434350	the tester has to send a request to get a seat. Then ECU sends back a 16-bit seat and the tester
434350	442110	calculates the corresponding key in order to obtain security access. Here's an example how
442110	449230	security access routine might look like. You have a secret which then gets shifted and moved
449230	456190	around with some magic numbers and at the end you obtain the key. It's important to mention here
456190	465170	that the key is constant so we get the same seat every time. And security access
465730	475690	takes 10 seconds after reboot until we can ask for a seat and if we fuck up and the key is wrong
475690	482930	security access is disabled until the next reboot. So we have to power cycle and we can try infinite
482930	491570	times. Every ECU sends different but constant seats and the whole cracking took us roughly
491570	501730	eight days so we had 10 to 10 times to the power of 16 possibilities for sorry seconds to test
501730	508850	every possible key. This is our setup in our laboratory where we have a power supply connected
508850	515870	to a car battery and a big relay here on the side next to the cat which is turning on and off the
515870	522050	car every 10 seconds and the Raspberry Pi which is then brute forcing every possible seat key
522050	527910	combination. All right after we have security access we can start with the enumeration of
527910	535050	services to see what kind of attack surface we have on the ECU. Again we use SCEPI for this.
535670	541150	We are pretty interested in the programming mode and after security access we can enter
541150	548210	this programming mode. Here's a screenshot of SCEPI of the results from enumeration. On the left
548210	556430	side you see all possible GMLAN services and on top you see different states where the ECU is in.
557130	564430	Most important the state on the most right side the programming session with security access and
564430	573350	request download entered. As you can see this one gives us a positive response on the request
573350	581330	download job if we enter that. So this is a good sign for us and a very good attack surface.
582450	588730	Let's look into request download and transfer data. How does that work? On this ECU we were
588730	595950	unlucky. Read memory address was not supported so we could not just say give me an arbitrary address
595950	600810	and give me a memory for it. So firmware extraction was not possible through that
600810	607250	but request download was possible and transfer data as well. Another feature of transfer data
607250	613250	is in this specification the download and execute sub-function. Let's look in the specification.
613250	619690	Here we have the GMLAN transfer data function and the sub-function can be two different things
619690	626570	download and download and execute or execute. Then you have to give a starting address
626570	632810	and a data record. This is how we will basically transfer data to this ECU.
633990	640950	And download and execute is really execute. Later we reverse-engineered the bootloader.
640950	648150	This is an IDA picture of it. So here you can see the service 36 which is transfer data
648790	654790	and the sub-function 80 which then gives us download and execute or execute. And if we enter
654790	662570	here we have the four bytes to int which is the starting address. This function gives us the
662570	672090	starting address back into R10 and then it's moved into R29 and after that we directly jump to R29.
672090	679250	So code execution by design is not a big deal for us. To exploit that you can use
679250	685310	scapy again. This is an exploit function. We have two sockets here for communicating with the vehicle
686050	693350	and then we have a couple of gmlan functions for initiate diagnostic operations,
693350	701630	getting security access and then finally transfer payload transfers our exploit payload to the entry
701630	709890	we give it. And then after all this went through you can just send gmlan transfer data with the
709890	715290	sub-function download and execute or execute and the starting address you want to jump to.
716030	724450	That's it. So Enrico, how do we move forward from here? So first of all we want to show that we
724450	733710	really have a code execution and for doing that the simplest way is downloading some garbage into
733710	740350	the memory and trying to execute it. So for example if I just transfer a 000 which in this
740350	747230	instruction set is a NOP, then the ECU will execute this NOP and then start executing whatever
747230	754030	is after it in the memory which might be uninitialized. And in fact if we do this,
754030	761490	if we call the previous scapy exploit function with 000 as data, the ECU will crash.
762270	769110	Now if instead I terminate the function with 7f00 which in this instruction set
769110	776210	is a jump to the link pointer which is how a return from a function is encoded, then the
776910	781590	ECU will not crash because we are correctly returning to the caller.
781630	789050	Now we were lucky in this case because the function that called our exploit call did not
789050	795190	create some stack frame, so we did not have to pop to the stack frame and restore the
796150	802970	registers for the caller. But in case that was the case, we would have needed to brute force
802970	811790	all the possible shapes of the stack frame which is not really a big issue. But in this case we
811790	820450	were lucky, so just sending out these four bytes will let the ECU execute this NOP and then
820450	828510	jump back to the normal execution. And yeah, this shows that we can execute code on this ECU.
829590	837630	Now we want to dump the firmware because we could not read it out with read memory by address.
839390	845050	So we want to build a small exploit, a small software that dumps the firmware for us over
845050	852750	KEM. We were able to find an IDE for the V850 family of processor for the V850 architecture,
852750	861050	but no tool specific for our processor. We assume that the tools for our
861670	866690	version of this processor are only available to automotive OEMs.
867390	872290	So in the beginning for us it was easier to write small chunks of V850 assembly
872290	880950	to dump the entire firmware over KEM. So this is an example of how we figured out how to send
880950	890610	messages over KEM with our small assembly pieces of code. First of all, we have to set the register
891350	901310	IP with the address of the KEM interface where we want to send the IP, where we want to send
901310	909810	the KEM message from. In this case it is FCN3. We figured this out by reverse engineering the PCB
909810	917890	and trying out all the different KEM interfaces. And then we just have to write 300 in hexadecimal
917890	926830	to that address in order to let the KEM interface send whatever was in the buffer
926830	935970	at that moment in time. Now doing this, the last KEM frame that the issue sent will be sent again.
935970	943850	And by seeing the same KEM frame twice we knew that we were successful in sending something
945310	952130	over with our assembly code. So the next step was sending some custom
953810	959570	data over KEM. This is a bit more complicated because it requires unlocking the message
959570	964790	buffer for writing it and then locking it again when sending the message. So this took quite a
964790	971390	long time to blindly run code, reading the manual and figuring out how to do this. But
971390	977350	in the end we figured it out. It's just a matter of writing 17 in hexadecimal in the same
977870	985870	address as before. This unlocks the message buffer for writing. Now we can write the
986510	993750	KEM ID. This needs to be multiplied by 4 for some reason. And we can write it. This is written to
993850	1002550	a different address in the same peripheral. Then we have to write the length of the message.
1002550	1011470	For some reason this CPU has a bit... has a curve where different sizes of registers need to be
1011470	1018910	written at different addresses in the memory map. So before we were writing half words, 16 bits at
1019010	1024870	a time. And now we're writing something in a register which is a single byte. So we have to
1024870	1031890	change the register, change the address of the memory map to register. But after reading the
1031890	1037070	manual enough and figuring out what we were doing wrong, we were able to change the size of the
1037070	1044850	sent KEM message finally, in this case to 4. And finally we can change the data by writing to this
1044850	1051150	address right here. In this case I'm writing dead beef. I have to write it in Lithuanian, so
1051150	1058890	A-D-D-E-E-F-B-E. Also here it was quite confusing the fact that the registers for the buffer
1059690	1067270	are not contiguous. So the first two bytes are stored at offset 0 and the next two bytes are
1067270	1073750	stored at offset 8 and so on. Finally we have to send the buffer that we prepared
1074350	1081010	and this time I have to write 700 hexadecimal instead of 300. This was because I also had to
1081010	1087230	lock the message and cause the buffer to refresh. Now all of these required a lot of effort and
1087230	1093990	trying, but in the end we were able to send the custom messages. So at this point nothing stops
1093990	1101170	us from dumping the entire firmware. So for example, if we want to dump address 1-2-3-4-0,
1101170	1106930	what we have to do is prepare the address that we want to dump into register 2 for example,
1107970	1115150	point the NTP pointer, which is another register, to the CAN interface like before and then
1115890	1124530	read two bytes at a time from R2 and write them into the EP. And this way we were able to dump
1124530	1131670	the entire firmware, one request at a time. So now we have the firmware and it's time for some
1131670	1141750	reverse engineering. This work was made a few years ago and at that point in time there wasn't
1142250	1147850	really a choice for tools to use for reverse engineering these architectures.
1147850	1157730	First we tried with AIDA. We actually have a license at our university, but our license is
1157730	1163230	only for a very old version and it did not support the V850-E2 instruction set.
1163410	1171450	And a new license is super expensive. We tried RADAR, same thing, didn't support the
1172150	1179370	V850-E2 extension of the instruction set. And finally JITRA didn't exist yet, well it wasn't
1179370	1186280	published yet, but when it was published it also didn't support the V850-E2 architecture.
1186710	1192310	So at this point we were really sad because we could not reverse engineer the firmware,
1192310	1198270	we did not have the tools. However you don't need to be sad anymore because recently JITRA
1198270	1203450	started supporting this instruction set and this extension thanks to this pull request here
1204190	1211850	from Alex Lasso, which is one of our students. And he just finished his bachelor writing this
1211850	1220410	plugin as his thesis. So what I ended up doing at the moment for getting to work fast was writing
1220410	1229810	an AIDA plugin for V850-E2 processors. I started from this already existing plugin called Necromancer
1230530	1238730	which supported some instructions but was incomplete. And then I wrote a small parser
1238730	1247710	that from the PDF manual generated the Python arrays, Python code for the AIDA plugin. So this
1247710	1253490	is the manual, this is how an instruction is encoded. There are a bunch of static constant
1253490	1260950	zeros and one and some bits which are representing the registers that this instruction can access
1260950	1270150	and these are variable. And yeah this parser will parse this PDF and output these tables,
1270150	1280290	these arrays which then could be fed into the plugin for AIDA. And this is a screenshot showing
1280290	1289450	it working. So all the instructions that are uppercase here were disassembled from the plugin
1289870	1295690	and they were not already existing in AIDA. They were not supported by AIDA.
1298580	1307300	Now that we can reverse engineer the firmware, we should look at how it is structured. There is a
1307300	1314140	bootloader in the beginning which is 32 kilobytes. This bootloader contains the code that is executing
1314140	1318380	during the programming mode. So when we switch to programming mode with security access, this is
1318380	1325600	what is getting executed. After that there is the firmware, the program for the rest of the
1325600	1331680	application on this issue. This is 1.3 megabytes and this contains everything that runs while
1331680	1339560	you're driving the car. Then there is around 700 kilobytes of empty program flash. So this is
1339560	1347360	great for us because this is where we can write our persistent malware. And finally there is a few
1347360	1355500	kilobytes of configuration. So we have a lot of space to write a persistent malware. So let's
1355500	1364260	try doing that. Let's see how difficult this is. Of course we cannot write simply with the security
1364260	1369720	access and transfer data because those can only write to a very specific portion of the RAM.
1372340	1376980	There is no code in the entire firmware that performs writes to the flashing.
1376980	1383180	So it is clear that for flashing, for updates on this issue, they were relying on the
1384820	1389780	execution of external data from the RAM, this programming mode.
1390920	1394300	And also the reference manual for the processor does not give any information
1394300	1400480	about how to write to the flash and it only says that you should be using this FSL library.
1401460	1407880	So we managed to find this library, download it, and again it didn't work for our specific
1407880	1414100	V850 processor, but we found one that worked for a very similar one.
1415020	1421920	And it's a binary. It's already compiled. There is no source code. There is some example
1422760	1428460	source code, but the examples use the compiled library.
1429800	1435320	So we had to reverse engineer this. And what we could gather from reverse engineering is that
1435320	1441120	first, the flashing code can only run from RAM because the entire flash,
1441120	1446260	which normally contains the program, is disabled during the write and erase operations.
1446760	1457460	So also when we disable the write protection on the flash, the entire address space of the
1457460	1464360	flash gets replaced by some other code, which was confusing, but it looks like some kind of
1464360	1471000	internal ROM or maybe a BIOS. And write and erase operations are simply executed by
1471000	1477900	preparing the command and the parameters like addresses and the new data into registers from
1477900	1488500	R7 to R10, and then jumping to a very specific address here, FEDFFFF0, which performs the
1488500	1498740	flashing operation for us. Of course, the first flash writes were very scary. So I first started
1500180	1508160	writing... as I said, it's scary. So I first started writing on empty places in the flash.
1508560	1513900	And this is just to verify that the flashing was working. And after a few attempts,
1513900	1519540	it was able to write the flash. And then the next step was patching the bootloader
1519540	1524500	in a way that we didn't have to wait 10 seconds before switching to the programming mode.
1524500	1528940	We could do it instantly. So yeah, I patched the bootloader in a way that
1528940	1534260	the issue would always start in the bootloader, so in the programming mode.
1535840	1542640	So now the requirement for writing a complex ransomware here. First, we don't want to write
1542640	1547700	the entire thing in assembly. We imagine we have to write a lot of code, so we want to write it in
1547700	1554320	C. Secondly, we don't want to break the functionality of the body control module,
1554320	1560700	because it's an essential component when you're driving the car. And because of this,
1560700	1566860	it will be very practical to have code running in your own thread. So a thread is just for us.
1566860	1571180	But this issue did not implement threads at all. This issue just has a single program
1571180	1579040	cooperating with the tasking, not even parallel tasks. One function executes after the other one.
1580020	1585860	Other problems. There is a hardware watchdog and a software watchdog.
1585860	1592540	Both are going to reset the CPU when it doesn't respond in time. And this is another reason why
1592540	1599060	we need to write a parallel thread with a yield function, because otherwise we cannot run a
1599060	1607120	long-running program. And also, we did not have the linker. We had a linker that supported
1608020	1615520	a very similar processor, and we could only compile C that ran from RAM, basically. No flash.
1615520	1622620	We could only run our C code from RAM. And finally, another issue. There are these two
1622620	1631080	registers, R5 and GP, which get set statically to a constant value by the compiler.
1631080	1634840	And then for doing the whole execution of the program, they will preserve the same
1636080	1641600	value. And this value is going to be different depending on what the compiler decides. So
1642420	1650120	when executing our code, it was necessary to preserve the original values of these two
1650120	1656920	registers and then restore them back before passing control back to the original code of
1656920	1661080	this VCU. And this makes return-oriented programming very hard, of course, because
1661080	1667460	we cannot just jump to already existing code to let it do our stuff. We have to
1667460	1673700	be careful about these two registers. So let's look at how we ended up implementing
1673700	1682740	our exploits, given all of these limitations. First, we used transfer data to load our code
1682740	1689260	into the empty portion of the RAM, where we can execute it from. And then we execute it,
1689260	1696760	and this one will patch some exploit into the empty flash, which is this large part of flash
1696760	1703560	which is not used, 700 kilobytes. Then we also patched two interrupt service routines. So the
1703560	1709980	interrupt handlers for both a timer, which gets called periodically, where we will execute our
1709980	1717820	thread, and the interrupt service routine for canReceive, so that we can receive can frames
1717820	1723640	for the rest of the car. And if we are interested in them, save them in a message box in a buffer
1724360	1732540	for our thread to pick them up later. After this patching occurs, during the first execution
1732540	1743870	of the timer ISR, our patch will jump to our code in the empty part of the flash,
1743870	1750410	which is now not empty anymore. And this code is written in assembly, because we cannot compile
1750410	1760230	code to the flash. And what this piece of code does, it just copies the rest of the code
1760230	1767730	from flash to the empty position in the RAM, where code normally is downloaded. And then,
1767730	1773870	after the code is copied there, on the next time the timer, interrupt service routine, or
1773870	1783130	canRoutine are called, we are jumping to the RAM exploit, so the code we have placed in the RAM.
1783130	1785970	Also, we have a small
1787990	1793690	signature at the beginning of our RAM exploit to verify that we prepared the exploit there,
1793690	1799710	and that it didn't crash last time. So, we put some safety measures there to ensure that
1800170	1806690	we didn't get locked out of our only ECU. We only had one ECU to do all of this.
1807490	1812110	And finally, to inject the parallel process, this thread,
1813050	1818810	we changed the timer interrupt, as I said before, and then implemented a small yield function,
1818810	1824690	which saves the entire state of the execution of our exploit.
1825730	1833370	Basically, in its own stack, we have a stack for our thread, and this allows us to do stuff like
1833370	1841010	yield or sleep in between our program, and it works like an Arduino where
1842310	1850810	we can keep running the rest of the code of the car and make sure the watchdog doesn't kick us out.
1852610	1858470	So, this is all regarding patching of the firmware. Now, Nils will explain the features
1858470	1867510	that we implemented in our ransomware. So, now after we have basically our own thread in an
1867510	1873990	unknown operating system where we can inject our code. So, all this portion that we showed,
1873990	1881810	which lives in RAM, has all code written in C, and we can write our ransomware completely in C,
1881810	1889330	we have a yield and a time or sleep function in order to wait for certain events,
1889330	1894950	and we can also receive CAN messages, as Enrico said, through the CAN interrupt service routine.
1894950	1903470	We can store incoming CAN messages into our own ring buffer in our ransomware and can then
1903470	1910710	give this message back to the normal operating system. And this is very handy for us since the
1910710	1916110	car acts completely normal. We can still drive the car, we can do everything with the car,
1916110	1923810	and have our ransomware running independently. Okay, to implement these features, we need a
1923810	1933230	couple of things. So, we want still to interact with the user. We wanted to lock and unlock the
1933230	1938150	immobilizer. So, we implemented a way that we can start the car without key, and we can also
1938150	1946870	not start the car with key, basically, in order to really put pressure onto our ransomware.
1947630	1956190	And then we also need to send ICTP messages to make the car behave badly, in order to
1956950	1963410	scare the driver. And we want to use some extracted rehearsal tester jobs
1964350	1971650	to run these actions, basically. Okay, talking to the user. This is very important for the
1971650	1977690	ransomware, because if you cannot tell someone that the car is owned by the ransomware, no one
1977690	1985450	will pay. But yeah, how can we do this? The multimedia ECU of this car has a screen connected.
1985450	1992790	The radio has its screen, and also this car has a Wi-Fi hotspot. So, the car owner can
1992790	1999730	open up a hotspot and connect with its smartphone to the Wi-Fi hotspot. In order to connect the
1999730	2008530	access points from the car, the car driver needs login credentials. And these login credentials
2008530	2015590	need to be transferred from the telematic ECU to the multimedia ECU. And obviously,
2015590	2021010	they get transferred over CAN. And luckily, over the same CAN as our body control module is
2021010	2027390	connected to. So, the module that we own now is connected on the same CAN bus, where also the
2027390	2034150	multimedia and telematic ECU do their job and their message exchange. Here is an example of
2034150	2041150	some SCEPI code, where we analyzed the ICT communication. We see a first frame here,
2041150	2049190	some flow control, and then some data. And if you defragment all of this data, you can see
2049780	2057090	some strings here. So, there's... it's Italian, since we put the car to Italian language.
2057090	2064160	You can see here Imposizioni Wi-Fi and Anula, which means Wi-Fi settings and abort.
2064730	2071010	And these are basically the text fields for the button on the screen in the car. And we can
2071010	2079270	send our own text strings here in order to show any message we want. Okay, so how does this look
2079270	2091190	like? So, here we see the car and it takes roughly 30 seconds to start. We can let you run,
2091190	2096810	the expert basically run on every event. You can wait for a year after the car got infected.
2096850	2103550	You can wait until the car does more than 100 kilometers per hour, whatever. So, it's completely
2103550	2112990	free. So, and this time, here the ransomware starts. We can see the screen, we can have the
2112990	2123650	buttons, and can talk to the user. Here we are playing around with the dashboard to behave badly,
2123650	2143090	basically. We disable GPS. We also spin up the engine van. So, you will hear it now.
2151860	2159740	And we attack again the dashboard to do some stuff. Let some LEDs blink.
2160880	2166100	So, as soon as you want to pay, the expert is over.
2167100	2176360	All right, this was the live demonstration. We also investigated if you can spread the infection
2176360	2183920	to other ECUs. So, during our time that we worked on this car, we investigated the EPIC ECU. We
2183920	2192140	investigated the telematic ECU and the engine control unit. And security access and code
2192140	2199000	execution on the EPIC ECU were trivial. So, theoretically, it would be very likely and
2199000	2207060	possible that you can infect also other ECUs in that car and that this one ransomware spreads
2207060	2219110	around over all the ECUs in the car. There are some limitations since to do this, basically,
2219610	2227390	our ransomware would be prepared with expert codes for all the individual ECUs. And this is
2227390	2233550	also one of the things which is still, in our opinion, the most limiting factor for writing
2233550	2242170	malware or ransomware for cars nowadays. So, lessons learned from here. In this car,
2242170	2248110	we didn't have any cryptographic challenges and the flashing of the body control unit was easy.
2249530	2257090	The most problems we had were by the obscurity. So, the flashing library was locked down
2257950	2264050	only for the OEMs. So, only if you sign NDAs, you get these tools, you get the hardware.
2264450	2272330	The hardware was proprietary. We didn't got any compiler for this processor. So, this is really
2272330	2280190	limiting factor. And also, in total for malware, the most limiting factor is the heterogonous
2280190	2286370	systems in the car. So, that every ECU has a different chip set, has different instruction
2286370	2292750	set, has different bootloaders, of course, which need to be exploited in a different way.
2292750	2298190	And this is, yeah, in our opinion, the most secure, in fact, at the moment.
2300370	2305970	Yeah, and this, as I said, the problems are common for all ECUs. In the future, we expect
2305970	2311870	more Linux in cars and less obscurity and more homogeneous systems and platforms
2312510	2318730	and probably more server-based. So, yeah, the architecture will probably completely change.
2320130	2328450	Some facts about our proof of concept. This proof of concept was released on a car in 2016.
2329370	2341610	We was made for a car released in 2016. We think almost all cars with a lower price range
2341610	2348710	will have similar bad security at the moment, or let's say a little bit older cars also,
2348710	2353570	you can affect even a not connected car as soon as it connects to the repair shop tester
2353570	2359610	and this repair shop tester has a malware, then you have it. And these cars will still
2359610	2366350	drive around for 5 to 10 more years. So, for example, in Germany, the average age is 9.5 years
2367650	2373670	and all cars will frequently connect to a repair shop tester. So, this is a very easy way for
2373670	2383070	infecting this insecure cars. All right, yeah, you can follow us on Twitter if you like and
2383750	2386730	thanks for listening. Thanks for listening.