And thanks for the testing. This was a nice example for community collaboration.
]]>Piwi: yes you are right, I was looking at this too quickly and didn't carefully look at all of 7 and 8. I'm glad you found the bug though! Thanks.
]]>How many blocks are there in a mifare 4k ? In the datsheet it says 32 sectors of 4 blocks and 8 sectors of 16 blocks... so when I use the hf mf chk with the "block number" option my possibility range is from 0 to 128+128 [255] ?
]]>And the rights for block 0 should be the right hand bits of byte 6, 8, 7
No. According to my documentation that would be bit 4 of byte 7, bit 0 of byte 8 and bit 4 of byte 8 - which is 011 in your example (can only be read with key B). The access bits are stored redundantly. Byte 6 contains inverted bits only (as well as the right hand side of byte 7) and is therefore not required.
But wait... ah, I see... the bits in rights[] are stored in reverse order, i.e. C3C2C1 compared to the Mifare doc which uses C1C2C3. 011 is therefore 110 = 6 in dez. (and it had been 6 in the if clause before I blindly changed it to 3).
I reversed the bit order in rights[] and made another commit to github master.
]]>I did debugging to print the access bytes for sector zero:
#db# READ BLOCK FINISHED
Access byte 6: 0F : 00001111
Access byte 7: 00 : 00000000
Access byte 8: FF : 11111111
http://www.nxp.com/documents/data_sheet/MF1S70YYX.pdf
Section 8.7.1
And the rights for block 0 should be the right hand bits of byte 6, 8, 7: F, F, 0 : 1, 1, 0 and the that's also what the existing code finds, 110 = 6 decimal
With 6 it should be readable by key A as well as B, but there's an exception at the bottom of the diagram in Section 8.7.3 of the spec.
But, reading fails.
So I added 6 to the list of access rights values to read using Key B and the hf mf dump 4 command worked for dumping the whole card!
I'm concerned that the access byte interpretation code is still wrong because it doesn't seem to take into account of data[6] of the access trailer block.
]]>I was looking at the dump that was failing today. I noticed that it failed on some sectors, but I was able to manually read the sector using key B, after putting a some print debugging statements in I noticed that the if statement to check which key to use isn't selecting keyB in times when it will work.
Also, I noticed the section reading the sector access bits only ORs together data[7]... | data[8]... | data[8]
I was hoping for a quick fix so I put data[9] in the last column... but that didn't work.
I'm going to look at the spec document again to double check which access bits.
]]>the small fix for the wrong sector and block number printout in hf mf dump
error handling in hf mf dump. If blocks can't be read, hf mf dump will abort and dumpdata.bin not be created/overwritten.
for those who want to use hf mf chk with more keys: I provided a file default_keys.dic which contains the keys from mf_default_keys.lua. This file can be read and used by hf mf chk.
added the d (dump) option to hf mf chk (writes dumpkeys.bin). Most likely there will be keys unknown to hf mf chk. In this case the dumpkeys.bin will contain the default key 0xffffffffffff at the respective position instead. I am not sure how usefull this option is, but anyway...