Is it possible using ATR to determine whether I have ISO14443A or ISO14443B type card? If yes, how?
As mictter correctly explained, a real ATR only exists for ISO 7816 contact cards. I can follow the argumentation that the ISO 14443 equivalent could be the ATQA/ATQB as this is the first answer you get from tags after activation, though I would rather say that the equvalent of the ATR is a combination of ATQA + SAK + ATS (for Type A) and a combination of ATQB + Answer to ATTRIB (for Type B).
Regarding the ATR you see, I assume that this is a PC/SC-emulated ATR according to the PC/SC specification.
For smartcards (ISO 14443-4 transport protocol) this ATR would have the form
3B 8n 80 01 T[1]..T[n] xx
with T[1] to T[n] being
the ATS historical bytes for ISO 14443 Type A, or
a concatenation of the ATQB application data (T[1] T[2] T[3] T[4]), the ATQB protocol information field (T[5] T[6] T[7]) and the ATTRIB MBLI field (T[8]).
So you might be able to do some form of matching to guess if it is a Type A or B smartcard. I.e. if n == 8 and the parameters in T[1] to T[n] match something that you expect for those fields of a Type B card. Still I doubt that you will get reliable results for arbitrary cards.
For contactless memory cards, the situation is certainly better. For these cards, the emulated ATR looks like this:
3B 8n 80 01 T[1]..T[n] xx
with T[1] to T[n] containing an application identifier presence indicator (tag 4F). So T[1] to T[n] typically look something like this:
80 4F yy A000000306 ss nnnn 00000000
with ss identifying the card's protocol:
0x01: ISO 14443-1 Type A
0x02: ISO 14443-2 Type A
0x03: ISO 14443-3 Type A
0x05: ISO 14443-1 Type B
0x06: ISO 14443-2 Type B
0x07: ISO 14443-3 Type B
and nnnn identifying the card name (see the PC/SC specifications for a full list).
ATR exists for contact smartcards only. For contactless cards, its equivalent is called ATQ, and it comes in two variations: ATQ-A and ATQ-B, for each of the two ISO14443 types.
So the way I'd recommend to go is:
The reader sends both REQ-A and REQ-B, polling to see if there are contactless cards in range.
If a card responds with REQ-A, it is Type A; or if it's REQ-B, it is Type B.
The contactless reader's drivers should pass on this information to your software.
I recommend you get hold of a copy of ISO 14443-3 standard, it explain the initial steps of the card discovery and anticollision protocol, so you can see the differences between types A and B.
#haythem souissi
You can find list of card's in pcsc3_v2.01.09_sup (http://pcscworkgroup.com/Download/Specifications/pcsc3_v2.01.09_sup.pdf)
Related
I started reading into the topic of NFC/Smartcard-Communication and I found many different standards and commands depending on the Tag type (for example see here)
I also came across the APDU-commands which seem universal to the communication of nfc/smartcards?
Does this mean, that these higher level protocols are all based on apdu and can be translated?
As an example, I found NFC 14443-A commands implemented with the android.nfc.tech.NfcA library, such as:
Action
Byte
Read
0x30
Write
0xA2
And APDU commands like these:
Action
CLA
INS
P1
P2
LC
READ BINARY
0xFF
0xB0
...
...
...
UPDATE BINARY
0xFF
0xD6
...
...
...
GET DATA
0xFF
0xCA
...
...
...
MIFARE CLASSIC READ
0xFF
0xF3
...
...
...
MIFARE CLASSIC WRITE
0xFF
0xF4
...
...
...
The commands seem to be completely different.
It would also help alot, if someone could point to good documentation on the topic
Documentation I have found so far:
The Android documentation on nfca (Link)
APDU description on wikipedia Link
(The german version contains some return codes)
APDU commands (by a card-reader manufacturer) Link
You have it a bit wrong, 14443-3A is lower level that APDU's which come from the higher level ISO 7816 protocol.
But the Byte's ( 0x30 and 0xA2) you reference as NFC 14443-A are not from NFC 14443-A but look like vendor specific Mifare Ultralight protocol commands which are again above NFC 14443-A
There is also a complication and probably the reason you are confused with APDU's you listed according to the ISO 7816 spec, all the APDU's you specified have a CLA of 0xFF are "invalid".
The reason for this is that a USB readers also use ISO 7816 for the host CPU to talk the NFC chip to work mainly with NFC Type 4 Tags, because 0xFF are invalid for ISO 7816 the reader uses them for other non ISO 7816 things the NFC chip can do, e.g. communicate to non standard Mifare classic commands, turn on/off the LED's on the USB reader, etc
So really CLA's of 0xFF are just a way to wrap other commands.
Or in a rough pictorial form
I would read as much of the Standard specification documents shown in the Stackoverflow you linked to and I wrote. There are a lot of specifications used/part used
I know that they are really pay for items but they are out there on the Internet.
e.g.
http://www.emutag.com/iso/14443-3.pdf
http://www.emutag.com/iso/14443-4.pdf
For the higher level NDEF stuff https://github.com/haldean/ndef/tree/master/docs
For the Various NFC Forum Standards
Google Index of the 4 Types
I'm interfacing with a smart card (ISO 7816-4)
I have been given the below C-APDU to read a value:
CLA = 0x90
INS = 0x4C
p1 = 0x00
p2 = 0x00
length = 4
parameters = empty
Which returns the response 00000 2f4 9000
(9000 being what I understand to be the SW1/SW2, and the 2f4 part of that response contains the relevant data that I want to change)
Given this provided info, is it possible to determine what modifications to this C-APDU would I need to make to instead UPDATE this data (2f4) to be a different value?
I am quite new to this, and am trying to learn, so thank you for your responses.
My understanding is that CLA of 90 means a proprietary command set and an instruction (INS) 4C does not match any of the industry instruction commands.
Thus as this looks like a proprietary read command it is most likely that the update command is proprietary to the hardware you are issuing it to, so impossible to guess what it should be.
Recently I have been trying to save list of hostnames from captured DHCP packets. I have found out, every DHCP hostname (option 12) should have form defined in RFC 1035. So if I understand it correctly, hostname should be encoded in 7-bit ASCII and have other restrictions like:
- name should not start with digit and should omit some forbidden characters.
Almost every device I have encountered in packets fulfill this constraint, but not Windows devices (Vendor ID MSFT 5.0). IMHO Windows DHCP client takes computer (mobile) name and fill it in hostname option.
Problem occurs, when computer name is set for example to "Lukáš-PC". Wireshark display this hostname as Luk\240\347-PC. (240 and 347 are numbers in octal). To see for myself I have printed values in packets with printf("%hhu", c) (C language).
á = 160
š = 231
IMHO I think this is simple char variable overflow. I tried deduce original value from overflow value, but I haven't found any relation between character and known encodings. So my questions are:
Is there any way to convert these values back to original?
If yes, what was original character encoding, when overflow happened?
Thanks.
Default char is usually signed, and extends to int when passed to a variadic function. To ensure that it is printed unsigned, use printf("%hhu", c) or printf("%d", (unsigned char)c);.
The correct encoding is impossible to know because it depends on each system's settings.
Note that any compliant systems MUST encode names according to RFC 3490, but Windows seems to enjoy violating standards.
The characters á and š that you are seing are encoded using code page 852 (Latin-2 - Central European languages).
Unfortunately there is no simple way how you can figure out the encoding used only by looking at DHCP requests. In principle the DHCP client can use any code page it wants. If you are working in a private/controlled network, then it is probably safe to assume the all clients are using the same code page and explicitly encode the strings using that particular code page.
i am looking for APDU to find UID of contact less ISO 14443 smart card and how to use it to print in Linux terminal. Problem is that i found many people talking about it, but there is no solution. Can anyone help is this regard???
Thanks
"Get Data Command" is defined in PCSC 3 v2. If your driver is PCSC v2 compliant, you can get UID using it:
Class = 0xFF
INS = 0xCA
P1 = 0x00
P2 = 0x00
Le = 0x00 (return full length: ISO14443A single 4 bytes, double 7 bytes, triple 10 bytes, for ISO14443B 4 bytes PUPI, for 15693 8 bytes UID)
Returned value is:
Data+SW1SW2
See the other answer, it is likely that most readers do support the pass through to the card reader by now.
Nobody can help as the UID is specified in the ISO 14443 T=CL transport protocol while APDU's are specified in the ISO 7816 application layer protocol.
So you need access to a lower level API for your contactless reader. PCSC will not suffice (unless there has been a pass through implemented for the specific reader that returns the UID).
I wonder how mobile phone companies generate both PIN and PUK for their SIM cards?
I have a large database of already generated codes, this database contains 3 columns:
* MSIN : Mobile Subscriber Identification Number (10 digits)
* PIN : Personal Identification Number (4 digits)
* PUK : Personal Unblocking Code (8 digits)
So far, maybe both PIN and PUK are generated from MSIN because the MSIN column is incrementing, while others, are generated with a logic, something like;
MSIN PIN PUK
1000000000 3234 20005627
1000000001 5993 92870018
1000000002 3465 30327846
...
is it possible to know how this serials are generated? Using the existing database is it possible to guess the algo used?
I'm asking this for the sake of knowledge only not to use the provided information in any illegal activity ;)
thanx.
UPDATE
I searched for how many times some pin codes are repeated and found this
0000 –> 261 times
1111 –> 429982 times
2222 –> 275
3333 –> 233
4444 –> 279
5555 –> 277
6666 –> 242
7777 –> 263
8888 –> 249
9999 –> 242
the pin 1111 is used more than others! so maybe the algo is changed from time to time.. or ther's no logic at all inside :(
UPDATE 2
I checked the MSIN and found that they make jumps in the incrementing system, so for example;
1011000000
1011000001
… here they followed incrementing until 1011499999
1011499999 and they jumped to 1031000000
1031000000
… the same thing here
1031299999
1131000000
…
this leads to an idea that whenever they want to issue new cards, lets say 500 000 cards, they start with a new MSIN that doesn't follow the incrementing rule in the database and the may change the algo behind the code generation (that's why we find in some cases they issued all the next cards with pin 1111)
The answer can go from really easy to pretty complex.
If I had to design the system, the f function (Pin,Puk) = f(MSIN) wouldn't be easy to guess, and, moreover, not reversible (meaning if you know (pin,puk) you cannot guess MSIN).
Because the subject is around security and payment, you can probably expect a complex function.
Unless it is documented somewhere on the net (which I doubt) it is very unlikely you will find the function f.
If we make the assumption that PUK/PIN are generated from the MSIN, there's a virtually infinite number of ways they could be doing this. To take one (reasonable) example, they could be using an HMAC. Even assuming you knew what hash algorithm they're using, you'd still have to determine the secret key, and the search space for that is on the order of 2^160 (for HMAC-SHA1) - totally impractical to search exhaustively.
The only chance you have is if they're doing something stupid, like using an easily guessed or determined algorithm to generate the PIN/PUK - and there's no practical mechanical procedure to work that out, just trial, error, and intuition.
Usually its not the mobile network operator who generates the PIN and PUK. The SIM card manufacturer does this unless ordered otherwise by the operator.
What makes you believing that one can calculate SIM and/or PUK from the MSIN? Neither the network operator nor the SIM manufacturer would have any advantage from this. I would assume that PIN and PUK are as random as economically feasible in order to implement the intended security.
However, I find the 1111 anomaly interesting. Is your sample right from manufacturing? Or did you get an HLR dump? The latter one might provide an explanation for the 1111 cumulation: People change their PIN to something easy to remember and to type, 1111 would be the most common candidate for this.