Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2835 Thanks!
[Music]
and
today we have the maintainers of the AFL
Plus+ open source project on stage
Dominic TOA Andrea Edison and fouser
fouser
will show us how this engine can be used
with qmo to fuss binaries in a quite
Advanced way stage is yours
[Music]
thanks thank you everybody for being
here to our talk fuzz everything
everywhere all at once Advanced qimo
based
fuzzing um as we were just introduced by
where the AF Plus+ project um it's a
project we started in 2019 as a fork of
AFL which was the one of the
state-ofthe-art FAS back then since then
we've added a ton of community features
and we started a new side project which
is lip AFL which is a fuzer that is very
similar but Rewritten from scratch and
rust and today we're going to talk about
this lip AFL we're going to talk about
fuzzing in general and we're going to
talk about cimu and how to use it for
fuzzing in a pretty Advanced way if you
want to know more about libf and the
underlying uh building blocks you can
check out our talk back from 2020 when
it wasn't released yet um from
rc3 and uh let's let's get to it we've
already been introduced um with the a
plus project we are a large community of
people where five of them are on stage
and there are more doing you know on the
side work voluntary vulnerable
contributions um in this talk first
we're going to talk about fuzzing the
quick fundament Ms of about emulation
with qemu binary instrumentation and
then we're going to have two nice
examples one is snapshot fuzzing of an
Android library on a server that is not
Android on at course and then um we're
going to show how to add sanitizers for
injections like SQL injections to
binaries add runtime using
qimo right let's fuzz um fuzzing in a
nutshell at this time probably most
people have heard it at least um
stumbled upon it it's um just very
simple concept you rerun a pro program
multiple times with a lot of inputs as
fast as you can and try to find bugs and
try to find crashes or you know other
objectives like uh injections for
example later and then coverage guided
fuzzing is um an evolved version of that
where you basically track uh basic
blocks or edges during your fuzzing so
um some people may have or probably most
people have seen a CFG or at least if
you code some something you by by
accident create a CFG a control flow
graph in your program um for every um
Branch you either go left or right um
and sometimes you go back in a loop for
example and each of these things is an
edge in a control flow graph um and now
the fuzer can count how often one of
these has been taken and if it finds a
new one it'll use that as feedback and
favor inputs that led to New Paths so
it's like novelty search you try to find
new things and then mutate those further
and this makes fuzzing orders of
magnitudes faster of which just um no
feedback blind
fuzzing now let's see what we can fuzz
we can pretty much fuzz everything if we
can use Quick uh emulator qemu um it's a
very popular full system emulator that
supports a wide variety of instruction
sets you such as basically everything
you use every day um and it also has
user mode emulation support where you
don't emulate a full system you just
emulate one process um and all CIS calls
that would usually go to the host
operating system go to qimo and qimo
translates it to the current host and
that we can abuse to change the Cisco
Behavior later um how does Kimu work
under the hood if you use it in emulated
mode um you have the target binary it
executes one block at a time you saw the
CFG earlier it lifts this block if it's
not cached yet into an intermediate
representation called TCG tiny code
generator and then um it compiles it
back down or assembles it back down or
whatever you want to call it um into the
host um architecture so it would take an
arm binary block one block of code until
the next jump lift it and then drop it
back down for the next architecture for
the one we want to run it on right and
now the cool thing is that in the
meantime we had it in in our hands right
the emulator lifted it and now we can
add instrumentation there what exactly
is instrumentation it's altering the
behavior of the code um and that is
pretty nifty usually you do it at
compile time but um here we can do it at
runtime sweet now
Li um TOA is going to talk about this
part thank
you thank you thank you Dominic and I'm
going to introduce about libf our
framework a bit so we already have a a
state of the art fuzer which is called
A++ and indeed it does work it can't
find
bugs but sometimes the problem is that
you have a very special Target that you
want to write a customer fuzer that is
adapted to your very special Target but
the problem is that we you have a custom
fer when you write a custom
fer uh first you're Reinventing this
wheel you're going to write the same
code again and again that the past fer
has has written the same thing but we
going to re rewrite the same thing again
also those fer typ typically has a very
naive design for example usually you
just have a mutator that changed that is
changed from the past fer but the other
part of the fer is just the same like
the schedu or the other component is
just very naive also the skating is a
very hard problem which we'll introduce
later so basically uh the fs share the
data by F via file system which makes it
hard to scale across multi multiple
cores or multip multiple
machines so our solution is Li we adopt
some of the state of the art Fen
techniques including from the Academia
or or
industry our framework runs on portable
is portable it runs on some computer
doesn't does not have any St standard
Library also it is very extensible you
uh the users can write any kind of
modules to extend the existing Mo module
that we already have in lfl that is
tailor to your custom needs so it is
scalable it scales across multiple cores
the finally it is very performant thanks
to the rest the compile time abstraction
we benefit from uh the rust
language uh so here's is the high level
design of liel first we have the core
library library liel core and the LI
targets the WR time code that liing
their Target also the compile wrapper Li
CC and many instrumentation engines like
Freda or Q qmu
so apparently qmu is the most important
part in our talk we support we have
support for user and for system mode qmu
based on qm
8 and the point of uh Q emulation is
that sometimes the comp the source code
is not there and compiling the this but
when even if you have the source code
compiling compiling the code and dealing
with the tool change is hard so we just
have the we can just use the binary to
instrument the the program and fuz it we
can also change the instrumentation at
wrun time using qmu that is another
benefit of
it and we also have uh different another
advantages of qmu over other Dynamic
binary instrumentation engines one one
one of the advant AG is the cross cross
architecture support you can run any
architecture like mips or power PC or
arm on top of it and it's reason
reasonably fast while being stable which
is why we adopt qmu so nextly Andrea is
going to explain the details of libf
qmu
all so we want to F also
everywhere to F everywhere we need to F
we want to F some cant on another
machine another system on our for
instance desktop machine to do so we use
Li fimu and uh before showing an example
of uh from the Android library that
Dominic talk about before we need to
understand a bit the inner working of
Liu Liu is based on um changing the
behavior of the jet compiler of of quim
itself and uh it's based on some hooks
these hooks are the callbacks basically
that are inserted by placing codes in
the translated code of the jet so the
the code that it's it's the odd code
that is
recompiled uh by quu and these codes
call the callbacks in Rust that the user
wres to do instrumentation mainly for
login things that are using for for fing
in this case there are the hooks for the
edge coverage hooks in which a callback
is inserted at every edge of the control
for graph so we have these hooks that
the user can use for Edge coverage
instrumentation logging an an unique ID
and uh for the coverage for the coverage
map if you are into fing you know that
um we use coverage map and for the more
advanced people in the audience this is
the first case in which which we have
biner only fing with emulation with
unique IDs and so Collision freeze
coverage
map there are many kind of HS and
instruction blocks and memory Lo store
comparison but also like HS before and
after cisal to build cisal filters we
will say lat for scalability for
instance to crashes and so
on so another important part of the
design of our library our Liu is how the
interaction between the fuder and the
guas code is done the execution control
happens in three different ways one is a
with a back door a back door is like
a hyper in when we talk about
hypervisors is a custom instruction that
is not defined for any of the qu
architectures then the target itself so
when you write the Arness you also you
want to insert this back door
instruction and the target itself ask
the fer to stop the execution of the the
emulator and go
back to the fer then there are the break
points like classic points like in any
other DBI so the fer set a points in
which the execution to stop and then the
execution stop and the fer get back the
control and then the very nice things
that um we have are the custom G GDB
commands so you may know that in Kimu
you can use GDB to the buug the target
code and with the custom commands we can
the user can create uh commands to do
something like uh while the bugging the
the the get code like the user is the
bugging till one point and then with the
c on command you can say for instance
okay we reach in the debugger an
interesting position let's start fuzzing
from here from the
debugger so the next part is about U
it's a quick and small example how to
use Li F we took a a very widely known
library that is not um normal one let's
say it's running on another architecture
than our desktop computers and in
another operating system in this case
Android a Samsung Firmware in on arm 64
and uh this library was targeted in the
past for many different research in this
case project zero Target the image parer
this library curum that is an image
parer uh for the MMS exploit then
flunker did a talk on reverse
engineering library and fuding this
library with a custom fser so right we
have here this problem of writing custom
fers and uh at the real world CTF so we
follow the path of the This research and
we reverse engineering again this
Library taking the the function that
were F before by this researchers we got
into the uh interaction code between the
Java part and the image Library so the
bridge you know the not and ndk Library
part that is the bridge between Java and
the C library and so we building in C
removing all the Java and DK usage in
the in this Library we build an Arness
in C that is not this one this is a very
simple harness just to show but then we
have a more complex harness using more
API to decode the dng format parer of
the curam
library and then with this harness that
we built to show up the the capabilities
of the library to FS on Android Android
code we built a fer with Lial cre so
let's
just discuss this fer this fer uh is
running inside emulator the target
library in which there are some hooks
going on mostly The Cisco hooks because
we need to hook and block some Cisco and
replace the behavior or some Cisco to
make the library run on our system and
then also we grab the file system image
of the firmware of Android and we use it
to run to run inside cimu all the
libraries on which the Cur Library
depends
on so let's show a bit some code don't
worry you don't need to know rust at
this stage I want just to show the API
how easy is to load things inside reimu
so reimu it's a library no it's not Kimu
is is a tool Li Kim is a library so we
build this API around Kimu in this case
we start ulator we resolve the symbol of
the Arness and then we set a break point
and run until the Arness
then we want to also to set the break
point to the return address of this
function so we can Loop over the harness
because the fing is a I mean we can
describe in a very high level fuzzing as
a loop no and then we sorry we save the
CPU states to restore it together during
the execution of the Arness and this is
the Arness the Arness is executed many
time inside the fer so it's the thing
that is run constantly at every F case
and the Arness is a callback we get the
input generated from the fer and with
this input we save it to to a file
because the the librar is reading it
from file we run until the address and
then we roll back the CPU
state in this case we are Sams and there
are the helpers that are collection of
looks that are already available in the
library so you can write your own HS but
there are already like built-in things
in the library that you can use in this
case for Edge coverage and other things
and then this is the fs running on one
cord is very simp fer like few lines of
code plus the codes for f to set up a
fer and we have the fer running with a
decent speed because it's a very wide
library and uh it can find bugs but we
can do better we can do better building
a more complex fer how we can do
snapshot fing because like all not all
the code in the in the library or in any
other Target is stateful stateless sorry
so there are code that leave some traces
in the state of of the program that we
cannot restore just by restoring the
state of the register and the CPU we
want sanitizer to uncover silent
Corruptions I don't know double freeze
for instance and we want to scale not
just one
core so uh in Li quu there are some
there is around time built on top of the
Liu HS to do add sanitizer that tracks
the the locations tracks the memory
loaden stores and so on to like catch
the sent if Corrections much like I
don't know ven or dynamore or add
sanitizer and so on and then there is
this uh the ability of doing user space
snapshot and that are written from
scratch that which we use the memory
load store and the Cisco UK to track the
Dy pages when the memories change to
track the changing of the memory
mappings like if I don't know the
process start to a map uh random pages
and then we have to restore them if you
want to like continue fing and restore
the state of the program and so on and
this is a little demo of um the fser
running on 8 course that is started like
we can see the file system of Android
that we downloaded from the vendor um
website and um we set for quimo this
file system to be loaded so like we are
saying to quimo okay we have to grab our
dependent libraries from this uh file
system and then we start our fer giving
the images as a initial seed corpora the
output and the number of
cores and yeah it's running then after a
few hours we get this that the status
screen of the Kimu address sanitizer in
Kimu of a bug that we found probably an
old one and uh you get information stack
tray state of the regit and so on like
anything useful for crash
analysis so now uh after this uh Addison
will introduce you how we scale overc
our this specific example on Android
scale overes but also in general ourl
scale overcore
machines thank
[Applause]
you so to get started um let's talk
about actually why we need to scale in
the first place so um fuzzing on one
core is great that only allows you to
actually utilize one of your cores right
we have many cores available to us on
Modern systems so uh we would like to
use all of them the problem is is that
the scaling problem is quite hard um if
we don't share events between different
instances of the fuzzer then we will
waste a lot of time doing the same uh
thing over and over trying to find the
same code regions over and over
observing the new things over and over
uh the problem is is that communicating
between the instances necessarily slows
them down um as you can see here this is
a graph of the executions per second
over uh versus the number of cord cores
utilized and you actually what's amazing
here is that with old AFL there gets to
a point where you add too many instances
and it actually slows the global
executions per second down meaning that
you actually lose performance by adding
new cores and some of the reasons for
this could be um that we're just not
using very good communication strategies
um suppose that we communicate over the
disk when we sharing the new uh inputs
that we were trying to use um we're
using a network to send events between
them uh we're using intermediate
restarts to just reload the set set of
inputs that we have available to us
something else generally not very good
so what we implemented was something
called the low lower level message
passing algorithm which is essentially
where we have a centralized broker which
initializes each of the fuzzer
instances now what it does to do so is
it launches the fuzzer instance and then
opens a shared memory region with that
instance so that it can communicate um
bidirectionally so let's say that uh
fuzzing one fuzzing instance uh has an
event occur such as the discovery of a
new test case that increases coverage in
the program uh what will happen is the
fuzzer instance will send that to the
broker and then the broker will
distribute that to each of the fuzzing
instances all over shared memory meaning
that there's no kernel IO or any other
uh overhead inducing um operations
occurring and what this allows us to do
is that we can scale up dramatically
here you can see um the sections in
green represent the amount of execution
that's spent in userland in other words
not being used to actually interact with
the system and the red representing uh
kernel uh interactions that will slow us
down necessarily we're losing time not
actually executing the
Target and just to show you the results
here um we have two different uh
situations AFL on the left um which is
the historical data uh for AFL scaling
uh that I showed earlier uh versus uh
libf with llmp and you can see that Li
AFL with llmp scales nearly linearly
over ches um in in what this allows us
to do is we can write the same we can
use the same fun that we used previously
but instead of getting you know uh 5 to
8,000 executions per second maybe we can
get upwards of half a million um which
is great um so next uh I'm going to
invite Mark to come speak to you about
how to catch injection style
vulnerabilities using cumu as
[Applause]
well
yeah please thank you um why is fuzzing
so popular PO fuzzing is great because
it finds memory corruption
vulnerabilities and 80% of the critical
vulnerabilities are memory corruption so
that why fuzzing is so hip every wants
to everyone wants to do that and there
is a large focus on that but the problem
so far is we only find memory corruption
vulnerabilities with traditional fuzzing
like we do currently with AFL Hong fuzz
lip fuzzer etc etc so what if we could
find other type of books that we are
interested in
exploiting
that was so far very difficult we need
very different tools like for example
sqlmap to be able to find SQL injections
but they work on a web server that we
have to talk over the network we don't
have coverage there so this is very very
limited what we have with other kinds of
fuzzles that we can use to find other
kind of
vulnerabilities though the idea is
finding injection vulnerabilities why
doing normal AFL Plus+ lipf
lip AFL sty
fuzzing so how do we do that um
basically we are using lip aflq user
mode um and we use
Hooks and the idea is basically so super
simple that I was surprised nobody ever
thought about doing that before so
basically we just H SQL functions Lup
function um HTML output functions and
then we just check the parameters if
there's anything suspicious in there
which means
stuff that would create an injection
vulnerability that was not
sanitized and if we detect this well we
just crash and the fer picks it up and
we find an injection vulnerability so
it's that easy and the eded advantage
that I did in the implementation here
for lip AFL is we can customize it with
an easy
script so a picture to makes it a little
bit more easier to understand we have
the standard lip AFL lip aflq U um where
we run the
target scaled to 100 cores if we want to
with snapshot fuzzing and everything and
we just fuzz normally but we added hooks
to specific function for example for SQL
light for Lup to hook the system call
etc etc and whenever they are called we
check the parameters if there's anything
that would trigger an injection
vulnerability type we crash it and we
find this kind of
bug to make this super easy to
configure so you can use that on
anything and you could use it on CSV
injection vulnerabilities XML injection
vulnerabilities any kind of injection
vulnerability you want or even you could
do something like data loss detection
secret loss detection for example while
fuzzing you just configure it in a
configuration file where you say hook
these kinds of function it's the first
second or third parameter that you're
interested in this is the input test
that you add to the dictionary and then
you have a match value which is
basically if this ever comes up like
this in the quer parameter crash the
Target and we have found an injection
vulnerability that there are false
positives this is something we don't
like in fuzzing false positives are
unlikely to happen if you set up your
configuration correctly so with it with
the injection string and the match
string if you set this up correctly
there is basically no chance of a false
positive of course false negatives will
happen all the time this is dead AR box
that you're not finding that you're not
triggering but this can be the better
you set up your injection handling the
more of these vulnerabilities you will
be able to find and as I said there is
no limit to the type of injection
vulnerabilities you can it's basically
up to you to set it up and make it work
and we have lots of examples for command
injection um for UB injection for C
injection now which you can already just
deploy and use and we can find these
kinds of bugs by doing the to the normal
kind of AFL lip AFL fuzzing for memory
Corruptions with Q ason etc
etc here's a small example so um it it
test me file which has an SQL injection
and a command injection vulnerability no
memory corruption vulnerability I run it
with our Kimu f with the injections yamu
file where I have defined several Target
functions to to trigger and immediately
Tri finds the SQL injection
vulnerabilities and the command
injection
vulnerabilities it's really that easy
so yeah that's already it um for me I'm
the main AFL Plus+ developer not lip AFL
developer but even for me with very
little knowledge of rust actually
because I'm more a c coder it was super
easy to implement and that's basically
the strength that we have with lip AFL
now lip AFL is open source so join the
cult um we have so many contributors so
many other projects depending on lip AFL
to write their own customized
fuzzer um yeah what we showed you is
that basically with qemu we can scale we
can fuss we can detect even bugs that
are not immediately resulting in a crash
because of qazen for example yeah we can
rehost we can fuss Android stuff on our
systems or on a Mac we can hunt for
injection vulnerabilities and we have
massive speed with that and that's just
5% of the features that lip AFL has so
just 30 minutes of presentations but we
could basically do 5 to six hours and
still show you more features and how to
how to use our lib AFL API to build
successful and good
FS um yeah and I want to use this
opportunity to thank our team um
where where are seven people from five
countries um
and it's such a pleasure to work with so
talented skilled people and we were able
to well before Google was was uh
developing the three most best fathers
in the world but yeah we made it
possible that the best two fathers in
the world are now written by us yeah
[ __ ]
[Music]
Google oh and we have perfect
timing time for questions
indeed thanks
everybody so do we have any questions
what about the internet yes there is an
internet question
please yeah the internet would like to
know can Hardware crypto be emulated as
a peripheral in qmu and can lip AFL be
applied to the hardware crypto
CS you want to take
that hardware for protocols I don't
think you can use
um yeah you're right
but the couch was more
comfortable so Hardware protocols you
mean like um in the drivers of some
firmware operating system that is um
interacting with Hardware no so you want
to F software and interacts with
Hardware that is you can do even you can
f even Hardware like not withu maybe but
there are projects Bas based on by that
use that bridge the fers the LI API to
Hardware simulators and um
you can even fud the hardware but if you
can if you want to use Li to FUD
software that interacts with Hardware
you need to implement your own uh
devices the emulated devices on top of
qu and this is still uh or maybe you can
do re
hosting but like most of the time you
have to write coding to quu to like
allow quu to run your firmware that
using your
devices thanks then microphone number
one please yeah hi um how about symbolic
execution can you
repeat okay what about symbolic
execution have you thought about doing
that I mean there's this s2e of course
from eurocom from epfl they want to me
to ask
questions okay yeah lefl uh there are
modules for concolic tracing and it's
not um Liu cannot do symbol execution at
the moment I don't think we plan to do
do it with the quu it can be uh there
are some modules to use simu that is a
conc sec based onu but then you don't
have all the apis to do the Arness and
uh so it's not extensible like Liu but
in theory you can you can Bridge Liu fer
with s to do con tracing so con fing
thanks okay and let's switch to
microphone number two please uh yeah
thanks for the great talk uh you said
that one of the advantages is that you
can actually use uh or you can actually
change the instrumentation and at run
time um why would you use that uh or any
examples of that maybe for optimization
but like imagine that you know about
like there are some techniques in
fuzzing like you need to do some more e
instrumentation I don't know for
instance with CMP we track the
comparisons but also every function call
with two pointer arguments but we need
to do it just one time for each test
case in the Corpus so uh as this like
instrument every recall is more EV
weight than instrumenting Forge coverage
every comparison and every call we can
actually like flash the jit cache and
rate the code with the EV weight
instrumentation do our run with the EV
weight instrumentation at is take I
don't know 10 times more than normal run
for just Edge coverage then refres again
the Jet and instrument with just Edge
coverage
o so basically for optimization purpos
yeah optimization or I don't know
sometimes imagine you want we don't do
that I can Envision we could do I don't
know Sy conco fing and normal fing in
the same process just like flashing
the the cach with a symbolic hooks that
are more EV weight you instrument every
instruction and then you flash it and
new instrument for fing or something
like that yeah yeah thank you okay the
internet is curious
please yeah why use a full-blown qmu and
not a lightweight Fork built for it like
unicorn because unor emulates only the
CPU I mean we want to emulate processes
so system calls that and um then unor
also it's kind of slow like the benefit
of user mode quum is that you use the
mmu of the uh a operating system so you
don't have to imate the mmu dtlb is much
much faster to execute um the same piece
of code even if not doing any Cisco
interaction under Kimu user mode at
nigor and then also we Shar the code
base with a full system Kimu we full
system Kimu that was not part of the
talk but like is working Pro almost
finish actually we can even snapshot F
windows at the moment but like the AA is
changing is changing very fast so maybe
stay tuned for the next Congress for
another
talk
maybe and uh so the entire part also
that we share a lot of code in common
within user space as system mode yeah
when one thing to add to that like there
is of course fuzzing based on um unicorn
but the problem the moment you hit any
system call you basically have to
reimplement that and there like rappers
like sheing for example that basically
build a full system in Python then and
that obviously is really really slow in
comparison to just using the host
operating system uh to do these things
but actually you can use a li with
unicorn
okay thanks Now microphone number three
please uh yes uh thank you for the
presentation um in the past I have also
worked in automated testing and one of
the things that was like quite common
there is that we would run our software
on for example the core cors to find
bugs and because most of the testing I
know is just for memory errors I just
wanted to you know uh did you find any
interesting bugs with your injection
detection I just developed this in
December so um it's still work in
process so I contacted Google with the
OS esas environment they have to let it
run in their environment to just see how
effective it is now so to see how many
re bucket can easily find or not so this
will be something I will hopefully know
in
February yeah but the so um another part
is is that there there has been some
related work using um command command
injection and that has found several
bugs in the OSS fuzz uh framework one so
far only but yeah at least sorry no
several but this the system standardizer
yeah okay let's go back to microphone
number one please uh okay thank you for
the great talk uh I have a question
about the last part about finding
non-memory corruption
vulnerabilities uh the question is uh
often uh systems having such bugs for
example command injections are not
written in uh binary languages not in C
or C++ so uh and to far uh programs and
other languages we have to get the
coverage information right so uh do you
know some ways we could uh give the fer
the coverage information if we are
fuzing program written in python or
maybe in Ruby or in Java but that's the
thing you can already do that with cimu
Kimu doesn't care if if the program is
running and was written in rust or
anything else you just run it and for
command injection this is CIS call this
is Kernel you hooked the kernel call so
it doesn't matter if you run if you run
qemu on python which doesn't make much
sense but it would still work and you
would find the command injection even
there uh but uh if we are fing a ruby
program it's not compiled so we will see
the coverage for the no I got the
question like you have to instrument the
Ruby interpreter yeah so um that's
already been done like not Ruby
specifically but we've done this with
lib AFL for both Python and for
JavaScript in the past so it's very much
doable um and you can use something like
uh the instrumentation passes from
something like jazzer to uh get the
feedback for something like Java so
there are open source implementations of
that instrumentation right precisely
thank you okay thanks microphone number
two please okay thanks for the
presentation from from I'm interested in
the full system uh thingy I know that
there's
KFL which is uh on running on NYX and I
understand that the API is very unstable
I'm just asking uh whether you can share
the details just quickly are you using a
patched KVM or are you planning to
Upstream the patches because I know the
snapshotting thing performance wise is
not the best there's snapshotting of qu
system we don't use it because they use
a user fault ald that is very expensive
so like um another guy in the team is
riding a full system like dirty page
trugging that is more efficient and it's
kind of working now about few AG cases
we we are able to like f windows we do
it in emulation mode because there is
already NYX for kbm we may plan to reite
also the same thing of Nyx with the same
API in maybe in the future but what we
want to do now is emulation based fing
with because like for KVM there is
already NX and uh the fact that for food
system quu you are stuck to using very
old tools or tools like Panda that is
amazing but is based on pimu so like we
really need something for emulation for
firw fing for instance so like you want
emulation you don't want to use kbm you
want emulation because fwes are I don't
know meeps power PC and you want to F
them on x86 and uh like the full system
that is working progress that is almost
ready is about TCG and emulation so so
you're trading off uh a bit of
performance for more flexibility in that
way thank you but also n is there is NX
bridge and you can us be with NX already
so like you yeah I know but the setup is
very
[Laughter]
painful okay uh we're running out of
time for this session here I would say
hands on on this type of
[Applause]
approach
[Music]