[BUG] ? StatusRequestV2Extension about utls

[VeNoMouS]

@gaukas PR sent #247

[gaukas]

Good catch. I agree that this is a bug. Would you love to submit a pull request addressing this issue?

We did not implement enough testcases to cover all the extensions, and I basically reversed the Read() function for the Write(). So testcases would benefit this project as well.

[VeNoMouS]

Yea that's not a problem, unsure why ReadUint16LengthPrefixed reads the last element tho,,, as there should be one more read left... 07, 2, 04, 00, 00

I'll look into that (unless it treating it as \0)

[gaukas]

why ReadUint16LengthPrefixed reads the last element

Can you be more specific on that? Like, which bytes are you referring to as the last element?

[VeNoMouS]

why ReadUint16LengthPrefixed reads the last element

Can you be more specific on that? Like, which bytes are you referring to as the last element?

with the last ignored.ReadUint16LengthPrefixed(&ignored) there should still be 0, 0 left in that array to read, but its empty, cryptobyte appears to do something with it... i'll run some tests

[2 0 4 0 0 0 0] <-- 8 
[0 4 0 0 0 0] <-- 16
[0 0 0 0] <-- 16
[] <--- missing

[gaukas]

When you call ignored.ReadUint16LengthPrefixed(&ignored) when ignored == [0 0 0 0] you are reading (consuming) next two bytes from ignored as length (which is 0), then put ignored[0:length] == [] into &ignored. Basically that's where you lose the following bytes by overwriting ignored == [0 0] with [].

[VeNoMouS]

ah right , my bad