![[F]](/Nano/mod/file/delete/1da74ce52d24f4b6f2b828016556cdc5a653696b129bad3dfe8ce20d148471fb.png){kind=link}
File: 1da74ce52d24f4b6f2b828016556cdc5a653696b129bad3dfe8ce20d148471fb.png (dl) (12.15 KiB)
/g/ - Technology
install openbsd
[Make a Post]>>1494
USB does not allow DMA though. At least not to the extent that a plugged-in USB device can read or write main memory. It is, however, a concern that a USB device can emulate e.g. a keyboard and start typing random commands.
SD cards are ok if you access them through SPI, but they also have a (((proprietary protocol))) for access which I wouldn't use out of principle, although it still doesn't allow for data theft. Most card readers use the (((proprietary protocol))) because it's faster.
>>1495
>USB does not allow DMA though
Hm, I thought the USB protocol could be exploited to allow for DMA access ... but I can't find much on it besides this:
https://github.com/ufrisk/pcileech
>Direct Memory Access
Only if you find a vulnerable driver (which probably exists).
And yes, use SD Cards for transferring to and from an airgapped machine.
There is a video from CCC on how to exploit SD cards microcontrollers. It's quite hard when you don't have access to the source code, but cianiggers probably have it.
From the microcontroller they can exploit SD card reader firmware, which is a USB device, so theoretically sdcards can be used to pwn the system. It must be a sophisticated malware like stuxnet tho.
>>1514
>exploit SD cards microcontrollers
That's only a problem when you, for example, re-use the same USB SD card reader on multiple computers.
>DMA and
what now. if a USB device can do DMA nothing else matters, it has access to all your RAM
>can pretend to be anything by changing its firmware/software.
>muh changing
no, it can simply be malicious by design, what kind of retarded thinking process do you have
File: 50a3fc3b9298ec52f4ed50f91cd2201c1e27640ce69658f36e154281784a009b.pdf (dl) (1.25 MiB)
>>1514
You're right ... I can't read and thought you were only talking about the (USB/internal) SD card readers, but yes, SD card firmware can be attacked as well:
>Attack scenarios:
> – Eavesdropping
> ● Report smaller than actual capacity
> ● Data is sequestered to hidden sectors that are uneraseable
> – ToC/ToU
> ● Present one version of file for verification, another for execution
> ● Bootloader manipulation, etc.
> – Selective-modify
> ● Scan for assets of interest, e.g. security keys, binaries, and replace with insecure versions
(quote from PDF attached, and I'm OP)
>can be attacked as well
Or be malicious in the first place. Which is very, very likely... is there any storage medium (for a Sneakernet) that isn't as susceptible to attack?
(still OP)
>Never underestimate the bandwidth of a station wagon filled with backup tapes
>>1808
yeah tapes probably better than floppies for a sneakernet because you don't need any random access
While not air-gapped, couldn't you do something like:
[connected x86]->RS232(A)->[C64]->RS232(B)->[x86]
Then have record-only hardware on both the RS232 lines so you can compare the signals to see if there's anything different. C64 (or other 8-bit machine) is used to review the data in binary-mode and re-transmit to second x86 machine. RS232 lines are optocoupled isolated, to prevent analog signals from moving over the lines.
Probably beats moving a microcontroller back and forth between computers...
>USB bus allows for Direct Memory Access
It doesn't.
>is it reasonably secure using an SD card to transfer files or not?
http://www.bunniestudios.com/blog/?p=3554
https://wookey-project.github.io/target.html
>>1499
>Only if you find a vulnerable driver (which probably exists).
That's still not DMA though because drivers run on the CPU. Direct Memory Access means peripherals read/write memory without the CPU knowing or being able to stop them.
>>1565
>That's only a problem when you, for example, re-use the same USB SD card reader on multiple computers.
Anon means the microcontroller inside the sdcard itself. Not a reader.
>>4460
>http://www.bunniestudios.com/blog/?p=3554
It seems to me that as long as you use encryption like dmcrypt then it's fine. The issue here is that if you try to run /sdcard/bin/myapp from an sdcard then malicious firmware can give you the correct bytes when you try to verify it but then when you try to execute it give you the bytes for /sdcard/bin/backdoor instead. This trick has been used to jailbreak locked down platforms like Android tv. If you use encryption though then the sdcard firmware can't make meaningful changes to the data. The only issue left is that malicious firmware can trigger bugs in the relevant kernel drivers but that will be true for most hardware.
>>4729
Dropping some related links you and others might be interested.
Exploits:
https://github.com/ortegaalfredo/kscope
http://spritesmods.com/?art=hddhack
https://opensource.srlabs.de/projects/badusb
https://github.com/brandonlw/Psychson
https://github.com/scanlime/coastermelt/
http://www.bunniestudios.com/blog/?p=3554
Projects:
http://www.openssd.io/index.html
https://github.com/openssd/openssd
http://www.fadu.io/
https://wiki.odroid.com/accessory/emmc/reference_chart
https://wookey-project.github.io
[Catalog][Overboard][Update]
[Reply]2 files, 19 replies
Using SD cards for secure "air-gapped" file transfer
Using USB sticks to transfer files across multiple computers is certainly not secure since the USB bus allows for Direct Memory Access and an USB device can pretend to be anything by changing its firmware/software.
Now, SD cards are far more limited as to what they are allowed to access on the host computer and offer only an SPI interface to write to and read files from it. Now, what do you think is it reasonably secure using an SD card to transfer files or not?
<Just use CD/DVDs
That's an option though it is quite bulky and quite wasteful (for write-once CD/DVDs)