[Gnuk-users] reflash without working pin?

Vagrant Cascadian vagrant at debian.org
Fri Sep 29 17:38:05 UTC 2017


> Vagrant Cascadian <vagrant at debian.org> wrote:
>> Without a reset pin, admin pin, or user pin, how can I reflash the
>> firmware?
>
> When you build your Gnuk with --enable-factory-reset option, you can do
> reset by the subcommand "factory-reset" of "gpg --card-edit".

Yes, I like that option.


> Or, you can flash it by SWD debugger.  When doing some experiments (of
> trials and errors), I recommend having SWD debugger, so that you can
> recover the functionality of device.

I've managed to reset both of my FST-01 devices multiple times now with
a black magic probe v2.1. Had to poke holes in the nice shrink-tube, so
not as tamper evident anymore, but it worked!

The black magic probe is documented here:

  https://github.com/blacksphere/blackmagic/wiki/Debugger-Hardware


I've tried this a few times, and seemed to work, if a bit cumbersome.

Create a file called flash.begin:

  monitor tpwr enable
  monitor swdp_scan
  attach 1
  load
  compare-sections

and flash.end:

  monitor option erase
  kill
  quit

Then run the following commands, with regnual.elf and gnuk.elf in the
same directory:

  arm-none-eabi-gdb \
    -ex 'target extended-remote /dev/ttyACM0' \
    -x flash.begin \
    -ex 'monitor option erase' \
    -x flash.end \
    regnual.elf

  arm-none-eabi-gdb \
    -ex 'target extended-remote /dev/ttyACM0' \
    -x flash.begin \
    -x flash.end \
    gnuk.elf

This got me most of the way there:

  https://github.com/blacksphere/blackmagic/wiki/GDB-Automation

And found this useful for identifying exactly which pins to use:

  https://www.earth.li/~noodles/blog/2015/08/program-fst01-with-buspirate.html


> That's because the locked state of Gnuk is irreversible (non-recoverble)
> by its design.

That's good.

After messing with SWD it makes me wonder: is it feasible to dump the
key material using an SWD debugger?


> I recommend building Gnuk with --enable-factory-reset option, only when
> needed, because it means inviting another attack vector.  Default is
> --disable-factory-reset option.

What sort of attacks are you concerned about with enabling factory reset
by default? Someone wiping the keys with access to the device, or worse
than that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20170929/d394f86c/attachment.sig>


More information about the gnuk-users mailing list