"hf mf nested" gets stuck with some cards #899
Comments
uzlonewolf
changed the title
hf mf nested gets stuck with cards that do not NACK bad keys
uzlonewolf
changed the title
|
Upon further reflection, I think the loop is from what seems to be a static nonce and is not the lack of a NACK. Either way #900 fixes it. The card I'm working on does not NACK, appears to have a static nonce, and seems to be invulnerable to nested, hardnested, and darkside. |
|
The infamous |
|
Seems to be. |
|
Yup, darkside, nested or hardnested will not work on it as you noticed. Should add blacklisting or somehow identify when nonce is fixed and abort correctly |
|
That's not a bad idea, I'll see if I can implement it later. I guess a more generic approach than blacklisting would be to keep a count and break if we get the same nonce more than X times. This also seems to be a dupe of RfidResearchGroup/proxmark3#408 |
|
yup, we have ran into that fixed nonce tag for some time now. If you try darkside etc on that repo it should detect a fixed nonce and quite. |
|
I didn't want to hardcode that nonce since it is possible to get it from a RNG and doesn't help if cards start using different static values, so I added a counter and it now bails out with a new error code (-4) if it doesn't get a different value after 50 tries. |
|
Sounds about like the solution in place, 50tries is way more lenient than needed. If you get the same nonce twice in a row something is fishy. Well, not for darkside but nested. I think if we have 10 times in a row without sync, is a no-show. |
|
True, but 50 is still finished in almost 1/2 the timeout value, so I didn't see a reason to reduce it more. Gives the card a few more chances in case it has a really bad PRNG. |
That is with standard timing or with 's' or 'ss' slow timing options? I would agree with @iceman1001 that 50 is way too much. A weak PRNG still produces 65535 different nonces, therefore the chances for a duplicate nonce is quite low. |
|
Are you going to crack it as well? Or do we leave it with the message because you can get the keys with 'hf mf cgetblk' anyway? |
|
Huh? Why do you think cgetblk would work? |
|
Because I have two cards producing this same nonce - and both are Gen1 UID changeable. |
|
There seems to be a whole family of these cards? |
|
These do not respond to any known backdoor commands and I find them unlikely to be UID changeable (they're from a Vingcard system in a large resort owned by a major international company). |
|
OK. Are you going to implement a key recovery? |
|
I would like to, though I'm not sure how. I completely commented out the duplicate nonce detection and got a list of 67272 keys which it was able to brute force in a couple minutes. Suggestions? |
|
Did you get a correct result? |
|
Yes. |
|
Bruteforce? You mean an online verification of each key until a succesful was found? I have had dubious results trying to get first key out from a fixed nonce card. |
|
With the duplicate nonce check commented out: Both of those keys are correct for this card. I think that time can be slashed by doing a bulk check like |
|
It should work as @uzlonewolf proposes. Suggestions: don't eliminate the duplicate detection but reduce the number of tries. Continue with two equal nonces. Give some warning about long expected run time. There shouldn't be more modifications required although you might want to avoid creating and intersecting two equal lists. |
|
@iceman1001 : do we risk to fry RDV4 with this approach or are a few minutes OK? @uzlonewolf : how many keys did you have to check? What would be the worst case runtime? |
|
I have no idea what the theoretical maximum number of keys is, I only know know what a few tests gave me: This is after rewriting the key check routine to use the bulk check like I just noticed that pressing the button does not abort it, so I'm modifying |
|
|
Also, I reduced the retries from 50 to 10. |
|
@pwpiwi, you still seem to belive that rdv4 will fry during normal operation which is not the case. Regarding nested. |
|
But we do do a nested attack, that's how we get the encrypted stream to begin with. We should be able to figure out the fixed "RNG" number and get even more bits to reduce the number of keys we need to try even more, but I'm too unclear on exactly how that works to do it myself. The only reason multiple nonces are needed for non-static cards is to get a predictable PRNG output. |
|
not really, nested attack uses a timing distance based on the different nonce collected. |
|
Except we only need that timing distance to calculate what the next nonce is going to be. Since we already know that we can just skip that step completely. |
|
but that guess of timing is basis for the offline part with comparing the 16bits of cryptostate, no? Lets see, if you run the nested attach several times against your tag, |
|
Yes, and I'm currently trying to figure out why there are not exactly 2^16 possibilities. I suspect the code is doing something else in addition to the nested attack. If different nonces were available that 2^16 gets reduced significantly as the additional shifts change which bits are available in the recovered 2^32 bits. |
|
I think it removes all possible keystates with faulty parity. That would explain reduction of candidate keys. |
|
And I just noticed the actual paper says "on average there will be 2^16 candidate keys." So, the code probably is correct as it is. The math in there is beyond me :( Without being able to shift to a different part of the key I don't think there's a way to narrow down the candidate list, though I'm still looking at it to see if we can at least squeeze out another bit or 2. |
|
There are 2^48 possible cipher states. We only have 32 bits of known key stream (derived from UID, nt and nt_enc). If there would be only one possible cipher state resulting in a specific key stream bit, then we could reduce to 2^16 possible states (=2^16 possible keys). However, there are several cipher states resulting in a specific key stream bit hence more than 2^16 possible keys. With standard cards we can use two nt/nt_enc pairs and create the intersection of possible keys. The parity check is used to check if we have guessed the correct nt (one that could result in the observed nt_enc). There are still possibilities to guess wrong - therefore @iceman1001 could find pairs even with constant nt cards). |
I am not sure what I should believe. There had been posts in the forum about RDV4 overheating, the Bluetooth module comes with an extra heat spreader, and I would not consider 2 hours of key checking as "normal operation". |
|
I find pairs? @uzlonewolf finds candiate keys. Don't get me wrong, the fixed nonce tags has bothered me for some months now and I am very happy to see progress with finding solutions for it. Let me just recap, to see if I got it right. Is there some way to remove states in the offline part? By using stuff from hardnested? side note |
|
The fixed nonce tags I have do not NACK at all. Both darkside and hardnested fail. Technically nested just uses a known-good key to then do a nested auth to recover bits for an unknown key. The statelist part is an extension to help narrow down the candidate list, and it only generates 2 lists. |
|
Maybe we shold add a dedicated command for fixed nonce tags. Mxing up existing commands to deal with these odd kinds of tags is not optimal. |
|
I'm not sure why a new command is needed, both are nested attacks. The only difference is for the non-fixed nonce tags the first part is run twice to reduce the candidate list to only a few keys to be tried. |
|
no problem. 78000 is few keys? |
|
Yes. Without it there are 2^48 keys. |
|
Put another way, single-pass nested (vs the original 2-pass nested for non-fixed nonce cards) still recovers at least 31 bits out of the 48-bit key. Unless you know of another attack which can do better for these fixed nonce cards, it's the best we've got right now. I'm not opposed to adding a switch to |
|
When compare with complete keyspace then I agree 78000 keys is few. That would be 1 key, 1 known, 30 to go for a 1K card. True that 78000 isn't an average amount of candidate keys. I happy I am not the one who will merge this PR. |
|
It's a card only attack. All we can get is one 32bit nt_enc and the corresponding one nt. I can only think of optimizations in the bulk key check. I am happy to merge it (when it is ready). |
|
Ok, just pushed a couple minor updates. Let me know what you think it needs at this point. Normal PRNG card: Fixed nonce card: |
…tags that has a static nonce. \n See #133 \n See Proxmark/proxmark3#899 \n This solution is based upon the ideas and solutions of @uzlonewolf and @xtigmh . Thanks!
|
It appears we can close this issue. Nice work all. |
When you run
hf mf nestedagainst a card that does not respond at all to a bad key (instead of NACKing it like it should), the pm3 gets stuck in a loop and requires you to pull the USB cable.Adding a
if(BUTTON_PRESS() || usb_poll_validate_length())inside the innerwhile(target_nt[i] == 0)loop invoid MifareNested()fixes it; I'll create a pull request for this in a bit.The text was updated successfully, but these errors were encountered: