[Battlemesh] [FCC] What hardware still works?
adam.longwill at metamesh.org
Tue Feb 23 19:07:48 CET 2016
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>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Battlemesh