[Cryptography] trojans in the firmware

[Tom Mitchell]

On Tue, Feb 17, 2015 at 6:28 PM, Henry Baker <hbaker1 at pipeline.com> wrote:

> At 07:06 PM 2/16/2015, John Denker wrote:
> >On 02/16/2015 01:39 PM, John Young wrote:
> >
> >> Kaspersky Q and A for Equation Group multiple malware program, in use
> >> early as 1996. NSA implicated.
>
........

> I (and most everyone else, as well) no longer care about booting from
> "hard" disks.  Everyone boots from flash memories these days.
>
........

>
> I haven't checked the details on the newest Raspberry Pi device, but
> perhaps its flash memory is based on similar completely raw flash devices.
>

My new Raspberry Pi is effectively unchanged from previous.  The SD card
and connector has been replaced
with a microSD card which permits a much better connector.  There is flash
boot ROM that is smart enough to bootstrap
a uboot chain and eventually something interesting.   That flash is not
visible from the processor might still
be available to a JTAG scan.

The Beaglebone Black flash boot code searches the onboard 2GB of nand flash
and would boot that, lacking
boot code there or seeing a "boot from mSD switch state"  on the card the
BBB will boot  from a micro SD card.
Some developers write 0x00 on the flash and test using the mSD card.
Flashing the nand flash memory can
take 40 min and then requires a reboot. So mSD is quicker to boot and test
from but not as fast for IO.
Having a large mSD card is another value.

Hacking hard disk microcode is double trouble.   Once the microcode has
been hacked all the spare
blocks and spare tracks are available to store rather heavy payloads.
These cannot be accessed unless
the hacked microcode allows (not likely).  To repair would require access
with a JTAG tester or other i2c
bus like side door if the design allows.    It is possible with physical
access to disconnect the read write heads
and position logic replacing them with a "known good" board and explore the
media.   Modern controllers have
rather airtight hardware blocks that prevent read access to stored bits.
In some a fuse link can make the lock
permanent.  Some disks keep boot bits and defect bits on spinning media and
have a hard coded boot ROM in
the processor itself. That can then boot from the spinning media.   Once
that control software is hacked on a
disk drive almost anything is possible given the heavy but hidden payload
that it can play with.

Instrumenting a drive might detect anomalies without disassembly.  If and
only if the media and signal
lines are buffered sufficiently can data bits be read by snooping on the
device and head control logic.


-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150217/65bab3eb/attachment.html>