I am not convinced that will work. It's a one way process and the regime is designed to make determining 'key.private.bin' effectively impossible due to the time taken to brute force its 256 bits.I haven't checked the code, but what if the length of firmware.bin is round up to 64byte boundary with random bytes? rounding up with say all zeros gives you a way into the private key.
Given a 'firmware.bin', 'signature.bin' and 'key.public.bin' I have managed to determine what the 'key.private.bin' used to sign that 'firmware.bin' was ... but only by starting with a value close to what it was to allow it to complete within a sensible time.
What concerns me is, given a fixed 'firmware.bin', fixed 'key.private.bin', fixed 'key.public.bin', running a fixed 'sign' executable, it generates a different 'signature.bin' every time.
The signing executable reports a correct verification every time, so perhaps there are multiple 'signature.bin' which are all valid and it was only my expectation that each signing run would be deterministic, generate the same 'signature.bin' every time, which is flawed.
That would be proven by trying multiple combinations on a Built HAT to check the results, but I don't have a Build HAT.
The only question I really have beyond that is; are the 'key.private.bin' and 'key.public.bin', created when the Build HAT GitHub is 'git' cloned, 'Lego keys' used to sign the Lego firmware.
As stated in the OP -
If that presumption was wrong, then that's fine, but without a Build HAT I am unable to confirm if it is a valid presumption or not.I am suspecting we don't have the 'Lego keys' because, once I had built the signing tool using the provided keys, I signed an original 'firmware.bin' and got a different 'signature.bin' to what it usually is. I presume the Build HAT would reject that.
Statistics: Posted by hippy — Mon Jul 14, 2025 10:38 am