On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > they always zeroes).
> [...]
>
> I wrote a script to try all possible byte values for 2 bytes before or
> after the short signature. For this particular file, none of them
> producd a valid signature. So the short signatures seem to be
> corrupted in a more complex way.
The "OCTET STRING" containing the actual signature is shorter for the
seemingly corrupted signatures:
+---
| $dumpasn1
./linux-image-4.19.0-21-amd64-unsigned/lib/modules/4.19.0-21-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
| 0 404: SEQUENCE {
| [...]
| 151 254: OCTET STRING
+---
vs
+---
| $ dumpasn1
./linux-image-4.19.0-21-cloud-amd64-unsigned/lib/modules/4.19.0-21-cloud-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
| 0 407: SEQUENCE {
| [...]
| 151 256: OCTET STRING
+---
Given the number of corrupted signatures is pretty much the number of
signatures where the two leading bytes should be 0 (as stated in [1]),
I suspect something (incorrectly?) outputs a shorter OCTET STRING
leaving out the 0 (as one might for a large integer type), but the
other side expects a fixed size?
If so, the file should validate if one injects two leading 0 bytes in
the OCTET STRING (and updates all length values). I would need to check
how to manipulate files using ASN.1's DER encoding to try this...
Ansgar
[1]: https://bugs.debian.org/1012741#48
