[Question] Secure SD Duck?

[overwraith]

I had a good Idea a while ago, would it be possible to make a USB rubber ducky firmware variant that has mass storage support, but write protects the mass storage? This would be good if somebody wanted to insulate their hack tools from antivirus software. Perhaps if the executable files are discoverable by one antivirus brand, but not another, and you don't know which antivirus software you are facing in the field.

[no42]

Worth an investigation....

[overwraith]

That's the enthusiasm I'm talking about!!!

[no42]

Sadly - looks like the answer is no.

Atmel Codebase:

bool sd_mmc_spi_wr_protect(void)

This function returns the write protected status of the memory.

Only used by memory removal with a HARDWARE SPECIFIC write protected detection ! 
The user must unplug the memory to change this write protected status, which cannot be for a SD_MMC.
Returns:false -> the memory is not write-protected (always) /

Looks like write-protect is permanently disabled on sdcards

Edited January 14, 2013 by midnitesnake

[overwraith]

Well, its good to know, thank you.

Edited January 14, 2013 by overwraith

[madhak]

What about using true-crypt to encrypt the executable?

http://www.truecrypt.org/docs/?s=command-line-usage

its a portable app and can be run in command-line

you can mount the volume in read-only :D just throw in an extra command to your ducky script to mount the encrypted file as read-only first, then lunch your exe from that volume...

Edited January 29, 2013 by madhak

[BlueMatt]

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).

Edited February 21, 2013 by BlueMatt

[no42]

GLOBAL_WR_PROTECT - Tried that, it didn't work.

So I dug a little deeper and found http://forums.hak5.org/index.php?/topic/28512-question-secure-sd-duck/?p=216531

Last option is probably to change the way alll the sd_mmc commands like sd_mmc_spi_write_sector_from_ram work.

I havn't got a lot of time at the moment, and I appear to be I'm a 1-man-band! until others catch up?

If you can work it out, share the source, and we can all test it.

[BlueMatt]

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).

[BlueMatt]

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.

[ApacheTech Consultancy]

If it's possible to make a 4 kilobyte partition, you could section off that partition for the inject.bin and the rest for "Essential Applications". Then truecrypt the entire drive with the dual password method shown on the show a few seasons back. One password can be known publicly, or at least safely to show the DuckScript partition and the other would unlock the entire drive. So far as Mr Official knows, you have a four kilobyte SD card with a single file on it which cannot be run by anything and doesn't seem to do anything. It's only the name that's suspicious.

I'd like a stealthduck firmware which allows you to rename the inject.bin as something inconspicuous like memtest.bin or bootmgr.bin. Something easily overlooked. Or one that you can flash the inject.bin to the ROM alongside the firmware so that it can be run with no card.

[BlueMatt]

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.