i make things!!

« laminar flow fogscreen + costume silliness Sewable LED's and knitting »

Fucking with USB Mass Storage protocols

2011
22
September

Recently I got give a Minimus AVR board, for those that CBA to click the link its a small dev board for the At90usb162 chip. Theyre mainly used for cracking PS3's but theyre also capable of running the LUFA stack well enough to start emulating most USB devices.
First example application I messed with was the Usb Keyboard demo, sure enough I had it making random capslock presses and typing "FUCK" into things. Shortly after getting bored with that I had a play with the USB Mass Storage demos. These allow the stick to emulate a USB storage device, unfortunately the demos require a dataflash chip that isnt present on the board I have. So off I go Vim in hand to track down the libraries that handle Dataflash

 

Give it a week and I have the dataflash libraries replaced with.... A serial port and Python scripts!

Whats happening here is that the Minimus board is acting as a USB Mass Storage controller and whenever it receives a SCSI read command it forwards the block address and length across a serial port to an FTDI adapter which then passes the request to a python script. The script has a 32mb disk image mmap'd and returns data across the serial port to the Minimus.

After creating a Fat16 formatted disk image, mounting it on a loopback device and filling it with stuff then "mounting" it in the python script we can see the files as normal :) Speed isnt too great, anywhere up to about 10kb/sec transfer rates but not slow enough to break things

 

Now the fun part comes when I want to start fucking with files as the device is running :)


to Fucking with USB Mass Storage protocols

Feed for this Entry

2 Comments

  • Already done this, but with a slight mod, writes come back to a separate sequential file accessed via a hash map.

    As in: get read request, is it in hash map, if no-- serve from original image, if yes-- serve from secondary file.
    if write, append to end of secondary file, place address in hash map.

    You can then get a history of the read/write accesses and by comparing the differences in the writes , identify individual changes.

    my other change was to spool the data over a 100/1000 TCP/IP connection rather than the FTDI, so it can be close to real time if needed. (very useful for tracking malware behavior)

    the request 'server' also has other uses--- just pop an FPGA on the end of the Network and handle any block device.

    #78 | Comment by on Nov 13, 2011 02:06am
  • awesome! I figured a network connection was the next step to speed things up. Its probably beyond the capability of an AVR chip though!

    #79 | Comment by on Nov 13, 2011 03:52am

About You

Email address is not published

Add to the Discussion

Subscribe to Feed

Navigation

Asides