hi everyone
uh this is samir from introfit control
systems
welcome to this talk uh about can about
fuzzing can and can
fd automotive ecu's and networks
uh fuzzing when applied to automotive
systems can make the systems
safer and more secure uh
i hope this presentation helps today
share some concepts and see what all
is on offer for fuzzing automotive ecu's
and networks
so this will be my agenda today i'm
going to talk about
these four items here today first i will
briefly
discuss what fuzzing is and why fuzzing
is already becoming
a part of standard verification and
testing
for oems and ecu manufacturers
in the second part of the presentation
we will discuss some of the techniques
and methods
uh for can and can of defuzzing and this
should be really interesting
for you know automotive uh you know
people are interested in automotive
world
third i will show how some specific
products from infrared control systems
which i have
used can help you with your can and can
have the fuzzing
needs these are the tools i have
primarily used
for developing fuzzing capabilities for
oems and clear suppliers so
this information will be also pretty
useful for uh people who are interested
in these areas
uh last i will discuss quickest way to
get
you know onboarding on can and kind of
be fuzzing
in you know for automotive ecu uh
software development life cycle
uh this has been a question asked to me
in various times in the past that hey
how can i start you know how
what is fuzzing you know what we want to
do so i'm gonna discuss some of those
things
uh as last part of my presentation
uh fuzzing concepts and definitions so
fuzzing as defined uh by
os for open web application uh security
project
is essentially uh this that's the
definition defined by os
so basically idea is to send unusual
malformed unexpected and error
induced data to the target dud
specific to the dut functionality and
performance requirement
a closed-loop control can then monitor
the duties
for any anomaly or any problems in the
duty
so fuzzing has been widely used to find
security issues
and bugs in iit software from actually
many many years
so the concept is not really new uh its
application to automotive is interesting
so that's why we we kind of you know
like to add
for you know to define what automotive
ecu fuzzing is
so it's a highly recommended last mile
test to reveal
uh any any possible
vulnerabilities in the network easy use
for can and can fd or there is a design
step or you know for can canopy design
strategies
or implementation and it performed as
part of product design development and
validation cycles so that's where
industry is going uh in our experiences
this does not necessarily mean that
tests should
only be done at the end of the design or
development and validation cycles
uh fuzzing essentially is now being
considered as part of a software
development lifecycle
and so it is even you know a better
strategy to include this testing
as part of milestone releases of
software uh during the entire cycle
uh and that is how the importance of you
know fuzziness is there for in
automotive
it's actually well understood fact you
know by we all of know
all of us know that you know it's a fact
of cost of fixing a bug
uh exponentially increases if discovered
later
in the development cycle uh in fact this
additional testing
uh may not be a large impact on the cost
you know and you know
people trying to assess hey you know if
we do can fuzzing you know kind of
defusing
uh you know and you know test you know
perform this kind of testing is it going
to be very expensive for me
uh so that's not entirely true the
impact on cost
is actually lowest if your existing tool
chains
support such testing and you know some
of the companies like ours like intrepid
we have recognized this
uh pretty early in the game and
this is alongside working alongside with
customers so today there are readily
available
tools for canon canopy advanced level
fuzzing
this means for existing users of such
tools
the adaptation is actually easy and
and for the new customers it is
something they can try to look into
for you know for advanced level of
fuzzing on cam and canopy
so let's look at you know some some of
the frequently encountered terms
uh and i'm gonna just you know uh you
know talk about
you know as a concept here uh these
terms actually are very common
in world of information technology very
common you know this is nothing
new you know and most of the audience
here i'm sure is very familiar with
these terms but the concepts are
important for people who are coming from
automobile world you know for
the things going on in the industry
right now so
let's look at these four you know
conceptual terms you know so to learn
what they mean
vulnerability so vulnerability is a
weakness in a system
so it could be for example a result from
a design deficiency
or an implementation bug a vulnerability
then
actually could be exploited to obtain
unauthorized access
to the system and and then affect the
system
one of the examples i can do is for
example an unsecured diagnostic code
or a weakness in a gateway module
which could lead to unsecured access to
an sub network ecu
that wouldn't be good right so you don't
want your
you know down down the stream ecu's to
be accessed through gateway
unauthorized so exploit
expert refers to an action that takes
the advantage
you know of a vulnerability an exploit
may reveal a behavior in the system
which was not a design or implementation
intent
in penetration testing we want to expose
maximum possible number of
vulnerabilities and exploit them
you know that's that's the purpose of
you know penetration testing on canon
canopy you want to exploit all the
vulnerabilities before
uh an adversary does it attack vector
attack vectors basically these are
mechanisms these are this refer to the
mechanism
and the targets or the paths an attacker
can use
to exploit a vulnerability so for
instance you know an exploit may use
an unsecured message vulnerability this
means the message on the pass on the can
bus is not secured
and so does it makes it it makes it
vulnerable
and it could use attack vectors such as
you know network management frames
or if there is time dependency of normal
mode transactions between the nodes for
correct operations
so those are the things a in adversary
can use
and confuse the network or even cause
problems in the in the safe operation of
the system in the car
attack surface is a set of attack
vectors you know essentially a group of
attack vectors you know identified
and uh you know they are loosely related
uh
to achieve an unexpected behavior in
in a in a duty or an ecu or a on a
network
so attack server surface is essentially
a group of attack vectors
uh you know which are kind of related
with each other for a specific
uh you know identifying an unexpected
behavior in the duty
let's look at fuzzing concepts you know
what are the objectives and what are the
definitions you know you know some basic
things before we get into you know deep
dive into more into automotive things
uh so fuzzing in information technology
has been prevalent for many many years
it's nothing new you know it's been done
there
uh many many times but with modern cars
in the complex eda's in autonomous
systems
they run millions of lines of safety
critical code
fuzzing is actually now becoming
extremely relevant for this
automotive manufacturers and we can feel
it being part of this you know community
working with oems and tier suppliers uh
with fuzzing essentially in the so my
talk here is gonna
you know kind of relate what it means
for automotive world
uh to do a penetration testing using can
fuzzy
so when with fuzzy we are challenging
the software design and implementation
through injecting most unexpected
you know semi-malformed frames
it's important to note this concept in
the terms for
automotive we do not want the frames to
be rejected at electrical level
otherwise it's meaningless the fuzzing
will be meaningless if the electrical
system rejects those frames
uh we do want this we don't we do want
to have
enough validity in canon canopy frames
for them to reach to the transfer layer
and ultimately you know to the
application layer and they should pass
they should go past the object layer so
it should reach the application
so we want enough validity around that
you know so otherwise uh the fuzzing is
not not much relevant
to can it must be noted that
most of such frames are still protocol
compliant you know when we are sending a
cam frame for fuzzing it's gonna be
protocol complex
and so this is what we call as
protocol aware fuzzy and in fact this is
most relevant to can technology
because can inherently in itself is
very robust at controller and electrical
level
and it has excellent fault confinement
so can itself is very well protected
so you know so what should be our key
objectives when it comes to
automotive fuzzing essentially first you
know uh
early identification of security gaps
and software parts
you know it's paramount to reduce the
number of field updates
because of software issues and bugs we
all know that because
you know they are not cheap they are
very expensive you know
and so for example to have an ota
or a photo campaign or their update
campaign for a bug
fix is really least desirable you know
nobody wants to
you know do an ota campaign uh to bug
to fix a bug you know that's not
something uh you know
ota campaign should be focused on ota
campaigns are really to provide new
features to the customers
there is tremendous need of testing
these ot updates before
they're deployed in the cars and that's
when the can and can fd fuzzing
is very important thus the
recommendation essentially
is to add the fuzzing first testing as
part of sdlc or software development and
release cycle
uh and automation tools are the most you
know
you know most important in this case
vehicle spy software is a good software
to
integrate the automation testing in
automated integrated testing for
running the fuzzer tests at every
release
cycle and that would be very prudent
to do this to identify security gaps or
software bugs
in the target ecu's or nodes and
networks
uh second fuzzing can be extremely
useful tool
to try to provide robustness to the
system level
validation or the system level fails
safe mechanisms good enough
against an adversary getting partial or
full control
of critical messaging between subsystem
nodes
that's why system level first testing is
also very very you know important
to be done third uh
idea is essentially again you know to to
look for vulnerabilities on can and can
fd
node and networks and before somebody
else finds it essentially you know
hack into your own network find out all
the exploits you know use all the
exploits
before somebody else does it uh and
so yeah that's that's one of the
important objectives
uh in automotive uh world for using can
and kind of defuzzing
uh lastly you know it's great test to
just test the network
and note performance against extreme uh
i would say unusual traffic you know
it's in itself it brings the robustness
you know
so you know adding robust robustness to
this in vehicle network performance
is extremely you know useful technique
and you know
that's why penetration testing using can
uh can fuzzing is
getting more grounds uh
let's look at uh some of the techniques
and you know methods
of how you can do can canf defuzzing so
i'm gonna
talk about few of them today and this
some of these come from our experience
working with you know a lot of our
customers
you know and you know doing some
research on my own
so i'm kind of sharing some of the
things which you know the
which is being you know practicing in
the industry right now
so let's become aware of some of the key
mechanisms when we are fuzzing
uh ecu's or can and can fd networks
can and canopy networks as i said are
inherently
highly fault tolerant buses uh also note
that
traditional automotive networks have
been
embedded device networks which have many
electromechanical sensing and actuation
systems
under their control thus the
identification of attack vectors
and careful identification of first
scenarios
is probably where the most focus needs
to be
you know we're to be very carefully
identifying all the attack vectors
because these ecu's control the vehicle
operation the automotive operation
and it's important to identify all those
possibilities for example you know
we all know about denial of service
situation
in i.t world but how do you define or
how do you can you can we envision a
denial of service situation
in the context of ecu cluster
or more importantly how do we design
fuzzing
so that we find all the vulnerabilities
before an adversary fines
on an ecu cluster so some of the methods
and techniques uh
which you know we could look into is you
know uh
are here so for example uh it's
important that we
thoroughly study to identify all
possible attack service surfaces you
know some of the examples i can give
is focus on payload data
bytes for example the payload the
content itself of the frame the payload
which is going to be consumed by
different nodes uh frame priorities
you know those are based on the
arbitration ids on can
so can we see a situation where
a design was dependent on a priority and
an adversary attack changes the priority
of that frame critical factors
like dependency of internal ecu
algorithms
on for example a periodicity of frame uh
with
needed data such as these are the things
you know we need to look into and
identify and study
you know if is my algorithm totally
dependent on a you know fixed frequency
can data
and can the adversary attack that and
affect the algorithm
and make a wrong decision in the car
these are good pointers to direct your
first test
and to cover all the you know aspects
some of the mechanisms which would be
useful uh
include monitoring the nodes for their
abnormal outputs
and such as you know like through
diagnostic queries you can query the
diagnostics
or you can stimulate the ios for example
and then observe the response on the
network
while you're conducting the fuss or the
first test serving run
in ecu world you know getting a feedback
from the system
is the key to make sure you know the
fuzzing actually
use the relevant results out uh
classical pervasive definitions in
fuzzing like uh
like generational techniques uh there
are generation techniques there are
uh there are mutational fuzzing there is
you know randomization
so for example in generational fuzzer
new frames
are actually created by the first tool
that's the concept in generational
fuzzer you know where you generate
the two the new new frames from the
first tool this means an intelligent
fuzzer
uh can establish a
closer relation between generated first
frame
to the normally present frames on the
network and that's an important concept
to to deceive a system the frame should
appear to be very normal
but carrying you know causing abnormal
effects on the bus
so thus making such injected frames
they have to be more valued from the
duty perspective
uh this kind of protocol aware fuzzing
is actually most relevant for can or can
fd nodes
uh in that i've been talking about that
you know in this presentation
uh mutational fuzzing also needs
to be protocol aware uh when it comes to
applying applying to automotive networks
you know that is not that much relevant
when it comes to
for example i.t networks for automotive
networks even the mutational fuzzing
you know technique needs to be protocol
aware
so how do you do that you introduce
minute variations in the data
through automated mechanism uh in a tool
in automation and you inject those
minute variation of the data
on the bus and so essentially
uh to see whether the relevant nodes and
ecu's
understand and can take you know write
actions uh when the data is not the real
data
but looks like real data uh with
randomizer
for example a unique it's a unique black
box you know
technique uh where you can realize
you can realize the first frame can
really create totally
agnostic uh situation to the you know
arbitration ids or dlcs
and you know you can in the
randomization you can actually on the
fly
switch between canon canopy frames to
see
you know how the reaction is from the
network
and there are tools like vehicle spy and
you know there are hardware tools from
us you know we have family hardware
which allow you know they're very
helpful in realizing
you know random randomizer for fuzzing
let's look at some more techniques here
as i mentioned before
it's important to understand if the duty
response is valid
or is it invalid or unexpected or
abnormal you know
so in automotive world rest bus
awareness
is the key you know how is the rest bus
behaving how are the other nodes
behaving when i am
for example doing a mutational fuzzer so
it's very important to get the
feedback from the network you know
another important aspect is what is
called as
what essentially it's a new phrase you
know phrase which is
you know quite decent is perpetual
fuzzing so this again comes from the
automotive concept
you know in perpetual fuzzing this means
the first
testing is a part of your development
life cycle
uh in these fuzzing configurations
improv
can be continuously improvised by adding
uh
more and more unusual scenarios one
aspect of can and kind of defusing it
is you know it's conceptually that these
tests
actually do not directly depend on the
duty
i mean duty specifications and
requirements do not
affect the can first test this means
first
first test could be independently
created as issued
to apply to various different duties uh
some parts of such first test mechanisms
as feedback measurement may only need to
really change depending on what ecu we
are talking to
for example if it's an abs ecu i could
measure
its performance differently than if it's
an airbag ecu
i'm going to talk more about this you
know you know more about vehicle spy
software
which has capability to run uh first
test
uh you know first test execution engine
and the measurement engine
in parallel you know that's the key for
vehicles you know that's the key which
i've seen in vehicle spy software
i should be able to run my fuzzer
execution engine
in parallel to my measurement engine
that gives
uh that gives very good control on
on the tests and this remains i think a
critical feature
for successful capturing of the failures
lastly a thorough consideration is
needed
if duty is a gateway device and you'll
see a lot of gateways these days you
know
new network architecture has you know
ota updates you know so there is a
generally gateway module a telematics
module uh and a gateway module and these
are very special
characteristics we you know i have had
experience and we have you know
tremendous amount of experience working
with gateway modules
for very complex scenarios and testings
and these gateway modules have special
character
characteristics like photo or
firmware over the air updates or if it
could
it could be like a telematics ec or a
v2x ecu's
in these scenarios uh fuzzing could be a
lot more complex
and and it may require
to run your first scenarios across
multiple of clusters
or networks at the same time because
gateway module connects to maybe let's
say eight subnet
sub networks and it's important to be
able to monitor all of them
while you are attacking the gateway
module for your first testing
so in such cases the response monitoring
also requires
pretty advanced setups because you need
you could have a downstream ecu on a
sixth scan network
misbehaving because we did the first
test or we did the first attack on the
gateway module
uh so these are all the things uh
happening in the industry and you know
i'm
i'm happy to share with this community
here my concluding observation
on this particular part is fuzzing for
automotive is more design oriented you
know
to be effective it has to be design
oriented there has to be design idea
behind how we want to first simply
sending random
frames without like a closed loop
control and without the ecu behavior
aware monitors may not necessarily yield
desired outcomes we need to minutely
observe what ecu's are doing what
network is doing when we
perform this fast testing
uh but the technique itself is doubtless
in the industry now you know is required
you know for the for the robustness of
the vehicles and the you know
uh the performance of the vehicles in
the you know in the field
uh you you know you finding a single
vulnerability
of in a post-production environment when
vehicles doing on the road
it's very expensive to update it's very
expensive
and it could be you know a safety issue
for
uh for people
uh with here you know i want to
i have spent a lot of time working on
you know interpret vehicle spy
tool and i want to share my experience
uh
in using this tool for can fuzzing uh
this this mostly this tool you know use
it has been used you know i've been
using this tool with automotive oems and
tier suppliers to you know see
you know how how they can first their
networks and ecu's
yeah so interpret you know has created a
set of tools and a framework
the framework is pretty involved
framework where you know uh
you could set up a bench for a feedback
loop mechanism from the ecu
from the duties and you can perform
extensive fuzz
frame injection and execute the first
tests on these networks uh
so some of the advantages which i have
seen uh for
from using uh vehicle spy and neo vi
family of hardware
is that vehicle spy has a ui driven
fuzzing engine
this means even associating a complex
complex test script with the first test
doesn't require
like a whole team of python programmers
you know that is the benefit i have seen
our customers using and you know
myself using it for my own fuzzing
research
uh you don't need like tons of script
creators or programmers you know
work on creating this you know thousands
of scenarios uh which you can easily
create
in automation uh and in in the
in the perspective of you know
automotive all of these things
must sit well with the current
verification valid
valid validation teams uh they need to
be onboarded immediately with this
you can develop a whole team who just
does the cam fuzzing
so vehicles fire allows those kind of
capabilities
in the tool itself and interpret
you know we as a company have been doing
automotive networks for i think almost
26 years now
and you know although ems have been our
customers we've been working with them
from years so
we have i mean we have applied all that
extensive experience
working with ecu's and networks and you
know building high-end you know
high-speed fpga based tools
in our tooling for fuzzer is also
designed totally around automotive ecu's
and networks
one of the biggest factor for
automotive ecu's fuzzing is diagnostics
you know diagnostics
is also an integral part of an ecu and
also an ethical part of vehicle spy
software
so while you're fuzzing you can do your
diagnostics on the diagnostic channel
and query the ecu at the same time
you can also essentially uh
fuzz the diagnostic channel itself
and that's the beauty of you know some
of the things which we have done with
the you know
our customers so
we the native support for a transport
layer is already there
native support for obd or worldwide
harmonized obd is already there
uh some of these tools are already
supported in vehicle spy and we were
able to leverage
all of that for our further
with inherent capability in these tools
for multiple channel fuzzing
is very important if duty is a gateway
node i do want to monitor
all the subnets at the same time you
know in the same
you know in the same context when the
same tests are running
at the same time the tooling also need
to be able to simulate
some of the rest bus behavior because
you know
some of the ecu's depend their operation
on the rest bus being perfectly fine
else it's going to shut down its
transceiver if it shut downs it
transceiver we are not going to be able
to fuzz anymore
so we have to kind of keep the ecu awake
to a certain point where it accepts our
you know first frames uh developed and
then you can attack the ecu so
rest bus simulation is also extremely
important when you're fuzzing so
remember that you know if your network
of ecu's make sure
you have also the capability to make
sure the issues
are awake and you know you simulate
the rest bus behavior to make them
active enough to accept
our frames and
at the same time there is also support
for measurement you know
of physical quantities or physical
signals and ios for example i want to
see
if the ecu went through a running reset
you know i can measure
the current on the on the on the battery
life
i can measure how much is the voltage
drop across a certain point
across you know certain connections on
the ecu
so all those capabilities are also
important when you're fuzzing on
automotive
networks uh
some of the other features which i have
used in the tool in
you know in vehicle spy is uh i was able
to generate you know
thousands of test cases from uh
the database files and this process
itself
if done manually could really take
months and you know months
of you know efforts by team uh but
vehicle spy
allow allows to create automatic signal
attack
from the dbc file you know and you can
create various different generational
fuzzing test cases
so you can generate any kind of frames
you want uh
and you know for mutational fuzzing you
can make a small variation
in the payload as an input of the duty
try to override the real data
and then you you do these minor
mutations minor variations
and uh you know see what how it goes and
vehicle spy has a lot of
inherent capabilities i found and i've
been using
to support extensive test design around
mutating known inputs
and uh that's a very powerful use
in vehicle spy the few other types of
fuzzer techniques like randomization and
some other techniques are very unique to
vehicle spy if you know
you end up using it you know feel free
to use those
uh you can you can give your own seat
for randomizer
uh you can have a vehicle spy generated
you know there are many various other
things possible in this
software one other thing i found is
support for database and i just
you know i did mention a little bit on
air xml supporting ar xml supporting
dbc's
for automotives are extremely important
because that's the real way
of being actually be able to affect the
performance
of the device or the ecu's
uh again you know the classical question
i've been always i had to add this slide
just to make sure you know
how you actually do all these things you
know seeing some pictures
you know helps understanding what can be
done you know if you're design you know
you're thinking to do you know
interaction testing on can
uh what are the actual things i'm gonna
do so how and where one could start with
can
and can fd fuzzing for production
vehicles or ecu's
or your bench networks you know so you
could start with some of these products
you know they're available in the market
you know so vehicle spa enterprise plus
for example
is the software which has full fledged
support for can fuzzing
you could uh uh you know you put nearly
a fire too again the device here
you know uh has eight can network so you
can
uh simultaneously you know fuzz devices
on eight
can networks you know so this is the one
you know i typically use this one of my
favorite two
and uh so it's widely vegas five has
been widely used in automotive software
development for more than you know 20
years
so our focus remains on the customers
and you know all the capabilities you
see in maker spies
because we've been work working with our
you know customers for a pretty long
period of time now
uh about neo via fire 2 hardware
uh this has a multi-channel can can fd
and in fact
it also has support it also has
uh which i also use very frequently is
it has inbuilt data logger
what that means is if i am i'm fuzzing
in the vehicle itself
i can record the entire traffic in an sd
card inside the device
and if i happen to cause an issue in the
car
uh shut down the car or put it in you
know for example lymphoma mode or
what have you or caused some multiple
you know uh
dtc's then uh you can record everything
in the device itself so you have the
least latencies from recording on
windows
or you know other pc or other mechanisms
so fire2 remains very useful device for
in vehicle level fuzzing and also
actually bench level
uh this year intrepid also launched our
latest you know platform agnostic uh
very advanced tool that we call it it's
real next generation tool uh
and it's like advanced automation and
testing for in-vehicle networks
uh it's called vehicle spy x you'll hear
a lot about that
in uh in this event and
so i was also asked a question hey you
know
can vehicle spy be used as can first
tool you know and i'm going to answer
that
in you know the next slide
so i summed up a lot of information
i collected a test i did with you know
working with the customers you know
internal bench level setups and
things like that and here is uh you know
my compiled information
and i think you know it's available for
you guys to use it
and i compared the current capability
support in
three different situations you know i
didn't do a lot of open source tooling
myself but this is the feedback i get
from you know
you know from the engineers using open
source tooling and methods to do fuzzing
on automotive
and so i'm gonna go through some of
these things uh with you guys here
and uh so
so the support for like dedicated can
can have the fuzzing support so i
my observation is it's a it's low in
vehicle spy x currently
uh open source tooling is really you
know
limited and it's exceptionally high in
vehicle spy 3 enterprise edition you
know it's really exceptionally high
because
there is a set of tools which are canvas
tools
uh for scripting i've seen python
support we have very powerful support
for python in basic spy
x and uh and you know of course the open
source truly use python extensively and
they use other languages in other
programming environments
in vehicle spy 3 it's a ui based
scripting engine called function blocks
and you can also do cc plus plus
programming
inside vehicle spy for scripting as far
as maturity i have seen very high
maturity
when it comes to vehicles piping
enterprise again for canon canopy
uh and for fuzzing you know like how
much automation is there how much
support native support is there
so for vs5x it's under development you
know because
and automatic generation of first
scenarios is right now not supported in
vehicles by x
but it is fully supported in vehicles by
three enterprise edition so you could
generate thousands of thousands of test
scenarios
possibly through a single click and
again i was told you know
that in vehicle spy x the team is going
to use the same
technology in vehicle 5x in upcoming
releases
now air xml bbc support very powerful
support for you know in vehicle spy
x and vehicle spy 3 enterprise edition
uh i haven't seen
really very native support in you know
there is open source grid project to
read a dbc file or a xml
but being able to put like you know
zeros across entire payload for
all the received messages in a single
click you know that kind of support
lacks in open source tooling uh
programming flexibility and development
very high i would say in vehicle spy x
because you have full control on
each layer independently
through programming environment through
api calls through
you know different layered
you know call through using python so
very very much
very powerful very programmatic
programmatic in this
in vehicle spy x i have seen the same
thing in open source tooling because you
have really a programming environment
there is nothing automatically done
there you have to develop everything in
in vehicle spy 3 there is limitation of
not being able to use python
but personally i'm a c programmer so i'm
happy with you know vehicles by 3.
uh automotive native protocol support
like xcp uds or autosar etc they're
fully supported
in again maker spy 3 and there is a
reasonably good support in vehicle spy x
but again like you know
looking for a uds based support in a
open source environment is kind of
difficult
and complex to create in itself so i
have not seen much support
on that front report generation we have
very good support in fact in vehicles by
x
uh there is a good support in vegas by
three this is again you know
i would say this is a area where we are
focused
and like i seen both of these tools you
know next
next releases will bring a lot of you
know test reporting
uh like potential for a tool to be part
of the development and design uh
scenarios uh vehicle spy
x is defined you know designed around it
you know you could actually
run your first test in your development
pipeline
through using vehicle spy x uh in all
those
capabilities will run in the pipeline
while
you are actually developing your ecu's
this means you make a change in the ecu
software and your first test could be
run
on in the pipeline on vspy x and test
out
in all your first scenarios so this is
very
this is an exceptional support for this
uh to be able to do that
and i've seen very there is almost
negligible support for that in vehicles
by three
this you still have to do drive through
a text api or something
uh in your pipeline so i would say the
support is low here
cost wise uh both the tools have a cost
uh but i think you know
as i say you know bang for buck and
that's highest for bspi x
because in future you reduce the amount
of time your validation team is going to
write first spss or run the test cases
and look into the results all of those
things we are going to eliminate through
vspy x for future so it's a good
investment now
but of course you know that's why i
listed all the things here you know
based on what
where you are what your scenarios you
are going to do
and based on that you could choose one
of these mechanisms to
do your can buzzing uh one thing i
should talk about is the os support
vehicle spy 3 only supports windows so
if you are running your
uh for example virtual ecu which you
want to fuzz
you do want to go for vehicles by x in
that case because you know we support
vehicle spy x runs on linux mac
or windows at the same time oh i mean
all three oss
are supported uh
hopefully this is uh you know this may
help knowing what capabilities are
available now in different ruling
and how you know industry is doing
they're fuzzing and what are pros and
cons
i hope this presentation was useful to
learn more things
for you guys and well that's
it from me now for now i think this last
slide of my presentation
and thank you very much for your time to
listen this
if you have questions you know uh just
ask me if you have fuzzing experience
you have worked on
you want to share with me you know if
you found a issue in the ecu let me know
i'm very excited to know all about that
you know and just share your experiences
with me my email id is here and if you
have more questions on some of these
products i work very frequently
then just send me a message thank you
for your time