Cloning does not work (Galaxy S21 FE) about nfcgate HOT 17 CLOSED

@roussosalex Do you know if relay/replay should work in that case? Currently, I don't have a second rooted device to test it.

Relaying and replaying APDUs does not require successfully setting NFCID or otherwise applying a config stream. This means that relay and replay could work if the devices do not check NFCID (or other static tag data). It depends on your applications, for example, with EMV systems the NFCID is not relevant.

Also do you know if this is a hardware limitation and it's impossible to be fixed or just no solution is found yet? If it's possible to be fixed, I may try to fix it myself after some months when I get some free time.

We actually don't know. Public datasheets of the NFC chipset do not list this problem and we debugged it in detail on OnePlus devices and could not make it work. The NFC chipset just does not respect the NFCID we set. It could also be a chipset configuration option, but finding documentation about possible configuration settings is hard or not even possible with public datasheets.
Feel free to investigate it yourself, it would be very nice to find a solution! If you need a starting point just ask. :-)

from nfcgate.

How did you fix it

To simplify, we discovered that the Embedded Elements (EEs) are interfering with the NFCGate operation. Then, we added code to disable the EEs when emulating and re-enable them when we are done.

This fix has led to fixing #159 as well as the issues with OnePlus devices

from nfcgate.

First, the UIDs you are seeing are not set by NFCGate, they are "random" UIDs generated by the NFC chip (e.g. 0x08E84E52). You can recognize random UIDs with the "0x08" prefix. This is the default behavior of the NFC chip and should happen even if NFCGate is not running or not even installed.

Yeah, I found that about the random UIDs later after I posted the comment.

Though, I didn't know that no solution is known.
Thanks for your hard work trying to help!

from nfcgate.

Thank you for putting in all that effort! It is very unfortunate that nothing has worked so far.

We will read through the logs and hopefully come up with new ideas soon.

Also, the "other" ID you are seeing is for NFC-B and should only be visible before cloning a tag, because after cloning NFCGate locks the NFC chip into the mode for the tag (e.g. NFC-A).

from nfcgate.

Update:
I tried using another phone as a reader to see what is received. It seems like the cloning "works" but it sends wrong data. Firstly, no matter if I'm trying to clone a tag with 4-byte or 7-byte UID, the other phone always receives 4-byte UID. Secondly, the received UID looks completely unrelated to the UID being cloned.

Examples:

• When trying to clone a tag with UID 0x045451721E7380, the other phone receives 0x08395E87 or 0x08AD9A6E or 0x086B9A85 (every time it's different);
• When trying to clone a tag with UID 0xE6B3A5D3, the other phone receives UID 0x08E84E52 or 0x089CE4B7 or 0x08AEDE9F.

Screenshot 1 - what is nfcgate showing:

Screenshot 2 - what is NFC tools showing on the second phone when the ORIGINAL tag is scanned:

Screenshot 3 - what is NFC tools showing on the second phone when the first phone with nfcgate is scanned:

Edit: The second phone reads this random data from the phone with nfcgate, even when nfcgate is closed and screen is off.

from nfcgate.

This issue is not a fault of NFCGate. We have seen similar issues with OnePlus devices:

First, the UIDs you are seeing are not set by NFCGate, they are "random" UIDs generated by the NFC chip (e.g. 0x08E84E52). You can recognize random UIDs with the "0x08" prefix. This is the default behavior of the NFC chip and should happen even if NFCGate is not running or not even installed.

Second, NFCGate correctly sends the NFCID to the NFC chip as seen in the log. Everything works, except the NFC chip does not accept the NFCID and keeps presenting random UIDs. This exact issue is why cloning does not work on any OnePlus device we tested so far (@kleest). Unfortunately, we have not found any solution for this issue yet except switching to a different device.

from nfcgate.

Second, NFCGate correctly sends the NFCID to the NFC chip as seen in the log. Everything works, except the NFC chip does not accept the NFCID and keeps presenting random UIDs. This exact issue is why cloning does not work on any OnePlus device we tested so far (@kleest). Unfortunately, we have not found any solution for this issue yet except switching to a different device.

@roussosalex Do you know if relay/replay should work in that case? Currently, I don't have a second rooted device to test it.

Also do you know if this is a hardware limitation and it's impossible to be fixed or just no solution is found yet? If it's possible to be fixed, I may try to fix it myself after some months when I get some free time.

from nfcgate.

Do you know if relay/replay should work in that case

Replay and relay work even without root, as long as you do not care about setting any "static tag data" such as the NFCID.

Also do you know if this is a hardware limitation

AFAIK the specification requires the NFC chip to support setting the NFCID.

If it's possible to be fixed, I may try to fix it myself after some months when I get some free time.

It's most likely some state-management or configuration issue.
From reading your logfile6.txt, I came up with some theories on what could be the problem:

• the NFCID is being set correctly, but the NFC chip is not in the "right" state to accept a change in the discovery parameters
• perhaps the chip only accepts a change to these discovery parameters the first time the state is "idle"
• maybe the secure element or SIM interfere with the config after is has been set (through e.g. NFCC_CONFIG_CONTROL)
• there is some configuration setting that, perhaps as a side-effect, always enables random NFCIDs (maybe something like CON_DISCOVERY_PARAM)
• some proprietary firmware config could disallow changing the NFCID
• it may also be something completely different.

Some of these theories could be tested. If you would like to disprove any (or all) of them or introduce new theories of your own, it would be very much appreciated!

from nfcgate.

Thank you once again! I will try to investigate it when I have some time.

from nfcgate.

I started by looking at the hook_NFC_SetConfig function and printing the returned value of

globals.hNFC_SetConfig->call<def_NFC_SetConfig>(actual.total(), bin_stream.get())

to the log. It returns 0 (which I found is NCI_STATUS_OK).

I looked at the code of NFC_SetConfig in the nfc library to see what is going on inside. I found it here.

In the function nci_snd_core_set_config (found here), which is called by NFC_SetConfig, I saw that NCI_STATUS_FAILED is returned only if either the memory allocation fails, or the arguments passed are not in the expected format (more precisely, the buffer pointed to by p_param_tlvs). In all other cases the function returns NCI_STATUS_OK.

To me, it looks like the actual config setting is done by this nfc_ncif_send_cmd (p); (the rest is just preparation of the buffer pointed to by p). But the returned value of nci_snd_core_set_config does not depend on it. So, according to the library, nfc_ncif_send_cmd (p); should always succeed? I didn't have time to look further into nfc_ncif_send_cmd, because it looks a lot more complicated.

So my main guesses would be

• nfc_ncif_send_cmd (p); fails silently, because the returned status does not depend on it;
• everything succeeds, but something else immediately resets it (if this is the case, that other thing should be using something other than NFC_SetConfig, because otherwise hook_NFC_SetConfig would be called since it's hooked?).

from nfcgate.

The NFC_SetConfig works as expected and sends the config stream down to the NFC chip, the problem likely lies in the entire system working together, not in any single point or function. This issue might require a deeper understanding of the NFC NCI stack and the inner workings of Android Hardware.

We have prepared test code on the v2-dev-debug-nfcid-153 branch. If you look in nfcd.h, there are several DEBUG_N switches to test with. If you could test the following combinations (check the NFCID after starting NFCGate without cloning anything and the NFCID after cloning a tag, also collect a log):

• any one option and all options: as a baseline
• (DEBUG_1, DEBUG_3) and (DEBUG_1, DEBUG_2, DEBUG_3) may set the NFCID to 04 54 51 72 1E 73 80 after restarting the com.android.nfc process
• (DEBUG_4, DEBUG_5) may set the NFCID after cloning, this would be ideal

Thank you for contributing to the solution for this issue!

from nfcgate.

I've tried all of the combinations you described and in all cases a random ID was presented (both after starting NFCGate and after cloning a tag).

log_10000.txt
log_01000.txt
log_00100.txt
log_00010.txt
log_00001.txt
log_11111.txt
log_10100.txt
log_11100.txt
log_00011.txt

While testing, I noticed that, very rarely (maybe about 5% of the times), the presented ID did not start with 0x08 byte. For example (and again it's different every time it happens):

from nfcgate.

Good news, while looking into #159 we stumbled upon a possible solution for this issue (and other devices, including the OnePlus device limitation). Please try the new debug apk app-debug.zip and confirm if it works for you now!

from nfcgate.

Unfortunately, it still does not work and the app also the app crashes frequently.

log.txt

from nfcgate.

After some bugfixing we have a new debug apk app-debug.zip. Please try it and report if it works.

from nfcgate.

After some bugfixing we have a new debug apk app-debug.zip. Please try it and report if it works.

Now it works! How did you fix it? (Edit: I saw that you commited the changes, so I will take a look in the code)

Here is a log anyway if you need it for additional improvements.
log2.txt

Thank you for your hard work!

from nfcgate.

This fix is now included in v2.4.0

from nfcgate.