Elise: So, making the magically past NVIDIA's secure boot
chain and breaking some Tesla autopilots along the way.
As a disclaimer: there is a lot of information on some of these slides.
On those slides, especially the ones with both code and text,
reading everything is not needed, but it may be nice to pause and
read if you're following along at home and want more information.
So, who am I?
I am Elisa Amber Katze, I'm 22, I like doing security
research on embedded devices in my free time.
My interest started back when I was 14 and had a Nintendo Switch, but
no interest in playing games on it, and then when the Fusée Gelée demo
came out, I touched my first line of C and I've been interested since.
Here's a teaser of what we will cover today.
The photo shows a demo of code execution inside the boot ROM of a Tesla Autopilot.
These Autopilot units are still in cars today, being driven around.
So, how did I get here?
Let's take a step back from the Autopilot for now and move to XR headsets.
Magic Leap, a company producing XR headsets dropped support for their
first product at the beginning of the year, pulling needed servers
offline and effectively turning the devices into paperweights.
This is morally wrong, and I fell down the rabbit
hole of trying to get code execution on the device.
More specifically, we will cover how code execution was originally gained on the Magic
Leap 1, named sparsehax, how persistence can be gained, named dtbhax, how the Tegra X2 boot
ROM was obtained, and a previously undisclosed set of
boot ROM vulnerabilities which together form rcmhax,
how exploiting it was attempted and finally successful,
and then at the end, if there is time, rcmhax will be
demoed on a Tesla Autopilot. So, what even is the Tegra
X2 anyways? It's an SOC designed by NVIDIA that was
released in 2017 as a follow-up to the Tegra X1. The Tegra X2
is used in less well-known but still interesting devices such as
the Magic Leap 1, which is the XR headset that started this
journey, the Tesla Autopilot, specifically Revisions 2 and 2.5,
NVIDIA's Drive PX2, which is their reference Autopilot
hardware, Skydio X2, a military drone seemingly still
actively used by the U.S., the U.K., Ukraine, India
and New Zealand, and countless other kind of boring
to me industrial applications. Here's a rough
diagram of the boot flow. It begins in the boot
ROM on the boot and power management processor, which
from here on out I will refer to as just the BPMP.
The boot ROM loads and validates Micro Boot 1 from Flash.
Micro Boot 1 is an encrypted blob provided by NVIDIA
that OEMs are seemingly not allowed to inspect or
modify. Eventually, code execution ends up on the
main CPU complex with Cboot, the final non-standard
bootloader, which is where we will start. So, first
exploits, sparsehax. The Magic Leap 1 supports flashing
firmware over USB. There was previously a fast
-boot-based web USB tool provided by Magic Leap.
The partitions are signed and those signatures
are device-unique. The keys aren't device-unique,
rather the data fed into the hash function when
validating the signature has the device's serial
number appended to it. Smaller partitions are uploaded in one go, but larger partitions are
packed in a sparseFS image and uploaded in chunks.
This means there's an unpacker reachable over USB,
which is a really interesting target, as unpackers
written in C are so often unsafe. As expected,
it's incredibly unsafe. There is a memcpy exposed
where the destination buffer is on the stack,
where the attacker can control the data copied, and
the length of the copy, which, well, stack smash.
So, it's trivial to smash the stack using this, but
there is very little information about where our
bad sparseFS image actually is in memory. We can overwrite the return address on this stack,
but what do we overwrite it with? NVIDIA released
the source to Cboot, and whilst Magic Leap clearly
have modified it, the original sources show that ASLR is not used, which is a good start.
It also shows that the heap must live after the
Cboot binary in memory. Given where Cboot lives,
and the maximum size of our bad sparseFS image,
there's a maximum of 64 attempts needed to brute
force the address of where our image gets allocated,
and this should be deterministic, so we only have
to search for it once. This worked. It proved to
be deterministic, which meant we now have reliable
code execution inside of the bootloader, but even
with code execution inside of Cboot, we still didn't
have a way to copy out the Magic Leap modified Cboot,
and this was wanted. There was no simple way to
read it out, because the addresses of the USB handler
functions were unknown, and at the time it was
also unknown where the UART test pads were on the Magic
Leap one. Reboot timings were consistent down to 15
milliseconds, though, which raised the question, can we exfiltrate data via reboot timings?
The answer was yes, it was just so very slow.
Reading out a single 0xFF would take 25.5 seconds,
giving an effective worst-case speed of 0.04
bytes per second. Leaving it to run did eventually
give the start function, which contains a snippet,
to zero the BSS segment, giving us the start of the
BSS segment, this part down here, and using that
and calculating the time it would take to read out
all the data between the start of the binary and
where the BSS segment began, at the worst-case speed,
that would take 224 days. A friend of mine plotted
out the time per byte on a graph, showing that it is
fastest to read out data a nibble at a time. This
lowered the time needed to 30 days, but, well,
who has time to wait 30 days doing nothing? So
another solution was needed. So at this point,
I wanted to try and find the USB functions at
runtime somehow. Compiling the unmodified upstream
cboot showed some mov instructions of magic values,
either in the needed USB functions or in their callers.
Searching the binary in our payload for these
instructions, whilst also masking away the target
register worked, allowing us to find and directly call
the USB functions at runtime and then just read out
cboot over USB. And here's an image of the exploit
running successfully and the payload meowing back
over USB. Quick recap. We now have tethered code
execution inside the bootloader that runs on the
main CPU complex, but this is only on devices where
a signed firmware update for that specific device was
archived, because they are, sadly, device unique.
An untethered solution would also be nice, though.
Second vulnerability, dtbhax, also in CBoot. The
function inside of CBoot for loading a binary
into memory from flash has two paths depending on
which binary is being loaded. It either allocates
a buffer on the heap or it uses a buffer at a fixed
address in memory. One of the binaries that gets
loaded to a fixed address is the kernel DTB. It gets
loaded into memory, always slightly behind CBoot.
And it just loads the partition no matter the size of the partition.
Making the kernel DTB partition larger than the
flash and writing a payload into it results in cboot
overwriting itself in memory with our payload,
leading to persistent code execution inside of it.
So now we have persistence inside of cboot using
dtbhax whilst using sparsehax as the original
entry point. I really, really wanted to look at the boot ROM still, though.
That means the boot ROM needed to be obtained.
So here are some facts about the boot ROM.
The boot ROM is mapped into memory on the boot processor at a fixed location always.
Only the first 0x1000 bytes of it are readable by
default and the rest of the ROM can be revealed
by adjusting an MMIO register. But this register
is only writable before secure mode is exited and
the boot ROM clears the secure mode flag when it exits.
Looking at the readable first 4096 bytes of the boot ROM
reveals a debug loader that takes a payload via UART
and doesn't exit secure mode before branching to it.
However, this path is only taken if a certain fuse is not
blown, and that's only the case on NVIDIA internal devices.
This is an ideal target for doing voltage glitching
on, though. If it enters the UART boot path,
we can just adjust the register that controls how much of
the boot ROM is visible and then send it back over UART.
The boot ROM has no glitching protection in
software, but supposedly the TX2 does have hardware
protection. It was certainly still worth trying,
though. So, voltage glitching. I assume most of you
here know roughly what it is, as it's a really
common attack nowadays, so I won't explain in depth,
but for anyone who doesn't know, you essentially
just drop the voltage for a very small amount of time
to induce miscalculations or faults in a processor. Too
long, the processor resets, too little, it behaves the same.
Just right: miscalculations, such as taking a branch that shouldn't have been taken.
This debug loader also exists in the Tegra X1 Plus,
and an attack had previously been attempted on this
last year with an RP2350, so the code for it was
already sitting around and should just require small
modifications to work. Except it didn't. Leading it overnight
didn't bring anything. So, capacitors try to provide
stability during fluctuations in voltage, so
desoldering capacitors for the power rail that the boot
processor is on should help. First, some of the
capacitors were removed, but this changed nothing.
Then, the rest of the capacitors were removed.
Still, it did not solve it. At this point, though,
a friend helped debug the issue, and it was due
to the voltage still not dropping low enough,
so a second MOSFET was added. And now it enters
the debug loader. The next step was just sending a
payload that sent the boot rom back over UART. And
now we have the boot rom. Here is the mess of wires
that was used for performing this attack. They
don't want you to know this. You can always just jam
wires into the connector of a system on module. It
just works. So, adding on to the recap from last
time, we now have a copy of the boot rom. Now it's
time to reverse the boot rom, which was also not
secure. Rcmhax consists out of unpatchable vulnerabilities in the Tegra X2 that can be used
to reliably gain code execution at the highest
privilege level in the boot rom, even on secured
systems. There's issues in both the boot rom, but
also in the USB controller. But first, it's useful to
talk a small bit about the current memory map.
For this chapter, all pointers are only 32-bit.
The boot processor has its own local memory, which can only be accessed by it.
The boot rom uses it mostly as shared memory
for interacting with peripherals such as the USB
controller. And importantly, and very annoyingly,
SysRAM has a different virtual address in the boot
processor than its physical address due to constraints of the boot processor. The first
vulnerabilities used here are in the receive loop
for the USB function, the USB function of the USB
recovery mode. Here is the start of the function.
The destination pointer argument is a fixed address
near the end of SysRAM. It initializes some variables and has some constants defined.
And then here is roughly what the receive loop
looks like, where there are two issues present.
Let's walk through this loop quickly together and then
I will leave it for a minute and then the problems
will be revealed. So inside the loop at the very top,
it requests from the USB controller to read up to 64
kilobytes to the destination buffer offset by the
total amount of bytes that have previously been read.
Then if a header has not been received yet and now
more bytes have been read than the size of a header,
it passes the message length from the header. The
message length is bound checked. And as a hint,
these bound checks are correct. Then if the total
amount of bytes read is exactly equal to the length
specified in the header, the loop exits. If they're
not exactly equal, it goes back to the beginning of
the loop to receive more data. I will leave this
here for 30 seconds or so. So has anyone spotted the
issues? Here they are. The first one is that it always
requests a fixed amount of data from the USB controller,
even if the remaining amount of data to be read is
less. And the second issue is the loop condition.
It uses a not equal comparison rather than less than.
So if we send a message in a single packet that is
larger than the length we specify in the header,
the loop condition always remains true and it keeps
trying to read more and more data. Theoretically, this
lets us write way more data than we should be able to.
Theoretically, at this point there was a small bit
of disbelief. A small proof of concept was written
and it behaved as it was expected to. It was
possible to write way more data than specified in
the header. Way more. More until the pointer had
overflown and had looped back around to the USB data
structures sitting near the start of SysRAM resulting
in the USB controller dying. But wait, there's no memory
at a lot of the addresses that were just written
to. Yet the USB controller did not raise an error.
It just kept on going and going and going, telling the boot
ROM it had successfully written the data it had received to
those addresses even if it hadn't. And, well, as
previously stated, this means we can overwrite
data inside of the start of SysRAM, which is mostly just
used by the boot ROM as shared memory for MMIO devices.
What's our current write primitive? So we can
write to arbitrary memory from the USB controller,
but it currently only has access to SysRAM. In
order to get code execution on the BPMP inside of
the boot ROM, we need to pivot and we need to gain a
write from the BPMP itself somehow to access memory
local to it. One of the peripherals the boot ROM
communicates with using SysRAM as shared memory
is the USB controller. Each USB endpoint has
its own ring buffer and the ring buffers contain
16-byte sized data structures called transfer
request blocks, which from here on out will just be
referred to as TRBs. There are four different types
of TRBs used by the boot ROM. Data, status, normal,
and link TRBs. And we will look at that final one
now. So, what is a link TRB? Link TRBs are located at
the end of each ring buffer and they contain a
pointer to the next ring buffer for the same endpoint.
They allow chaining together ring buffers across
multiple allocations, but the TX2 boot ROM just
keeps a single ring buffer for each endpoint. Thus,
the link TRBs just point back to the start of its
respective ring buffer. The boot ROM, however,
still passes these link TRBs, so we can overwrite a
pointer in one of them. Then, after passing it, the
boot ROM should queue the next TRB at a pointer of our
choosing. So, if we can control whether boot ROM
queues the next TRB, this is a write primitive but with
serious limitations. We cannot control the data the
BPMP writes. It is just a TRB. We can also only do this
once and only with the control endpoint. They forgot
to raise an error on the control endpoint when the
read of the TRB fails, but they do raise an error
when it fails on the other endpoints. But still, this
is a write primitive. No matter how limited it
is, it really must be workable into arbitrary code
execution somehow. The obvious approach now would
have just been looking if we can overwrite some
return address on the stack, as some of the TRBs do
contain pointers as the first 32 bits of the TRB,
but this fails for multiple reasons. Firstly,
mapping out the stack contents by paw reveals that
none of the return addresses are aligned correctly
on the stack for us to be able to overwrite them.
Secondly, all pointers in the TRBs written by
the boot ROM contain physical addresses anyways,
so even if the BPMP jumps to one of them, an exception would just be raised.
There are also some pointers in the data segment
for dynamic dispatch of the USB functions, and
one of them is aligned correctly, but overwriting
it also fails due to the address in the TRB
being a physical address. Writing to some MMIO, it's
also not an option, as the memcopy writes byte by
byte, and the devices accessible via MMIO require
32-bit writes generally. Quick sidetrack. The boot
processor inside the TX2 has a patch controller. It
allows overwriting what data is returned when the
boot processor fetches from certain addresses.
It's initialized with data read from fuses that are
only burnable still in the factory. The idea behind
this is to avoid having to change the data stored
in the mask on the chip when something in the boot
ROM needs fixing, and rather just change the software
at the end of the factory line that is responsible for
burning those fuses. The simplest way of using it is
to fix a mistake like this. Here we have an assembly
routine. It takes a password as an argument,
and if the password matches the developer's very
secret key, it reveals all of its inner secrets.
However, the observant among you would see that
the developer set the branch condition incorrectly.
This function actually just reveals all the inner secrets when the argument is anything
but the very secret key. The patch controller can
be used to just patch that one, blxne instruction,
and there. With the patch controller, we fixed this
mistake. It now only reveals its deepest secrets
when the value matches. But what about more complex
situations where, say, you need to insert more
instructions in between? In these more complex
situations, a hooking-based approach is taken.
Where hook should be inserted and instruction is replaced with a syscall instead. A syscall
handler stub is copied into the BPMP local memory by the boot ROM during initialization,
and then each hook-based patch implementation is read from
fuses and copied after the syscall handler in BPMP local memory.
It's essentially just constructing a switch
statement. But this means there are some instructions
sitting in the boot ROMs local memory, and that is
RWX. This is what the syscall dispatcher looks like.
It reads the syscall number, it multiplies it by 2, and it does a
relative branch from the end of the step to the result of the calculation.
And it does all of this using just R0, R1, and R2. So what if we patch the patches?
What if we overwrite part of the syscall handler with a TRB? Could
this work? There is a hook-based patch used in a control request
handler in the recovery mode implementation. And when
this patch is reached, there is also a sysram virtual
address sitting in R0. If we can overwrite the 16 bytes in the middle of the dispatcher
to be three NOPs and an instruction that clears
R1 somehow, it will branch to a sysram address.
Can we encode three NOPs in something to clear R1
using a control TRB? Actually, yes. Specifically
with a status TRB for an unstalled endpoint. If we
treat it as instructions, it is three NOPs followed
by an instruction that clears R1 if the zero flag is
set in the CPSR. And as luck has it, we can ensure
the zero flag is set when execution gets here. With these bytes of the handler overwritten,
the handler now dispatches entirely differently.
The dispatch logic is now branching to the syscall
number multiplied by two, added with the value in R0, which in the patch in the USB stack,
is set to a sysram address. The resulting address is also still a sysram address.
To be very clear, that's now a branch to memory the USB controller can write to.
So, putting this all together looks something like
this. First, we write a single packet containing
the RCM header, with the length in the header
being smaller than the size of the packet we send.
Then we write enough data that the pointer overflows
and loops back around to the address where the
control endpoint ring buffer is. Then we overwrite
the link TRB to point at the syscall handler in
the BPMP's local memory. Then we need to overwrite
the other USB data structures after it without killing
the USB controller, as we need to place our payload
a small bit after them in sysram. Then we write our
payload. Then we request an endpoint to be unstalled so
a status TRB gets written to the pointer we specified,
which overwrites the syscall handler partially.
And finally, after sending the control request with
the patch, our payload should now be executed inside the context of the boot ROM.
Now this will be demoed on the Tesla autopilot. Sadly, you can't see the
output whilst it runs. There was no extra connector heret to plug the
laptop into, but it will be seen after it runs. So
first, in order to get it to enter the recovery mode, I
need to short a test pad to ground. The test pad
specifically is one of the data lines for the QSPI flash,
which is here. And that just corrupts the data read
out from the QSPI flash, so it enters recovery mode.
Next, I have to... so there's a mean chip somewhere
on the autopilot. It watches for the TX2 to boot fast
enough, and if it doesn't boot fast enough, it just
issues a reset. I don't know why this is the case,
but it is the case. I guess there was maybe problems
with getting it to boot reliably, so this was some
hacky workaround to solve that. But this is a problem
for us, because it takes around 100 seconds for the
exploit to succeed, because it writes just over 4
gigabytes of data at USB2 speeds. However, this chip,
it dies from too low voltage way before the TX2
does. So, I will make it enter recovery mode again,
because the chip reset it and took it out of recovery mode. And now I will turn the voltage
down from 11 volts down to something a bit more
reasonable. Let's say 7 volts. And maybe I can
pull my laptop into view of the camera there. No,
that does not work. Well, I will start it now and
it says that it is sending the data to it. Yeah.
Now you will all have to patiently wait with me for
these 80 more seconds. You can imagine how much
pain debugging this was when every single attempt I
had to wait 100 seconds. 50 seconds. 30 seconds. 15
seconds. It's getting close enough that you can all
join in with me again in the excitement of watching
this. And my payload crashed. I promise you all,
this is my payload, not the vulnerability. It should have worked. It's just a skill issue.
Yes, it also doesn't start up if the voltage is too
low. Okay, if this is going to be so temperamental,
how about we try this again later if there is still time? And for now, we go back over here,
where the thing can be watched and try it on a different
Tegra X2 based device. So the first thing with the
magic leap is there is no way externally to get it into recovery mode without opening it up.
However, if you hold down the volume down button
and press the power button, it enters into fastboot.
And there is a fastboot command that resets it to
recovery mode. I think I cut it out of the talk
due to time. But as part of this, a fastboot
implementation was rewritten in Rust. And that's
what this reboot forced recovery thing is. It's not
in standard fastboot. And there it enters recovery
mode and we see if it is nicer. Whilst we wait. I
mean, the weather was better today at least. There
was no ice outside. Let's go back to the slides
whilst this runs and go here. Here's a quick recap.
So we started out attacking an unpacker for the
sparseFS that was available over fastboot. With this,
we gained execution in the main CPU's boot loader.
Then we gained persistence via another vulnerability
in the main CPU's boot loader. Now we have gained
code execution at the highest privilege level in
the boot ROM of the boot processor. But what's
next? There are more vulnerabilities in the Tegra X2
that just aren't disclosed here due to limited
time. One of them is in the boot ROM, also allowing
arbitrary code execution in certain cases, which
is confirmed to be patched in the Tegra X1 Plus.
And similarly, rcmhax, it's also patched in the Tegra X1 Plus. They fixed that check.
Another is in microboot 1, which is confirmed to be patched in, at the very least,
the Orin, which is the one used in the Nintendo Switch 2, whatever they named it.
And it reset. It worked. Hi NVIDIA. Meow from the TX2
bootROM. Here is a SHA-256 hash of the secure boot key
of the Magic Leap 1 headsets. These are not device-unique. These are manufacturer-unique.
And here is 0x200 bytes of the protected boot
ROM. In here, you can see that NV Prod Boot T186.
That is a version string that is only available in
the protected part of the bootROM. And any of you who
have been following switch hacking in the past remember when Fusée-Gelée was first released.
This is the roughly same snippet of the boot ROM that was
in the Fusé-Galais demo, but instead of the T186 there,
it was T210 for the Tegra X1. With that successful, I
will turn this off so it doesn't start speaking to me.
We can go back over here and see if this wants to be nicer now.
Get long nails, they said. They're pretty, they
said. And it should be in recovery mode again.
It is sending. 100 seconds. I will not bore you all
again by waiting for this with nothing else to do.
If there are questions, I could start taking the questions now whilst this runs.
Herald: Wow. Thank you, Elise, for that awesome and entertaining talk.
Yeah, if you have questions, please, we have six
microphones in the room. Please line up at these
microphones. In the meantime, we can take the first question from the internet, please.
Signal: Yeah, so there is a question about the reset if it
doesn't boot chip, if it might be a safety feature
that was actually required for the use in cars.
Elise: So, I don't have an answer to that. I don't know much about
car safety regulation. The autopilot was not my original target. It was just
collateral. And yeah, the turning the voltage down
to see if it did anything was just a prayer. And it
worked. I don't have a better answer.
Herald: Microphone three, please.
Audience: How did you make the choice on which
voltage glitcher and what voltage glitching method
to use? Because there's like a hundred boards out
there, all purporting to be the best. So, how did
you choose which one was best for your use case?
Elise: By not wanting to spend money on them and wanting
to do it myself. So, I just bought an RP2350 and
went at it writing it myself in Rust, buying
MOSFET, soldering it on, trying it until it worked.
Quickly, before anything else. It was nice. So,
I would also like to say these wonderful beings
here provided me help throughout this in multiple
ways each. Labeling them each with specific ways
which they helped would be difficult because they
all helped a lot. I would not be speaking to any of
you right now, if any of them didn't exist or
didn't help. So, thank you very much. If there are
any questions that come up after this talk, feel
free to email me here or directly ask if we run
into each other around Congress. Here, this Codeberg
link has all of the code needed to do everything
in... Oh, not everything. That's not the glitching
stuff currently there. Everything but to the voltage
glitching stuff is in that repository. If you have
a Tegra X2 based device sitting around at home
that is your own, you can perform these attacks
on them yourself. You can run the demo payload. It
*should* just work. If there are more questions, I am
happy to take them now. Otherwise, that was it from me.
Herald: We have 10 more minutes for questions and microphone five, please.
Audience: So, first of all, kudos to your research. It's awesome. Just one question. Did you
report the vulnerabilities to NVIDIA?
Elise: Nope. I would like to elaborate on that more than just a "no".
So, A, the Tegra X2 is end of life. As of the beginning
of this year, they're not producing more of them.
B, they seemingly were producing more of them before that
time. At least it sounded like they were still producing them.
Maybe I'm wrong. And this is no...
This is no accusation. I don't have proof. I don't want to make it seem like it is as such.
It may be as just a coincidence, but in the Tegra X1
Plus, the SOC used in the revision of the Nintendo Switch,
not to be confused with the Nintendo Switch 2, uses
the newer bootROM. It is using the same bootROM base
as the rewrite used in the Tegra X2. And I've
confirmed that it's patched there, but I have not
seen a single Tegra X2 in the wild, which has this patched. Not even in fuses or anything.
I didn't see a reason to report it. Plus, I'm
sorry, NVIDIA is the largest company in the world.
Pay security researchers if you want your products to be safe. It's not my job.
Herald: One more question from the internet, please.
So, there was a question how long the research for this talk I took.
Elise: So, it's hard to quantify time in this. I first touched the Magic Leap one at some
point last year, when everything was still online.
Not this Magic Leap one, a different one that I
destroyed trying to decap one of the chips whilst
having had a bit too much Tschunk, and it slipped.
I lost interest in it fairly fast. I moved on. But then at the beginning of this year,
shortly after Congress last year, after speaking
about it with a friend, I picked it back up again
and started looking at it. For fastboot hacks, I had stuff done within three weeks, at most,
of starting at it again. No. Two weeks. It must
have been at most two weeks. I strongly remember
what was going on in the day where I successfully got
the meow back from the fast boot. Everything else,
it was up until maybe quarter three this year I was
working on it. The longest part by far was getting
the code execution inside of the bootROM. I found the
vulns. It was not mentioned in this talk. There is a
simpler way to use the vuln to get code execution,
but it results in you no longer being in secure
mode inside the boot ROM, and I was not satisfied
with that. So I ignored beings telling me that is
enough. I never implemented that. I kept going
for two months, maybe, until I got what I wanted,
which was code execution inside of the boot ROM with
it. So I would say maybe half a year to slightly
longer of working on it in my free time.
Herald: Microphone two, please.
Audience: Hi. Regarding the fastboot
implementation, I am also working on one written in
Rust, which I found from somebody else. I saw that
there is only like five or six or something, like
Fuchsia has one. How did you implement yours? Did you
write it all from scratch, or did you take parts from
somewhere else or something? Because I happened to
find them a bit finicky at times. Did you run
into issues there, like weird stuff in the spec or
something, which was not really complete?
Elise: So yes, for weird spec nonsense, I didn't actually base it off of
anything like, except the spec and reverse engineering,
the CBoot and the source code from it, from NVIDIA,
so for the upstream one, that was it. With spec
quirks, yes, magic leap violate the spec of fastboot,
but that was no issue. Just ignore the spec.
Audience: Thanks. That confirms my findings.
Herald: Mic five, please.
Audience: Hi. Have you tried to see what the implementations would be for the Tesla autopilot?
Um, have you tried this on any vehicles, or have you like just messed around with it?
Elise: If anyone here or anyone watching has a Tesla, which is with this, please.
Audience: I do have one, and I have FSD paid by the previous owner.
Elise: Hey, my email address is there.
Audience: Okay, I will reach out.
Herald: Microphone one, please.
Audience: So given the fact that for the first two exploits you mentioned,
you do need an archived version of the firmware, which is device specific,
do you see or did you find any way where you might be able to, through the boot ROM maybe,
get code into the actual operating system and upkeep the usability of the device?
Elise: Me? No. I did what I wanted. I then, yeah. However,
M3gagluk has been working on the Magic Leap 1 stuff and
has been working on it for a very long time and
maybe eventually things there will be released,
but that's nothing to do with me. That is entirely from M3gagluk.
Audience: Okay. Thank you.
Elise: One second. What is that around your neck? I see an XR headset.
That may or may not be an ML1.
I thought so. I was looking at this like it looks so similar.
Audience: Yeah. I came here and sat in the front row specifically because I wanted to be here to
show it off. I'm going to be completely honest.
Elise: Thank you for coming.
Herald: I think we can fit in one more question. Microphone one, please.
Audience: So you said that all of these vulnerabilities were
fixed on the Switch 2. Do you know if any of them
affect the ipatched but non plus X1 Switch 1s?
Elise: The Switch 1s do not use the bootloader here,
which I'm sure you know, but I don't think many
beings here do know, so they don't. The RCM vuln no, it's using an entirely old version
of the boot ROM. This is the first rewrite of the boot ROM and it has this issue.
Something, something, there may be some other
issue in the USB stack that I have not implemented
a thing for. I'm not sure how feasible exploiting
it would be. Definitely not without something else.
It exists. Maybe someday there will be something,
but by itself no promises. Maybe it's fixed in the
orin. I don't have a copy of the boot ROM, but given what it is, I would guess it isn't.
Audience: Sad.
Elise: Yeah, truly.
Herald: Unfortunately, we are out of time for more questions.
If you still have any, you might be able to find Elise around this great event.