So, thanks for coming out on a Sunday afternoon here at DEF CON.
And today, I'm going to talk a little bit about mouse jigglers,
and defense, and a little bit of offense as well.
So, what's this talk about anyway?
Why should you be here, or some of you might be in your hotel room watching this.
Mouse jigglers are now a common item in a tool kit for many law enforcement organizations,
and also for people who like to come and grab your stuff.
And if you're using full disk encryption, which you should be using,
it's kind of worthless if you're actually logged into your computer.
So,
other reasons that this might be interesting is if you want to build your own mouse jiggler,
it can be kind of fun.
Just a little bit about me.
This is my seventh DEF CON talk in the last five years.
So, if you've seen me around, you think, he looks familiar.
Maybe that's why.
Also, a funny story, I have a film credit.
I'm on IMDB for the DEF CON documentary.
As the professor.
I was in the elevator the other day with someone who is also credited as the student,
and someone recognized him, like, you look familiar to me for some reason.
So, I teach digital forensics and security at a university.
That's my day job.
Also a hardware hacker.
Been known to write a few books.
Just released a very small book on Windows forensics last year.
We released a little bit of a book.
Linux forensics book, and a couple years before that, I released this book on hacking with low-power devices.
So, yeah, I mean, this is the small book.
So, what's this talk about?
Well, first of all, you don't want to be like this guy.
This FBI is knocking on his door, and he's thinking, oh, shit, right?
So, what is he doing?
He's running to all of his computers, and he's launching a nice little deletion process.
He's grabbing drives, throwing them in the toaster.
He's putting CDs in the microwave.
And here's my favorite part.
He's got these huge magnets, and he's deleting his hard drives.
And now he pretends like, hey, what's going on, guys?
You know?
So, you don't want to be like this guy for a couple reasons.
Number one, what this guy just did is called obstruction of justice, and it kind of gets you into a bad place, right?
The other thing is, as much as it looks really cool when you're going across all your hard drives with magnets, it doesn't really work, okay?
Those suckers would have to be super...
Super powerful, but it's Hollywood, right?
So, what is a mouse jiggler anyway?
You know, it does sound a little dirty.
A lot of people are like, ooh, that sounds like an edgy talk you're giving this year, Phil.
But it's simply something that's used to keep a computer awake and unlocked.
It can be used as a prank.
Anything can be used as a prank, right?
And there are two basic types.
You have your software jigglers.
That's not what we're going to talk about.
And then you have your hardware jigglers.
And that's what you've got to be worried about.
So, I've got a couple of pictures here of two very common mouse jigglers that might be in somebody's tool kit.
So, we're going to talk about how do you detect these, what sort of things could you do, just simple stuff in order to defend yourself.
So, when it comes to detecting a mouse jiggler, you could use a known vendor ID and product ID.
Now, it turns out there's pretty much one company that makes these.
And their vendor ID is 0E90.
And their product IDs, the most common ones, are 28 and 45.
But honestly, this company makes forensic stuff.
So, if anything from their company is plugged into your computer, it's probably a good idea to do something about it, right?
You can also detect behavior.
You know, what if somebody...
You know, listens to this talk and they're like, well, I'll just make my own.
So, we'll talk about how you can detect that.
And also, you could just do things based on a device class.
You know, any kind of device that could be a jiggler, do something.
So, the easiest detection is detection by a known vid-pid combination, known vendor ID and product ID.
So, since there's a...
There's a single manufacturer, this is super easy, right?
And the nice thing about it is very quick.
You can immediately detect it.
Some of the other things I'll talk about are not as quick.
You have to analyze stuff for a little bit.
It's very easy.
And it's definite.
You're like, okay, it was definitely one of these devices.
You know, it's not like I think it was, right?
So, how do we do this?
Well, we use UDEV rules.
How many of you are familiar with UDEV rules?
All right.
Just a few of you.
All right.
So, UDEV rules are kind of like the new thing.
I say the new thing.
They're not super new.
I think like in the last 10 years or so.
But, you know, for Linux, it's been around forever.
That's new.
And they determine what happens when your new device is attached to your computer.
And they have a set of matching conditions.
And you can use them to launch various scripts.
Now, one caveat is if you launch a script, it should return right away.
Otherwise, bad things happen on your computer.
You don't want to launch a script that says, let me spend five minutes analyzing this device to figure out if it's a mouse jiggler.
Because you can't install any other USB devices in that time.
And it's going to kind of suck.
All right.
So, here's an example of a UDEV rule.
This one will detect a known mouse jiggler.
And if you look at the rules, normally they're set in etsy UDEV rules.d.
And you just create a simple text file with a bunch of rules.
I believe you have to mark it executable.
But other than that, there's no real requirements.
Normally, we name these rules with a number and then a dash.
And then it's name and it should end in .rules.
All right.
Now, the reason we use the numbers is these things are executed in alphabetical order.
So, you might have something that definitely has to run right away or should run after other things.
So, that's how we handle that.
We just use a different number.
So, in this case, I use 10, which is appropriate for this particular thing.
All right.
So, then here's my rule.
My rule just says action double equals add.
So, a double equals, if you've ever programmed in C, C++, et cetera, you know means this is equal to.
Not please assign something to this.
All right.
And the same is true with UDEV rules.
So, it says.
If the action equals add.
You just plugged in a device.
And the vendor is 0E90, which is the known vendor ID.
Then to your list of scripts to run, please add.
That's what the run plus equals this.
So, it says at C UDEV scripts lock screen dot SH.
All right.
So, in this case, the first thing I'm going to do.
Is just lock this screen.
All right.
You know, what was the goal of the mouse jiggler?
Don't let your screen lock.
All right.
You plug it into my computer.
It instantly locks.
Sorry.
But now, when you change these rules, you have to restart the UDEV service.
So, that's why I have the little note that says don't forget to run sudo service UDEV restart.
All right.
Let me back up for just one second.
So, you see here where it says adders with an S ID vendor equals equals equals 0E90.
What that is about is that you can detect the device.
Now, when you plug in a device, USB devices are layered.
Right.
They're a device.
They could be a composite device.
And so, you say when I add an S to any of these matching items, that means if anywhere in the chain, you know, my parent, anybody has this vendor ID for this device or part of it in this tree structure that's going to get loaded, please match it.
All right.
So, that's why it's important to add the S in there if anyone's wondering.
You can also detect a mouse jiggler based on behavior.
So, what do they do?
They periodically make small mouse movements.
Now, the prank version, which you can buy, doesn't make just small movements and periodically.
It just, like, makes your machine unusable.
So, this is something you can prank your friends with.
Although, honestly, it's like if you have physical activity, you can prank your friends.
If you have access to your friend's machine, there's a lot more fun things you could do.
But they do sell this device.
I don't think your typical law enforcement person is going to have this in their toolkit because they couldn't use your machine anyway.
And then there's a forensic version.
The forensic version has a much longer period, usually around half a minute to a minute.
Sometimes they're randomized depending on which version you buy.
So, what you can do is you can detect these periods.
Periodic mouse movements.
Now, the other thing that's a little bit unusual about these devices is that they normally have no clicks.
Why don't they have any clicks?
Because that could screw you up.
If you're working on something, if the mouse moves a little bit, eh, whatever.
But if the mouse is moving and clicking, like you might do in the prank version, that's a problem.
So, another thing that we can detect.
Normally, these mice are two-button mice.
So, they're two-button mice that are never used to click on anything.
And they move in predictable ways.
So, if you think that you might have a mouse jiggler, you should probably immediately apply some sort of benign defense.
You know, something like locking your screen.
Yeah, it could be a pain.
It could be a pain if every time you plugged in a possible jiggler, the screen locked, but so what?
I mean, that's how often you plug in a mouse or keyboard, things like that.
Because this will take a couple of minutes.
So, here's the udev rule for that.
And, again, this is another file stored in at cu dev rules dot d.
And the action is add again.
And it says, oh, you just added anything, right?
So, I'm going to be super cautious.
I'm not going to check the vendor ID or anything like that.
I'm just going to say you added something.
So, please add to your list of things to run this little script.
It's a detection script.
And I'm going to pass it two parameters, the bus number and the device number.
You'll notice that there's also an ampersand.
Added to the end because I said you shouldn't have long-running scripts.
And I just said this might take a couple minutes to run, right?
So, you don't want this running and clogging up your udev system.
So, once you've added this simple rule, remember you need to restart udev with sudo service udev restart.
And then you can go on to the script.
So, this detection script uses something called USB hid dump.
And this will dump hid reports.
Hid, if you're not familiar, stands for human interface device.
So, there are a class of USB device.
You have keyboards.
You have mice.
You have joysticks.
Basically, a hid is anything that connects a human to your computer.
So, this script.
This script has to be run with root privileges, which it will be if it's run by the udev system.
And it relies on the no-click behavior among some other things.
So, here I have a little screenshot.
Hopefully, you can kind of see that.
This is a couple of reports from a mouse, like a proper mouse.
And you'll notice that this mouse has, I think, something like 15 buttons on it.
And a couple of axes.
In general, normally, a mouse report like this will start with a byte or bytes for the buttons.
So, each button gets a bit.
So, you can have eight buttons per byte, if you will.
And then you'll have the various axes.
So, this is a really nice mouse that has got, you know, scroll bars and all kinds of stuff on it.
So, it's a bit longer of a report.
So, here's the script itself.
It starts out with the standard shebang, bin bash, just to make sure that it's running the bash shell.
And I have some stuff in this script that, obviously, if it's being run as a non-interactive process,
it's printing stuff to the terminal, which you'll never see.
But you can also run it separately.
That's just kind of there for debugging.
So, yeah.
Normally, you don't need a usage function in your scripts that run.
So, I define a little usage function.
And then I check and say, hey, did you give me enough parameters?
Remember, I need the bus and the device number.
And then I first do a check for the standard El Cheapo mouse jiggler that Emily had.
It's a two-button mouse.
So, what I do is I look at...
The address.
So, I get the address.
I use printf in order to format that.
So, you might recognize that statement where I say device address equals...
Let's see.
Let's see if I can successfully...
Cursor over there.
Yeah, here.
All right.
And I'm using a little trick that some of you might be aware of already.
In bash shell scripting,
you can run any command and then take the results from that command
and use it to set a variable by enclosing that command in parentheses
and preceding those parentheses with a dollar sign.
So, here, I've said, please run the command printf.
And I have a format string.
And that format string just says, please give me zero padded,
three byte decimal numbers separated by a colon.
And then I give it dollar sign one.
And dollar sign two.
Which were the two arguments passed into the script.
And then I get a report.
I use that same trick.
My dollar sign parentheses.
And I call timeout one second.
Timeout, if you haven't used it,
it just runs whatever you give it for how long you say.
And then it kills the process.
Okay.
So, I run usb-hiddom.
And I give it that address.
And I'll give it another parameter dash e.
Which says, please give me the streams,
not just the descriptors that describe the device.
And then I pipe that to egrep.
And I say, hey, did that begin with three bytes of zeros?
Or did it not begin with three bytes of zeros?
Because it turns out that the cheaper mouse jiggler
will give you a lot of null reports.
Like, yep, didn't click anything.
Yep, didn't move.
Over and over and over again.
Now, if you get the fancier one,
it doesn't really do that.
But it works differently.
So, I get a bunch of these.
And then I check.
And then I say, all right, did I get anything?
That's what this first statement says.
It says, if that thing wasn't zero,
then I'll just echo something that you'll never see,
unless you run it directly.
And then I will start declaring.
I declare a couple array variables,
which you can do in bash.
That's where the declare dash a mouse reports
and also not null reports comes in.
By the way, just a FYI, you'll notice,
I don't know how visible it is here,
that those are separated by semicolons.
And the reason I did it that way is just to put
more than one command on a line so that I could
kind of fit it on this screen.
Obviously, it's still a little bit smallish.
But in the materials on the DVD from DEF CON,
we have all this stuff.
So, you know, don't stress too much if you can't read it.
So, then I get two minutes worth of reports.
And I store that in my array.
And then I do a little bit of command line kung fu here.
And I say, okay, are any of these not null reports?
And then I look at that list and I say, all right,
it wasn't null.
And there's two reports that are exactly the same.
And there's no mouse clicking going on.
You pretty much got a mouse jiggler, right, at that point.
Now, if you have the slightly fancier one,
then I'm going to check for things like a five-button mouse.
It's a five-button, three-axis mouse.
And once again, there will be no clicks, right?
So, that's kind of a big key.
And I will look for the report that corresponds to that.
And if I get a bunch of reports that are duplicates
or, you know, nobody's ever clicking on anything,
then I know that this is a mouse jiggler, right?
Finally, I can do detection based on a device class.
So, whenever you insert a possible jiggler,
I can do something about it.
Again, this should be benign.
You know, don't start wiping your drive
just because something that might be a jiggler was installed, right?
This is really a good idea,
even if you have the other rules in place.
You know, you could do something simple as,
hey, you inserted a USB drive or any USB device.
I'm just going to lock the screen now.
I mean, if I do that,
here's the U-dev rule where I say,
all right, any hid device.
So, it's like, all right, you inserted a mouse,
a joystick, a keyboard.
Your screen's going to lock.
So what, right?
If it's you, so what?
You know your password.
You know, by the way, you know,
if someone storms into your office
and they're trying to, you know,
their first goal is to get you away from your computer,
and their second goal is to keep it from going to sleep, right?
So that's where their mouse jiggler's going to come in.
But, you know, I think personally,
with all the stress of armed people in my office,
I would temporarily probably forget my password
until all my encryption and deletion scripts completed.
That's just me.
All right, so this script,
or this U-dev rule is pretty simple.
You say anything that was in the hid subsystem,
go run lock screen, right?
Now, when it comes to the scripts themselves,
you have to choose your level of paranoia.
You know, do you just want to lock the screen?
Do you want to encrypt some files?
Again, I recommend you use whole disk encryption in general.
Do you want to start a secure wipe?
Do you want to do some physical destruction?
Now, there's been some other DEF CON talks in the past
that I'll reference later about that.
So the first thing I want to talk about
is locking your screen from a script.
Now, this might sound simple,
but remember, you have a non-interactive process, right?
So it's like, what screen, right?
It doesn't have a screen.
And that's kind of an issue.
So if you're running various windowing systems,
it's going to vary a little bit.
So if you're running GNOME,
you can get the session ID
by running bin login control list sessions,
and then you can run bin login control lock session
with that session ID.
If you're running KDE or LXDE,
you can look at the display,
and you can use the xscreensaver command.
So basically, you say,
oh, I'm going to log in as root, essentially,
and lock the screen.
And in other systems,
if you just do su dash c,
and then you run a command, screen lock command,
whichever it is, that'll work.
Now, here's another little tip for you
if you're kind of new to Linux.
Notice that I have display equals colon zero
before my command.
This is a nice little thing you can do in Linux.
So if you want to run a command
and you want to change an environment variable
just for that command and not in general,
you can do this.
You can list all the environment variables you want to set
before you run your actual command,
and it works great, right?
So here's my little lock screen script.
In this case, I just put my username in there.
You could somehow, you know,
try to figure out what your username is,
but keep it simple, right?
This is your computer.
You're trying to lock it down.
So, you know, make it applicable to you.
And I'm running actually Ubuntu
on the test system that I ran,
so it's running Genome.
And here's the little command.
So I run list sessions,
and I pipe that to grep.
I grep for my username,
and I pipe that to awk.
And then I print the first item from that line,
and that is my session ID.
And then I call lock session with that session ID.
And it's very similar for some other windowing systems.
So it looks kind of like this.
I'm just minding my own business here,
working on my little Ubuntu system,
and here comes some person,
and boom, all right?
So, you know, my computer just locked.
Now, a little word about this, right?
My computer just locked.
It's encrypting files in the background.
Don't be stupid.
All right?
Don't have a little graphic going,
ha, ha, ha, ha,
I'm, like, deleting shit,
or, you know, encrypting files, right?
That's kind of a bad idea, right?
You don't want to alert people
as to what you just did.
Or, I'm sorry, what they just did,
because did you touch that computer?
No, you're not like that first guy from the movie.
That was from the movie The Core, actually.
But, you know, that wasn't you.
Your forensic tech, I don't know what he did.
Not my problem.
I was nowhere near it.
You know, things happen.
Oh, I forgot about that script.
Yeah, we have that safeguard, sorry.
All right, so encrypting stuff.
If you want to encrypt your sensitive files,
again, you should be using whole disk encryption.
You have a couple of options.
You can use GPG,
which is GNU Privacy Guard.
It's the same thing as PGP, but open.
You can use OpenSSL.
You can use bcrypt and ccrypt.
And you can also use random encryption keys, right?
So you might temporarily forget your password
if people ask you.
And then if they say,
well, what did you use to encrypt this file
or set of files?
If you can honestly say,
I don't know.
I don't know the key.
I'm sorry, you can't coerce me
to give you something I don't know.
So we talked a little bit about generating random keys
and somewhat securely storing them.
I mean, obviously,
if you want to stash this key somewhere,
it could be discoverable.
So, you know, I'll give you some general ideas.
Don't be the guy that does the exact thing
I'm going to show you in this talk, right?
It's kind of like,
I taught a pen testing class a couple years ago,
and I had some students in the class,
and they're like,
I ran all these commands to,
you know, encode my stuff from Metasploit
in Dave Kennedy's Metasploit book,
and AVG found it every freaking time.
I'm like, they read that book too, you know?
All right, so here's how you can use GPG.
And again, I have a little usage statement.
And it will take,
you know, a directory,
and for everything in that directory,
it's going to use for to loop through everything,
and it's going to say,
hey, is this file already encrypted?
Does it have a GPG extension?
So that's what you see going on here.
Let's see if I, there it goes.
So here I'm saying, all right,
if you get the file name,
get the base name,
oops, sorry.
Base file is a command,
or base name is a command,
that will get you just the file name.
Like it could have a huge path on the front of it,
and you strip that off.
And then you can use base file,
and then pound, pound, dot.
That is a construct where you can take that name,
that shell variable, base file,
and get just the extension off of it.
So it's kind of a cool little trip.
And then I check and I say,
all right, has this thing,
oh, this is the wrong script.
They're all about the same, right?
So if it doesn't have a GPG extension,
then I'm going to echo my password
and pipe that to GPG
and give it a pass phrase,
which is in file descriptor zero,
which is standard in.
And I'm going to say,
please use symmetric encryption using that key.
And here's the file name.
And then as soon as I'm done,
I'm going to remove the file.
So I'm going to remove the original file, that is.
And that's pretty much it.
OpenSSL, very similar.
It's just a different command.
And I'm looking for ENC as the extension.
Now here, I'm going to use AES 256 CBC,
which, how many people went to Hacker Jeopardy last night?
How many of you were sober enough
to remember what CBC stands for?
All right, you can look it up later.
All right.
It was actually in a question.
Or I guess in an answer, technically.
All right.
You can look it up later.
You can also use CCrypt.
CCrypt, you pretty much want to use that little trick
where you set an environment variable.
So I set my environment variable jiggly
equal to whatever your password is.
And then I call CC encrypt on,
and I give it dash capital E
in that environment variable.
And then my file name.
So if I want to randomly encrypt stuff,
I can get a random password.
Well, there's a lot of different ways
you can get a random password.
This is just one.
So we use our old friend DD.
If you do any forensics,
you probably know about DD.
Love or hate it.
It's very easy to use.
My input file in this case is dev Urandom.
Urandom is better than random.
It's more cryptographically sound.
And I give it a block size of one
and a count of 128.
So it says, please go to random,
Urandom, that is,
and give me 128 random numbers.
And then I'll pipe that to base 64,
and that's my new password.
So if I want to get my files back,
I have to find a place to put this password.
So some suggestions.
Again, don't do exactly
what I'm going to do here.
The middle of a log file.
Some obscure log file
that nobody's probably going to look at.
You know, don't make it a juicy system log
that they're going to look at
because they're trying to figure out
what's going on in your system.
Some random file.
You could also use a random sector on the desk,
including something that's unallocated.
You could also use Slack space in your files.
And whatever you do,
securely delete your script.
When you're done, you know, don't just like,
hey, I did all this awesome stuff,
and I stashed it here,
and I didn't delete the script that stashes it there.
So someone might find that.
So here's a simple example
of doing a random encryption.
You know, I get a password using DD,
and then I go and encrypt stuff,
and then when I'm done,
I'm going to securely delete my files.
So speaking of securely deleting files,
you can use the secure delete package,
and it comes with SRM.
It's like RM, but secure.
SFill for filling things with zeros or random stuff.
And Sswap, which will nuke your swap partition or file.
Some common options.
Dash D says ignore the dot files,
the dot and dot dot files,
which is probably a good thing.
Dash F is for fast.
I don't recommend you use that,
because, you know, fast says don't use U random.
If you're really in a hurry,
like if you have a lot of files,
maybe, maybe it's not such a bad thing.
Dash L, lessen your security.
Sounds like an option you don't want to use.
Dash R will recursively delete subdirectories.
Yes, please.
Please delete everything in the directory that I set up.
For Bose, you're running a script.
I don't know why you'd want that.
And dash Z will zero out things on the last write.
So it looks like it's empty space.
So here's a pretty simple delete script
where I'm going to go to the directory
that you told me to burn.
And first I'm going to use Sswap
to kill anything in the swap file.
Then I'm going to burn your files
using a for loop going through that directory.
And then I'm going to use Sfill
to get rid of the directory itself.
And then I'm going to hit the swap again,
and I'm going to shut down the system.
All right, so what if I want to wipe the whole disk?
I'm just like, I don't ever want to see this stuff again.
There you can get your data from dev zero
or random or U random.
Now, if you use U random for this process,
it's going to be slow.
Now, one thing I should say,
yes, it's possible that if you have a government
that's going after you,
if you overwrite your disk a few times,
they can get it back
if they have specialized equipment
and they're willing to spend, you know,
a million dollars to get your hard drive back.
So choose your level of paranoia here.
Might take a little while, so if you're going to do this,
I recommend you delete the important stuff first.
So if you're going to wipe a partition,
it helps to have more than one partition
because you can't really do this on a mounted partition, right?
So you've got to unmount it first,
and here's just a couple of ways that you could do that.
Physical destruction, our favorite, right?
There's a lot of things you could do.
Charge capacitors.
You could charge up some capacitors
that are just going to fry some circuits
if you give them the command to discharge.
There's always pyrotechnics.
Hopefully you don't start a fire.
Destructive edges, you know,
things that might explosively go
through your hard disk platters, things like that.
There's been some past DEF CON talks.
There was one, DEF CON 19,
called That's How I Lost My Eye,
and then aptly named last year,
How I Lost My Other Eye.
Both very good talks.
I recommend you go out to YouTube and watch those.
All right, and the last thing I wanted to talk about
really briefly is how you could make your own mouse jiggler.
Now, I'll preface this by saying
you probably don't want to.
You can buy a mouse jiggler for 20 bucks,
so what's the point in building one?
Unless you just want to do it for education.
If you did want to make one,
I would probably use the FTDI VNC2 microcontroller.
FTDI, if you don't know them,
they make USB stuff.
So if you had an older Arduino,
you would have an FTDI chip
that would do the USB to serial conversions for you.
There's cables.
If you do any hardware debugging,
you probably have one of their cables
that use stuff like that.
A couple years ago,
they came out with a microcontroller
that was really good at USB stuff.
It's kind of like an Arduino,
but it also supports two USB devices and or hosts.
So if you want to decode your own jiggler,
you basically have to create a USB HID device
and send some commands.
So creating a USB HID is like this.
You have to create a HID descriptor.
This describes that device
and the kinds of reports that it sends.
As noted in the slide,
I have shamelessly taken this from John Hyde's
USB Design by Example book.
So here's an example of a mouse descriptor,
and it talks about what are the minimums and maximums
for each of the ranges.
Does it have this many buttons or that many buttons?
What do the reports look like?
All right, so that's what this is about.
You can send some commands.
So you send HID reports to the host.
Again, the cheaper ones have, like,
a two-button mouse with two axes,
so it sends a three-byte report.
You could do something a little bit longer if you wanted.
And you could add other axes.
It doesn't really matter what you do.
All right, so if you made your own,
you could make it a little bit harder to detect.
First thing I'd do is not use either FTDI's VID and PID.
Actually, they're VID.
You can set your own PID.
Or the one in the commercial mouse jigglers.
Just pick something random, all right?
You can also randomize the inputs a little bit better
than some of these doing.
Do that, and you could also randomize the interval.
All right.
So it's not periodic,
and it's not super easy to detect.
And if you're doing this yourself,
you're probably doing this as a prank anyway,
so you could add, you know,
a little keystrokes here and there.
If you wanted to add a keyboard to your device,
you would use something like this
as the USB HID keyboard descriptor.
Again, this is shamelessly ripped off
from John Hyde's book,
which, by the way,
this book you can download for free
if you go to ftdichip.com
and just search for USB Design by Example.
You will see this book.
It's freely available with example code
and all of that, all right?
If you do decide to send some keystrokes,
something you should be aware of,
that you're not using ASCII codes.
You're sending key codes,
which are different,
so you'll have to map those.
You can press multiple keys at once.
You know, you can make things happen like,
oh, I don't know,
you want to lock their screen
or things like that.
The other thing is, yeah,
you can have those keys set to specific values,
but if you're just messing with somebody,
do you really care what they are?
Just randomize it.
Just, like, send random junk on that.
You can get more details.
A talk I did last year,
it was called One Device to Pwn Them All.
I actually went through making a scriptable HID keyboard
and some attacks and things that you could do with that.
Some other ideas.
You can convert that annoying device
into a keylogger pretty easily
if you bother to make one.
And you could combine
that homemade jiggler functionality
with some stuff I talked about last year.
All right.
All right, so with that,
if you have any questions,
you can always hit me up on Twitter
at peepolstra.
I'm also the handsome guy
you might see sporting a deerstalker hat
at a conference.
You can follow me on Twitter
and you can also catch me at BloomCon.
A little plug.
It's a conference we started this year.
It's going to happen next year,
March 24th and 25th.
We're over in Bloomsburg, Pennsylvania.
I know most of you are like, where?
But we're a couple hours from Philly,
New York City, D.C., and all that.
So it's a good time.
With that, if you do have any questions,
I was told to ask people to come up to the mics
so that they could be heard in the recordings.
And I might have some free stuff to give away
if you have a good question.
Just saying.
Wow.
There they go.
Would it be possible to design the scripts
that when a mouse jiggler is plugged in,
depending on the design of them,
it rewrites the firmware,
so then any other computer they're put into,
it would lock those computers too?
Okay.
So you're saying somebody inserts a mouse jiggler
and you want to infect the mouse jiggler?
Yeah.
I can't think of a mechanism where that would work.
I'm not going to say it's impossible,
but I'm going to say probably fairly difficult.
All right.
Any other questions?
Yeah.
Does it work for only one computer
or the entire network?
Okay, so you could deploy these scripts
on your entire network,
if that's the question you're asking.
She just answered my question.
Okay.
Have you thought about detecting the mouse jiggler
and then putting this into a log file
which then gets deployed to the other computers
so if you detect one that took a couple of minutes,
the other ones will then immediately detect it?
I haven't thought about that,
but that is a good idea,
and I think that's a mouse jiggler-worthy question.
Yes, sir.
You talk in detail a lot on Linux.
Is there a way to do this on Windows
or Apple computers as well?
Yes, there is.
Certainly with Apple computers,
because Apple computers are sort of running Linux, right?
They're running a different variant of Unix
in that family tree.
Windows, I'm not going to say it's impossible.
I'm just going to say I don't know how to do it
because I don't use Windows, all right?
Windows is great for hacking on
and doing forensics on,
but actually my latest book is about doing forensics
on Windows subjects from Linux,
where you get real power,
so it's basically,
a little plug for my book,
it's how you can do this
without spending $10,000 on software,
so like using all the free open source stuff in Linux.
All right.
And I'm getting a sign that I'm done,
so thank you very much.