NTAG424 ChangeFileSettings from factory default

bettse · ‎09-26-2021

I'm working to script personalizing an NTAG424 and I keep running into an issue. The settings I want are plaintext UID, Counter, and CMAC mirroring ("40e0eec1ffe01900002c0000140000350000"), but when authenticating and sending a ChangeFileSettings in full mode (encrypted + mact), I get back "917e". However, if I use the example config from section 6.9 of AN12196 ("4000E0C1F121200000430000430000"), it is successful, and subsequently I can send the config of my choice and it works correctly.

1) Any reason my config ("40e0eec1ffe01900002c0000140000350000") might be internally consistent and cause that error?

2) Is their anything about the factory default NTAG424 that could limit the initial file settings it can be configure with?

bettse · ‎10-20-2021

Is this still being looked into, or is this just a flaw in the NTAG424?

Kan_Li · ‎11-01-2021

Hi @bettse ,

I have consulted the expert regarding your issue, and just had some comments from there, please kindly refer to the following for details.

It is really strange that they get 917E with this procedure and settings which look good. It works on my end though. Their procedure and settings are correct. Also strange that it works when they use “mine” settings (this rules out that maybe session keys are not constructed well). 917E error is usually thrown if ChangeAccessRights for NDEF file are set to one of the keys, but command payload is provided in plain, instead of Enc + maced.

I do set:

FileID=02;

FileOption=40;

AccessBytes=E0EE;

SDMOptions=C1;

SDMAccessBytes=FFE0;

VCUIDOffset=190000;

SDMReadCtrOffset=2C0000;

SDMMACInputOffset=140000;

SDMMACOffset=350000;

Answers to both below questions are NO.

At the moment I do not see any issue. ANY additional info from customer would greatly help. Maybe construction of Session Keys is not implemented fully correct, sharing source code maybe?

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

bettse · ‎10-07-2021

I haven't seen anything on this in a week. Is their anything else I can provide to assist with troubleshooting?

bettse · ‎09-27-2021

Something like this?

NTAG424:send [select app] sending <Buffer 00 a4 04 0c 07 d2 76 00 00 85 01 01 00> +0ms
NTAG424:recv [select app] received data <Buffer 90 00> +0ms
NTAG424:send [select file] sending <Buffer 00 a4 00 0c 02 e1 04 00> +4ms
NTAG424:recv [select file] received data <Buffer 90 00> +3ms
NTAG424:send [read ndef] sending <Buffer 00 b0 00 00 80> +3ms
NTAG424:recv [read ndef] received data <Buffer 00 52 d1 01 4e 55 04 61 63 63 65 73 73 67 72 61 6e 74 65 64 2e 65 72 69 63 62 65 74 74 73 2e 64 65 76 2f 3f 75 69 64 3d 30 30 30 30 30 30 30 30 30 30 ... 80 more bytes> +6ms
NTAG424:send [get file settings] sending <Buffer 90 f5 00 00 01 02 00> +7ms
NTAG424:recv [get file settings] received data <Buffer 00 00 e0 ee 00 01 00 91 00> +4ms
NTAG424:send [select file] sending <Buffer 00 a4 00 0c 02 e1 04 00> +4ms
NTAG424:recv [select file] received data <Buffer 90 00> +3ms
NTAG424:send [write ndef] sending <Buffer 00 d6 00 00 54 00 52 d1 01 4e 55 04 61 63 63 65 73 73 67 72 61 6e 74 65 64 2e 65 72 69 63 62 65 74 74 73 2e 64 65 76 2f 3f 75 69 64 3d 30 30 30 30 30 ... 39 more bytes> +3ms
NTAG424:recv [write ndef] received data <Buffer 90 00> +10ms
NTAG424:send [authenticate] sending <Buffer 90 71 00 00 02 00 00 00> +9ms
NTAG424:recv [authenticate] received data <Buffer 24 2d e8 c6 98 2b c1 87 65 dd 06 13 f7 69 d9 2a 91 af> +6ms
NTAG424:send [set up RndA] sending <Buffer 90 af 00 00 20 9f 88 25 5d 36 5c 47 8d 82 7f 5b 16 99 97 cd ca 2b 0d b2 b8 90 0f 95 8f b5 3e 3a f2 e4 b8 d1 78 00> +6ms
NTAG424:recv [set up RndA] received data <Buffer 3d 21 16 f9 b4 35 2f 5d c9 59 fa d5 c3 c7 f4 e4 f9 00 9e 96 17 5c c1 91 6b 29 86 d1 44 80 8c 37 91 00> +6ms
NTAG424:send [set file settings] sending <Buffer 90 5f 00 00 29 02 95 bd b4 67 79 d0 e6 b6 1a 1e de a2 74 55 cb f5 d4 a4 53 1b 15 93 a7 d5 f5 44 8f b0 c0 f6 fe 43 40 ae 48 e3 5f da 47 e7 00> +8ms
NTAG424:recv [set file settings] received data <Buffer 91 7e> +6ms

Kan_Li · ‎09-30-2021

Hi @bettse ,

Thanks for the information! Indeed 91 7E means "Length of command string invalid" . Comparing the CmdData part from your command and the example from AN12196, seems there is difference in command length.

Would you please specify what 350000 is used for? Thanks for your patience!

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

bettse · ‎09-30-2021

Hi Kan,

>Comparing the CmdData part from your command and the example from AN12196, seems there is difference in command length.

Yup; they're just mirroring encrypted data, while I'm mirroring uid, counter, and cmac.

>Would you please specify what 350000 is used for?

0x350000 is the SDMMACOffset

Just for completeness, 0x190000 is the UIDOffset, 0x2c0000 is the SDMReadCtrOffset and 0x140000 is the SDMMACInputOffset.

As mentioned before, this is a particularly curious problem since I can use that same command _after_ setting the settings using the example from AN12196. Only when going from the factory does it seem to be an issue.

Kan_Li · ‎10-08-2021

Hi @bettse ,

Do you mean if you run the example in section 6.9 from AN12196, then run your own commands as above, both processes are successful, right? Is it possible to share the successful log for the above case? I may check it from my side.

Thanks for your patience!

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

bettse · ‎10-09-2021

> Do you mean if you run the example in section 6.9 from AN12196, then run your own commands as above, both processes are successful, right?

Correct. And that is that is exactly what I said when I started this post 2 weeks ago.

>Is it possible to share the successful log for the above case?

Unfortunately no. I don't have any more factory cards left to produce a log with. Last night I decided to just use the method of setting the example and then my preferred setting since I hadn't seen any response to my last message after 24 hours. If NXP would like to send me more NTAG424s so I can produce a log, I'm open to that, but I'm not sinking more money into them.

Kan_Li · ‎09-27-2021

Hi @bettse ,

Is it possible to share the full log for a review? Thanks for your patience!

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------