You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Wow, those look really cool.

    if it can't be taken apart without damage it quite likely won't be updatable as the firmware updates are typically signed

    I've wondered about this - I know atc1441 has a 'glitcher' for nRF52 that can allow you to read out the firmware of locked devices:­WD

    The private key won't be in the DFU firmware, but I assume that if you could basically take one apart by destroying it (melt the case off with acetone?), and then read the firmware using the glitcher, you could find the public key - and then maybe you could brute-force it on a PC to ensure that you got an initdata packet that fooled the bootloader? But the hash looks like it's 256 bits (at least) so maybe that's not an option.

    Thinking about this, as far as I can tell it's only the initData packet for DFU that has microecc run on it (not the whole firmware?), and that packet just contains the size and CRC of the actual firmware, so actually, if you:

    • Found an existing ZIP file for a firmware update
    • Looked at the 'dat' file to figure out what the CRC of the .bin file was
    • Crafted a new .bin file with custom firmware but with a CRC that matched the CRC in the dat file

    You should be good?

    The CRC computation is pretty simple (crc32_compute function) and there's probably some fancy maths you could do to calculate what bytes you need to add right at the end of the binary to 'fix' it (maybe even a tool out there already?) - but actually I think if you ran crc32_compute on all of the file apart from the last 4 bytes, then just ran through all 4 billion combinations of the last 4 bytes on a modern PC, it probably wouldn't take all that long?

    Also, I'm not sure if it's relevant but microecc had a security flaw in it (­0-27209) and the one in the ring's firmware almost certainly got that flaw.


Avatar for Gordon @Gordon started