libtomcrypt uses a macro "byte" which conflicts with this type. Since
the underlying type is uint8_t and there's no real benefit from using a
custom type use the actual underlying type.
Change-Id: I982c9b8bdcb657b99fa645a5235303af7afda25b
It was a mess, a mix of crypto_* and cbc_mac calls. I made everything call crypto
functions, and also separate key setup from cryptographic operations, this will
be useful to speed up the code in the upcoming commits. Drop support for "usbotp"
key, since the crypto code for that was never mainlined and we can always get the
keys from a device as long as we have code execution (using the DCP debug registers).
Change-Id: I7aa24d12207ffb744225d1b9cc7cb1dc7281dd22
After some reverse engineering, it appears that the keys of the
sb1 format are very weak: the 128 bytes are generated from the
laserfuse words 4,5 and 6 but in a weird manner: 4 and 5 are
simply ORed and 6 is only half used (somehow), making it "only" a
48 bit word to find.
Change-Id: I40702e19d0924ef51c01894efce3cb65bd664456
Implement actual loading of a sb1 file to a structure in full
generality. Also implement dumping for debug purpose
Change-Id: I320035ea628719480a79aaccb05dce9a83256927
In the case of encrypted SB files without any key match, it is
still possible to dump the section headers. The force option
allows one to do so. It also allows to dump unencrypted sections
of encrypted files if there are some.
Change-Id: I36280230679ac5903f9c451c68c276f5c6959536
