I´ve got a JavaCard (SmartMX) with emulated DESFire EV2 and want to get both Uid´s from DESFire and JavaCard.
Therefor I´ve found the following APDU command:
0xFF, 0xCA, 0x00, 0x00, 0x00
But only get the DESFire Uid. May someone tell how to retreive the JavaCard Uid?
I´m using PCSC Lib together with C# .net5.
The documentation is saying, that the first protokoll which is called will be proceed. Therefor I´ve tried to read JavaCard free memory with APDU:
0x00, 0xB0, 0x00, 0x00, 0x02
But after again calling GetUid I´ve received again the DESFire CSN/Uid. May someone also tell which format a JavaCard´s Uid has?
But only get the DESFire Uid. May someone tell how to retreive the JavaCard Uid?
NXP SmartMX has ISO 14443 type A communication. UID value appears during initialization phase of the contactless protocol
(see ANTICOLLISION and SELECT commands in ISO 14443-3). It's before branching between protocols (Mifare and JavaCard protocols).
Protocol type A initialization is common for both Mifare and JavaCard. There is no special value for Mifare and special value for JavaCard.
Therefore, chip can have only one UID value for all protocols.
May someone also tell which format a JavaCard´s Uid has?
As far as I know UID in JCOP cards is configurable until the card is fused. There are several acceptable formats of UID. See your chip datasheet for exact information. Sometimes UID can be random.
Related
Undocumented in the Proxmark3's Wiki as well as in its command-line documentation, the proxmark3 Linux client provides the hf 14a apdu command (though there is no hf 14b apdu command).
The way I view things is that APDU build on top of ISO14443. ISO14443's anti-collision and selection protocol can be implemented using hf 14a raw or hf 14b raw command.
After selecting my chip using the raw command, can I simply send and receive APDU messages using the same command?
No, you won't be able to use hf 14a apdu after you selected a card with hf 14b raw. The problem is that the command hf 14a apdu will use ISO/IEC 14443 Type A coding and framing (including CRC). Since Type B uses a different coding, framing and CRC, the Type B card would not be able to understand what you sent. However, you can easily wrap your APDU commands into raw Type B frames by prepending the PCB (which in most cases is just alternating between 0x02 and 0x03). Waiting time extension and other elements of the ISO-DEP protocol may be a bit more tricky though.
I have a Mifare fob and a magic Mifare Classic card. When I fully clone the fob onto the card, the SAK found from the card is 0x88, despite a SAK of 0x08 on the fob.
If I change the sixth byte of block 0 on the card from 0x88 to 0x08, the SAK changes accordingly. However, the fob holds a value of 0x88 at that position whilst reporting a SAK of 0x08. So, what determines the SAK such that two cards with supposedly identical data can report different values for it?
I had the same problem. I had:
An original TAG (mifare 1k)
A chinese TAG (mifare 1k) gen1a with block 0 rewritable.
From the Rfid Research Group documentation we can found this information:
MIFARE Classic block0:
11223344440804006263646566676869
^^^^^^^^ UID
^^ BCC
^^ SAK(*)
^^^^ ATQA
^^^^^^^^^^^^^^^^ Manufacturer data
(*) some cards have a different SAK in their anticollision and in block0: +0x80 in the block0 (e.g. 08->88, 18->98)
so usually the SAK is determined by the bytes #6 of the block 0.
But as specified in the doc, some cards have a different SAK in their anticollision and in block0.
So unfortunately my chinese TAG gen1a was unable to reproduce the same behavior of my original TAG. Also a gen1a TAG accept magic command, which means that a backdoor exist with those tags and you can read or write a block without using the access key, this backdoor is now well known and some reader can detect that.
The solution was to use a gen2 TAG aka CUID card, with block 0 rewritable. This TAG add a 08 SAK, by default, that did not change, even if a rewrite the byte #6 of the block 0.
The SAK byte identifies the manufacturer code and product code.
x08 would be NPX mifare clasic 1k and
x88 would be Infineon mifare clasic 1k
You would need to clarify with your card supplier which one does he sale.
source: http://nfc-tools.org/index.php?title=ISO14443A
I'm currently planning out the code for a Bluetooth low energy (BLE) device that will operate on the HID over GATT profile from the bluetooth specification. I've read through the HID specification 1.11 and the Usage Tables 1.12, but I can't find anything about the minimum required use of Usage_pages and Usages.
Since we're implementing both the host and device, the plan is to use a vendor defined usage page for our report descriptor, but since our goal is to have fast connections and low power consumption, I don't want to send more bytes than I have to in the report definition phase of HID over GATT. Because of this, I'm considering removing all usages that would normally tag an input/output since they only seem semantic.
Here's a sample of what I'm considering:
Usage_Page( Vendor Defined)
Usage( Vendor 1)
Collection(Application)
Collection(Logical) ; First Collection and Report
Report_ID(1)
Usage_Page(Button) ; This is what the specification seems to encourage
Usage_Minimum(Button 1)
Usage_Maximum(Button 3)
Logical_Minimum(0) ; Logical limits
Logical_Maximum(1)
Report_Size(3) ; Three bits corresponding to the buttons
Report_Count(1) ; One of the three bit sets
Input( Data, Variable, Absolute) ; Make it an input
Report_Size(5)
Report_Count(1)
Input(Constant) ; Pad the transmitted byte
Collection End
Collection End
When I look at the this, I see a lot of extra bytes that do nothing since I'm not using a native parser. These range from Usages to even logical minimums/maximums. What consequences would there be if I just defined my report descriptor with only the top-level usage and no use of things like logical maximums?
A compliant parser should accept the following optimized descriptor:
0x85, 0x01, // ReportID (1)
0x05, 0xff, // UsagePage (255)
0x09, 0x01, // Usage (1)
0xa1, 0x01, // Collection (Application)
0x25, 0x01, // LogicalMaximum (1)
0x75, 0x01, // ReportSize (1)
0x05, 0x09, // UsagePage (Button)
0x19, 0x01, // UsageMinimum (Button(1))
0x29, 0x03, // UsageMaximum (Button(3))
0x95, 0x03, // ReportCount (3)
0x81, 0x02, // Input (Variable)
0xc0, // EndCollection
logical minimum defaults to 0,
padding at the end of last byte comes for free.
Also note all Central-side implementations (Win, Bluez, CoreBluetooth, and Bluedroid) of HoG actually cache the report descriptor when pairing occurs in order to minimize the reconnection time. So, the actual size of the report descriptor is not that important: it will only take time once upon pairing, and probably never again (until device is paired again of course).
Also consider the report descriptor reading represents a few packets exchanged between central and peripheral (one every 20 bytes with a default MTU), each round-trip costs two intervals (if both stack implementations are not too bad), which will be around 60 ms (most centrals connect with a default interval to ~30 ms). So the actual discovery latency will be less than 200 ms longer when your report descriptor is 60 bytes longer... It is not a big deal for something that happens only once in the life of the device.
Lastly, a side note: You should probably not use a vendor-specific collection type, but try to stick to standard ones. It will allow driverless operation of your device in most cases.
Don’t forget that even if you only foresee an application-specific usage of your hardware, some people may actually be happy to reuse it for something else. If so, driverless is better, unless you want to forbid third part usage at all, but there is no point using HID in the first place. (HID was designed for driverless operation, and I'm still puzzled to see drivers for mice and gamepads, remote controls and push buttons just because of the maker's laziness.)
I've started to work with the JavaCards and trying to grasp the sense of CLA byte.
If to read RFC 5.4.1 Class byte
5.4.1 Class byte
According to table 8 used in conjunction with table 9, the class byte
CLA of a command is used to indicate to what extent the command and the response comply with this part of ISO/IEC 7816 and when applicable (see table 9), the format of secure messaging and the logical channel number.
So... CLA flag is used for the indication, but what exact? Because, the table and description as for the beginner is rather difficult, I understand that usually are used the next CLA bytes: 0x00, 0x80, 0x84.
For e.g. if to read the content from table:
0X' Structure and coding of command and response according to this part of ISO/IEC 7816 (for coding of 'X' see table 9)
10 to 7F RFU
Reserved for PTS
I understand that for the fine developing - I should read GlobalPlatform specification, the specification about the exact card (mine is NXP one) and other related materials, but I want to admit, that it's difficult to understand the content.
I've expected the following (pseudo-table):
0x00 -> for reading streams from file system
0x01 -> for writing byte buffer to memory blocks
0x02 -> call AES/RSA methods
The CLASS byte is defined in ISO 7816-4. The first bit indicates the interindustry class. Java Card applets shall operate in this interindustry standard. Global Platform is another specification to manage and maintain the card and all commands will have class byte 0x80 - 0x8F. Class byte 0xFF is used for communication with the card reader in some cases and is otherwise invalid for a card.
The interindustry meaning for the CLA serves 3 major functions:
Function 1: Chaining
bit5 = 1 signalizes that the current command is not the last command of a chain, meaning that multiple APDUs all belong together and the card may therefore do additional things
Function 2: Secure Messaging
bit4+3 serve to signalize the secure messaging status of the current command. This means that the APDU is authenticated(e.g. MACed) and the data is encrypted(e.g. block cipher). The command header is never encrypted.
Function 3: Logical Channel
bit2+1 serve to identify the logical channel number. Logical channels are parallel communication interfaces through the card, therefore an applet A can be selected on Channel 0 and an applet B can be selected on Channel 1 while both applets remain in their internal state(no RAM is reset). Most cards do not support logical channels or you have to enable them explicitly.
CLA byte is a typical trap for Java Card beginners and its usually best that you leave at 0x00 for the start.
I'm new to embedded devices and am trying to understand how to use i2cget (or the entire I2C protocol really).
I'm using an accelerometer MMA8452, and the datasheet says the Slave Address is 0x1D (if my SAO=1, which I believe is referring to the I2C bus being on channel 1 on my raspberrypi v2).
From the command line, I enter
sudo i2cget -y 1 0X1d
It returns
0X00
I think that means I'm attached to the correct device.
So now, I'm trying to figure out how do I get actual data back from the accelerometer?
The i2c spec says
i2cget [-y] i2cbus chip-address [data-address [mode]]
So I have tried
sudo i2cget -y 1 0x1D 0x01
where 0x01 is the OUT_X_MSB. I'm not sure entirely what I'm expecting to get back, but I figured if I saw some data other than 0x00, I might be able to figure that out.
Am I using ic2get wrong? Is there a better way to learn and get data from i2c?
The datasheet for my accelerometer chip is at
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Accelerometers/MMA8452Q.pdf
I am way too late but this might help other people. You might be getting the 0x00 output every time you use i2cget is because you might have forgotten to set some mode. For instance, I was working on pcf8583 which is a clock and calendar chip and can also be use as a counter.
My goal was to use this chip as a counter. It was connected to i2cbus1 with device address 0x51. So reading the data sheet, I found out that, the chip would work as a counter when the mode is set to 0x20 in the control register 0x00. The command I used for doing this:
i2cset 1 0x51 0x00 0x20
Now, I could read the counter pulses from a wind sensor with the command:
watch i2cget -y 1 0x51
watch is just a linux command that runs the specified command (i2cget) repeatedly every 2 seconds and displays the results on standard output.
From the datasheet its clear that the default value of Status Register Address 0x00 is 0x00, so you are doing fine I guess. See Table 11 Register Map Address in the datasheet.
You may try reading the device ID at Register Address 0x0D. You should get value 0x2A when you read this register(0x0D).