Fixes a couple of bugs, the first being that block_cnt was actually the last block read not the block count, but was being used as both depending on context. This meant dumping eg a 16k card with both debit and credit keys specified would only dump blocks 0-236 truncating the last 19 blocks when AA2 first block was 19 (236+19=255). The new code now dumps all 256 blocks (0-255) for a 16k card.
While dumping full 16k blocks a bunch of times to test this, I noticed if coupling wasn't perfect it would fail on a few of the blocks which seemed strange as the code should have retried any failed reads. Looking closer at the trace I noticed the retry logic seemed to immediately retry so all 3 attempts failed - even though it read the block before and after perfectly fine. I realised this was because it was retrying almost immediately, when in reality the card may have head the command and started replying but we missed the reply - as such our logic should be to wait the time it would have taken the card to reply first before retrying. In reality when testing I found waiting 2x as long made it much more reliable so that's what the code does now.
I also did a little cleanup replacing some magic numbers with PICOPASS_BLOCK_SIZE in the memcpys I was touching.
Fixes a couple of bugs, the first being that
block_cnt
was actually the last block read not the block count, but was being used as both depending on context. This meant dumping eg a 16k card with both debit and credit keys specified would only dump blocks 0-236 truncating the last 19 blocks when AA2 first block was 19 (236+19=255). The new code now dumps all 256 blocks (0-255) for a 16k card.While dumping full 16k blocks a bunch of times to test this, I noticed if coupling wasn't perfect it would fail on a few of the blocks which seemed strange as the code should have retried any failed reads. Looking closer at the trace I noticed the retry logic seemed to immediately retry so all 3 attempts failed - even though it read the block before and after perfectly fine. I realised this was because it was retrying almost immediately, when in reality the card may have head the command and started replying but we missed the reply - as such our logic should be to wait the time it would have taken the card to reply first before retrying. In reality when testing I found waiting 2x as long made it much more reliable so that's what the code does now.
I also did a little cleanup replacing some magic numbers with PICOPASS_BLOCK_SIZE in the memcpys I was touching.