Jump to content

[Question] Secure SD Duck?


overwraith
Go to solution Solved by madhak,

Recommended Posts

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.

Link to comment
Share on other sites

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 by midnitesnake
Link to comment
Share on other sites

  • 3 weeks later...
  • Solution

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 by madhak
Link to comment
Share on other sites

  • 4 weeks later...

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 by BlueMatt
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...