how to Modify the access bits of the sector trailer in Mifare Classic 1k. I want toauthenticate sector.
Modifying access bits is carried out by the same methods as writing normal blocks. You only aim at block 3 of the sector you want to alter access to. Taking into account the specs of the access bits present in block 3 of each sector (see chapter 8.7.1 from spec). A valid control bits combination along with the desired keys (A + B) must be specified (read/write operations on Mifare Classic Cards are performed at a block level basis).
For example if you want keyA-or-keyB-read operations available on any block of the sector and keyB-only-write permissions you can use a combination of [C1, C2, C3] = [0x78, 0x77, 0x88]. As you have to specify A and B keys (assuming all 0xAA for A key and all 0xBB por B key) the block data to write would be (take into consideration that byte 9 is unused):
byte authBlockData[] = {(byte) 0xAA, (byte) 0xAA, (byte) 0xAA, (byte)
0xAA,(byte) 0xAA, (byte) 0xAA, 0x78, 0x77,
(byte) 0x88, 0x00, (byte) 0xBB,(byte) 0xBB,(byte) 0xBB,(byte) 0xBB,(byte)
0xBB,(byte) 0xBB};
Related
I am testing with Mifare-Ultralight nfc card. It is new and not have private key.
NFC Tools app and NXP TagInfo app, show me a difference in bytes read respect to my read data. result 1 and result 2. That why I suppose my code is wrong
my code:
byte[] key = new byte[]{(byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF};
StringBuilder result = new StringBuilder();
for(int i=0;i<64;i+=4){
if(util.authenticate(i, 0, key)){
for(int j=i;j<i+4;j++){
byte[] readData = util.read_block(i);
if(readData != null){
result.append(NfcUtil.toHexString(readData));
}
}
}
}
All authenticate in blocks return false, even I tried all key in extended-std.keys
I tried commenting authenticate method, but then the result of data is different. I think the problem is here.
047BB94E8B700000FBA30000E1103E00277E047BB94E8B700000FBA30000E1103E00277E047BB94E8B700000FBA30000E1103E00277E047BB94E8B700000FBA30000E1103E00277E0312D1010E5402656E68656C6C6F20773EE40312D1010E5402656E68656C6C6F20773EE40312D1010E5402656E68656C6C6F20773EE40312D1010E5402656E68656C6C6F20773EE46F726C64FE0000000000000000000000CE626F726C64FE0000000000000000000000CE626F726C64FE0000000000000000000000CE626F726C64FE0000000000000000000000CE62000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749000000000000000000000000000000003749
If I decode that data the info is there, but no in standard Type2 Ndef format. Or at least not equal to NFC tools output.
Is necessary authentication for get right data all time?
I would have to authenticate in all the blocks even if I only have a record on the card?
Your looping over the blocks is wrong
if you simplify the loop to just print out the blocks index you read
for(int i=0;i<64;i+=4){
for(int j=i;j<i+4;j++){
System.out.print(i);
}
}
gives a result of
00004444888812121212161616162020202024242424282828283232323236363636404040404444444448484848525252525656565660606060
So you are reading block 0 four times then block 4 four times, etc
Which matches the repeating patterns in your data
047BB94E8B700000FBA30000E1103E00277E047B
As a read of a mifare ultralight will give you 4 blocks of 4 bytes from the start address of the read command your loop should look like
for(int i=0;i<64;i+=4){
if(util.authenticate(i, 0, key)){
byte[] readData = util.read_block(i);
if(readData != null){
result.append(NfcUtil.toHexString(readData));
}
}
}
which means the start of the 4 block read is:-
0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60
(a read of block 0, returns data of blocks, 0,1,2,3 )
I also note that a mifare Ultralight don't have multiple keys/passwords for different memory areas and once you authenticated once you can access the Tag until it is Halted. I know you are using a proprietary API to access these Tags but you should not need call util.authenticate more than once. But calling it multiple times won't have a bad affect.
I have qot android app for printing the cp1250 chars to ESC/POS BT printer.
I initialize the printer with header
byte header[] = null;
header = new byte[] { 0x1b, 0x40, 0x1c, 0x26, 0x1b, 0x39, 0x01 };
os.write(header);
0x1b, 0x40 - initialize printer
0x1c, 0x26 - Kanji character mode
0x1b, 0x39, 0x01 - what does it mean ?
Would it be possible to explain what is Kanji character mode ? If i print with whole header { 0x1b, 0x40, 0x1c, 0x26, 0x1b, 0x39, 0x01 } my printing cp1250 characters is right. If I use only { 0x1b, 0x40 } printing cp1250 chars is wrong
The specification of the command supported by the printer is included in the device driver which can be downloaded from this page.
Rongta Tech - Thermal Receipt Printer Driver, Mobile Printer Driver
Portable Printer 58mm CD (For RPP200/02/02N/210/210A/02A/02B)
However, the commands corresponding to 0x1B, 0x39, 0x01 did not seem to exist.
The command of 0x1C, 0x26 is described and has the following contents.
This is the same as EPSON's ESC/POS.
FS &
FS &
[Name] Select Kanji character mode
[Format] ASCII FS &
Hex 1C 26
Decimal 28 38
[Description] Selects Kanji character mode.
[Notes] For Kanji model:
- When the Kanji character mode is selected, the printer processes all Kanji code as two bytes each.
- Kanji codes are processed in the order of the first byte and second byte.
- Kanji character mode is not selected when the power is turned on.
[Reference] FS .
The command to switch to code page 1250 is 0x1B, 0x74, 0x1E.
ESC t n
[Name] Select character code table
[Format] ASCII ESC t n
Hex 1B 74 n
Decimal 27 116 n
[Range] 0 ≤ n ≤ 5, 16 ≤ n ≤ 19, n = 255
[Description] Selects page n from the character code table.
30 WCP1250[Central Europe]
Kanji character mode is a mode to print Japanese character set.
In Addition:
Looking at the details, code page 1250 is not supported in the specification.
n parameter 30 was not in the supported range.
[Range] 0 ≤ n ≤ 5, 16 ≤ n ≤ 19, n = 255
If your control code allows the code page 1250 to print, it's either private or hasn't been documented yet.
{ 0x1b, 0x40, 0x1c, 0x26, 0x1b, 0x39, 0x01 }
Please ask your vendor's support desk.
All my attemps to verify a PIN code on a PINPAD reader ends up in failure, here is my situation:
Setup
Belgian EID card;
Vasco DIGIPASS 875, connected in Bluetooth;
Android application using the SDK from Vasco.
Situation
I've used APDU command to select and read files, to set the secure environment (MSE : SET), and after numerous research and merging of different solutions from different documentation, I can make the reader ask for my PIN code. But with my pseudo-APDU command, I receive a 69|C# response. The same process (reading files, set secure environment and verify the PIN) works fine on a USB reader with no PINPAD, so I guess that the APDU command is ok, but not the pseudo-APDU command that precedes.
Documentation used
The BEID documentation, PC/SC Spec part 10 (2.5.2) and supplement (2.2.1) and USB Smart Card devices for chapter from 6.1.11.3 to 6.1.11.6.
What did I understand?
The first part should be FF C2 01 06 for direct PIN verification on reader, followed by the size of the subsequent data.
Next should follow the structure from PC/SC part 10, with:
Timeout 1 & 2 (00 for default);
Format (should be 89 for me, as it should be 10001001 for 1 byte offset PIN, justified left and BCD);
PIN block format (should be 48 because 4 bit length included and 8 byte for the PIN block);
PIN length format (04: 4 bit offset in the PIN block);
Min/Max PIN length : 040C (but didn't work like that, 0404 is sure to work);
Validation condition is 02 for ok button;
Number of messages : 01 to use the one in the command;
Language is 0409 for english;
Message to display is 00 for enter PIN;
000000 because this field isn't used;
The length of the final APDU command to transmit once formatted with the PIN (0000000D is my guess);
And then the APDU command : 0020000108FFFFFFFFFFFFFFFF
Results
I have changed several times some values that I wasn't so sure (2, 3, 4, 11 and 12 for the padding characters already present or not), with no success, just different result codes sometimes.
What do I do wrong here ?
Thx in advance !
After a last round of research and checkup, I found another example showing me my mistake: the PIN block ! It was 47, because it didn't include the control/effective PIN length. So the correct answer for me was :
0xFF, 0xC2, 0x01, 0x06, // Base PPDU command
0x20, // Length of the data
0x00, // timeout
0x00, // timeout
0x89, // format
0x47, // PIN block
0x04, // PIN length format
0x04, // Min pin size
0x04, // Max pin size
0x02, // Entry validation condition
0x01, // Number of messages to display
0x04, 0x09, // English
0x00, // Message "Enter pin"
0x00, 0x00, 0x00, // Non significant here
0x00, 0x00, 0x00, 0x0D, // Length of the apdu once formatted
0x00, 0x20, 0x00, 0x01, // APDU command VERIFY
0x08, // APDU command Data length
0x20, // APDU command Control data + Effective PIN length
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF // APDU command PIN + filler
I'm having a problem in my application with the MifareClassic.autenticateSectorWithKeyA(int sector, byte[] keyA) method. I have tried many ways but it dose not authenticate.
My key A is:
byte[] key = new byte[] { (byte) 0x3c, (byte) 0x55, (byte) 0x28,
(byte) 0x12, (byte) 0x5c, (byte) 0x61, (byte) 0x00,
(byte) 0x5C, (byte) 0x71, (byte) 0x00 };
What does each byte in this key represent?
If I have a key like 3c5528125c61 as above, how should I write the byte array to authenticate, read block 2 and get the bytes?
What is an AID (Application code)? When should I use it?
Your key byte array does not make much sense as a MIFARE Classic key. A key for MIFARE Classic consists of only 6 bytes. Hence, this would be a possible value for key:
byte[] key = new byte[] { (byte)0x3c, (byte)0x55, (byte)0x28,
(byte)0x12, (byte)0x5c, (byte)0x61 };
How do I authenticate to a sector and read a data block?
In order to read block 2 (and assuming that it is readable after authenticationg with the above key), you would do something like the following:
Authenticate to the sector that contains the block to read (block 2 is located in sector 0, you can use the helber method MifareClassic.blockToSector() to obtain the sector number for a given block number.
If authentication was successful, you can read the block.
final MifareClassic mfc = MifareClassic.get(tag);
mfc.connect();
final int blockNumber = 2;
if (mfc.authenticateSectorWithKeyA(mfc.blockToSector(blockNumber), key)) {
final byte[] data = mfc.readBlock(blockNumber)
// TODO: do something with data
}
mfc.close();
What is AID (Application Identifier)? and when should I use it?
MIFARE Classic itself has a linear memory layout. I.e. one that is addressed based on block numbers, where each block contains 16 bytes. These blocks are grouped into sectors with individual access conditions and keys.
In order to logically assign this data (the sectors/groups of blocks) to specific applications (e.g. some data for a physical access control system, some data for an electronic purse, etc.) and, hence, to use one card for more that one application at the same time, the MIFARE Application Directory (MAD) was introduced. The MAD is basically a lookup table (located in sector 0 for MIFARE Classic 1K and in sectors 0 and 16 for MIFARE Classic 4K). This lookup table maps each sector of the card to one application. Applications are identified though a two byte value, the MIFARE application identifier (AID). Thus, if a card uses the MAD, an application can lookup its data sectors by browsing the MAD for its AID.
I'm trying to read some information out of an ISO/IEC 14443 Type A card.
After analysing the card with the android app NFC TagInfo, I found out, that the application (AID: 15845F) has the particular file (File ID: 01) that I need.
I already managed to connect to the card and to select the application.
String action = getIntent().getAction();
if (NfcAdapter.ACTION_TECH_DISCOVERED.equals(action))
{
Tag tagFromIntent = getIntent().getParcelableExtra(NfcAdapter.EXTRA_TAG);
Log.i(TAG, Arrays.toString(tagFromIntent.getTechList()));
IsoDep isoDep = IsoDep.get(tagFromIntent);
try
{
isoDep.connect();
byte[] SELECT = {
(byte) 0x00, // CLA = 00 (first interindustry command set)
(byte) 0xA4, // INS = A4 (SELECT)
(byte) 0x04, // P1 = 04 (select file by DF name)
(byte) 0x0C, // P2 = 0C (first or only file; no FCI)
(byte) 0x06, // Lc = 6 (data/AID has 6 bytes)
(byte) 0x31, (byte) 0x35,(byte) 0x38,(byte) 0x34,(byte) 0x35,(byte) 0x46 // AID = 15845F
};
byte[] result = isoDep.transceive(SELECT);
Log.i(TAG, "SELECT: " + bin2hex(result));
if (!(result[0] == (byte) 0x90 && result[1] == (byte) 0x00))
throw new IOException("could not select application");
byte[] GET_STRING = {
(byte) 0x00, // CLA Class
(byte) 0xB0, // INS Instruction
(byte) 0x00, // P1 Parameter 1
(byte) 0x00, // P2 Parameter 2
(byte) 0x04 // LE maximal number of bytes expected in result
};
result = isoDep.transceive(GET_STRING);
Log.i(TAG, "GET_STRING: " + bin2hex(result));
}
}
But my second query fails with the error code: 6A86 (Incorrect parameters P1-P2). I already googled a lot and found different documentations (for example: http://bit.ly/180b6tB), but I just could not understand, how I can implement the right values for P1 and P2.
EDIT
Tag type of the card using NFC TagInfo: ISO/IEC 14443-4 Smart Card, Mifare DESFire EV1 (MF3ICD81)
The SELECT command as used in the source code actually did not fail, but instead it returned a 9000 response. So this is why I assumed that everything is working fine.
You mentioned that NFC TagInfo does not provide the correct values for DF-names etc. Is the value 0x313538343546 correct and how did you find it out?
Can you provide me a short description, how I could get the data I want? Are there any other android apps that I can use to read the right DF-names, AIDs etc.? I basically need to get ONE file out of ONE application. I could also provide some screenshots of the information gathered with NFC TagInfo, if needed.
EDIT 2
I have rewritten the commands, but (as you proposed) kept them in the APDU wrapper. Therefore I ended up having two different commands, one for the selection of the application and the other one for the selection of the file.
private final byte[] NATIVE_SELECT_APP_COMMAND = new byte[]
{
(byte) 0x90, (byte) 0x5A, (byte) 0x00, (byte) 0x00, 3, // SELECT
(byte) 0x5F, (byte) 0x84, (byte) 0x15, (byte) 0x00 // APPLICATION ID
};
private final byte[] NATIVE_SELECT_FILE_COMMAND = new byte[]
{
(byte) 0x90, (byte) 0xBD, (byte) 0x00, (byte) 0x00, 7, // READ
(byte) 0x01, // FILE ID
(byte) 0x00, (byte) 0x00, (byte) 0x00, // OFFSET
(byte) 0x00, (byte) 0x00, (byte) 0x00, // LENGTH
(byte) 0x00
};
The search for a tutorial for native Mifire-Desfire commands was not successful, so I stick to the following tutorial: http://noobstah.blogspot.de/2013/04/mifare-desfire-ev1-and-android.html
This tutorial provides a card authentification, which I disabled, and also uses the transceive method, which for my understanding is not a proper way for executing native commands? Which method, purhaps even code snippit, is used for executing native commands? Which Android-Class should I use?
I have rewritten the class provided in the tutorial and uploaded it to pastebin. After executing the class I've got following results.
Select APPLICATION: 9100
Read DATA: 91AE
At this point I am quite stuck and do not know what steps I should do next. Was is actually the error or rather what changes in the queries should I perform, to get the data I want?
Given the information you extracted from NFC TagInfo and the commands you are trying to use, I assume the card is MIFARE DESFire EV1. Correct?
Regarding your selection command: NFC TagInfo does not currently read the DF name value used in the ISO command set for DESFire EV1. Thus, I assume that the DF-name that's setup for this application is actually 0x313538343546, otherwise the SELECT command should fail. Note, however, that this value is by no means derivable from the DESFire AID shown in NFC TagInfo! In fact the DF-name is a seperate value defined during application creation. (This is different from the previous DESFire version.)
Regarding your READ BINARY command: The command you used would imply that you previously selected a file. However, you only selected the application. Thus, you would either need to issue a SELECT command for the data file or use a short file ID within the READ BINARY command:
byte[] READ_BINARY = {
(byte) 0x00, // CLA Class
(byte) 0xB0, // INS Instruction
(byte) 0x80, // P1 (indicate use of SFI)
(byte) 0x01, // P2 (SFI = 0x01)
(byte) 0x04 // LE maximal number of bytes expected in result
};
However, when it comes to DESFire (EV1) I suggest that you rather stick to the DESFire native command set (either direct or wrapped) instead of using ISO 7816-4 APDUs.
With the native command set, you get the full functionality of MIFARE DESFire. Command wrapping is done by embedding native DESFire commands into a ISO 7816-4 APDU structure. The wrapping command looks like this:
0x90 CMD 0x00 0x00 LEN CMD-PARAM 0x00
Where CMD is the native DESFire command and CMD-PARAM are the commands parameters. The response is:
[DATA] 0x91 STATUS
Where status is the native DESFire status code. If STATUS is 0xAF, you can get the remaining response data by issuing this command:
0x90 0xAF 0x00 0x00 0x00
So in your case, you would issue a select application command for your application 0x15845F (mind the different byte order!):
0x90 0x5A 0x00 0x00 3 0x5F 0x84 0x15 0x00
|SELECT| |APPLICATION ID|
Then, you want to read the data file 0x01 (whole file, starting at offset 0):
0x90 0xBD 0x00 0x00 7 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|READ| |FILE| OFFSET | LENGTH |
Regarding your question how to get the ISO DF names and ISO FIDs for your application, you can try the following commands:
Select master application:
905A00000300000000
Get applications including their DF names:
906D000000
Select your application:
905A0000035F841500
Get DESFire FIDs:
906F000000
Get ISO FIDs:
9061000000
You can always use the transceive() method of the IsoDep object. IsoDep (i.e. ISO/IEC 14443-4) is used anyways (for native DESFire commands, for wrapped native commands and for ISO 7816-4 commands).
The error code you received from the card (0xAE) indicates an authentication error (see this datasheet for further information: DESFire). Thus, the file allows authenticated read only (see the access conditions shown in NFC TagInfo).
Thus, in order to read this file, you will need to implement the authentication procedure.