Huang: On Hacking MicroSD Cards
Posted Dec 29, 2013 23:29 UTC (Sun) by deconfliction (guest, #94407) [Link]
"From the security perspective, our findings indicate that even though s/memory card/router/s look inert, they run a body of code that can be modified to perform a class of MITM attacks that could be difficult to detect; there is no standard protocol or method to inspect and attest to the contents of the code running on the /memory card/router/’s microcontroller."
Huang: On Hacking MicroSD Cards
Posted Dec 30, 2013 0:47 UTC (Mon) by csamuel (✭ supporter ✭, #2624) [Link]
There also appear to be attacks against firmware in more usual hard disks (and BIOS's) too according to this article in Der Spiegel reviewing an NSA catalogue, talking about persistence of attacks:
The ANT division doesn't just manufacture surveillance hardware. It also develops software for special tasks. The ANT developers have a clear preference for planting their malicious code in so-called BIOS, software located on a computer's motherboard that is the first thing to load when a computer is turned on.[...]
Another program attacks the firmware in hard drives manufactured by Western Digital, Seagate, Maxtor and Samsung [...]
Huang: On Hacking MicroSD Cards
Posted Jan 2, 2014 5:51 UTC (Thu) by Gollum (subscriber, #25237) [Link]
Huang: On Hacking MicroSD Cards
Posted Jan 2, 2014 6:11 UTC (Thu) by foom (subscriber, #14868) [Link]
Huang: On Hacking MicroSD Cards
Posted Dec 30, 2013 11:49 UTC (Mon) by rsidd (subscriber, #2582) [Link]
Huang: On Hacking MicroSD Cards
Posted Jan 6, 2014 11:55 UTC (Mon) by njwhite (subscriber, #51848) [Link]
ubifs/jffs2?
Posted Dec 30, 2013 13:16 UTC (Mon) by giggls (subscriber, #48434) [Link]
ubifs/jffs2?
Posted Dec 30, 2013 23:36 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
I'm picturing updating the algorithms to better account for media defects, or to improve other aspects of the storage system like wear-leveling and maybe even compression. Or encryption? I don't know, just conjecturing here.
ubifs/jffs2?
Posted Dec 31, 2013 21:29 UTC (Tue) by hamjudo (guest, #363) [Link]
It would only be useful over the long term, if there are plans for a long term, predictable supply of media which supported a particular API.Not much point for the good guys to learn how to write code for a particular flavor of ARM based microSD cards, if next week the manufacturers are switching over to MIPS based cards.
Our only hope, is that a market will develop for SD cards that are fully independently audited, and by implication, auditable. The manufacturers would need to publish the complete specs, including the source code for the internal controllers. Then the auditors could verify that the SD cards were made with the stated chips, and that those chips were running code which matched the source code, and further, that there are no other chips present, nor hidden modes of operation.
To do their job, the auditors would need to be able to install test code, to probe for hidden operation modes. Auditability, leads to hackability (in the nice sense of hackability). Each design change would require a new audit, and a new set of documentation for auditing. This would provide market pressure to provide stable internal APIs, to prevent the cost of auditing going out of control.
In that sort of environment, it would make sense to write nice code to run on SD cards. Without some assurance of API stability, writing the code would only be useful for short term projects, like evil NSA tools.
I know this is a fantasy. Learning to replace the embedded code in one flavor of SD card, has about the same level of long term utility as learning how to add new hardware microcode to a Pr1me 450 in 1980. It might be useful on the few Pr1me 450s that were in circulation at the time, and impress the professors, but the code wouldn't even be useful on other Pr1me computer models, possibly not even on different revisions of the same model, and certainly not on something as different as a VAX 11/780. (I believe this is the sort of low-level microcode that Ken Thompson was referring to in the paper referenced below. Yet it has much in common with the embedded firmware of the microSD card.)
hardware sources and power profiling
Posted Jan 1, 2014 0:53 UTC (Wed) by deconfliction (guest, #94407) [Link]
"No, instead you should be able to verify all of your hardware and software are valid. One way to do this is demand the VHDL and compiled chipset designs for all your hardware. This way one can benchmark things such as power draw or timing characteristics in reality and simulation, allowing some degree of verification that pattern matching code isn't running across your bits."
Another Pr1mate?!?
Posted Jan 5, 2014 11:16 UTC (Sun) by Wol (guest, #4433) [Link]
Mind you, as a lesson in code compatibility that ain't a bad list!
Cheers,
Wol
ubifs/jffs2?
Posted Jan 2, 2014 8:50 UTC (Thu) by Lennie (subscriber, #49641) [Link]
That might be a start to solve that: there is no standard protocol or method to inspect and attest to the contents of the code running on the memory card’s microcontroller.
ubifs/jffs2?
Posted Jan 2, 2014 8:58 UTC (Thu) by Lennie (subscriber, #49641) [Link]
How about a device with direct access to the flash instead of the firmware handling all the access.
Then the software on the computer driving it can be open source.
Huang: On Hacking MicroSD Cards
Posted Dec 30, 2013 18:29 UTC (Mon) by geek (guest, #45074) [Link]
Is anyone looking hard at microcode malware?
Dave
Huang: On Hacking MicroSD Cards
Posted Dec 30, 2013 20:04 UTC (Mon) by deconfliction (guest, #94407) [Link]
I think for over a decade the NSA has been hard at work waving its hands getting people to look away from microcode malware. Their success rate in doing that may however be on a downward trend recently for some reason...
hacking wi-fi sd card
Posted Jan 1, 2014 9:26 UTC (Wed) by dufkaf (guest, #10358) [Link]
BTW, there is even more advanced controller in so called wi-fi sd cards, it runs linux and can be hacked too. see e.g. http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds