Jump to content

BlueMatt

Active Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

410 profile views

BlueMatt's Achievements

Newbie

Newbie (1/14)

  1. Changing the name of the inject.bin should be a 10 second hack, flashing all of the MSC-available memory to ROM should also be a relatively simple hack if you just want it to work and base it on https://github.com/TheBlueMatt/Mass_Storage/commits/initialbytes_inrom'>this branch. It would limit you to about 200K, but if thats all you need, it works pretty well.
  2. Similar issue here, though more like a week instead of 8 hours, seems to be some solder is loose somewhere, but I cant seem to identify where...(works sometimes when you apply slight pressure in various directions, but otherwise nothing in dmesg/lsusb/no lights/etc). Worst part is there was no physical trauma to the Ducky, it was working one minute, the next it wasnt.
  3. Implemented with AES-CBC, turns out its actually not as slow as one might think when reading (about half the 400 i get just reading the sd card, though thats still pretty terrible for anything more than one or two blocks at a time), though its pretty slow writing. Still, we don't even have a processor with Atmel's AES instructions, and its not too shabby for that...
  4. Oh, Ill be uploading all my stuff to github at https://github.com/TheBlueMatt/Mass_Storage if anyone wants to look there.
  5. OK, so 407 (on that test, which was chosen to test something else, so was in my .bash_history, the read speed is better if you are doing longer reads) is where the clocks seem to make no difference (running the processor at 60 vs 48 MHz made no difference) when using the stock USB MSC example from ASF 3.5.0 for EVK1101 (the closest example board they have to the ducky). Also, the USBCLK must be set to exactly 48MHz, which wasnt in datasheet, but in source comments... Now the real work of porting over my anti-forensics stuff to the 3.5.0 codebase begins (and it should be able to do better since the CPU speed isnt the limiting factor anymore)
  6. Thanks for that, Im not very far yet (for the life of me I cant find the spec for USBCLK in the datasheet, so its kinda guesswork there...) but I do have a ROM that is reading @ 407kB/s, USB_Duck 2.1 got me 171 kB/s (measured using dd bs=524288 count=1)
  7. I take back my comment about requiring an L-Series processor to lock the ROM, it turns out there is a setsecure flag for our B-series...(I need to dig in a bit deeper and make sure there really is no way to dump the ROM short of some serious processor disassembly...) But this means its possible to get probabilistically perfect security if I implement a real encryption algorithm...now to go look up RC4 implementation details.....
  8. Can you upload the source for version 2.1, it appears to be missing?
  9. Just to confirm, I decided to copy some parts of my sd card into rom to see if it would read quicker there (unsurprisingly only barely faster) but I can confirm that the sd_mmc_spi_wr_protect trick works.
  10. A few options: The usb msc layer uses mem_wr_protect to check for write protection, which just calls sd_mmc_spi_wr_protect. The comment says that it is used to check for hardware read-only, but we just want to emulate hardware read-only, so just setting that to return true will actually work. The only write function used by the sd_mmc layer is sd_mmc_spi_write_sector_from_ram, so if you return false only there it will make all writes fail (though that may upset the host if you dont return the wr_protect flag (which will be returned if sd_mmc_spi_wr_protect returns true).
  11. What? Of course this is possible at the firmware layer...there are some flags in ctrl_access.h which you could try so that the ducky tells the host that it is read-only (if you set GLOBAL_WR_PROTECT), but if you're lazy, you could just return false in one of the read functions in sd_mmc_spi_write_sector_from_ram (that way writes will always fail, or maybe just return true so that they "succeed" without actually being committed to the sd card).
  12. This is all inspired by Travis Godspeed's 29c3 talk. If you haven't seen it its excellent and you should go watch it (because it suggests some other cool uses for USB dev boards like the rubber ducky). The goal is to create a anti-forensics drive which is used as a full drive encryption keyfile/keydevice. This means that in the process of forensic imaging of the keydevice, the key material itself will be deleted before it can be read. Essentially, the goal is to create a full drive encryption setup for the reasonably paranoid cyber-criminal. The specific goals of this project: A forensic investigator who attempts to make a forensic image of the key storage device should, as a result of the imaging, clear all useful information from the drive before said useful information is imaged. This means a court can't later compel you to decrypt your drives. A keen investigator shall not be able to derive the keying material directly from the SD card, given the assumption that the Rubber ducky was actually a simple SD card reader. Note that a court will probably compel you to reveal the relevant info, so you better hope it gets cleared before the SD card is imaged. Given knowledge of the Rubber Ducky and the firmware source, there should be no way to decrypt the contents of the SD card without reading from the ducky itself and probabilistically clearing it before reaching the keying material. Short of knowing the key sector and passphrase, there should be no reliable way to steal keying material given physical access (ie we shall be coldboot-attack resistant). How it works To accomplish this, we use a tweaked version of TRESOR (sorry Windows folks, I wrote this for myself and I'm on linux) and a custom Rubber Ducky firmware. If you don't care about being coldboot resistant, you could probably use any keyfile-using drive encryption software with a bit of work (to find the sector constants you will need). The firmware works by acting as a standard mass storage device, with some tricks. First it encrypts the data on the SD card (AES-CBC with a key hardcoded in the firmware). Second, it has a range of data which it considers "private" and a range around that private data which is considered a trigger. If you read from anywhere in the trigger range, it will clear the AES key, resulting in all data being lost. Note that a forensic image of a drive will almost always read it sequentially, resulting in the private section being cleared before it is read. Also note that a clever forensic imaging software which reads random blocks all over the place to avoid anti-forensics detection will probabilistically also trigger clearing of private data before the one important sector is read. How-To(ish) You can find the Rubber Ducky firmware source at https://github.com/TheBlueMatt/Mass_Storage/. In order to flash, you need to install Atmel Studio and open the project. Then go to src/asf/common/components/memory/sd_mmc/sd_mmc_mem.c and take a look at the settings at the top of the file: READ_ONLY: sets the usb device to appear read-only to the host and reject all write requests. USE_ARRAY: uses the array defined at array.h (you need to provide your own array.c) which contains the first N bytes of the storage contents. This gets compiled into the ROM and is just a slight optimization. (it only works if you are running READ_ONLY). USE_ENCRYPTION: encrypt the contents of the SD Card, provide your own aes key in AES_KEY and your own IV seed in AES_IV_XOR. If you only want to encrypt after a certain block (eg I have a partition on my SD card which is not encrypted and a second one which is) then set CRYPT_START to the first block which you want encrypted. CLEAR_ON_READ: Enables the clearing of the AES keys if a read occurs between BAD_START_SECTOR and OK_START_SECTOR or between OK_END_SECTOR and BAD_END_SECTOR (include in the BAD_* sectors, not including the OK_* sectors). Flash your .hex, making sure to SET THE SECURE FLAG on the device after flashing. Then, overwrite the SD card with random data and pick a random sector in your private range to be your keydevice for TRESOR. You can find my version of TRESOR (which has been modified to work with keydevices) at https://github.com/TheBlueMatt/linux. Note that its also a WIP, though most bugs are worked out and I am transitioning to it for daily use. On backing up your key Note that when the trigger happens, only the AES keys on the device are removed, the data isn't actually lost. If you still have the original .hex, you can flash the ducky and read the data as it was. That said, keeping the .hex around unencrypted or encrypted with a password which you can be compelled to give up is useless, so I recommend keeping a copy of the key sector encrypted somewhere out on the net that no one knows about (eg encoded base64 and thrown in the description of edits on wikipedia or similar). Thanks Travis Godspeed for the original idea The original TRESOR team at Uni-Erlangen Hak5 for the USB Development Board in a very covert casing Atmel for the solid datasheets and clean APIs/example MSC controller on which this firmware is based Edits Feb 20: Fixed a few incorrect hex constants Feb 23: Whole new firmware from the ground-up, including AES for the SD card, resulting in perfect probabilistic privacy. Because I doubt many others are actually interested (Im just gonna use this thread as a place to link when sharing info on this project), Im not gonna bother distributing .hex's, if anyone wants one, ask. Feb 24: Redo how clearing is done to make it actually secure.
×
×
  • Create New...