Forensics Impossible: Self-Destructing Thumb Drives BRANDON WILSON

Forensics Impossible: Self-Destructing Thumb Drives BRANDON WILSON

What is a USB flash drive? Answer: a computer Processor RAM Firmware I/O USB controller LED(s) NAND flash chip USB is just the transport mechanism

How does a computer interact with a flash drive? USB Device Descriptor Vendor and Product IDs Device class, subclass, and protocol Configuration Descriptor Interface Descriptor(s) Device class, subclass, and protocol Endpoint Descriptor(s) Control (0) Bulk Interrupt Isochronous

How does a computer interact with a flash drive? USB Mass Storage Device Class Bulk-Only Transport Protocol One incoming bulk endpoint One outgoing bulk endpoint Command Block Wrapper (CBW) Optionally, either: Incoming data, or Outgoing data CBW (Command Block Wrapper) Incoming Data Outgoing Data Command Status Wrapper (CSW) CSW (Command Status Wrapper)

How does a computer interact with a flash drive? USB Floppy Interface (UFI) Protocol SCSI Command Set Inquiry Get Capabilities Request Sense Data Read Sector Write Sector (*) Vendor-Specific Commands (*)

How does the flash drive work? Phison controller:

Can we change the code that executes? Trigger some kind of buffer overflow with the commands? Find the firmware upgrade tools and study them

What do we have to work with? http://usbdev.ru/files/phison Chinese manufacturing/qa tools MPALL UPTool GetInfo Patriot Memory firmware upgrade utility Firmware leaks

How do we see what the tools are doing? Software USB analyzer HHD USB Monitor USBSnoop USBlyzer Fake the device using an Arduino or other USB peripheral Hardware USB analyzer

Analyze the upgrade process

Analyze the upgrade process Get Info 05 00 05 I N F O Transfer Image Send Header: B1 <byte1> 00 00 00 00 00 01 <data> Get Response: B0 00 00 08 For each 512-byte chunk: Send Body: B1 <byte2> AH AL 00 00 BH BL <data> Get Response: B0 00 00 08 Firmware Upgrade Transfer Image (byte1 = 01, byte2 = 00) Unknown: EE 01 00 Transfer Image (byte1 = 03, byte2 = 02) Unknown: EE 01 01 Unknown: EE 00 00 Unknown: EE 00 01

What are the image blocks? Reconstruct from traffic logs into BIN files Fire up IDA Pro? Apparently Intel 8051 compatible chip

Study the 8051 code images

Firmware image layout Page 1 0xEFF F 0x Page 2 Page 3 Page n Page 10 0x4000 0x3FF F Base Page (Page 0) 0x0000

Boot process Boot ROM swapped into address 0x0000 8051 code execution begins at address 0x0000 Read firmware area of NAND Is firmware present? Yes, load first 32KB from special area of NAND to RAM at address 0x0000 and pass control to it No, sit and wait for firmware/flashing code to be sent for execution

Burner image Send command BF (jump to boot ROM) Send 32KB image burner image Send command B3 (jump to RAM) Send 241KB image firmware image Send command B3 (jump to RAM)

Writing new tools Drive communication implemented in Python Windows Linux OS X http://github.com/brandonlw/psychson Send the original firmware Success! But can we modify it and send it? What should we modify?

Patch the firmware and try to flash it What could we change and easily see? Hard-coded strings? Don t see any Cripple functionality? Prevent one or more SCSI commands from working

Recovering from failed flash Read firmware area of NAND Is firmware present? Yes, load first 32KB from special area of NAND to RAM at address 0x0000 and pass control to it No, sit and wait for firmware/flashing code to be sent for execution

Recovering from failed flash Short the NAND data pins

Kinds of patches we can make Create hidden partitions Expose only one half of drive at a time (manipulate LBAs sent to drive) Password protection bypass Send raw NAND chip commands ourselves Get the chip ID Erase blocks Hmm maybe we can do some damage Self-destructing drive patch

Self-destructing drive patch Add concept of a locked vs. unlocked state Drive starts in locked state While locked, the drive reports no media inserted/present No reads/writes/accesses to any data Only special SCSI command can unlock drive When the drive is idle, increment a counter over and over (pseudo-timer) Counter is only reset via special SCSI command Script on PC sends this command over and over, enabling normal use When counter reaches maximum value (several seconds of inactivity): Erase firmware area of NAND Lock up Evil laughter ensues

Self-destructing drive patch Steal some bytes from RAM (*) Locked/Unlocked flag Timer counter Patch initialization routine Reset unlocked flag Reset counter to 0 Patch infinite loop If unlocked, increment counter If counter hit threshold Disable all interrupts Erase firmware area of NAND (*) And anything else we can Patch to add commands: Set unlocked flag Reset counter to 0 Patch request sense command: If locked, return no media present Patch read sector command: If locked, do nothing

Self-destructing drive patch: Stealing bytes from RAM We have no idea what RAM is in use by the firmware But we do know it doesn t modify itself Page 0 runs from 0x0000 0x? Other pages run from 0x4000 0xEFFF It ll probably be okay if we steal a little from ~0x3FF0

Self-destructing drive patch: Patching in calls to subroutines 8051 lcall instruction is 3 bytes lcall opcode + 2 byte address Find a block of code at least 3 bytes long Replace with call to empty area at end of page, where we ll place code we want to run Replace any extra bytes with NOPs In code we want to run, place the instruction(s) we originally replaced

Let s put on our FBI/attacker hat Proper drive behavior is now reliant on the computer script that sends the unlock and (continuous) counter-reset commands yay! But what if the computer script gets leaked to the Police? FBI? CIA? Girlfriend? Bad people? Require a drive-specific passphrase in the counter-reset command, to be checked by the firmware? Vulnerable to USB traffic sniffing, which can even be done in software

Let s put on our FBI/attacker hat What if we scramble the traffic between host and PC? Disney Infinity: Console generated random seed, sent (scrambled) to USB portal Portal descrambled and stored the random seed Portal generated random number and sent (scrambled) back to console Console generated same random number, and if it didn t match portal s, freak out and de-authenticate Prevents USB traffic sniffing As long as peripheral is only one that can descramble

Let s put on our FBI/attacker hat Okay, fine, we won t plug it in Dump the NAND chip Direct access to firmware and the data We ll patch the read/write commands to use encryption The data s now protected, but what about the firmware? Calculate the key based on information sent to drive beforehand Computer script can prompt for password, send that to drive, which then gets used to calculate the key This could go on forever

Demos

Links http://github.com/brandonlw/psychson http://usbdev.ru/files/phison http://github.com/brandonlw/drivecom http://bitbucket.org/flowswitch/phison

In conclusion If you want to preserve the state of a device Don t apply power to it See what you can physically get access to first Be careful Email: brandonlw@gmail.com Web: http://brandonw.net Twitter: @brandonlwilson YouTube: http://youtube.com/ti83programmer