<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 17, 2015 at 6:28 PM, Henry Baker <span dir="ltr"><<a href="mailto:hbaker1@pipeline.com" target="_blank">hbaker1@pipeline.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">At 07:06 PM 2/16/2015, John Denker wrote:<br>
>On 02/16/2015 01:39 PM, John Young wrote:<br>
><br>
>> Kaspersky Q and A for Equation Group multiple malware program, in use<br>
>> early as 1996. NSA implicated.</span><span class=""><br></span></blockquote><div>........ </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I (and most everyone else, as well) no longer care about booting from "hard" disks.  Everyone boots from flash memories these days.<br></blockquote><div>........ </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>My new Raspberry Pi is effectively unchanged from previous.  The SD card and connector has been replaced</div><div>with a microSD card which permits a much better connector.  There is flash boot ROM that is smart enough to bootstrap</div><div>a uboot chain and eventually something interesting.   That flash is not visible from the processor might still</div><div>be available to a JTAG scan.</div><div><br></div><div>The Beaglebone Black flash boot code searches the onboard 2GB of nand flash and would boot that, lacking</div><div>boot code there or seeing a "boot from mSD switch state"  on the card the BBB will boot  from a micro SD card.</div><div>Some developers write 0x00 on the flash and test using the mSD card.  Flashing the nand flash memory can</div><div>take 40 min and then requires a reboot. So mSD is quicker to boot and test from but not as fast for IO.</div><div>Having a large mSD card is another value.</div><div><br></div><div>Hacking hard disk microcode is double trouble.   Once the microcode has been hacked all the spare </div><div>blocks and spare tracks are available to store rather heavy payloads.   These cannot be accessed unless</div><div>the hacked microcode allows (not likely).  To repair would require access with a JTAG tester or other i2c</div><div>bus like side door if the design allows.    It is possible with physical access to disconnect the read write heads </div><div>and position logic replacing them with a "known good" board and explore the media.   Modern controllers have </div><div>rather airtight hardware blocks that prevent read access to stored bits.  In some a fuse link can make the lock </div><div>permanent.  Some disks keep boot bits and defect bits on spinning media and have a hard coded boot ROM in</div><div>the processor itself. That can then boot from the spinning media.   Once that control software is hacked on a </div><div>disk drive almost anything is possible given the heavy but hidden payload that it can play with.</div><div><br></div><div>Instrumenting a drive might detect anomalies without disassembly.  If and only if the media and signal </div><div>lines are buffered sufficiently can data bits be read by snooping on the device and head control logic. </div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>