They're hacking USBs now

The bugs we're talking about today are

really fun for a couple reasons. One,

they're super lowle. It's the name of

the channel, by the way. And two, the

way you exploit them is kind of like

what you see in those spy movies,

right? Where you stick like a bad USB

stick or like a bad SD card into a thing

and it pops the device. And I actually

got it to work sort of on my Flipper

Zero. We'll go into that here in a

minute. What we're talking about is

unpatched flaws discovered in the file

system code bundled into millions of

embedded devices. So if you're not

really aware of how file systems work,

right, there are different kinds of file

systems like NTFS or FAT is another one.

XFAT in particular for this video. And

to actually interact with a file system,

you have to have some kind of code that

knows how to parse and read and present

the files in that file system. Now this

library in particular is called FAT FS.

It is a generic FAT file system module

and you'll notice by the very um web 1.0

look of this that it's very old. Okay,

this is an old file system

implementation of both FAT and XFAT for

very very low-level devices. Again, that

is the name of the channel. So, when I'm

talking about low-level, right, what do

I mean? I don't mean like a Linux

device. I don't mean like an IP camera

like this because this runs Linux and

Linux has their own implementation of

FAFS that is not this version. What I'm

talking about is like super low-level

stuff like this, like microcontrollers,

right? This is an STM32F7.

Uh this is vulnerable on a lot of the

STM lines. And the reason is kind of

interesting. So the way that you

actually trigger warning uh go and and

make uh code work on these STM devices

is you have to use this toolkit called

STM32 cube IDE. You don't have to, but

it makes the process of assigning pins

to different functionality and

generating code for the IP stack and the

file system a lot simpler. Okay, the way

that these uh idees work is they go and

they pull code that already exists off

the internet like the lightweight IP

stack for maybe a TCP IP stack for your

embedded device and they also point of

this video happen to use the FAT FS file

system here that is written by uh

elmchan.org.

I have literally no idea who this person

is. If you want to learn more about how

to implement this stuff, I have this

tutorial that I found. I'll put a link

in the description below, but basically

it shows like, hey, if you want to be

able to use an SD card on your SKM

application, you have to make it like

this. And you'll see that there's um FAT

FS middleware. It's kind of this blob

that's just ignored third party library

referring to FAT FS, right? In

particular, what this applies to is the

Flipper Zero. These bugs exist in this

device because the Flipper Zero at the

end of the day is just an STM32 W series

W for wireless, right, for the uh for

the 433 MHz and sub gigahertz antenna.

Um, and so this bug applies here too.

Now, I keep saying this bug. What are

the bugs? Now, the bugs were found and

disclosed by this company called

RunZero. Runzero, I think, recently

acquired by Accenture, but it's founded

by the person HD Moore. HD Moore, if

you're not aware, is the inventor, the

originator of Metas-ploit, right? Like

kind of the OG learn to hack, learn to

exploit platform. And so, they disclosed

a variety of vulnerabilities, a variety

of integer overflows, stack overflows.

We're going to go into this one here in

a minute. It's very funny. Uh, long file

name overflows, unsigned, subtraction,

etc. I'm not going to go into all these

bugs. There's a ton of them. But the

problem that HD Moore kind of highlights

here that runs zero highlights is one,

the reason why these bugs are so bad is

kind of what I highlighted in the

beginning of the video. All you have to

do is take a fat file system that is

corrupted in a way that exploits the

vulnerability and how this library

parses the data and plugging in the disk

and having the OS or the system scan the

FA file system is what exploits the bug.

That's it. This is literally like circa

2007 Windows XP bad hacker drops USB

stick at the stuckset factory, right?

Like like that kind of Like that

is the the way that this bug would be

exploited. And guys, it's no secret that

big bugs like this can lead to big

hacks. And that's why today's video is

sponsored by Flare. Flare is an identity

focused threat intelligence system that

allows you to see if your company's

credentials are being talked about on

the dark web. Flare is actively scooping

up threat intel from a variety of

sources like 22,000 Telegram channels

and hundreds of millions of stealer

logs. Now, with this data, you can put

in identifiers about your company

through either their identifiers

dashboard or easy integrations like

their Entra ID. I like this one in

particular because you're able to

integrate either Entra or Octa or just

basic custom web hooks. You can pull in

identifiers from your current systems.

And from there, what you get is alerts

when certain identities get compromised.

So, here I have an account that I did

kind of a little test run on and it sent

me an email automatically when these

credentials came up in their systems.

Then I can go and remediate that issue

as fast as possible. I think I've seen

the quote from Crowdstrike that once an

attacker gets in, it takes only 36

minutes for them to compromise their

credentials in that network and it takes

an organization, a big, you know,

bureaucracy upwards of 48 hours to

respond. If you get notified when these

kinds of things happen, you can

dramatically reduce that time. Also,

Flare has recently added threat flow. It

is a threat intel feed that is curated

based on the events that Flare is

picking up. The offer to try this for

free expires, I believe, in 3 days when

I'm recording this. So, if you want to

get in, try it now. Anyway, if you're

interested in staying ahead of hackers

in cyerspace, check out Flare. Thank you

for sponsoring the video, Flare. Let's

get back to it. And again, it has to be

a code base that uses this

implementation of of the FAT file

system. Uh but, you know, even then,

it's it's not unlikely that these still

exist in the uh IT, right? Like the um

the power plant world, the water

management world, right? And what's so

scary about this is these systems rarely

get updated. They're very hard to

update. So, if this code exists there

now, it's unlikely it won't exist there

in the future. So, what are the bugs?

What are we keep saying the bugs? What

are the bugs? Well, one of the bugs is

an overflow in the get volume label,

right? So, when you have a an SD card,

I'm going to try to show it to you real

quick if it can focus. You know, this

represents a a a file system and that

file system is basically it lives inside

of a a device and that device has a

volume label. It is the name of the

thing. And as I highlighted before,

there is a buffer overflow in the

parsing of the get volume label. So, the

the library exposes this get label

function. And you use this get label

function to get the label of the volume

you want to look at. Right? And so what

you'll see here is we have the uh the

device the drive number that tells you

like which device are we talking about

and then we have the label output. So

you you give it the path to a drive and

it will output the label to this tcar

pointer, right? Uh and what it does here

is we have this directory here and what

we do is we mount the volume. We read

the label into a structure locally and

then what we're going to do is we're

literally just going to do this very

long for loop where all we're doing is

loading a word from that directory and

then we're going to put it as UTF. So a

a 16 byt code uh UTF-16 encoding at the

address of the label offset by the

destination counter. That is the entire

loop. What you will notice here is there

is no length check. we are not checking

against some end value that determines

that we've hit the end of the label

buffer. So this effectively is a stir

copy that lands in label. So the user

the consumer of this API does not have

the ability to say hey by the way can we

stop at 64 bytes. And so unfortunately

uh you know lier zero the the device

here uses that file system when you plug

in an SD card into this device which

I'll show you here in a second um it

crashes the device and as uh run zero

says the problem here obviously is that

any physical access to this device or a

device where this is vulnerable leads to

a jailbreak. So a lot of the times these

very very very embedded devices because

of like the hardware limitations and the

software limitations don't have modern

mitigations like ASLR right which

randomize the location of binaries so

you don't know where to exploit or NX

where you can't execute certain pages

that are writable at the same time as

executable right these devices that not

only don't get updates very often don't

have basic protections okay so by this

bug existing uh it's very hard for this

to get mitigated by the industry by the

way HD or actually published some proofs

of concept if you want to test this

thing locally on your own device. It's

called Vol's 2026 FAT FS Chance. I'll

put that link in the description below.

Uh I'm pretty sure a lot of these bugs

were found by AI, by the way, just based

on the way that the uh the markdown

files are named.

[music]

Perfect. Yes. Now

time to trigger [music] the exploit.

So you see we we got a bus fault here

because the the exploit overwrote the

program counter and I returned to

ox41414141.

That's it. I made a video where I

describe how AI and kind of why AI is so

good at finding bugs and you can find

that video right here. Go check it out

and we'll see you in the next one. Bye

guys.