NFC issues

[hexan86]

Describe the bug.

NFC function presents issues copying data from tags and it remains stuck.

Reproduction

Tag used: Mifare 1K

1. Added the Tag keys to user_dict. #Gained with PM3: hf mf autopwn -k FFFFFFFFFFFF
2. Readed the Tag with Flipper. #It finds the keys, copies the Tag, it seems ok
3. Selected the cloned Tag from the Flipper and emulate it.
4. Attack the Flipper emulated Tag with PM3. #hf mf autopwn -k FFFFFFFFFFFF
5. It successfully recover the UID, but all other blocks are empty.
6. Re-try the autopwn with another of the known keys, i.e. AABBCCDDEEFF.
7. Autopwn recognizes the key as existent in the right block.
8. But fails the autopwn with message "AcquireEncryptedNonces: Can't select card (UID)"
9. At this point I have to press multiple times "back" on the Flipper to exit emulation and I can't select any other tag. It keeps going back to the list and I have to exit to the main menu or reboot the Flipper.

Also leaving the Flipper in emulation mode for a while, without interacting with a reader, will require to press multiple times "back" to get out.

Note that if I copy a Tag with the Flipper, convert the .nfc to .bin, upload it to my Chameleon Tiny, then the PM3 is perfectly able to perform autopwn.

Target

No response

Logs

No response

Anything else?

No response

[NathanielJS1541]

"AcquireEncryptedNonces: Can't select card (UID)"

This usually indicates bad coupling between the two antennas, try changing the spacing between them with something non-conductive to get consistent reads.

With the other issue you describe, is this a specific card you have problems with? Are you able to provide more details i.e. a type of card (I'm guessing it's Mifare Classic, but is it magic? EV1? 1k? etc...), card dump etc?

[hexan86]

"AcquireEncryptedNonces: Can't select card (UID)"

This usually indicates bad coupling between the two antennas, try changing the spacing between them with something non-conductive to get consistent reads.

With the other issue you describe, is this a specific card you have problems with? Are you able to provide more details i.e. a type of card, card dump etc?

I'm using a paper box to keep a distance of 20 millimiters between Flipper and PM3 RDV2.

Mifare Ultralight seem to work fine, the PM3 is getting a full dump from the Flipper. I'm working mainly with Mifare Classic 1K and 4K. There's something in Darkside that is corrupting the Flipper.

If I run autopwn on the PM3, Darkside goes forever. When I remove the Flipper, this is stuck on emulating, so I've to reboot it. But if I start the emulation again (notice that I haven't stopped Darkside) and put the Flipper back over the PM3, even for few seconds, it gets stuck again. Proxspace become unresponsive too, even pressing the button or unplugging the PM3.

This one is a MC1K. Even with the correct key there's something wrong:

[NathanielJS1541]

There's something in Darkside that is corrupting the Flipper.

How exactly do you mean "corrupting"?

If I run autopwn on the PM3

I don't really see the point of running autopwn on a Flipper? Why not just get the dump off of the flipper?

When I remove the Flipper, this is stuck on emulating, so I've to reboot it.

Is it actually stuck or just slow? If i press back the emulation closes eventually (~1 minute or so). I presume this is because the darkside attack is spamming it to look at the error responses, so it's still trying to generate respoonses to the commands before closing the app. Either that or it's writing something to the SD card. I can take a look into this if I get the time.

Proxspace become unresponsive too, even pressing the button or unplugging the PM3.

This is probably because the darkside attack relies on the predictable PRNG of some Mifare Classic cards. I'm not sure why it doesn't detect that the darkside attack won't work on the Flipper, maybe the Flipper doesn't respond in a way it expects. I'll take a look at that.

This one is a MC1K. Even with the correct key there's something wrong:

What is wrong here? Have you checked that the output is different to the original card, or are you just seeing something you don't expect? The access bits are 787788. These can be checked in the pm3 client to check what they mean: As you can see here, neither key has read access on any key, so the response you are showing is exactly what I would expect. If you could show the output of the same command against the original card to show what is wrong, that would be helpful.

I hope you also realise that the reason the pm3 tries the darkside attack is because the fchk command does not find any keys, and afaik the darkside attack is the only attack that doesn't require a known key. This points towards the Flipper not responding correctly for the fchk command, which may be an implementation problem. I will look into this and why this may be.

The output of hf search should show that the PRNG is "hard", which means the darkside attach should not work on the Flipper.

I am able to confirm that the fchk command does not work correctly on the flipper, and it seems like this may be one of your issues running autopwn:

In the meantime here are some things for you to try: The --slow flag is most likely going to be needed, as an emulator like this won't be able to respond to the commands as quickly as the pm3 is expecting.

1. Specify a key and a sector when running hf mf autopwn: i.e. hf mf autopwn -s 0 -a -k FFFFFFFFFFFF --slow. This should remove reliance on fchk to recover a key, thus avoiding the fallback to darkside as it is the only attack that can work without any known keys.
2. See if you can use hf mf chk or hf mf autopwn -l --slow as this may work around the flipper not working with the fchk command. I'm not sure what pm3 firmware you're running but the one I have compiled at the moment crashes when I use hf mf chk on more than a couple of sectors at a time, so watch out for that...
3. Are these issues present on the OFW? If they are, then that should be where you open the issue, as this Firmware is built on top of the official Firmware. If they are not then they need to be solved here.

I would also strongly encourage you to consider why you are running key recovery tools on an emulator, though. You can just pull the dump off of the Flipper. Running these tools is unlikely to ever run that well on an emulator and is really outside the use-case of the Flipper. Most of these key recovery tools absolutely thrash the card as fast as possible, and the processor in the Flipper will probably struggle to keep up with that.

[NathanielJS1541]

I forgot to mention, assuming the antenna coupling is good AcquireEncryptedNonces: Can't select card (UID) is likely because the Flipper can't prepare the next response in time. This is the issue that may improve by using the --slow flag, but you'll have to try it and see.

[NathanielJS1541]

The better option instead of using timing-critical and intensive key recovery tools is probably just to add the option on the Flipper to have the card respond to magic commands when emulating. This would let you access the card contents easily with the hf mf cview and hf mf csave commands, without having to use any key recovery methods. This could be just another menu item on the card screen (i.e. Emulate and Emulate (Magic)). I can work on this if you're interested, just let me know if that is an acceptable solution to your issue.

[hexan86]

@NathanielJS1541

Thank you for all your responses.

The point, or at least my point, to run autopwn on the Flipper is the curiosity of it an see the results, the same way I've tried the same thing with my Chameleon Tiny. Also, to test the ability of the Flipper to copy and act as an original card/tag and the limits. Other than try to help developers to improve their work. You can also suppose that one is interested in attacking a Flipper owned by somebody else and he can't download the dump from the Flipper itself.

You were right about the time, it seems to be stuck, instead it's only slow or still processing.

The --slow flag is getting an hardnested start, but immediatly it goes back to AcquireEncryptedNonces: Can't select card (UID)

First of all, this is the hf search result: Flipper Original

Then autopwn: Flipper: 1 2 Original: 1 2 3 4 (This, however, can be a problem related to this specific Tag and its security, because with other MC1K I can dump the Flipper emulation, so still not sure)

The sector 1 that I was reading is working correctly, I saw a problem that wasn't there.

hf mf chk Flipper Original

You're right, I still haven't tried on the OFW, as soon as I can I'll try and I'll let you know.

I really want to thank you for your interest and your time!

[NathanielJS1541]

Thanks for all that information, I'll try and break down some stuff I've noticed about all this:

Limitations of the Flipper for key recovery attacks

The point, or at least my point, to run autopwn on the Flipper is the curiosity of it an see the results, the same way I've tried the same thing with my Chameleon Tiny

This is a fair enough reason, and curiosity is always a good thing. The reason I think this problem exists on the Flipper and not the Chameleon is because at the end of the day there is a lot more going on with the Flipper: The Flipper uses the FreeRTOS Kernel to allow it to run multiple tasks and schedule them etc. You may have noticed that you can be connected to the Flipper via Bluetooth or a COM port and run things like NFC emulation at the same time. This is because they are running in seperate tasks but sharing time on the thread, and this can cause problems if a task (like the NFC emulation, for example) is being thrashed by something like the proxmark during a hardnested attack.

It's purely speculation but this could be why it takes a while for things to catch up after you run the attack and quit the app; lots of interrupts or tasks are enqueued and have to be processed before the app can close. Please take all of that with a very large pinch of salt :salt: - I'm not an expert and that is my layman's guess at what's going on.

Contrast this to something like the Chameleon with none of that overhead and you can maybe see why it's able to stick to the timings much better than the Flipper when running these attacks. For that reason I don't think the Flipper will ever be compatable with these attacks, though I'd be happy to be proved wrong - I just don't have the time to sink into something that seems unfeasable.

Possible usecases

You can also suppose that one is interested in attacking a Flipper owned by somebody else and he can't download the dump from the Flipper itself.

I see your point, but unfortunately even if autopwn did work, any more than a couple of non-default sectors and it would genuinely be much faster to just pull out the SD and grab the files :grin:... On my hardware the hardnested attack takes ~80 seconds per sector, even at 1 sector I can probably copy the file faster.

AcquireEncryptedNonces: Can't select card (UID)

The --slow flag is getting an hardnested start, but immediatly it goes back to AcquireEncryptedNonces: Can't select card (UID)

I'm getting the exact same behaviour - at least it's reproducible I guess... I think the limited time for each task on the thread is to blame for this.

First of all, this is the hf search result: Flipper Original

Just an FYI, you can embed images in comments etc by adding a ! to the start of the link, and making sure the link is to the image itself (i.e. right click on the image from your links and press "copy link"), or just paste an image from the clipboard to the comment.

Mifare Classic EV1 cards

(This, however, can be a problem related to this specific Tag and its security, because with other MC1K I can dump the Flipper emulation, so still not sure)

Judging by the output of hf search from your original command, your hunch is correct:

The fact that it shows you a tag signature indicates that it is a Mifare Classic EV1, something the client doesn't explicitly tell you.

Mifare Classic EV1s have two extra sectors (citation needed...) at the end I think, which have fixed keys. That is where the tag signature is stored, along with some modulation strength modifiers, and I'm not sure what else. But those are where you are getting the "Partial Dump" error from, as I don't think they can be read like normal sectors and that seems to not be accounted for in the pm3 client yet when dumping the tag. If you run hf mf autopwn -v with the original card you should see it pull the key 4B791BEA7BCC or similar seemingly out of thin air:

That key is for one of the sectors 16 or 17, and a standard Mifare Classic 1k would only go up to sector 15. The error is nothing to worry about and the card's contents have been correctly dumped. The rest of the keys in these special sectors can also be cracked, and it is used because it is guarenteed to be a usable sector for the hardnested attack on EV1 cards:

You can actually see these keys in mfc_default_keys.dic as they seem to be standard across most if not all EV1 cards:

The sector 1 that I was reading is working correctly, I saw a problem that wasn't there.

I suspect the reason you're not used to seeing this is I think the pm3 client overlays the keys it discovers over that of the read blocks when you create a dump with autopwn etc., it doesn't just output the results of rdbl like you were looking at.

Fin

Sorry for the long response, but I hope that explains everything you are seeing.

Other than that give OFW a try, and if NFC behaves the same then you can raise a similar issue with them if you'd like and close this one, although I think it is unlikely to ever be able to behave as well as the Chameleon for reasons I've stated above.

[hexan86]

Thank you again for answering and I appreciate the long response!

I just tried with the OFW and the autopwn attempt fails in the same way, but I've noticed a difference: With Xtreme, if I start the emulation and let it run for a while (even without interacting with the PM3, but leaving it there on the desk), when I press the "back" button it takes some time to exit. In addition to this, going back to the NFC main list, is not possible to select another Tag. Like, it fails and goes back to the main list.

With the OFW this is not happening, when the back button is pressed it immediatly goes back to the Tag menu, where I can press back another time and easily select another Tag from the main list.

So, the attack maybe isn't possible, but there's something else.

I'll now close this issue, because the conversation is gone a little far from the point that there is, in effect, a problem in this FW with the emulation of NFC tags.

I really hope that this can help figure out what and solve it. I can't thank you enough for your time, your patience and your help!