I posted this to the net-snmp mailing list Monday and got no reply, so I am trying here.
I am confused and I hope someone can help.
I am writing an SNMP agent for a Cortex M4 application.
The SNMP books I have bought and what I have read on the net indicate that all data fields should be ASN.1 encoded. I know the OIDs are ASN.1 encoded. I am not sure if that applies to other fields like Request ID.
Looking at snmp commands sent by net-snmp, it appears that the Request ID field is a simple (4 byte) 32 bit integer.
Here is a screen shot showing an snmpget transaction monitored through Wireshark:
http://www.ko4bb.com/net-snmp/RequestID.png
It shows the RequestID to be 1750020546 (decimal) and 0x684F31C2 in hex. The data field in Wireshark also shows it to be “68 4f 31 c2”
This is not ASN.1 encoded, otherwise the first 3 bytes would have their bit 7 set to 1 and the last byte would have bit 7 set to 0, meaning the first 3 values would be >0x7F and the last value should be < 0x80
So is ASN.1 not used for the RequestID field?
I added the wireshark tag, as this is purely a Wireshark issue.
The Request ID field, is strictly in ASN.1 BER format, which is 02 04 68 4f 31 c2.
You should be careful that Wireshark is too smart to parse the data and hide some details from you.
Please check the botton panel where 68 4f 31 c2 is highlighted. Wireshark highlights them, but intentionally ignore 02 04 ahead. That's the problem.
As #GuyHarris pointed out in the comment, this Wireshark behavior is configurable. Other packet analyzers (such as Microsoft Network Monitor) might behave differently in the same scenario.
Related
I have started working with the NXP NTAG 424 TT chip together with nfcpy and an Identive SCL3711 Reader/Writer. I can successfully send and receive APDU commands, securely authenticate myself and send and receive commands in encrypted communication mode.
However I can't read or write Data to the chip, and I don't know why. Here is what I do (mostly taken from the NXP application note Page 24):
I send the command "ISO Select NDEF application using DF Name"
00A404C07D276000085010100
Then I perform the secure authentication protocol via AuthenticatEV2First with key 0x00
I try to write some data as follows:
cmd_header = 02000000040000
cmd_data = 00D1FF00 (before padding)
cmd_data = 00D1FF00800000000000000000000000 (after padding)
The complete command which I send looks like this:
cla cmd P1&2| Lc |ISO Header | encrypted Data |LE
90 8D 00 00 1F 02 000000 040000 6688A4D75482FC972C2447A1A20F0AC9C073C1CF506B2BD3 00
However the chip only responds with 917E: "Length Error"" which translates to "Command size not allowed"
What am I doing wrong? It can't be the encryption, I tested that with various other commands (getTTStatus, SetConfiguration) and these all worked fine. I quadruple checked the header. Did I perhaps fail to select the correct File, or did I miss some other steps? Also what does "Command size not allowed" mean? This error is pretty cryptic to me (which is funny when working with encrypted chips :D).
Any help is greatly appreciated!
Best regards,
Phil
The length of "encrypted data" field in your case is 24 bytes, whereas the length which you have mentioned in ISO Header is "040000" i.e. 4 bytes.
Your encrypted data length should match with the length of data you are writing.
In your case there is mismatch in both lengths and resulting in error.
Hope the information is clear.
Cheers!
I was modifying a piece of PC software I wrote to read multiple NDEF records from an NFC tag. However, one of the tags I have contains a record with what seems to be a mangled NDEF header. It's the last record of 6, the other 5 coming in as expected. I've listed it below. For simplicity, all values are listed in hexidecimal and the payload has been truncated.
Record #6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
As you can see, 3 random zero bytes are shoved between what should be the Type Length and Payload Length. I have double checked the Length Field in the TLV and found that it accounts for these 3 bytes. I'm not getting any data truncated off of the end of the TLV due to these added bytes.
I decided to do a sanity check with NXP's TagInfo app to make sure I wasn't just reading the data incorrectly. Checking the data dump from a full scan, I saw that the data does in fact match. I've listed the memory scan below. Only the relevant data points are listed and the payload is, again, truncated.
Memory Dump
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
We thought that maybe this was an issue with padding given that, in this case, the Terminator TLV appears at the end of page 0x3D. However, due to the nature of previous records, this is not always the case. Sometimes, the Terminator TLV shows up in the middle of a page.
However, the strange thing is that, in the same TagInfo app on the NDEF page, it reports the NDEF message as follows.
NDEF Message
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
Somehow, the software has not only removed the 3 extra bytes, but has correctly set the SR bit in the NDEF header. I have double checked this with another NFC app on Android and have confirmed that the other app is able to read the NDEF Message this way as well.
My question is, is there a reason or logic behind how the app is able to correct not only the the added bytes, but also the NDEF Header? I'm not sure if this is Android doing the correction or something else deeper in the NDEF message structure. Either way, I'm looking at the right way to make the correction while not effecting how I read the other 5 records held within this tag.
Those bytes are also part of the payload length
If the record does not have the SR (short record) bit set, then the payload length is 4 bytes long rather than one byte.
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
The first byte is 0x42, which in binary is 0100 0010. If we separate that out, we can see that the record has the ME (or 'Message End') bit set, as well as a TNF ('Type Name Format') of 0x02 - 'MIME Media Record'. The SR bit is bit 4, which is zero in this case.
That's also why they disappear in the version corrected by the TagInfo app - it has set the SR (which is why the header jumps to 0x52) and removed the unnecessary bytes.
I've got a contactless chip card (not bank or SIM) which I can interact by NFC channel (ISO14443, ISO 7816 Part 4).
All I want to get from this card is getting of UID of the card, which can help me to differ one card from others. As I understand this is PAN value which I can get under the tag '5A'.
Firstly, I can send this command to the card
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
and get positive answer (SW:9000) with the AID value.
So, I have AID and I can send such command
00:a4:04:00:LеnAID:<AID>:00
to open file for reading TLV-based info under different Tag, am I right?
But when I send ('5A' - tag for PAN)
00:CA:00:5A:00
I have bad response -> 6E:00
So,
1)Should I change Class value (CLA = 00 for right now)? And for what value?
2)Maybe I have to change INS value for READ RECORD (B0 or B2 or something else) because "The kernel uses the value of the AFL (i.e. tag ‘94’) to issue one or more READ RECORD commands retrieve the Application data elements", in my case tag '5A' for PAN.
If so, what the complete workflow should be for getting PAN?
UPD.
When I sent
ff:ca:00:00:00
I receive
6e:00
For unknown for me reason I couldn't get positive answer on command
FF:CA:00:00:00
I got answer 6E:00
But I found another way how to get card info. I have to execute not one but a sequence of commands:
1) Firstly I have to find out the AID of the applet. If you know AID you can skip this step (2PAY.SYS.DDF in my case)
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
2) Then SELECT APPLICATION
00 A4 04 00 AID-Lenth AID
3) After that we GET PROCESSING OPTIONS
80 A8 00 00 02 83 00 00
4) And READ RECORD
00 B2 01 14 00
For decoding TLV-response I use this utility - https://www.emvlab.org/tlvutils
In response I got not only 5A tag but also others and for right now I have to parse the whole R-APDU for fetching particular tag value.
Is there any java-libs for parsing TLV-response?
I am trying to read and write data on Mifare DESFire cards using ISO 7816-4 APDU commands. I followed the steps:
Select application using {00,A4,04,00,07,D2,76,00,00,85,01,00}.
I get the response as 9100.
Then I select file using {00,A4,00,00,02,3F,00} and I get the response as 9100.
Then I try to read the file using command {00,B0,00,00,03} and I get an error with code 6A86.
Now I want to know the exact commands to read and write the data on the cards. I think I still don't get the meaning of P1 and P2 in read/write commands. I already tried many other combinations but I always get errors like 6A86, 6982, etc.
I assume you receive the status word 9000 on success. If you actually receive 9100 when using ISO/IEC 7816-4 basic inter-industry command APDUs something very strange must be going on. 91xx status words should only be returned when you use the ISO/IEC 7816-4 wrapped command set (i.e. when the class byte of the command APDU is set to 0x90).
Let's look at what you currently do:
You start my selecting the MIFARE DESFire ISO AID D2760000850100:
00 A4 0400 07 D2760000850100
This makes sure that the card is in ISO/IEC 7816-4 framing mode and automatically selects the MF (master file; i.e. the PICC level application).
You then, again(!), select the MF (PICC level application):
00 A4 0000 02 3F00
So you are now at the same level as after step 4.
Finally, you try to read 3 bytes starting at offset 0 from the currently selected file using the READ BINARY APDU:
00 B0 0000 03
Since the currently selected file is the MF you can't read binary data from it. The MF does not have a data part. Consequently, the card reports the error code 6A86 ("wrong parameter P1 and/or P2") as it tries to tell you that reading at offset 0 (P1|P2 = 0x0000) from the MF (currently selected file indicated by the upper bit of P1 being zero) makes no sense.
Therefore, before you can read binary data, you need to select an elementary file (EF), probably even located in a different application (dedicated file, DF), that contains an actual data part. This can be done bei either explicitly sending SELECT commands for EF (and, if necessary, the DF) or by implicitly selecting the EF using a short file identifier in P1 of the first read binary command. In the latter case, you would set the upper bit of P1 to one to indicate that the remaining part of P1 encodes a short file ID. In both cases you would need to know the file/application identifiers of the files and applications that you want to read from.
Apple Wallet supports the Value Added Services protocol. I want to use this to read the Walgreens loyalty card (the only NFC-enabled loyalty card I have), to better understand the technology.
The APDU commands needed for this can be found on page 68 in the NFC.15 spec, where APDU command SELECT FILE is described:
http://www.gsma.com/digitalcommerce/wp-content/uploads/2014/07/NFC.15-Version-1.0-Mobile-Commerce-NFC-Coupons-and-Acceptance-Technical-Proposal.pdf
Trancieving the following APDU SELECT FILE to the Apple Watch (while having the card selected)
00 A4 04 00 07 A0 00 00 05 59 00 01 00
Returns
6A 82 (File not found)
From the documentation I expected this command to select the present loyalty card file, or a special response containing a list of more specific IDs if multiple files are available. What am I doing wrong? Does the Apple Wallet use a custom RID?
Karl, You need the Merchant ID or Application ID. Without the AID (Based on the NFC Spec) you will not be able to get the Customer ID or even get any other data from the Reward pass.
Check this blog entry for more details:
http://flomio.com/2016/07/nfc-enabled-passes-on-apple-wallet/
In case anyone is wondering if simply specifying a different 2 byte Application Code after the RID of A0 00 00 05 59, which the NFC.15 document assumes is 00 01 will yield a successful file/application selection (SW 90 00), it won't. I tried all 65,536 combinations of these two bytes with no luck. So yes, some additional information is clearly needed. The link above is now dead, so I have raised a support inquiry with Apple Pay (as other posts mention) to see if the documentation required by NFC terminal makers/integrators can be made available under NDA. So far the Apple support team is giving me a bit of a runaround but I think once they understand that I'm seeking non public documentation I'll get the information I need :) I'll keep this post updated if they respond to my inquiry.