Forensics Impossible: Self-Destructing Thumb Drives

hello everybody uh my name is Brandon Wilson and I'm here to talk about the end of forensics as we know it well not really that that's overstating a little bit but what I'm going to talk about and hopefully get across is that um USB storage devices are not as simple as they may seem uh forensic tools like right blockers may give the appearance that you can preserve and extract data from a device in a safe way but they just simply cannot do that uh so I'm going to take you through the thought process of how I and you would create a flash drive that self-destructs when they're accessed or even plugged in in a way that we don't

authorize uh so first off who here thought there was actually going to be a thumb drive explosion during this talk no yes no well sorry that's that's not going to happen what is going to happen though is a uh discussion on what a flash drive actually is what it isn't uh how I learned more about it and how it works uh especially with little resources or help uh some interesting things I found and uh how we can all take advantage of them and how we can protect ourselves against them uh so what is a USB flash drive well the answer is that it's not just a storage device but you know it's a computer like any other so you know it's

complete with a processor code for that processor to run RAM for that code to for that code to utilize and uh various forms of input and output such as the USB controller so it can communicate with the computer uh LEDs so uh like little activity light on your flash drive like when you're reading or writing data it blinks at you and the nand memory flash chip which is what actually holds all your data uh USB is just the transport mechanism it just enables the communication between the drive and a host computer so just like an ethernet cable networks computers together this is just what links these two computers together uh so how does a computer

interact with a flash drive um well to answer that we have to dig a little into how USB actually works when a USB device is plugged into a host The host's Root Hub detects that a device is connected and then the host enumerates that device which means it makes a series of standard requests asking it what kind of device it is and these standard requests involve getting the device descriptor from the device as well as one or more configuration descriptors Each of which holds a series of interface descriptors a device can choose to report itself as a custom vendor specific device or it can report itself as part of a standard device class such as human interface devices which is what

keyboards and mice joysticks and all that are or Bluetooth device like a a USB Bluetooth adapter or most importantly mass storage dri mass storage devices which is what flash drives hard drives even USB floppy drives are and the way it reports these things is through uh class subclass and protocol IDs in either the device descriptor or if it's not specified there one of the interface descriptors within the configuration descriptor uh some IDs are result reserved for specific device classes such as human interface or mass storage device classes or for custom vendor specific devices the actual communication happens on specific one-way unidirectional pipes called endpoints and the aformentioned descriptors Define how many npoints the device has as well as what type each of

them is and in what direction data flows through them so the host can send or receive a number spe a specific number of bytes on a particular endpoint or the device can do it and what happens beyond that is entirely device or class specific uh so as I said in our specific case a flash drive falls under the mass storage device class and that particular device class defines several different protocols such as CBI or control bulk interrupt which is used in USB floppy drives or the one we'll be dealing with uh the bulk only transport protocol or bought which is used in pretty much everything else uh bulk only transport utilizes one bulk incom one one bulk

endpoint for incoming data and another bulk endpoint for outgoing data so in this setup the host always issues commands to the device and the device responds the device never volunteers data on its own the host always initiates these requests so a host initiates a request by sending what's called a cbw or a command block wrapper which consists of the command and sometimes a little extra data kind of like parameters if necessary for that command and then it enters the data phase where either host the host sends more outgoing data to the device or the device sends incoming data back to the host and then it enters the Final Phase where the device sends back to the host

a csw or a command status wrapper which indicates the success or failure of that request so what data is contained in these command and Status wrappers um that's defined in the USB floppy interface or ufi protocol and it has it has floppy in the name because it was originally intended for floppy drives but it's used for everything now um the ufi specification defines a subset of the scuzzy command set which contains all sorts of commands for getting the capabilities capacity of a device reading logical blocks or sectors uh writing data to a logical block or sectors all kinds of stuff it's also very flexible and that you can Define your own commands that get passed

through this layer which the specification defines as a vendor specific command um and these commands make up the core of how we interact with USB storage devices so as we'll see later on those these commands are extremely important so if we open up a flash drive we'll see all the core pieces uh we see the USB port on the left the naan flash memory chip on the right and then in between them we see a chip and this chip is the brain of the whole system it is responsible for communicating over USB and implementing all the aspects of that protocol that I just went over as well as issuing commands to the nand flash chip so it's in other words it

translates the request uh to read or write logical box from the computer over USB uh and then sends that to what the Nan memory chip needs to know in order to return or modify the request to data and in this particular picture you could see hopefully you could see it uses a chip made by fison PHH n which is a company you may have heard of before if you follow this kind of thing um if you recall all the bad USB stuff from a couple years ago uh this is the chip that people focused on in order to implement so-called bad USB exploits um the code that this little chip runs can be upgraded without

requiring a signature to verify that it's genuine and came from a trusted source so since we know this chip can run code that we write seems like a good Target so how in the world can we do that uh well we can maybe fuzz the commands that are sent to it you know see if we can figure out some kind of buffer overflow or some other kind of trick I mean we could do that but that sounds really hard plus I don't really know all that much about fuzzing so we'll put that on the back burner um another thing we could do is try to find the tools uh used to upgrade the firmware and then study how they

work and then just duplicate what they do it sounds promising so we'll go with that um if we do some Googling about this kind of thing we very quickly come across a Russian site called the usbd usbd ru and this site has this site has everything it has all sorts of information about USB flash drives upgrading the firmware on them reformatting them uh leaked firmware images the Chinese tools and utilities to flash them everything um they're also a handful of English utilities intended for end users um the most important one being in my opinion The Patriot memory firmware upgrade utility uh for certain Patriot USB flash drives um these Chinese tools are I don't know if you ever messed with them

but they are very finicky I had a lot of trouble trying to get these things to upgrade the firmware on a drive that I actually have because they they're highly configurable but they're also very complex and when the interface is partly in Chinese it's hard to diagnose some of the more cryptic errors that it has um but so these tools were useful in knowing what all should theoretically be possible with these drives but getting them to actually do it is kind of a challenge um the one tool that doesn't throw any errors for me was is called get info and it just retrieve get info. exe it just retrieves information from the drive such as what firmware version It's

currently on uh what version of what utility flash that version to it how many partitions it has what what the name of the drive is vendor product IDs all that kind of stuff uh as far as upgrading firmware the one tool I could get to actually work was the one intended for end users which is the Patriot fir more utility upgrade utility uh to know what is happening over USB we need to log that traffic somehow though and there are a bunch of options here we can use uh one of a number of software analyzers some are windows only some work on Linux and that works pretty well with most devices um we could fake the device

using an Arduino or some other USB peripheral so that means we would write code for that Arduino so that it would simulate a USB flash drive and then uh plug it in and then log the traffic that it receives from that firmware creade utility you could even go so far as to add a USB host Shield to it so you could plug the actual flash drive into the Arduino and then just relay the traffic between the two and just log it somewhere and study it later but that's really complicated and that could be its own talk I I have done stuff like that before but that's just overkill for this um so our final option is a hardware USB

analyzer like the total phase beagle USB protocol analyzer here I am fortunate enough to actually own one of these so that's what I used but the software one would have been fine but this made my life a whole l easier uh unfortunately though the one I have is the cheapest one you can get which is not cheap just the cheapest uh and it can only log full speed or USB 1.1 traffic so to get around that I had to I had to do what most people with this analyzer do they hook up a self-powered USB 1.1 Hub between it and the host so it slows it down to full speed that way you can log

whatever traffic you want and let me tell you finding a self-powered hub not not a hub powered one so it has its own power supply finding a self-powered USB 1.1 Hub is not easy these days but I did find one and so that's what I did so we hook up the analyzer The Hub the flash drive and the PC and we run our firmware update tool the Patriot one and this is what we get uh hopefully you could see that um but what we're looking at here is a traffic log between the PC and the USB flash drive and you can see a series of uh outgoing packets in green and then incoming packets in blue going

back and forth as I mentioned a little bit ago the a flash drive uses the mass storage device class and since this is not a floppy drive it uses the bulk only transport protocol which means it uses an incoming and outgoing bulk end point for communication back and forth and it uses the ufi protocol which is a subset of the scuzzy command set so basically it wraps scuzzy commands and their responses back and forth so we're just just scuzzy commands all we're talking about here so you can see that the green outgoing packet that I've got highlighted starts out with uh bytes 55 53 42 and 43 in X those are asky codes that correspond to USB and C C being

command which is which means this is a cbw or command block wrapper so it's wrapping the scuzzy request and um after that follows a unique packet ID and some other junk and then a packet length which is in that in that highlighted row is 10 hex and then the command bite is right after that so here that's a 606 and six as it turns out is a vendor specific command so it's reserved in the scuzi command set for the vendor the manufacturer whoever to use and normally you'd see something like 28 which means read sector or or z0 like like what's highlighted above above what's highlighted but since we have 06 that's a vendor specific command and the

bik that follows the 06 which in the screenshot can be b305 or b0 seems to be some sort of sub command if you will with that the fison software uses to determine what we're really trying to do so they use one command and then all the data that they attach after that command is the actual command that it's going to work with the action it's it's been it's being told to do so after that packet we can see an incoming packet that starts with 55 53 42 53 which is USBS s being status which signifies the csw the command status wrapper which is the end of the command it's just the response to the success or failure response to that

command sometimes your data in between there as such as the long stream of incoming packets that you can see in the middle of that screenshot towards the bottom and sometimes there's not it just depends on the command some get read data in some send data out and so the cbw indicates how much data is going to be in between there and in what direction it flows in so to summarize this what I discovered is a handful of commands such as what drives that get info. exe utility and then the basics of the firmware upgrade process so to get basic information we send the vendor specific command 06 which is how all of these commands work and then 0 five 0500 for

one type of information or 0 five and then the word info for another type of information what the difference is exactly I'm not sure I don't know but to transfer some kind of block of data uh we send a initial header using B1 to check to make sure that it worked with b0 and then 512 bytes at a time we send the rest of the image with the address in the offset there's some sort of image that gets sent across so to do the actual firmware upgrade we transfer the data using a certain couple of bytes then we send this unknown e command don't know what that is then we transfer the data again using a different couple

of bytes exact same data again then several more e commands don't know what that is uh but that's what we've observed so far uh so what are these unknown chunks of data these images that get transferred during the firmware upgrade well obviously at least one of them part of it has to be the firmware data so let's just reconstruct it from the traffic logs which I did by hand uh load it up in Ida Pro and just find out so and there's no way to know if that would work if it's compressed encrypted or off you skated in some way but it's worth a shot we'll try it so when I get to Ida PR processor selection window where you

choose what processor it is I don't know what to pick because I don't know what instructions that this fison chip uses well a little quick Googling and fison has a nice page on their own site that says what it is it's an Intel 851 CPU now I had never seen 8051 assembly before this uh but I did know assembly for several different processors from x86 to to zlog or Zog z80 to motorol 68k and I dabed a little bit in arm power PC so I figured you know you know one you know them all right so I'll give it a shot so I pick 851 and I start analy it address zero just assume it's at zero

and what I see actually seems to make sense uh the 851 like a lot of embedded CPUs tend to have interrup vectors and other stuff at the very beginning of memory so we can see that Ida Pro if you can see if you can see in the screenshot has assumed the reset Vector is that address zero that's the first code it gets executed which immediately jumps elsewhere it's just a jump instruction jumps elsewhere in memory which is typical and then it seems to do a bunch of initialization things before it enters an infinite Loop that's exactly the kind of thing I would expect to see ineed devices Os or firmware so that's great we got a pretty idea pretty good

idea what's going on here we can at least see some code so the firmware upgrade traffic log revealed two different 8051 images one of them which is uh 32 kilobytes looks pretty normal uh patted out to zeros at the end that's what all the zeros are there and but the other one is around 241 kilobytes now if you know anything about 851 the only um it only has one useful 16bit register which is the dptr data pointer register that means it can't address anything beyond 16 bits so that's 64 kilobytes because 65,535 is the largest 16bit number so uh in order to have a firmware image that's that large 241 kilobytes it has to be

utilizing paging in some in some way if you aren't familiar with memory paging that means it needs to split up the addressable 64 kiloby range into Pages or groups of memory and then the firmware then swaps in whatever block of memory it needs at any given time to one one of those pages so all you have to do to access an address with is is access an address within that page whatever you swapped in there now some devices have additional Hardware that do this paging for them and some devices like this one do it through a combination of hardware and software and I'll show you what I mean through playing around by loading different chunks of the firmware into

different starting addresses in Ida Pro because I don't know where this code running from so I'll just try things I but eventually I figured out I realized that the firmware is actually split up into a dozen or so different pages the most important one being page zero at the bottom there that's the base page which is fixed at address zero and that base page is 16 kilobytes big paded out 16 kilobytes from zero all the way to 3 FFF leaving 4,000 upwards as another 32 kilobytes for swapping in different pages now there is code littered all over the place in the firmware that makes what I call off-page calls or calls into sub routines that exist off

on one of these other pages so it passes the address of the function that it wants to call at the location it would exist if it were swapped in at 4,000 and up into a function that temporarily swaps in the page you wanted it calls the code that you wanted and then it restores the whatever page was at 4,000 before you called it so as an example if I wanted to call a function at address 5,000 on page one I would set the data point register to 5,000 and then I would call the readin page one function that you could see in the screenshot which would swap in page one call the code at adjust 5000 and then return back to

another function that swaps in the original page so it's like I never happened now this raises some questions first off what is that function doing and where is it getting the rest of the firmware from and also wherever the base page is stored just what exactly is initially loading it at address zero well as it turns out this reveals some things about the boot process on this device so we'll take a look at your typical boot on this thing uh from the moment power is supplied to the device via the USB port all it needs is power from the USB port it needs to boot off something something that it's fixed in memory so that means it must have some

sort of readon memory some sort of boot ROM in the chip with built into the chip that square chip a fixed block of memory that can't be upgraded can't be changed or anything and the code stored on that boot ROM then becomes the very first thing to execute add address zero so that code is responsible for communicating with the Nan flash chip and seeing if there's firmware stored on it for booting so the firmware is actually stored on the Nan chip with your data um how it determines whether there's firmware there or not I don't know we don't have the code stored the boot ROM we just you can't see it we just know that must be that must be what

it's doing so we're just going to go with that assumption now if there is firmware present it loads the first 32 Kobes of it to Ram at address zero and then tells the chip to start booting from Ram instead of ROM so normally the firmware runs from Ram it just gets loaded from the Nan flash memory the the Nan flash chip into RAM and then runs from there if there's not firmware present then it just sits there and waits for code to be sent to it over USB which means it has at least a tiny amount of code code to communicate with the USB hardware and expose itself as a simple mass storage device without any

media inserted so that the host can see it in order to send new firmware to it so in lot of these Revelations we can visit the USB traffic log from the firmware upgrade and we can make a little more sense of the unknown commands uh the First Command that the host sends is BF which causes the device to the drive to disconnect and then reappear as a basic drive with no media present so that is the boot ROM which waits to receive more code to execute from Ram so we send that small 32 KOB image I mentioned earlier to RAM and then send a B3 command and that B3 command tells it to execute whatever we

placed in Ram so by that point at this point we're now it's now running that small 32 kiloby image um so then we send the large firmware image and then B3 again which causes it to execute so it was apparently necessary to be running this small 32 KOB image before we sent the firmware it's reasonable to assume that this Cod is responsible actually flashing or burning the the firmware image that it's been receiving to nand to the Nan chip and that Russian usb. R site refers to this as the burner image probably because it burns the firmware into the uh into the end so it's great that we've learned all this about the firmware on the drive but

what about actually modifying it uh to do that we need to ride our own tools so I did that originally in C but I wasn't exactly happy with that especially since it's Windows only because it's C so I decided to rewrite it in Python and I'm glad I did it's much better now now a word about crossplatform compatibility since the firmware process and in fact any non-standard communication happens over scuzzy vendor vendor specific commands I needed a cross-platform method of sending scuzzy commands to attached USB devices now Windows that's like all the Chinese tools and on that CER that's how they do it on Windows that's very easy it supports a scuzzy what's called a scuzzy pass through

interface that allows you to send any command and even standard ones to any storage device you specify and on Linux that's also easy there's a IO coddle ioctl however you prefer to say it uh that allows you to send commands through its scy generic interface but on OSX you just can't not not easily anyway and there is one wacky way of doing it but I didn't want to even try bothering with it so instead I implemented another way of communicating with it uh with the USB device and that's through lib USB uh the python script also supports sending um m storage Sky commands through the LI USB which will work on anything Windows Linux and OSX but that requires

installing a lib USB driver so you can communicate with it with with lib USB on Windows and Linux that's cumbersome so it just uses the os's built-in scuzzy interface but on OSX libp is your only option so if you use OSX and you want to use this good luck you you'll have to unload the kernel the M storage kernel driver then install your own driver and then use that lib USB method which theoretically works but I don't know so anyway using these tools I sent the original firmware to the drive and it still works so success yay but the the real question is can we modify it and send it well we know we should be able

to but what should we try to modify well let's take a look at what we could easily change and see the effects of it are there any hard-coded strings that we could change in the firmware no there's not not that I could see what about crippling functionality in some kind of semisafe way well digging into the code that handles incoming USB data we can find the equivalent of a case statement which in assembly looks like this it's a table of addresses and values like in the bottom of the screenshot uh where it deals with certain commands so for example to send or to handle scuzi command 03 which is requesting sense data that you could see

in that table there's an address that zero that Ed it would jump there and handle it uh interestingly despite the read and write sector commands which are I mentioned before was 28 and 2A they are in that they are in that table that case statement but they're also explicitly checked for checked for before we get there so if you look up a little bit above that table you can see it's doing an exor with 28 and 2A it's checking those commands explicitly now I don't know why it's doing that it's probably to speed up execution when you're reading or writing sectors but um if we were to patch the 2A value in that in that code that it's xoring as well as

the 2A in the table to something nonsensical like F1 then the Drive will no longer have the ability to respond to right sector requests so I did that and as you might expect it does work so now that drive can't write to it to its manship so it's read it's a readon drive now so we know we're able to modify the firmware successfully since we know we can do that but what happens when we do something dangerous and screw up the firmware so badly that it can't even get to the it can't even boot or get to the point where it will accept new firmware which I can tell you I did many many many times

what do you do in that situation well if you recall during the boot process when we first plug the drive in and Supply power to it through USB it executes the code on the boot ROM and then if it can detect valid firmware on the N chip it copies it to RAM and transfers control to it so if we disrupt that process it'll enter what that Russian site refers to as test mode which what is what we've been calling the boot ROM where we'll be able to transfer new firmware to it so how do we disrupt that process you disrupt the ability to communicate with the nship so if we take a look at the data

sheet and pin out online also on the Russian site can't tell you how enough how useful that site is we could find a couple of pins next to each other that are tied to the named data pins so if we short that's how the the chip communicate that's how the N chip communicates with that fison chip to read or write data on it so if we short those pins together there's no way it can Comm the controller can communicate with that memory chip so no communication means no firmware which means we're in test mode and from here we can just use our tools to flash it as normal now it's difficult to hold something really tiny and metal on two

very specific tiny pins while trying to plug the drive into the USB port all at the same time so I came up with a quick reset cable which is just a switch just just a USB extension cable with a switch on the 5vt line uh that way I can short the pin with one hand and just flick the switch with the other one that's why I don't have to plug it in it's already plugged in and that's the same as inserting it into the USB port so I had to do that oh so many times so I got really frustrated so I made that thing so now that we have a super basic understanding of how the firmware works

and how to go about making patches to it now we can finally get to decide what we want to do so if you've seen all the bad USB talk from a while back you may have seen some of these patches before uh we can create hidden partitions by changing the scuzzy response code to only return half the capacity of the drive whatever would Norm return we just cut it in half we just patch the firmware to cut it in half and return that instead and either leave the read sector command alone or change it to double the uh the sector that it's going to be runting to the LBA or logical block address uh so while the

user and the OS thinks that they're modifying the entire drive and see the entire Drive they really only see half of it and they're only manipulating half of it so there's an entire half of the N chip they can't even see so we can change the way that command works and it won't be obvious to any software that exists today or since the firmware actually the firmware actually the firmware is really complicated it has some it has built-in password protection functionality it even has some basic encryption stuff in there all kinds of stuff uh so we could it to always use the same password so if the user tries to set ABC we really store de so you know their

password becomes useless at that point or we could send raw nchip commands ourselves such as getting the chip ID or the Nan chip ID reading Pages or ECC data or or writing to it or erasing it so maybe we can do some damage with this so now we finally get to the self-destructing drive patch firmware patch so what we can do is patch the firmware to start off in a so-called locked state so we would have to unlock it via a special command that we just make up and create before it will indicate that there's any media present or any read sector request succeed so um we'll also uh we'll add a counter since normally we'd have like a timer but

since we don't know anything about the timer Hardware in this thing we'll just use a counter kind of go old school where they just use a counter so we'll have a counter that keeps incrementing over and over which can only be reset a via a command that we send it so only we know what command is send to reset it otherwise it just keeps on ticking up and when that counter reaches a certain point say several seconds worth of inactivity the drive will just lock up and erase the area of the N chip that holds the firmware as well as everything else on the N chip and just wait for the user to realize how screwed they

are so the N effect of this is that if anyone plugs the drive or even supplies power to it you know you could plug it into a cigarette lighter after anything uh without plugging it into a computer that keeps sending that reset a counter reset command over and over the drive will kill itself within a matter of seconds so in fact you know unless you send that special command to unlock it you can't even access the data on it anyway so to implement this idea are a whole bunch of things we need to do we need to keep track of this locked versus unlocked State and the potentially very large because we don't know how many how

big it needs to be this very large counter value so we're going to need to steal some bites from the RAM on the chip we're also going to need to patch the initialization code that runs at the very start of the firmware to set the initial values of these ram bites you know started at zero started at locked so we're going to need to patch we're also going to need to patch the infinite Loop that it runs in over and over while it checks to see if there's any USB data it needs to deal with any any scuzzy commands it needs to deal with we're going to need to patch that infinite Loop uh to increment the counter if it's

unlocked so it doesn't do anything if it's locked but as soon as it becomes unlocked it starts incrementing that counter over and over again and if we hit whatever threshold equates to a few seconds of inactivity then we disable all interrupts issue the raw erase commands to the inch to erase the firmware and everything else on it and just lock up just spin an infinite Loop over and over again um a counter is probably not the best thing to do but uh you know like I said it's kind of old school but since it's a safe to assume the speed of this process is probably constant a counter to C to track the passage to time probably okay

so that's what we'll go with um we're also going to need to patch in scuzzy Vendor commands to set the unlocked flag and to reset that counter back to zero so we're going to need to patch the request sense command to that's that's the command that the computer uses to figure out if there's any media inserted or not like for a floppy drive you don't have a floppy in the drive you know it returns no media present uh so we'll patch the request sense command the handling of it to return no media present if that flag says that we're still locked and we're also going to want to patch the read sector command to do the same thing just in case some wise

guy doesn't believe the sense data and tries to read it Anyway by sending the read sector command regardless of what the sensor the sense data says so stealing bites from Ram um we have no idea what Ram areas the firmware is coded to use but we do know that it doesn't modify itself uh particularly page zero since that never changes it's that address zero it needs to be there in order to do all this page swapping Madness uh so it's the area from 4,000 onward that the page swapping code uses to swap in different pages of code so it's probably okay to steal a little a few btes from the end of page zero so right around 3 ff0 right

right before 4,000 it's probably okay to steal those all so dep patching calls to those sub routines we're going to we're going to need to find a section that's at least three bytes big since that's how big an 851 call instruction is and replace it with a call to our code way towards the end of page zero we're going to patch our code in there as well or we could patch it somewhere else but page zero is easiest uh any leftover bytes from Instructions that we partially overwrote with that call instruction we can just replace them with zeros which in 851 is a KN or no op or no operation instruction is that just does nothing

which if you've patched anything that's you got to have an OP instruction or something that does nothing uh then our own code could do at the end of the at the end of page zero can do whatever the firmware originally did and that we overwrote in addition to whatever we needed it to do in the first place so this is great we finally have ourselves a self-destructing drive okay but theoretically all a person would have to do is get a hold of the python or whatever computer script that sends that unlock and counter reset commands and just run that on their own computer so then they're free to run whatever kind of forensic analysis they

want that's true but it is as simple as sending a counter reset command but what if we made that command more complicated like sending a password in the command you could do that but then it would be that packet would be vulnerable to USB traffic sniffing which you can even do remotely in software so that's probably not the best thing to do so now what um we could scramble the traffic between the host and the PC so that if you're looking at it in an analyzer you don't know what's going on uh it's a separate decide discussion how many here have heard of Disney Infinity a game for you overpriced game with all the toys yeah uh it's a game

released for pretty much every console that comes with this USB portal that you plug into the console and you buy a ton of expensive RFID toys for your kids to place on it and then when you do the game recognizes that it's a you know a charact recognizes that you placed a character on it and let you play as that character in the game well to prevent people from emulating that USB portal with an Arduino or something and just never buy any of the figures uh they came up with Disney came came up with this scheme where both the console and the portal had to keep generating the same random numbers based on a shared

seed that they both knew and had decided at runtime and if they were got out of sync the game would just stop talking to the portal uh so the console would generate a random seed scramble it so you couldn't tell what was in the USB traffic logs and then send that to the portal so the portal would then descramble that and use the C to generate its own random numbers um and then it would generate the next random number and it send it scrambled back to the console and so the console would do the same thing it would generate its own random number and if what it came up with didn't match the random number that

the portal sent it would just freak out and stop talking to it just assume it's a fake and just stop talking to it well we can do that same kind of logic here so if we did that we could prevent USB traffic sniffing but it would only work well if the drive is the only one that could descramble the traffic the big problem with all this is what if the attacker never plugs the drive in which is what you should do if you're dealing with this kind of drive and instead dumps the entire contents of the N which would give them access to the data as it sits and the firmware so then they could just disassemble and

figure out our scrambling algorithm or pass phas or whatever it is that we try to do to protect it and then they'd have then they'd be able to do the same thing well okay fine so we'll patch the firmware so that whenever a read or write sector command comes in will just encrypt or decrypt the contents of the USB data buffer before it sends it passes it along to the nchip but that raises the question where would the encryption key be because if you stor it in the firmware then all to do is dump the firmware and then they got their key so that's useless so instead of storing it in firmware you could have the

firmware derive it based on a password or something sent to it by the PC side you know counter resetting script the point is this whole Captain Mouse game could just go on forever it can get as complicated as you want or need it to be so it's kind of you know it's just a cat Mouse thing no demo sorry to say I I ran out of time couldn't scramble one together for you but uh have a nice graphic it's it's almost almost as good right um here are some links to the um to the GitHub repository that holds the original C bad USB code that I wrote the uh the new python code that's the

third link there uh the Russian site specific to the FIS USB controller that I've been talking about and then the at the bottom a repository of code that has a from scratch implementation of firmware for one particular version of these controllers these fison controllers and it also has a technical Wiki for writing 851 code for this thing it's got a lot of documentation about all the registers and all the uh memory math IO and all the stuff that you would need to know to write code for this thing which can be really helpful so um in conclusion a flash drive is not just a storage device it's it's really not all that different from your host computer and USB is nothing

more than a transport mechanism connecting the two together so you can't trust a flash drive any more than you can trust another computer on a network that the moment you supply power to a device by plugging it in you're taking a risk not only a risk for your computer but risk for anything about the state of that device that you might care about such as what's currently stored on it so I I promise you everything I just stood up here and talked about there are people in this world that are doing it already it's no it's it's out there so it's not just theoretical uh and if you truly care about retrieving the data from something don't plug it in right

blockers are not good enough all that does is block the computer from sending the command the flash drive can do whatever it wants if it's got power it can do anything so um hopefully this talk educated entertained a little bit um I put up a few ways to contact or follow me if you're interested and um thanks for time appreciate

it