hf mf mifare problem

C0Y0-Ck3r · 2013-05-24 11:20:17

Hey,
Thats what I get after executing hf mf mifare :

uid(32f84ed3) nt(2298eff1) par(000021690929c909) ks(0c04010303020f06)

          
|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| c |  9  |0,0,0,0,0,0,0,0|
| 20 |00000020| 4 |  1  |0,0,0,0,0,0,0,0|
| 40 |00000040| 1 |  4  |1,0,0,0,0,1,0,0|
| 60 |00000060| 3 |  6  |1,0,0,1,0,1,1,0|
| 80 |00000080| 3 |  6  |1,0,0,1,0,0,0,0|
| a0 |000000a0| 2 |  7  |1,0,0,1,0,1,0,0|
| c0 |000000c0| f |  a  |1,0,0,1,0,0,1,1|
| e0 |000000e0| 6 |  3  |1,0,0,1,0,0,0,0|
Key not found (lfsr_common_prefix list is null). Nt=2298eff1

Every time I get the two first bytes zeroed, and when launching nonce2key on that I got that the last two bytes of the key found zeroed too !!

Any hint ?

Last edited by C0Y0-Ck3r (2013-05-24 13:44:08)

Neuer_User · 2013-05-24 12:33:24

Maybe similar/identical to http://www.proxmark.org/forum/viewtopic.php?id=1556 ?

C0Y0-Ck3r · 2013-05-24 13:39:55

Yeah same problem, but still no way to fix that !!

Neuer_User · 2013-05-24 14:19:03

What firmware version are you running?

I thought that it was fixed in one of the last revisions?!

holiman · 2013-05-24 22:43:19

Yep, that one is fixed as of r710. I forgot to write that in the topic mentioned above, where I said the trunk is broken. I have added that now, in case someone stumbles over the post.

Last edited by holiman (2013-05-24 22:45:40)

C0Y0-Ck3r · 2013-05-24 23:39:06

Well I got the memset with 8 in stead of 10, and I did the svn download its been two days. So don't really know what it still not fixed. Any other help ?

holiman · 2013-05-25 07:47:29

Did you successfully flash the device?
What does 'hw version' show?

C0Y0-Ck3r · 2013-05-26 16:06:41

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 671 2013-03-07 17:12:17                 
#db# os: svn 671 2013-03-07 17:12:31                 
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56

I think its the last version here no ?

holiman · 2013-05-26 17:27:48

Nope, you're at r671, patches went in at r710. This is what mine looks like:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 709 2013-05-04 22:15:52                 
#db# os: svn 717-unclean 2013-05-22 18:32:51                 
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56

So either you have old code (but you have memset 8, so probably not), or the flashing did not work... The method to flash the device changed with the new usb interface, there is some more info about that somewhere on this forum , I think Neuer_user wrote a how-to about it.

C0Y0-Ck3r · 2013-05-26 20:32:43

yeah I see, but where did you get the latest os and bootrom ? Didn't find them.

holiman · 2013-05-26 20:41:51

I use this when flashing :

./flasher /dev/ttyACM3 ../armsrc/obj/fullimage.elf

I once used a -b (for bootrom) flag, but I think I only did that once, when I upgraded from old usb-interface to the new usb-interface.

[Edit:] I am no expert at that flashing business, it has worked pretty well for me and I haven't dived deep into it. Sure there are others who knows a lot more about this...

Last edited by holiman (2013-05-26 20:43:19)

C0Y0-Ck3r · 2013-05-26 20:44:40

The problem is that I can't find any file with the elf extensions after doing the svn chekout.

holiman · 2013-05-26 20:51:59

You'll need to compile it, there are instructions on the wiki here : https://code.google.com/p/proxmark3/wiki/Compiling

After arm-compiler is installed, just type "make" in the source folder

C0Y0-Ck3r · 2013-05-27 08:35:06

after flashing to the new version, the problem persists.

holiman · 2013-05-27 08:56:08

Could you do both 'hw version' and 'hf mf mifare' and paste the results here ?

C0Y0-Ck3r · 2013-05-27 09:52:21

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 716 2013-05-27 07:00:10                 
#db# os: svn 716 2013-05-27 07:00:12                 
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56                 
proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
...........................................................#db# COMMAND mifare FINISHED                 


isOk:01          


uid(22209939) nt(d82ec399) par(80e0e0d8980030d0) ks(0f060e0c0d040108)

          
|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| f |  a  |0,0,0,0,0,0,0,1|
| 20 |00000020| 6 |  3  |0,0,0,0,0,1,1,1|
| 40 |00000040| e |  b  |0,0,0,0,0,1,1,1|
| 60 |00000060| c |  9  |0,0,0,1,1,0,1,1|
| 80 |00000080| d |  8  |0,0,0,1,1,0,0,1|
| a0 |000000a0| 4 |  1  |0,0,0,0,0,0,0,0|
| c0 |000000c0| 1 |  4  |0,0,0,0,1,1,0,0|
| e0 |000000e0| 8 |  d  |0,0,0,0,1,0,1,1|
Key not found (lfsr_common_prefix list is null). Nt=d82ec399

That's it. And thanks a lot holiman for the fast responses

C0Y0-Ck3r · 2013-05-27 09:53:31

And even when using the non2key tool, I always got 2 null bytes at the end of the key found, and when checking it, it doesn't seem to work.

holiman · 2013-05-27 12:11:05

The problem you're having now is not the same, because the old problem was zeroes here : par(000021690929c909) .
Now there's another problem - and one that I have been suspecting also. A lot of times (not always), it just goes to that "Key not found (lfsr_common_prefix list is null)" thing. I haven't gone deep into it (yet), but someone ought to check up what that's all about... I wish there were some testcases so this could be reliably reproduced, the problematic part about testing it against a live card is that there are differenct nonces used, so it's very difficult to compare a "correct sequence of events" against an "incorrect sequence of events" when the data changes for each execution.

What tool do you mean by non2key tool ? There is a function within the pm3 source code called nonce2key, do you mean that ? Did you test that isolated somehow?

C0Y0-Ck3r · 2013-05-27 12:28:53

Yeah exactly, but the function gives 4 zeroes at the end of the key each time. And when checking the key withe the zeroes it seems not working.
Here are two examples :

root@L3tsXpl0it-desktop:~/proxmark3-read-only/tools/nonce2key# ./nonce2key 22209939 d82ec399 80e0e0d8980030d0 0f060e0c0d040108

uid(22209939) nt(d82ec399) par(80e0e0d8980030d0) ks(0f060e0c0d040108)

|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| f |  a  |0,0,0,0,0,0,0,1|
| 20 |00000020| 6 |  3  |0,0,0,0,0,1,1,1|
| 40 |00000040| e |  b  |0,0,0,0,0,1,1,1|
| 60 |00000060| c |  9  |0,0,0,1,1,0,1,1|
| 80 |00000080| d |  8  |0,0,0,1,1,0,0,1|
| a0 |000000a0| 4 |  1  |0,0,0,0,0,0,0,0|
| c0 |000000c0| 1 |  4  |0,0,0,0,1,1,0,0|
| e0 |000000e0| 8 |  d  |0,0,0,0,1,0,1,1|

key recovered: 0e0600a50000

root@L3tsXpl0it-desktop:~/proxmark3-read-only/tools/nonce2key# ./nonce2key 22209939 6d47605c 9555ad258dedb54d 0502060d060c060c

uid(22209939) nt(6d47605c) par(9555ad258dedb54d) ks(0502060d060c060c)

|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| 5 |  0  |1,0,1,0,1,0,0,1|
| 20 |00000020| 2 |  7  |1,0,1,0,1,0,1,0|
| 40 |00000040| 6 |  3  |1,0,1,1,0,1,0,1|
| 60 |00000060| d |  8  |1,0,1,0,0,1,0,0|
| 80 |00000080| 6 |  3  |1,0,1,1,0,0,0,1|
| a0 |000000a0| c |  9  |1,0,1,1,0,1,1,1|
| c0 |000000c0| 6 |  3  |1,0,1,0,1,1,0,1|
| e0 |000000e0| c |  9  |1,0,1,1,0,0,1,0|

key recovered: 5fb4e3660000

and another problem I'm facing atm, the famous error 'got 0 keys from proxmark'. And the problem is that with the old version I cracked well this card.

holiman · 2013-05-27 12:37:57

Cool, I actually hadn't seen the nonce2key tool (I'm pretty new to proxmark aswell). If someone with a working example (parameters leading to a correct key) can post it here, I think we can solve it pretty quickly. I can also try to use an old nonce2key and test if it gets the same results.

holiman · 2013-05-27 12:42:41

I get the same results with an old version:

$ svn info
Path: .
Working Copy Root Path: /home/martin/tools/proxmark3-svn
URL: http://proxmark3.googlecode.com/svn/trunk/tools/nonce2key
Repository Root: http://proxmark3.googlecode.com/svn
Repository UUID: ef4ab9da-24cd-11de-8aaa-f3a34680c41f
Revision: 623
Node Kind: directory
Schedule: normal
Last Changed Author: bushing
Last Changed Rev: 300
Last Changed Date: 2010-01-04 05:13:39 +0100 (Mon, 04 Jan 2010)

martin@lenovox2:~/tools/proxmark3-svn/tools/nonce2key
$ ./nonce2key 22209939 d82ec399 80e0e0d8980030d0 0f060e0c0d040108

uid(22209939) nt(d82ec399) par(80e0e0d8980030d0) ks(0f060e0c0d040108)

|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| f |  a  |0,0,0,0,0,0,0,1|
| 20 |00000020| 6 |  3  |0,0,0,0,0,1,1,1|
| 40 |00000040| e |  b  |0,0,0,0,0,1,1,1|
| 60 |00000060| c |  9  |0,0,0,1,1,0,1,1|
| 80 |00000080| d |  8  |0,0,0,1,1,0,0,1|
| a0 |000000a0| 4 |  1  |0,0,0,0,0,0,0,0|
| c0 |000000c0| 1 |  4  |0,0,0,0,1,1,0,0|
| e0 |000000e0| 8 |  d  |0,0,0,0,1,0,1,1|

key recovered: 0e0600a50000

holiman · 2013-05-27 12:43:49

Can you find an old version which does not produce the same results?

C0Y0-Ck3r · 2013-05-27 12:51:31

Got the same result with an old version too !!

Last edited by C0Y0-Ck3r (2013-05-27 13:00:47)

holiman · 2013-05-27 13:10:55

Yep, and that means it's much harder to diagnose..

C0Y0-Ck3r · 2013-05-27 13:34:43

And I can confirm another problem, I just cracked the mifare card with the old version, but once on the new one, I got all the time the error 'got 0 keys from the proxmark'. Are you facing this problem too ?

holiman · 2013-05-27 13:43:20

Nope, haven't had that. Could you paste it here ?

C0Y0-Ck3r · 2013-05-27 13:46:45

With the old version I got all the keys:

proxmark3> hf mf nested 1 0 A a0a1a2a3a4a5
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a5  etrans:0
Block shift=0
Testing known keys. Sector count=16
nested...


..uid:6ed1bd16 len=2 trgbl=0 trgkey=1
.uid:6ed1bd16 len=4 trgbl=0 trgkey=1
.uid:6ed1bd16 len=4 trgbl=0 trgkey=1
.uid:6ed1bd16 len=5 trgbl=0 trgkey=1
.uid:6ed1bd16 len=4 trgbl=0 trgkey=1
.------------------------------------------------------------------
Total keys count:1187902
Found valid key:43724f75534c
.....

With the new version I got the error message :

proxmark3> hf mf nested 1 0 A a0a1a2a3a4a5 d 
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a5  etrans:0          
Block shift=0          
Testing known keys. Sector count=16          
nested...          

          
...Got 0 keys from proxmark.          

          
...Got 0 keys from proxmark.          

          
...Got 0 keys from proxmark.

holiman · 2013-05-27 19:05:03

The one that works - which version is that ?

holiman · 2013-05-27 20:28:40

Does hf mf check work ?

Could you try this:

hf mf chk *1 ? 43724f75534c

I'm thinking that if it fails, we know there's a problem with check (which is used by both hf mf mifare and hf mf nested - and could cause problems with both those commands). As I understand it, that key is valid for your card (right?) and the check should work.

Last edited by holiman (2013-05-28 07:22:42)

C0Y0-Ck3r · 2013-05-28 08:54:16

There is already a problem with the chk command on the new firmware, it only checks the first key then it stopped.
Yeah 43724f75534c is one of the keys and it can be matched using the old version.

proxmark3> hf mf chk *1 ? 43724f75534c
chk key[0] 43724f75534c
--SectorsCnt:0 block no:0x03 key type:A key count:1
--SectorsCnt:1 block no:0x07 key type:A key count:1
--SectorsCnt:2 block no:0x0b key type:A key count:1
--SectorsCnt:3 block no:0x0f key type:A key count:1
--SectorsCnt:4 block no:0x13 key type:A key count:1
--SectorsCnt:5 block no:0x17 key type:A key count:1
--SectorsCnt:6 block no:0x1b key type:A key count:1
--SectorsCnt:7 block no:0x1f key type:A key count:1
--SectorsCnt:8 block no:0x23 key type:A key count:1
--SectorsCnt:9 block no:0x27 key type:A key count:1
--SectorsCnt:10 block no:0x2b key type:A key count:1
--SectorsCnt:11 block no:0x2f key type:A key count:1
--SectorsCnt:12 block no:0x33 key type:A key count:1
--SectorsCnt:13 block no:0x37 key type:A key count:1
--SectorsCnt:14 block no:0x3b key type:A key count:1
--SectorsCnt:15 block no:0x3f key type:A key count:1
--SectorsCnt:0 block no:0x03 key type:B key count:1
Found valid key:[43724f75534c]

PS : This is the old version I'm using:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 607 2012-08-17 06:22:09
#db# os: svn 607 2012-08-17 06:22:19
#db# FPGA image built on 2012-08-17 at 08:13:54

Last edited by C0Y0-Ck3r (2013-05-28 09:06:14)

holiman · 2013-05-28 10:48:09

And what does it look like with 'hf mf chk *1 ? 43724f75534c' on new code? Right now, I can't reproduce any problems with hf mf check on my machine.. it works fine..

C0Y0-Ck3r · 2013-05-29 10:38:31

Well int the new version the check works well with one know key :

proxmark3> hw version 
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 716 2013-05-27 07:00:10                 
#db# os: svn 716 2013-05-27 07:00:12                 
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56                 

proxmark3> hf mf chk *1 ? 43724f75534c
chk key[0] 43724f75534c          
--SectorsCnt:0 block no:0x03 key type:A key count:1           
--SectorsCnt:1 block no:0x07 key type:A key count:1           
--SectorsCnt:2 block no:0x0b key type:A key count:1           
--SectorsCnt:3 block no:0x0f key type:A key count:1           
--SectorsCnt:4 block no:0x13 key type:A key count:1           
--SectorsCnt:5 block no:0x17 key type:A key count:1           
--SectorsCnt:6 block no:0x1b key type:A key count:1           
--SectorsCnt:7 block no:0x1f key type:A key count:1           
--SectorsCnt:8 block no:0x23 key type:A key count:1           
--SectorsCnt:9 block no:0x27 key type:A key count:1           
--SectorsCnt:10 block no:0x2b key type:A key count:1           
--SectorsCnt:11 block no:0x2f key type:A key count:1           
--SectorsCnt:12 block no:0x33 key type:A key count:1           
--SectorsCnt:13 block no:0x37 key type:A key count:1           
--SectorsCnt:14 block no:0x3b key type:A key count:1           
--SectorsCnt:15 block no:0x3f key type:A key count:1           
--SectorsCnt:0 block no:0x03 key type:B key count:1           
Found valid key:[43724f75534c]          
--SectorsCnt:1 block no:0x07 key type:B key count:1           
--SectorsCnt:2 block no:0x0b key type:B key count:1           
--SectorsCnt:3 block no:0x0f key type:B key count:1           
--SectorsCnt:4 block no:0x13 key type:B key count:1           
--SectorsCnt:5 block no:0x17 key type:B key count:1           
--SectorsCnt:6 block no:0x1b key type:B key count:1           
--SectorsCnt:7 block no:0x1f key type:B key count:1           
--SectorsCnt:8 block no:0x23 key type:B key count:1           
--SectorsCnt:9 block no:0x27 key type:B key count:1           
--SectorsCnt:10 block no:0x2b key type:B key count:1           
--SectorsCnt:11 block no:0x2f key type:B key count:1           
--SectorsCnt:12 block no:0x33 key type:B key count:1           
--SectorsCnt:13 block no:0x37 key type:B key count:1           
--SectorsCnt:14 block no:0x3b key type:B key count:1           
--SectorsCnt:15 block no:0x3f key type:B key count:1

But stops after the first key found, when looking for all the keys as shown below :

proxmark3> hf mf chk *1 ? t
No key specified,try default keys          
chk default key[0] ffffffffffff          
chk default key[1] 000000000000          
chk default key[2] a0a1a2a3a4a5          
chk default key[3] b0b1b2b3b4b5          
chk default key[4] aabbccddeeff          
chk default key[5] 4d3a99c351dd          
chk default key[6] 1a982c7e459a          
chk default key[7] d3f7d3f7d3f7          
chk default key[8] 714c5c886e97          
chk default key[9] 587ee5f9350f          
chk default key[10] a0478cc39091          
chk default key[11] 533cb6c723f6          
chk default key[12] 8fd0a4f256e9          
--SectorsCnt:0 block no:0x03 key type:A key count:13           
Found valid key:[a0a1a2a3a4a5]          
--SectorsCnt:1 block no:0x07 key type:A key count:13

Do you face any problems cracking the mf cards with your version, or that check problem too ?

holiman · 2013-05-29 13:27:38

I'm having a few problems, although check seems to work. I'll look some more into it.
The problem I'm investigating now is that nested seems to freeze the client and host when an invalid key is used. The device-issue may be that leds aren't reset correctly when it aborts, the host-client problem seems to be that 'abort' only exits a loop, but does not return and really end it. I may have solved that, but I need to test it some more to be sure. sometimes I have noticed freezes that totally spins my cpu, and I am not sure that one is solved yet.

These are really annoying issues, and I would like to get rid of them.

C0Y0-Ck3r · 2013-05-29 13:34:28

Well I'm facing too a problem with nested, with the same mifare card, the old version was able to crack, but with this new version, I got the message "got 0 keys from proxmark", and it does it with the all other mifare cards. That's so wierd. I have updated the revision to 727 now and still have the same problem.

holiman · 2013-05-31 13:06:22

Regarding this:

proxmark3> hf mf nested 1 0 A a0a1a2a3a4a5 d 
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a5  etrans:0          
Block shift=0          
Testing known keys. Sector count=16          
nested...          

          
...Got 0 keys from proxmark.          

          
...Got 0 keys from proxmark.          

          
...Got 0 keys from proxmark.

I think I found the problem. There is a waitfortimeout-function in the cmdcommand, it sleeps for 10 ms and then checks if anything has arrived. when the device sends keys, it send 3-4 data packets (usbcommands), then a final one. The problem seems to be that with the new usb interface, this sometimes happens during that 10ms window, and eack packet overwrites the previous one, so only the last ("finished") command is left once the sleep is over. Changing to a 1 us-sleep seems to have fixed it.

But, then I tried this on a 'clean' svn (my code is heavily polluted with debug printouts), and couldn't quite reproduce the problem or verify the fix. So, I need to check this a bit more before I commit anything.

Oh, and if this indeed is the problem, this particular little bug could probably cause some random havoc with all operations where usb packets are returned in quick succession.

holiman · 2013-05-31 20:29:43

I implemented a patch now.
Just making the wait-cycle smaller seemed like a bad idea (it would still discard messages if no process was listening), so instead I implemented a circular buffer which stores up to 50 commands from the device. If the buffer circulates and overwrites data, the user is alerted (and informs the developers, so we can increase the buffer). I tested this on a 'vanilla' svn, and it seems to work.
Please test it, potentially it could solve various problems, but I don't know exactly which. Nested (after 'nested...') was one such operation in which the device sent messages too quickly.
r729.

holiman · 2013-05-31 20:32:17

Oh, and I just saw that dn337t submitted another patch, in which delays have been put back into the device. Please test without that patch - which is very simple, just don't flash the device his patch (my patch is host-side only). If it works, we can revert that patch and keep teh speeeed!

cupido · 2013-06-02 18:31:08

I just checked r729. Nested attack worked but I got new problems with other commands, e.g. data hexsamples chrashed again after it had just been kitted under the cmd interface.

C0Y0-Ck3r · 2013-06-02 20:52:56

Still got the same problem, but the other commands like hf 14a snoop, hf 14a list, hf mf sniff, seems to not work !! I'm still digging to see why they don't.

Last edited by C0Y0-Ck3r (2013-06-03 09:58:11)

holiman · 2013-06-03 12:05:36

Ok, there was a problem; https://code.google.com/p/proxmark3/issues/detail?id=46 .
This explains why hexsamples crashed, but I haven't looked at snoop and list does not work. @C0Y0-Ck3r do you have any more details about what happens (or does not happen)?

[EDIT]:
Oh no wait, those are also effects of that bug. Should be resolved in r730.

int CmdHF14AList(const char *Cmd)
{
  uint8_t got[1920];
  GetFromBigBuf(got,sizeof(got),0);
  WaitForResponse(CMD_ACK,NULL);

Last edited by holiman (2013-06-03 12:08:19)

holiman · 2013-06-04 19:56:27

Oh, and another thing. Nested does a check for known keys. It contans this:

switch (cmdp) {
			case '0': SectorsCnt = 05; break;
			case '1': SectorsCnt = 16; break;
			case '2': SectorsCnt = 32; break;
			case '4': SectorsCnt = 64; break;
			default:  SectorsCnt = 16;
		}

On the other hand, the dedicated check-command contains this:

		switch(param_getchar(Cmd+1, 0)) {
			case '0': SectorsCnt =  5; break;
			case '1': SectorsCnt = 16; break;
			case '2': SectorsCnt = 32; break;
			case '4': SectorsCnt = 40; break;
			default:  SectorsCnt = 16;
		}

Spot the difference ? Wikipedia says mifare 4k has forty sectors, have no idea why 64 is specified in the top example, nor what the consequences of that are..

piwi · 2013-06-05 06:26:37

I had a look at the new 50 commands circular buffer (r729). Don't we need a mutex here? We have two parallel threads (main_loop and uart_receiver) accessing the same data structure via getCommand and storeCommand. If both of these functions are called simultaneously, the contents of cmdBuffer, cmd_head and cmd_tail would be inconsistent.

piwi · 2013-06-05 06:46:42

regarding hf mf chk: there is another "buffer" issue with sending commands to the proxmark. If you add the "t" option, found keys are written to the emulator memory on the proxmark. The client doesn't wait for a response on this command (there is none) and continues with sending the next CMD_MIFARE_CHKKEYS command. Chances are that the previous CMD_MIFARE_EML_MEMSET command hasn't been sent completely at this time. It depends on the processor speed if this happens sooner or later or never.

The client software should cope with that issue but needs a tiny fix. See my other post here: http://www.proxmark.org/forum/viewtopic.php?id=1637

holiman · 2013-06-05 09:02:07

@piwi, regarding mutex. Good question, generally I'd say yes. However, in this case, I think we don't need one. There is only one reader, and only one writer, so the code does not have to be multithread-safe in that sense - only that reading and writing is safe against each other, so to say.
storeMessage writes to a free slot, and then increments head.
readMessage reads a message, then increments tail.

The scenario above should, I think, be safe, since store does not update the head-pointer until the data is already there, and does not really care about tail. The only thing that violates it a bit is when storemessage modifies the tail, if the tail is -1. I still think that's ok in this case, but I can be mistaken here.

Regarding the mf check issue, nice catch! I can't commit the fix right now (at work), but I'll look at it later.

holiman · 2013-06-05 09:51:27

Volatile thingy committed as r731. Good work!

asper · 2013-06-05 10:44:18

[OT]Just to say that I really appreciate your efforts to make PM3 code ebtter and cleaner ! THANK YOU GUYS ![/OT]

piwi · 2013-06-05 11:53:03

Regarding the difference in number of Mifare 4K sectors in Nested and Chk:

The Mifare 4K in fact has 32 sectors with 4 blocks each plus 8 sectors with 16 blocks each. Chk knows about this structure. Nested ignores it and assumes 64 sectors with 4 blocks each. This results in some blocks being checked which aren't sector trailers. Not very clean but shouldn't hurt.

piwi · 2013-06-05 12:47:36

Regarding getCommand and storeCommand: I am worrying about the following scenario:

there is one command in the buffer, i.e. head == tail+1
getCommand starts retreiving the command
storeCommand starts adding another command
getCommand increases tail, then sets tail to -1 because tail == head
storeCommand increases head but leaves tail unmodified, because it doesn't know about the tail meanwhile being set to -1

The result is a buffer which contains a stored command but tail == -1, therefore the next getCommand would fail.

I am not sure if I really can reproduce this scenario but I will give it a try...

holiman · 2013-06-06 19:35:36

@piwi, no need to reproduce that scenario, you are correct - I was wrong. I committed a new version now that does not violate the access-rule (store writes data and updates head, get reads data, updates tail, neither one touches the other's data). I do believe it's thread-safe, but please prove me wrong! (r732)

@asper, thanks for the appreciation! I think the pm3 is a cool piece of hardware, and I haven't done much c-programming the last few years, plus I'm kind if new to embedded-stuff, so I enjoy hacking on it. Plus I really would like it to be simpler to experment with RFID, without worrying about pointers and allocations. That's the beauty of open source; if something is not the way you want it, you're free to make it into what you want.

Last edited by holiman (2013-06-06 19:35:56)

piwi · 2013-06-06 20:47:47

@holiman: I couldn't reproduce my described scenario with the r731 version (which doesn't proof anything ). But I agree: r732 should to be even safer.

But: during my efforts I managed to overflow the buffer. See http://www.proxmark.org/forum/viewtopic.php?id=1639 for a proposed patch.

@asper: This is starting to be quite interesting and fun. I recently replaced my book (well, Kindle) with laptop and proxmark while commuting. And every day I see some code which could need some improvement.

Proxmark3 community

Announcement

#1 2013-05-24 11:20:17

hf mf mifare problem

#2 2013-05-24 12:33:24

Re: hf mf mifare problem

#3 2013-05-24 13:39:55

Re: hf mf mifare problem

#4 2013-05-24 14:19:03

Re: hf mf mifare problem

#5 2013-05-24 22:43:19

Re: hf mf mifare problem

#6 2013-05-24 23:39:06

Re: hf mf mifare problem

#7 2013-05-25 07:47:29

Re: hf mf mifare problem

#8 2013-05-26 16:06:41

Re: hf mf mifare problem

#9 2013-05-26 17:27:48

Re: hf mf mifare problem

#10 2013-05-26 20:32:43

Re: hf mf mifare problem

#11 2013-05-26 20:41:51

Re: hf mf mifare problem

#12 2013-05-26 20:44:40

Re: hf mf mifare problem

#13 2013-05-26 20:51:59

Re: hf mf mifare problem

#14 2013-05-27 08:35:06

Re: hf mf mifare problem

#15 2013-05-27 08:56:08

Re: hf mf mifare problem

#16 2013-05-27 09:52:21

Re: hf mf mifare problem

#17 2013-05-27 09:53:31

Re: hf mf mifare problem

#18 2013-05-27 12:11:05

Re: hf mf mifare problem

#19 2013-05-27 12:28:53

Re: hf mf mifare problem

#20 2013-05-27 12:37:57

Re: hf mf mifare problem

#21 2013-05-27 12:42:41

Re: hf mf mifare problem

#22 2013-05-27 12:43:49

Re: hf mf mifare problem

#23 2013-05-27 12:51:31

Re: hf mf mifare problem

#24 2013-05-27 13:10:55

Re: hf mf mifare problem

#25 2013-05-27 13:34:43

Re: hf mf mifare problem

#26 2013-05-27 13:43:20

Re: hf mf mifare problem

#27 2013-05-27 13:46:45

Re: hf mf mifare problem

#28 2013-05-27 19:05:03

Re: hf mf mifare problem

#29 2013-05-27 20:28:40

Re: hf mf mifare problem

#30 2013-05-28 08:54:16

Re: hf mf mifare problem

#31 2013-05-28 10:48:09

Re: hf mf mifare problem

#32 2013-05-29 10:38:31

Re: hf mf mifare problem

#33 2013-05-29 13:27:38

Re: hf mf mifare problem

#34 2013-05-29 13:34:28

Re: hf mf mifare problem

#35 2013-05-31 13:06:22

Re: hf mf mifare problem

#36 2013-05-31 20:29:43

Re: hf mf mifare problem

#37 2013-05-31 20:32:17

Re: hf mf mifare problem

#38 2013-06-02 18:31:08

Re: hf mf mifare problem

#39 2013-06-02 20:52:56

Re: hf mf mifare problem