Closed dabazti closed 7 years ago
How does it make sense to hardcode 16 * block count ?
It's not a hardcoded 16 block count, it's a hard coded 16 byte count. In the old calculation the length of the file is calculated as follows:
number of blocks * number of sectors
This works for Mifare 1k by accident:
1k: blockcount = 4blocks/sector * 16 sectors = 64 blocks 64 blocks * 16 sectors =1024 bytes
But for Mifare Mini 0.3k and Mifare 4k it does not work:
0.3k: blockcount = 4blocks/sector * 5 sectors = 20 blocks 20 blocks * 5 sectors = 100 bytes But we need 320 byte. Its too small
4k: blockcount = 4blocks/sector * 32 + 16blocks/sector * 8 = 256 blocks 256 blocks * 40 sectors = 10240 bytes But we need 4096 byte. It's too big.
For a calculation of the file length, the relevant multiplicators are: number of blocks and blocklength. We know that Mifare Mini, 1k and 4k use a fix blocklength of 16 bytes (Thats why i hardcoded the 16 :)).
Now the calculation is done as follows:
0.3k: blockcount = 4blocks/sector * 5 sectors = 20 blocks 20 blocks * 16 bytes = 320 bytes Perfect! :)
1k: blockcount = 4blocks/sector * 16 sectors = 64 blocks 64 blocks * 16 bytes =1024 byte Perfect! :)
4k: blockcount = 4blocks/sector * 32 + 16blocks/sector * 8 = 256 blocks 256 blocks * 16 bytes = 4096 bytes Perfect! :)
This should be a fix for issue #29 too.
Sorry I missed this bugreport but actually it has been fixed with f172064f988ebd871ce2e941cae1bee905a638c5 so I'm closing this one now.
Bug: Mifare 0.3k tag has 5 sectors with 20 blocks = 100 bytes. Thats too small for 320 bytes.
Edited the size calculation of the target file for the dump to support Mifare 0.3K tags. Dump file will be sized as follows: 16 bytes / block * number of blocks.