[hf seos] Carry when incrementing

[aaronjamt]

Currently we only increment the last byte of the input, even if it overflows from 0xFF back to 0x00. I tested this behavior against a real Seos card by setting the RND.IFD to all-0xFFs and the card failed to read. After adding this patch and testing again, the card was successfully read.

[github-actions]

You are welcome to add an entry to the CHANGELOG.md as well

[iceman1001]

Maybe make it a u16 reference and increase instead of this logic

[aaronjamt]

Maybe make it a u16 reference and increase instead of this logic

This wouldn't fully solve it, as then if the last 2 bytes are 0xFFFF it would still have the same issue it does now. It would need to be at least a u128 to be able to handle AES-128 properly (since the passed array of bytes is a full block size of the selected algoithm).

[iceman1001]

highly unlikely scenario for the device to send the full u128 integer space. Make it a u32 ref and I promise you the command iteration never will go above it. You will most likely burnt out your proxmark device before.

[aaronjamt]

highly unlikely scenario for the device to send the full u128 integer space. Make it a u32 ref and I promise you the command iteration never will go above it. You will most likely burnt out your proxmark device before.

Will do. As it stands, the Proxmark always uses a RND.IFD value of all 0x00s so this issue won't ever appear under normal use, but it did appear while testing with custom provided values.

[iceman1001]

We love using bad random numbers.

[aaronjamt]

Just tried to make it a uint32_t* instead, but (at least on my machine) the endianness is incorrect. For instance, [0x01, 0x01, 0x01, 0x01] is incremented to [0x02, 0x01, 0x01, 0x01], rather than [0x01, 0x01, 0x01, 0x02], and I'm not sure how to fix this without writing a bunch of unreadable C pointer magic.

[iceman1001]

in common/commonutil.c there is functions like

u32 a = MemBeToUint4byte(d);

Uint4byteToMemBe(d, a);

[iceman1001]

Excellent!