[Battlemesh] [FCC] What hardware still works?

[Adam Longwill]

Thank you VERY much!
On Feb 23, 2016 1:04 PM, "Jonathan Morton" <chromatix99 at gmail.com> wrote:

>
> > On 23 Feb, 2016, at 19:42, Adam Longwill <adam.longwill at metamesh.org>
> wrote:
> >
> > I do not have a good understanding of the difference between
> jtag/serial/ and tftp. Can someone briefly explain the difference for
> people like myself? Can JTAG flashing replace a locked firmware? I thought
> the chips themselves could be built to only cryptographically accept
> approved firmware? Or is that only with "higher level" flashing methods.
> >
> > Anyone have a Explain it Like I'm 5 version out there to help explain?
>
> With TFTP, you’re relying on running firmware to load and write its own
> replacement.  This may be part of the bootloader or the main firmware -
> doesn’t matter.  Bootloaders are now large and sophisticated enough to
> support cryptographic signatures (simple, slow implementations of SHA256
> and RSA aren’t very big), which means they can refuse to process images not
> originating from the original vendor, and they can also refuse to downgrade
> to an older version which ignores signatures.
>
> Serial console access *might* let you bypass that, by installing and
> running a flash-writing program that doesn’t care about signatures.
> Obviously this is a bit trickier than using the built-in utilities, but
> when the latter refuse to work, it’s a good option to try.  However, if you
> format the image wrong, this is an easy way to brick the device.
>
> JTAG is a very low-level debugging interface.  It works completely
> independently of the firmware (even the bootloader!) and usually has
> sufficient access to rewrite the flash.  This makes it a great tool for
> un-bricking devices, where the only fault is in the firmware image.
> However, setting up a JTAG is even more fiddly than setting up
> flash-writing software.
>
> When JTAG doesn’t work - usually because it couldn’t be set up correctly,
> rather than because it doesn’t have access - the “buspirate” method is the
> last resort.  This takes direct electrical control of the flash EEPROM’s
> signals in order to rewrite its contents.  The only plausible defence
> against this that a vendor could implement would be an access-control
> password built into the flash chip itself.
>
>  - Jonathan Morton
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160223/66c46130/attachment.htm>