I'm Josh Thomas, Monk. We're going to get started. We're going to have a lot of fun today, I hope.
A couple of intro ratted to the talk. I made a drinking game and then I got really lame and I don't have anything to drink on stage.
But if you do and want to play around, this is Ricky. Ricky likes to drink. If you see Ricky, take a drink.
He'll come up a lot. So this talk has a couple of phases, but before I even get started with the actual talk, hands up if you run Android.
All right. Keep them up if you actually have your own kernel, own ROM. Okay. Did you actually compile it? Okay.
Did you ever look at the source, like any source at all? Wow. Okay.
All of it? Yeah. So you have no fucking clue what's running on your phone. We'll come back.
Even if someone was in the room and was like, yeah, I looked at every fucking line. No, you didn't.
Sorry. And we all know that. But this talk is going to play with what you don't know about what's already running on your phone.
So start. I wanted to skip this because personally I really don't like these slides.
But.
Given what I'm going to be talking about, I guess I needed a little bit of background, so why you should trust me.
Don't. If this makes logical sense to you, thank you, man, then believe me, if not, have fun with the tools I'm going to show you.
These are my opinions, not my employers. And the tools in the second half of the preso are really, yeah, they're fun, they're playful, they're offensive, whatever.
The whole point of me open sourcing them is we don't know these type of tools exist.
Let's learn about them.
Let's learn about these tools. Let's figure out how to protect against them.
I'm not really talking ODAs. We'll get to that in a second.
And I'll get on a tirade.
But this is post-ODA, post-X.
Like, I'm in the system.
We as a community don't really ever look at that type of persistence and how to protect against it.
So I'm going to show you how I as an attacker would do things.
And then maybe we can all start figuring out how to protect against me.
So I'm going to talk about boring-ass things.
And then I'm going to talk.
I'm going to talk about the actual war games that we're going to talk about today.
And then we'll go through a couple scenarios on my tools and what they do.
And then we'll wrap up at the very end.
So, boring kit.
I hear malware. I hear root kits.
I fucking think spam.
It's boring. It's really, really boring.
It makes money.
You know, someone wants to pop 50,000 boxes so they can do something.
Blah, blah, blah, blah, blah.
It's boring.
It's boring.
It's not interesting at all.
But hackers love the malwares, right?
Because with the malwares, you can get the credit cards and then you can buy all the things.
Again, fucking boring.
So, it is, right?
I mean, it's not innovation.
There's nothing new.
It's normally not actually anything sexy at all.
It's just iterative, boring.
You don't have to do anything cool because you don't really care if your bots get popped, right?
I mean, that's not the point.
You know you're going to lose them.
You know you can just pop another 50,000.
Next month, it just goes back and forth.
Everything is disposable.
No one is specifically targeted.
Boring.
If you want to know more about that mentality, Mudge did a great keynote two years ago.
Pretty much everything he's talked about since then kind of talks about that symbiotic relationship and how that's boring.
Whatever.
Our real fun.
For every game, we need rules, right?
So, what do we need?
We need two players.
We need game mechanics.
And we need goals for a game.
Player one.
I wonder who player one is.
I'm going to go with player one is any government worldwide, any state-sponsored organization.
So, you're talking people with a lot of money or corporations with a lot of money.
You know, bad guys, right?
Maybe more bad guys.
Prepping for it.
Maybe more bad guys.
Player two.
So, we've got a lot of money on player one.
Who's player two?
Fucking you.
And you.
And y'all.
That's pretty cool.
So, in this game, when we start getting into mechanics, yeah, we still need O-Days, right?
Because we actually want to pop things.
We're starting to target people for some reason.
So, we still use O-Days.
But really, that's just the gift wrap.
I don't know.
I mean, that is disposable.
No one cares.
Well, a lot of people care, and I'm trying to get you to not care so much.
What we really want is we want to get on devices.
That's the only reason we use O-Days.
O-Days are not the real point.
They're disposable.
I'm going to spend money on an O-Day to get on your device to then do something interesting.
But, because everyone likes O-Days, and I'm saying it a whole bunch, how much do they cost?
Do they cost money?
There's the grug.
With more money.
And, fuck it, more money, right?
So, Rick Ross is happy because there's a lot of money.
But, I mean, again, you may spend 10, 20, 30, 50K, 500K, a million on some really sexy O-Day.
Remember that number.
A million.
We'll pretend that all O-Days sell for a million.
Every single O-Day is a million dollar O-Day.
I want to hack all the things, so I need all the O-Days.
I don't really care about laptops anymore, personally.
This is where it's at to me.
It's all mobile devices.
It's all cell phones.
They have everything.
I can listen to all your calls.
I can read all your e‑mails.
I know exactly where you are.
I mean, it's obvious.
This is now what used to be our computer.
This is now us in digital form.
We carry them everywhere.
We use them for everything.
Oh, if you're targeting him, Symbian O-Days are actually still worth a million dollars.
But, fuck it, right?
Like, everyone raised their hand.
I don't care.
I'm Android.
I'm special.
There's no exploits there.
Sure.
Unless, you know, I had money, at which point ‑‑ so we've got game mechanics for this type
of world.
What we're really doing is we're taking an O‑Day, we're jumping on the device.
So what I care about is that kit, whatever that implant is I'm putting on a device, that
is ‑‑
that's where the real money is.
That's what's doing something.
And I mean, let your minds run wild.
What would you want to do on someone's phone?
You know, whatever that is, that's what you're doing.
Doing that type of coding is boring.
Those are just lame‑ass developers in cube farms cranking out code.
It's typical software.
It's boring.
It takes dev time.
People have a real job.
But it costs money, too.
Typically, it costs a lot more money than an O‑Day.
Typically it costs a fuck‑ton more than an O‑Day.
As I mean, think about it, if you're trying to do something sexy, a million dollars for
an O‑Day, $20 million for whatever you're going to do.
Which do you not want to lose?
Especially if you know when you bought that O‑Day it's got a shelf life.
What you really, really, really care about is protecting that large investment.
Not this disposable thing that you bought that, I mean, you know maybe around two months,
maybe around six months.
So we get a little more disturbed.
That's okay.
What do we want?
We want all the data.
That's what your cell phone is.
That's what I want.
I want everything.
So we've got all of our players.
Let's have a game.
Who's going to win this game?
How long is it going to take?
Very, very, very short.
And I wonder who won.
Yeah.
They won.
Every time.
No one is even remotely capable of writing the tools right now that can detect against
advanced things.
Because we're not looking at it.
We're still focused on malware and spam and all the boring shit.
So if I'm writing $20 million worth of code, I want to protect that investment.
I want to protect it lots.
I want to make sure that it's never found.
I want to make sure that it's deep.
It's not something that's going to pop up on McAfee.
It's not something that's going to pop up on the New York Times front page that we found
X doing Y.
Like, this needs to never, ever exist.
So again, because we kind of picked on him a little earlier, he, the Gruck actually
does talk about quite a bit of these things, at least on the theoretical thing on Twitter,
which is always kind of fun.
But.
What we don't want is we never want our gear to show up because that will make Rick sad.
And we don't want a sad Rick.
We want a happy Rick.
So we're going to hide.
We're going to hide deep.
We're going to have a lot of fun hiding.
Before I move one definition, because I just tend to say it and I've realized that not
everyone knows what I'm talking about.
So if I say air to glass, what I mean is I'm coming off.
CDMA, GSM, Wi‑Fi, I don't know, I'm coming from somewhere, Bluetooth, outside of the
phone.
I'm getting on the phone.
Air to glass means I never touch storage.
So I've got an implant, it's in a device.
You reboot that device, it's gone, right?
It's got to be reinfected.
If you do something like that, though, you're pretty damn secure on the protection of your
investment because unless someone can forensically jump in there and grab things out of, like,
RAM, volatile memory before they reboot, you're safe.
The problem with air to glass is, I mean, you never know when you're going to lose your
implant.
That sucks.
And you've got limited space, right, if you don't want to start interacting and being
obvious that there's something wrong with the phone.
So we're game one.
Let's move away from air to glass.
How can I get something on disk and hide it to where no one can find it?
So this is the NANDEX project.
This project was originally funded by DARPA's cyber fast track, awesome, awesome project.
The goal of this was, you know, how can I do a proof of concept for offensive work and
then how can we take that and try to defend against it?
So I'll do my demo.
So I'm going to run the demo twice on video and then once at the beginning and once at
the end of talking about it.
So.
What we have on the ‑‑ ooh, is it not showing up?
Cool.
So what this video is going to do, yeah, I'm basically side loading a kernel module,
which we'll talk about and look at source in a second.
But this is going to kill a block on NAND.
So I've got an image.
This is an implant that's actually on disk, it's saved on disk.
Now I'm going to remove that block of memory from the phone.
I can still call into it.
But it doesn't exist.
DD won't pull it.
Forensics tools won't pull it.
It's just gone from typical devices.
I show this twice because I just really love how sexily Android crashes here.
So we're side loading a kernel module remotely.
And I'm forcing a kernel panic.
Or a kernel thing as well.
And we reboot eventually.
And the block of memory is just gone.
Now I've got 512K I can play with for as long as I want.
How do I do this?
Sweet.
How NAND works.
Let's start there.
So NAND is very complicated.
You've got little bitty buckets that hold an electron.
If there's an electron in there, you've got a one.
If there's no electron, it's a zero.
That's basic binary.
That's how this hardware works.
EE's decided to say, hey, these little buckets that hold one bit need to be organized into
pages.
Those pages are then logically created into blocks.
Blocks are pretty easy to deal with.
It's what you're normally dealing with if you're writing drivers at a block level.
It's easier to latch onto for us.
It's security and software guys, right?
So blocks typically half a meg.
When you wipe a NAND, everything gets set to ones.
The reason everything is FFs is there's an electron in every little bucket.
Then when you're actually writing data to NAND, you start popping electrons off.
You get a zero.
So you kind of sculpt your data in NAND.
But that's trapping.
Trapping individual electrons is hard, right?
So the hardware wears out.
It dies over time.
I'm taking advantage of that the same way that the designers of the hardware take advantage
of that.
What they do is they know it's going to die.
They know it's going to die after 10,000 to a million writes, that little bucket.
So they build in tools to gracefully fail.
They have a threshold of I can detect so many bits aren't writing when I want them to.
Once I go past that threshold, that block is marked bad.
It's never used again.
The kernel doesn't see it.
The driver doesn't see it.
It's just there's a bit that gets flipped saying I am bad and it's never touched again.
Anything that goes through the driver, the very first thing in the driver code goes is
this block bad?
If it's marked bad, the driver just says no, it's not there.
So that's handled in the bad block table.
Which ‑‑ yeah.
It's typically stored on NAND itself, right?
So NAND actually has a table somewhere saying you can trust this block.
You can't trust this block.
In NAND, there's two types that we see.
Typically we see managed NAND which has a little embedded controller where all that
logic goes.
On some NAND, like Sony phones, that's actually built into the kernel.
The kernel deals with it.
For how NANDX works, it's really irrelevant where that code is.
The code that's open source on GitHub is attacking the raw NANDs just because it was easier
to stay in kernel NAND.
Everyone kind of gets that better.
Raw NAND has a very complicated driver because it's got to do all this where leveling and
all this bit checking and ECC values and whatnot.
Where leveling is proprietary and closed.
We don't really care about for this.
I go into way more detail in other talks.
So if you're interested in this deck, it's also online.
But we're going to go through it.
We're going to attack the MTD subsystem which is like this super epic massive driver for
Linux that a ton of things are run through.
I'll attack it again in a little bit.
But for NAND, it manages how everything is working.
So we can get into that driver and start arbitrarily saying this block is bad, but go ahead and
let me write data to it.
Go ahead and let me read from it again.
Let's just make sure no one else can but me.
Can we do that?
Yeah.
Thanks.
So if I wanted to hide NAND in general, you know, once you kind of figure out blocks get
marked bad and then they disappear, you're like, oh, I can do that at a shit ton of levels,
right?
I can do that at the file system.
But the file system then has, like, trailing pointers and stuff to data that just got removed,
which is why you see that horrible crash on screen.
MTD subsystem is much lower.
It's clean.
I forget the actual number of lines of code that I have.
I had to change, but it was like 30, something like that.
Like it was tiny.
And then I've got full control.
So it's in Android.
It's also in Linux.
So any device you see that's running Linux or a Linux variant or maybe pseudo based off
Linux or inspired by Linux, start thinking SCADA, things like that as well.
I mean, everything that's running the hardware is susceptible to this type of attack.
Everything that is running software is pseudo based on this code.
Code is also susceptible.
When I started the project, I expected full hardware.
I didn't have to do that.
I just had to buy a shit ton of phones.
I bought a ton of phones.
I started playing with them.
I found one that had full MTD, like the whole NAND was basically managed by MTD.
There was no Turing thing built in to manage NAND.
So I was like, sweet.
This is really easy to code on.
I created a couple of unit tests because that's what you do, right?
So I created unit tests.
I created a unit test that basically just killed ‑‑ arbitrarily read and wrote
data to a block of NAND, marked it bad, checked that nothing else could see it, and then read
and write again.
Yeah.
So the code was ungodly simple.
And if you are actually interested in how I'm pulling it off, I spent more time writing
notes in the source code that I checked into GitHub than I actually did the coding.
It's ‑‑.
I tried to just walk line by line of exactly how everything works.
In a nutshell, I'm grabbing a block, I'm erasing it, writing dead beef all over it, I'm making
it disappear from the system, writing dead beef again and then reading it back out just
to kind of show that we've got full arbitrary control.
Oh, and for the demo, then I'm doing a double release on the driver just to force a reboot
of the phone.
Because when I do that, it reads back the bad block table from NAND and the thing disappears.
So the demo that I have the video for, I killed block 37, just kind of arbitrarily
picked that block.
That's where a system ‑‑ yes, Android.settings is stored.
So it's no longer there.
That phone is ‑‑ I've got it with me.
If anyone wants to play with it, it's quirky.
But yeah.
So I can take data.
It's gone from the system.
And yet I can still arbitrarily read and write.
I took these phones after I did this.
Full factory reset, dead beef is still there, you know, DD, didn't see dead beef, ran my
tools, saw dead beef, another factory reset, throw other ROMs on there, do a whole bunch
of things.
The phone is completely stable and it's just dead beef all over it.
I've got like a quarter of the NAND that's just dead beef and nothing sees it.
That's pretty fun.
Since I'm running a little fast, one of the fun things you can do with this is I'm making
drives disappear half a meg at a time.
And after half a meg, I'm forcing a reboot.
But you don't have to.
You can just disappear the drive under the OS.
You can disappear the whole damn drive.
And nothing can recover that.
That device at that point.
It's just gone.
When you start talking to cell phones, it's like, dude, that fucking sucks.
That's like 600 bucks and it's inconvenient.
You get pissed off.
If that's SCADA, like that gets scary real quick.
Because it's remote.
I don't care if it's remote.
And it's not patchable.
You can't recover because there's no drive there.
Like the hardware goes, dude, there's no storage space left.
It's just dead.
You've got to replace the device.
So that was the first ‑‑ cool.
And it's all on GitHub if you want to read about it.
I've got links.
But it's basically my name and then NANDX.
I've got a paper that goes into great ridiculous detail on how NAND works and then a bunch
of source code and the presentation.
I mean, it's out there.
There's no fix that I can see.
So since this is kind of an offensive for defensive type of a talk, if you can think
of a better way to protect against this, I'd love to hear it, or really would, because
it's based off an assumption that the guys that originally sat down with pen and paper
on a napkin and figured out how NAND would work, they made an assumption that it had
to fail.
And, I mean, the hardware is based on that.
The hardware is built on that assumption.
The software on top of it is built on that assumption.
And there's nothing.
There's nothing that can keep me from taking advantage of that.
So as long as there's NAND around, we can hide.
And we can hide deep.
None of our tools can pull it out right now.
Any tool that you can start kind of thinking about how I could protect against this starts
failing real quick.
Like, yeah, I can wipe everything on boot that's in a bad block table.
Not really.
You can't validate that since blocks do go bad, how do you validate that you want to
wipe it or not?
And if I'm at that low of a layer, I can just block it anyway.
So that was NANDX.
Second project I'm working on is Clock Locking Beats.
What this is looking at is, okay, I'm hidden on disk.
That's cool.
I still have to run at some point.
I want to be able to run and never have a user be able to tell that something is going
on.
I mean, obviously, you don't want your thread showing up and things like that.
That's great.
But what if I want to go deeper?
What if I want to make sure that the kernel just has no fucking clue that anything's running?
What if I want to make the kernel have no ability to even see that?
So Clock Locking Beats is looking at taking a running operating system and slightly tweaking
the processor by overclocking it and then outside of full kernel space, like in hardware
damn near.
I'm injecting a second process.
It's a thread that runs outside of the kernel that I manage myself.
That thread runs my kit.
So no tool that you would write that's running in kernel space remotely has permission to
even see me.
Like I just don't exist.
I can reach in, but it can't reach out because it doesn't know I'm there and it has no ability
to know I'm there.
That project is at the very beginning.
And it will be.
It will be on GitHub, I promise, as soon as I'm done.
Wow.
I'm going to finish so early.
Burner.
This is the really fun one.
So like I said, I've got 20 million invested in whatever kit I'm shoving onto a device.
I'm actively monitoring that.
I know it's getting ready to get found.
I know that it's going to ‑‑ my phone is going to be in someone's hands that's going
to do a forensic deep dive.
Maybe I don't have all that much faith in Nandex anymore.
Maybe someone has figured out how to get rid of it.
Maybe there's other tools.
I want to make sure that nothing that I have on there gets out.
So I want to set the phone on fire remotely.
Fuck it.
Why not, right?
So ‑‑ and I want to do this all from the kernel.
This will be ‑‑ this project will be on GitHub probably within about a month and a
half.
I really wanted to demo it, but I swear to God it's the lamest demo ever.
It's like side load kernel module, phone turns off, like that's it, right?
It's hard to show it never boots again.
What it does internally is I'm playing with all the voltages that run internal to the
phone.
So I can target specific pieces of hardware, like the chip or the NAND or the base band
and just start dumping a lot of power to them and fry them.
Okay.
And this seems to universally work on almost every Android phone I've poked at in the
run time of this project, which is pretty much probably what you have in your pocket.
So I can attack and kill your phone dead, make sure that it will never turn on.
The only way to ever pull data off of it at that point would be to take it apart, desolder
the chips and put the NAND in a reader.
Maybe you can find me then.
That's it.
So now we've hidden, right?
I feel good that with those three projects together you're probably not going to find
any code that I'm running at all.
How do we combat against that?
Like us as users and hackers, like how do we make sure that shit that that deep just
doesn't happen to us?
I'm open sourcing everything.
That's my solution.
At least.
If I can think of these, someone else can.
If I can open source them, hopefully at least we start talking about it.
Maybe we start looking for things like this.
And at that point we're at least a little ‑‑ we at least know where to look for security
because we're not right now at all.
And maybe it will make us work a little harder.
So I felt pretty good about this.
I was like, yay, I'm awesome.
And that's pretty much it for me.
I'm godly early.
But I love questions.
Thank you.