Virtualizing Your Ford SYNC3 for Fun and Profit

this next talk is being presented by breaking ground it is virtualizing ford sync by bo wang and jung fang yang uh first of all we would like to thank besides lv for providing us the opportunity to present artwork today we'll be sharing our journey through our sync 3 research and teach you how to start your own vehicle security research without having to buy a real car or car parts uh we would like to first introduce ourselves uh i'm jin fong and i have been working as a security researcher in the industries for more than 10 years most of my times is spent fighting malwares and vulnerabilities this is my first time to try my hand at the vehicle securities i'm

presenting today with my friend bob buck you'll introduce yourself uh yeah sure uh hi i'm bo uh i'm working as a software developer at google i'm an active ctr player and a part-time security researcher this is rough guideline what we'll be presenting today we will talk about why we started the project what is our methodology and current progress and finally we'll share what the security committee liked the most some cool bugs we found during our research without further ado let's get started i'll first introduce the background of our research first of all why do we choose thing 3 as a research target well for one thing we have one in our lab but most importantly lincoln mkz is

very popular in the autonomous vehicle industry especially as a test vehicle a lot of projects are built and tested upon it such as baidu's apollo the reason for that is there are a lot of third-party distributors who provides lincoln mkz as a starter kit for autonomous vehicle development for example autonomous stuff the second reason is that we can easily obtain the full infotainment images since you can just download it online and there's no need to do hardware food versus on saturn chips extracting flashlights etc last but not least nobody seems to have done a public comprehensive research on the sync 3 platform and we would like to get a head start on it now you may want to ask what is this

thing thing we're talking about in force own words forsync is a factory installed integrated vehicle communication entertainment system that allows users to make hand-free telephone calls control music and perform other functions with the use of voice commands the first two generations runs on a windows embedded automotive operating system designed by microsoft while the third generation currently runs on the qnx operating system from blackberry limited most current generation sync 4 which appeared after our research started our lincoln mkz run sync 3 which is the target platform we'll be focusing for our research now you may wonder if we already have a vehicle why do we even bother with virtualizing it rather than just working on the original vehicle

well there are many complicated details for starters we do not want to break our test vehicle nor taking it apart but for our research to go smoothly we would like to get access to a rooted sync 3 infotainment thus we tried some options we found online the first thing we tried is searching if anyone already have rooted in existing sync 3. luckily for us we did actually find someone doing it and they even posted a root password on the forum the only caveat for us to get a specific ethernet dongle they mentioned in the forum connect to the vehicle and ssh with the root password easy right well not quite so what went wrong uh before

disable the usb dongle uh the dev c serial usb after actually finding the initial post if there's only other some way we can get a root shot on the system uh well if we can't break the vehicle then why not try running out on dev boards we consider and try many alternative solutions the first 100 solution we consider is an easy setup that board with the closest hardware spec and features which is the dra74x evm it costs about like 1500 bucks and ain't nobody is willing to afford that a cheaper alternative we found is by extracting information from the config in the download image which is the omap5430 es2 evm uh it's inferred from the environment

variables which we'll talk more about it later and it costs about like 140 bucks okay but can we do better yes the ultimate beaglebone black is for the rescue if you're not familiar with the beaglebone black the beaglebone black is a simple dev board similar to raspberry pi and it officially supports by qnx 6.5.0 sp1 and qm 6.6 with network driver available it cost us about 50 bucks well it's better but it has omaha 3 support rather than omap5 and is limited by the hardware performance i.e you have no bluetooth and it's not scalable for fuzzing and we still need to pay so the ideal infotainment research platform we're looking here is a privileged and easily debuggable

environment has individual components we can run observed behavior such as we can run the individual bluetooth stack and it's cheap ideally we want no cost at all and it's also fuzzable and not restricted by hardware solution for us is building an emulator for sync 3 and virtualize it which is the focus of our talk so now i will introduce you to kiwi mula linaro uh cumular is the branch of the qemu uh the problem with that is uh it only has qnx 6.5 bsp available and has no network driver and it's end of life so there's no support added anywhere anywhere and but the pros of that is that it's really convenient it has no cost

and it's very scalable and there's previous work that's already been running q and x on the linaro which is done by malwarelabs so this is what we choose to focus our research on uh now i'll be talking about how to actually prepare the images so uh where to actually get the upgrades well there are like multiple ways you could do that first thing you could just get it on the official site uh in order to do that you need a valid via number which is not an issue as you can easily get one from any dealer website the second thing you could do is like getting the uh image from like four modeler enthusiast forms like the

mustang forum for example uh the structure of the upgrade images is as follows uh most of them are actually navigation information except uh the ones in the red and uh it when you extract it uh the structure in there have contains one ml which is the second stage bootloader a uboot the qnx ifs which is the qnx os image the app.tar.gz which is the sync 3 apps and the version.the office signature file we'll talk about what these are in the next few slides so for the version.der it actually is the signature of the files based on shot 256 and signed by ford and verified by the appsum application the qnx ifs is actually the os image of

qnet in order to extract files from it we need to use the dump ifs from qnx sdp the version 6.5 is buggy but the version 6.6 works uh there's also the open source version on github which we post a link above and you you also need to decompile the bootscript which is in the procboot.script uh this shows you what's initially uh booting and with dump fs this is easy you can just dump it to std out or uh if you really want to know how to actually parse the dot script binary uh here's the source to that so the useful info in the uh this is the useful info for in from the boot script and as you can see

it's mounting several partitions into dedicated locations and it's running some of the scripts so uh we modified and i was adding stuff for the ifs we'll show about uh we'll show why we did this later uh basically we're following our labs work uh which we do make nand and then do uh for making the images and then ecc for doing the signature and um zero f zero start address and xerox e800 is the end address so you might actually need to adjust the end address accordingly for uh the signatures uh the caveat here is that uh we need to modify the image build file to include three specific things uh this is mainly why we do modification

on the ifs it's just like libsy libraries for example uh because the original bsp came in uh for human linaro is in 6.5 and uh the sync 3 system for our link and mkz is based on 6.6 so we need to add the corresponding libraries in there we also need to modify build files including three startup dependencies instead of directories mount images to folders as you see in the boot script so we made a couple of tool modifications the original layout specified in the make nand does not actually provide enough space for us to fit and modify ffs so we modify the script to increase available ifs size and output image size load instead of using the default size

so now to the apps archive um apps.tar.gz actually only contains absol img the format of that is qnx6 it's mounted on linux but read-only as you can see here uh apps.img is actually what's inside the sync 3 that's different for each vehicle vehicle provider so why are we actually doing this even with the expansion of ifs modification we still cannot actually fit the entire apps.tar.gz so instead we create and format a qnx 6 partition we add an additional hard drive to x8664 qnx vm which uses fdisk create all partitions and make q and x a 6fs to format them copy files and using dd to make an image copy uh you can uh we also did make

images.this image using connexxus dp 6.6 so the entire app style img is about two gigabytes and uh with just the qnx ifs we are only allowed to upload um uh i think around 500 megabytes or something i don't remember the exact uh size but uh that's the limit we have on the qe moving ro flash so this is the um actual layout for the disk partition uh there are some helpful tools in there like um socad and netcat which you can use for hunt for network tools and there's also uh like scp for secure poppy and stations uh for example uh it's like dropbear but yeah uh we'll talk about more of these later so now onto booting the image

the first problem we're seeing is the missing of sd card uh there's no problem with beagle physical beaglebone blackboard as we tried uh cumulinaro with linux as guest has no problem as well but with huey milinaro and qnx 6.5 as guest there's no sd card device appears so what's going on here so it turns out the problem actually lies in the mcsd driver qnx 6.5 we posted the source code link above and so you could check in the bsp basically there are three important functions the mc create thread which creates the control thread and driver thread and after that it also detects the presence of the sd card and start identification process there is one

there's the mc control thread which handles sd insertion removal and ready event there are there's mc driver thread which handles interrupts so after that we turn on the debug logs and to try to figure out what's going on as you can see in the here uh the only thing that's different is the ext state and it says unexpected interrupt in the state uh which we'll find out what's actually happening in the few next few slides so from the debug law you can see that the problem lies in the state transition mc create threat which fails to start the identification sequence here's uh we show what happens in the real hardware the mse create thread will

first send out a command 5 to reset the sd card sd card respond with the command complete interrupt after that mcc create thread will switch its state to mc state ident now in the real hardware the nerve coming back from sd controller will have some amount of delays and the state transition can happen before the command is completed as you can see on the left hand side uh so now we have a race here this is what actually happens in the virtual emulator the command coming from the virtual sd controller and qemu finishes immediately and the command complete interrupt is raised immediately thus the state machine lets you create thread does not have enough time to switch the state to

mcstate ident but still remain in mc state idle thus causing interrupt processing throughout confuse and throw in the error so the ideal fix for this would be to introduce the synchronization process between the two threads mc create threat and mc driver threat however for our purpose having the interrupt thread sleep for a while and preempt the task to create resolves the problem easily note that this was highly impossible to actually happen on the hardware due to latencies introduced in the hardware pipeline after we fix there we're able to successfully boot our emulator sync 3. next infrastructure change we make is for debugging the qnx sdp provides source level debugging however we do not have the

source in this case so we need to think differently qnx does not support local debugging it does support local debugging in order to debug any uh start does not support the hooked phone and in order to develop any apps on the qnx you need to use the p debug program which is the gdp server and pdb supports debugging over tcp ip and serial port here are the example of usages as you can see in on the slide uh uh pdws debugging protocol is self-defined which is not supported by the official gdb you have to use the custom version of gdb from the qnx sdp so you can connect to the target with command line like this and we also know

that the custom gdb version also implements some useful commands such as file download upload which comes in handy during the debugging process so it wasn't long before we encountered the first user that impeded us from debugging well when the custom version of gdp stops on a break point it will check the stack frame even though you do not command it to do so then if the frame pointer is invalid address the gdp will complain about it by throwing exception more annoyingly exception will be sticking around and no further commands can be processed to get around this issue we'll apply further dirty patch to change the throw error function call to printf unfiltered as the patch needs to be done at the

machine code level it's not as straightforward as showing the pseudo sequel here especially since we need to remove the first parameter but with a little more effort it can be done now with the debugging environment ready i will hand over my talk to my colleague doing phone who explained how we set up the communication channel between the host and our guest qnx think about whales we have gotten our vm radius then the next problems pose up that's how we communicated with the guests so by default the vm has a zero power available which is the only channel for us to communicate with the guest like many other embedded system the default console is founded on the

serial port we can execute the commands through the console with the root privilege and as we mentioned before we can also do debugging over the serial port however it's kind of accurate as we won't be able to to interact with the systems with the console during the debugging serial port is real capable of transmitting binary data if we configure it in the right way the code here shows you how we can open the serial port for binary data transmission the key point here is to set the terminal parameter properly no big deal right i'm not going to explain the code line by line here we do not have enough time for that if the serial port is capable of

transmitting binary data then tunneling tcp or udp over the serial power is doable then i turned it to google for help i did note that socat can further a single tcp use connection over a serial port but it does not satisfy us and on the stack overflows we found an answer saying that pppd could do the trick we tried and failed we also noted that return rate has a policy a proxy protocol called marked daku which allow user to route multiple tsp connection over single a single reliable street street oriented transport but unfortunately its whole framework is written in gold lands which is not supported by qx as of now supporting it it's a bit change finally we decided to make

our own one uh the diagram here illustrate how the terminal work to forward the tcp over a single serial port there are just a few uh events that we need to pay attention to they are connection data sending and connection close the program on the left side is running on the holder the right one is in the current x guest the process incarcerate the tcp event in the message and send them over the serial port the acknowledgement package is really important for congestion control but is really inefficient to acknowledge every package instead we can send our acknowledgement package every 200 packets or even more here's the message format we need the first two byte as the magic numbers

because we noted that in some cases if we send data to the serial port of the qm u2 fast the data will somehow be messed up we need to make sure that we are able to detect those errors the connect underscore id is the unique unique identities of the connections and other fields are self-explanatory the bandwidth of the serial ports is very small so we don't want to waste too much space on the header so we keep the message headers as simple as possible when we deploy the tunnels the iv table comes in handy as it allows us to forward any tcp connections to a specific port to do so we need to enable the ip

forward options then here is the command that forwards all the tcp package to your specific ip address to the local host 444 for tcp part i drew a diagram to get this process across one and applications on the host trying to connect to the applications in the guest the kernel module of the ip table will intercept the package and redirect them to the terminal process server and then the process server in incarcerate the package by adding a header and send them to the proxy clients in the guest so here's the demo of the serial port we bring out the vm4 step while waiting for the terminal to be ready we check the direction rules in the ip

table and we also add the aesthetic entries in the host files for convenient purposes once the tunnel is ready we're going to log into the guest okay just wait for me for a few more seconds now it's ready then we can ssh into the host and let's check the environment and then we're trying to um upload the file into the transformer files to the guest the speed is kind of pathetic and then we're also trying to download the files from the guest also it's really slow then we try to post the file by this curve call this post would not touch the ios the file system then you can see the speed is still really slow

so to summarize their implementation um the good point of our implementation is that it supports multiple concurrent tcp connections which means you can access the consoles while you are doing the debugging function is completely as expected the bad points of this implementation is that is pretty slow as shown that the speed of the serial port is the bottom bottom next um can we improve the implementation the answer is yes a little late after we complete the serial port terminals we came across a block from the alpha security they encountered the similar problems when they virtualized the ios assist system then they devised a smart idea here's a brief introduction to their solution they defined a custom system registers

at the qmu layer any programs in the guest theory are right the registers will trigger the callback functions and the copy functions at like the rpc stop there are some drawbacks of this prototype first it lacks a signal support so that the programs in the guest must perform the infinite poolings which will render significantly higher cpu usage if we let this program sleep between pooling that can help but still have rooms for improvement second the prototype only supports a single tissue connections at all times that's pretty much like the soak as we mentioned the earlier throat there are some potential bugs such as writing the swap out memory of the guests from the qm u layers which

might lead to memory question problem and the prototype also assumes that the definition of the error numbers are the same between the host and the guest which might not how choose in some cases we might need to do the translation for the error codes so after reading alpha's skill disposal and ideas joke asked that we can combine these two channels to create a fusion channel we can turn the serial port into a signal channels we can send one byte to the guest to notify the guest programs that we are going to send a data pack the data channel is basically on the qmu custom register the package format is exactly the same as the serial port tunnel moreover

for the best performance we implement the fusion tunnels basically on lib evs yes it supports multiple concurrent connection uh besides we also add the error code translation and fix those minor issues some some of you might wonder why we don't add a new interrupt for the signal support uh that's because we want to keep the channel as universal as possible because for some systems it's really hard to add the introductory support to implement the fusion channel we first need to define a concurrency register we cannot just copy and code paste the codes from alpha security prototype since there theirs is for armed 64 and our cpu is different the patch here is very clear you need to

pay attention to the access fields the pl0 write nwm allows the programs from the user modes to read and write the register and then there are the read function and the write function call but the read functions will simply return the operating system type of the host and the write function is responsible for dispatching the function calls uh here's an example because of writing and reading the custom registers from the guest system the qc underscore get systems simply retrieve the operating system type of the host as we mentioned it here is the incomplete list of the error code on different operating system we can see many error codes various varied from parent phone to platform

and that's why we need translation here's our implementations um it's very simple we define several two dimensional tables so we can convert the error codes by simply consulting the table here's an example um of a calling from the guest the code is self-explanatory we use the qmu called uh structure to incarcerate all the parameters that we want to pass to the kmu layer the line highlight here in yellow lock the buffer in the physical memories technically we should also lock the queue uh the queue code structure but because it's on the stack of the current active thread is highly unlikely to be paged out to the disk so we decided not to lock it in

the physical memories after the qmu return we convert the error number another current um is that the size of the data type may be different between the guest and the host you have to handle them with care okay another demo and uh this demo uh let's take a look at what we have achieved

so um here uh yeah as we can see uh uh we also use ib table um and then we also add the entries in the host when the tunnel is ready we are going to try to log into the guest yeah just wait for a few more seconds yeah it's going to be ready okay it's almost there yeah then let's lock in the guest and the investment is exactly exactly the same as the last one so let's check the speed well uh as you can see the differences right uh compared to the serial port the speed is really kind of magnificent yeah we like that bye so uh okay after so much harvard hard work uh finally we come to the most

exciting part we are going to pick the fruit so when we try our hair at the vehicle we wanted to root the head unifor resources so we'll spend a little time on their app some application which is the application that is responsible for update or an upgrade in which we found our command injection problems which affect us sensory versus release the earliest then april 2018 including the the version that was released in april uh 2018. successfully successfully exploiting this vulnerability can allow attackers to execute arbitrary commands on the systems of a route privilege to exploit these problems fiscal access to the vehicle might be needed middle attack can be another hacking avenues but we have not

verified that intriguing list readings to first vulnerability uh process on hack one it seems any vulnerability that requires physical access to uh fiscal assets or men and middle attacks are considered off scope by fraud so that's really interesting the vulnerability involves involves two key functions the first one supports the lsd files such as auto install the lst the image here shows how the sd files look is not signed in and the get version info underscore fpn functions will call another function to extract the version from the upgrade archive to verify the integrity of the archive the problems is in the process of extracting the file here's the code that addressed the dr files we can see that it caused the sn print

function to construct the command line and then um it caused the execute self commands which later just called the system functions to execute the command the archive name is highly but not fully controllable by us noticing there is no quota surrounding the parameter yes so there is exactly a command inject ingestion problem when the problem pass when the programs pass the else defines if you check the archives a long live of those charts are considered malicious you are not going to be able to use them in defining them so besides except for the those malicious trans there are two more bad charts that we can use there are the slash and the back slash the spacer can be used if you prefer to

update through the wi-fi instead of the usb storm disk the culprit are those two functions named men manufacture as many plate strings as their name suggested they manipulate the strings yeah and um any directory part of the archive names will be removed during the prior reconstruction let's say we um craft an archive pass like this the final commands will look like as follows we can see only the base names is remaining we know that that many dangerous charts are not filters like the dollar symbols and the blankets and the back quotes moreover the space is also available so we don't even need to use any trick like ifs uh to brief uh to briefly summarize the

main major concentrate the uh the first one we can use the slash and best rice which implies we won't be able to use the we won't be able to reference any location that are not in the environment variables and the second limitation is that we can can concatenate multiple comments um commands um the app some current working directory is not writable you can let the tar programs to um that you you you can let the tar programs extract files to the current working directories and many of those environment variables are not usable because they do not end with slash if there's no stress at the end we can control a valid path take the temporary environment variable as an

example if we put the file names right after the variable then it produces a string like this which is not what we want all the countries can be circumvented here are our solutions the first one is really straightforward p debug is our built-in programs on sync 3. we can use it as a back door as well uh here we let it listen on 8 000 tcp port and then we can connect our gdp clients to the port and game or assets the second process is more interesting we add our malicious switch to the unclear archive and then we let the tar programs release our switch to a writable position first and executive script in the next

round the programs will execute these two commands yeah we use the environment variables that ends with the slash that's really helpful thank you thanks uh thank you to sing three uh for the reflector the uh epstems and the vulnerabilities has been fixed um once um only god knows whether or not they have ever not been aware of this issue and uh upgrade link has also been uh had also been has also been changed from htv to https uh then we move to the next target the bluetooth stack of sync three which is based on i inverse and the synchronous support bunch of profiles including the pro the phone book access point as uh etc etc

um and if you happen to have a uh a car you can try to scan all the profiles with the command here signature bluetooth that can support most commands most common psm as well with one just one exception that the bnap is not enabled by default the bit is there is the bluetooth deck of the sensors which heavily use the bss segments instead of heat as a result it's really hard to distinguish the boundaries of objects and it also pose difficulty to fuzzing because in most cases re or write off boundaries in the bsn sections can be perceived the bt stack is even driven and there are a lot of callback functions which make it difficult to do the static

reverse engineers of the program however the bt stack comes with with a bound uh abandoned debugging logs and it's really easy to enable of them they are really helpful to us the diagram here shows how the bluetooth deck works the bt stack is bluetooth driver of the host we need a bluetooth driver to complete the puzzle so according to our analysis stability stack will communicate with the bluetooth device directories if the co bt5 percent on the system how to create a fake serial port because we do not have a physical one then we need to create a fake one well we can write organic resource resource many uh managers programs or just utilize the soul cap program using

a command like this once you can forward the ttp tty p0 to your ad tcp port it's really handy right after creating the pseudo serial port we hook the open functions in the bt step program and redirect the path of the serial port to the pseudo tty there's not enough actually to simulate the serial port we also need to hook that divide control function uh the purpose of this uh is that uh when someone some programs are trying to uh are trying to detect if the serial port is ready we need to let them know that we are ready for data transfer for data transmission so well we are almost there by reverse engineering so we figure out

that the bts there would wait for uh an uncanny message we need to feed it the messages once again we hook the receive message functions and feed feed the message here's the definitions of the messages structure honestly i'm not 100 sure about the purpose of all those members of the structure i just know that it can kick off the bt stack um the beat here um blue bluetooth okay um so um so uh as we know we need our host controllers the uh we can port the bluetooth emulator or even use the physical controllers on the linux host that eventually we designed to write um a simple host controller the bluetooth hci protocol is relatively

simple in our case we just need to pay attention to a handful of events here's our snapshot here's a snapshot um if you look close to the source and and the destinations you can see that the hsi event is the response to the htc command command we need to repay the hsi event only so you might wonder why repaying well because we don't want to craft those packages that's kind of tedious and painstaking to replay you just need to pass the bt snoop packet file and create the htc commands with the hsi events please don't forget to update the hsi handle when repaying the package it's fine if you want to repay the hcl data

package but perhaps perhaps you need to do a little more passing um yeah wait we still need to uh tackle one more usual before bringing up the bt stack of the things when the program tries to create a shared memory of just under the temp directories i will thrill because the file system just doesn't implement the function so however luckily we are able to create folders in the fat 32 partitions so again um it's really easy to redirect the access with hooking again so here's the code we hook the shm open function and then if like the pass cont the password starts with with the temp then we simply direct it it died to our writable position

okay here's the demo shows how we bring out the bluetooth deck as we can see we have uh four pens uh payments here the top left depends was running the virtual machines and then we execute the command uh to launch the ss underscore launch process in the top right panes and which could bring out the service that the bit step depends on after that we start the virtual bluetooth hosting controllers which named the vhci um and after the the virtual host controller uh radius then we will bring out the bluetooth stack and we can see the virtual host controllers was rapidly outputting the logs of icci packages which means the bt stack was interacting with the virtual host controller

yeah we we make it finally

so um we founded two vulnerabilities in the british deck one have been awarded yeah the other one is still waiting for processing uh we also found some other hand harmless readout boundary about which we have not reported as they made no harms whatsoever uh and i don't think four will give a uh we also reached out to your fraud um one month ago for permission to disclose the details um we haven't received any response from fraud as of now so and the both tickets are still open so unfortunately we are not able to share the details of these bugs here this time oh that's kind of the pity and uh here's the final thought um

uh yeah definitely having a vehicle for researcher would be really helpful but it is not a match we found and verifying all the problems with only the virtual environment there are still many venues we can explore [Music] please feel free to dm us at twitter if you want to discuss or if you have any uh brilliant idea or that you want to share with us all suggestions are welcomed yeah uh thank you and uh please let us know if you have any questions yeah that's all thank you um so we were chatting beforehand before we got to the qa and i heard you have some updates for us uh yeah thank you everyone for listening

sir yes we would like to ratify our mistake in the presentation first the vulnerabilities in the absence was actually fixed in the late 2015 uh first improve the character filter which only allows the wireless characters so um as a result you won't be able to inject the cell command anymore but according to my analysis it seems the patch was not thorough i'm still working on the poc to see if the patch could be bypassed anyway the problems um have uh has been thoroughly patched by force inventories um since they changed they changed to the leap archive um we made the mistakes because we only use the command lines as the vulnerability indicator when we try to determine the

objective versions uh we apologize for the mistake and hopefully it had these clarifications could right oh yeah mean mistakes happen uh i'm i'm monitoring the discord so if you have questions in the discord uh go ahead and i can ask the speakers i've got some questions for them because i really like the content and the material so i'm gonna i'm gonna ask them so uh you know in your opinion what was what was the hardest part or maybe like what surprised you the most when you started uh doing this research both of you uh i think for me uh the most surprising thing is that it actually works um because like originally we didn't actually expect

this to work i mean like it's easy to like hack a car if you have a car right like or if you have like a workbench but like just having like a simulator is pretty hard to imagine i guess uh and also like qnx isn't like a normal operating system you use every day so it's like the infrastructure side on that isn't really great for support so like uh we hacked a bunch of things and yeah we got it to work finally that's like most surprising for me uh from my side i think the most difficult thing is that you you when we start starting the project we just could not foresee how many obstacles

are lying ahead so at the time at some points in the middle we just had no idea whether this is doable so as we we were facing so many problems and we just had no idea how much effort uh required to make work so that's that's the the most frustrating challenges we face in during the the research and uh regarding another things like you do not have a reference point if like because we do not have vehicle and then um if if like you have weaker you have reference reference points you could quickly do the debugging on the vehicle uh some sort of those things and then you know uh what kind of thing you are missing

but because we do not have that luxury then what we need to do is we need to do a lot of the reverse engineering and uh it require a lot of skills in the reversing ring you have to do the static reverse engineering to figure out how to how to make the thing work i think that's the most difficult yeah the most difficult thing yeah i think i just want to add a couple of uh synthesis on that so like uh there's like a lot of like state machines and like static uh lib compilations in there so uh if you have like a dynamic infrastructure uh like a car then you could easily verify if like

your reverse engineering results was correct but if you don't have that then like uh basically you have to guess or like just statically reverse engineering the whole thing which is like a huge complication for us as well yeah i can completely understand uh you you both mentioned that you've been working on this for a little while how long you guys been working on this before i think uh since we started the project it has been uh almost two years almost two years but it's not a continuous work at some of the middle point as i i mentioned that we do not have the confidence that this that did that this was going uh to uh gonna work so

we somehow um just play assigned and turn to other work and then later um we pdr again and just kind of those process start and go start and go start and go and something like that some sort of that kind of thing uh how did uh how did ford respond to their vulnerabilities so for the app thumb we realized that basically has been fixed in the latest version uh it's kind of a thorough patch so uh uh i and you know um according to their disclosure process on hackmon they said this kind of phenomena that require physical assets or men in the middle a man in the middle attack uh they they consider them out of scope

scope of scope so uh then even though if it affect the latest versions i think they will not accept the report there and then uh another for for the other of uh vulnerability i report for the uh the first one the uh the bluetooth one um then that it took them about three months to uh give a response and they said okay uh we confirmed the vulnerability and we are going to give you a bounty and for the uh and then for the second one um we report them and um they have not give any response and um yeah that's kind of intriguing and we also reached out to them uh for permission to share the technical details of one

month ago also as of now so we have not received any response from them great um this is really interesting research where can we follow you to um yeah we uh as you can see and the presentation week they're there there are our twitter so you could follow us so maybe uh uh we're going to publish the slides a little later yeah uh what's your twitter handles uh yeah twitter and those blue last uh how could i just simply type here at the i think at uh in the uh on the last slide of our presentations you can find our uh uh twitter name great yeah feel free to dms uh for any questions you have

yeah well great thank you so much for presenting it at eastside las vegas i really enjoyed this talk and uh thanks again thank you for giving us opportunity yeah yeah thank you yeah