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.
Related
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 am trying to build an RFID based door opener with an Attiny2313 and an RDM630 RFID reader. There has been no Problem with programming or getting the two ICs to talk to each other via UART. The Problem is the interpretation of the data.
I wasn't able to make any sense of what the RDM630 had sent to the Attiny, so I hooked it up via an RS232/USB Adapter, and this is what I get on my PC:
Display = ASCII:
Display set to HEX:
Written on the Card is:
0000714511 010,59151
Can anyone help me make sense of the Data?
Most of the bytes that the RDM630 RFID reader module sends are ASCII characters of hex digits ('0'-'9','A'-'F') which means 0x30-0x39, 0x41-0x46.
It looks like your RS232/USB inverts the bits, comparing to a direct TTL connections.
(RS232 is inverted TTL. It has also different voltage levels, but that's OK as long as TTL transmit output feeds RS232 receive input, as in your case. The other way around is more tricky).
I have bunch of records in my offcard application and I want to save them all in javacard,
The question is:
What is the best way of transferring data to Java Card?
Should I transfer all data record by record (each one with a APDU) or send all the records in just one APDU?
Of course I know the limitation size of APDU and I'm using extended APDU in order to send all data just in one extended APDU which is more than 255 bytes..
It does not matter much if you send your data in one extended length APDU or one single APDU security wise. It is however much better to send unrelated information using separate APDU's. This would make your application much more modular. Note that if you send related information using separate APDU's, you may need to keep state between those APDU's for validation purposes (e.g. you may have to send either none or all of them, or send the APDU's in specific order).
Furthermore, ISO 7816-4 only defines 2 byte status words to send back to the sender, e.g. 8A80 to indicate any error in the command data. This means that it is impossible to tell from the status word which of the records contains failure information.
Finally, there are certainly still readers and software out there that have issues handling extended length APDU's. So if your software is going to be used by other parties you may want to stick to normal length APDU's.
I am beginner,
I have enabled the uart2 by using the make menuconfig in my linux source. I am using LPC1788 cortex m3, in that uart tx is connected to P0.10 and rx to P0.11,
I want to utilize the uart to read the RFID card using SL031 (http://www.stronglink-rfid.com/download/SL031-User-Manual.pdf) reader, which will be connected to rx and tx pins that means P0.10 and P0.11. please guide me how to read the RFID and save the the data received.
by enabling the the uart I have tested the uart working by shorting tx and rx,now i want to connect the reader to those tx and rx and read the data. how can i do this.
Task: Write/send data & read/receive data over UART to/from SL031 using microcom.
Problem: Your device expects data/commands in hexadecimal format and, as far as I know, microcom does not directly support sending data in hexadecimal format.
Solution:
To write/send:
Use a hex editor, Bless Hex Editor for instance, to write a series of commands you want to send to SL031. Redirect/pipeline this data, using basic shell commands, to microcom.
To read/receive:
Capture the data of microcom in a file and analyze it with a hex editor. You can do this by redirecting/pipelining the output of microcom to a log file.
Hope this helps. If it does kindly accept the answer :)
Ask me if you need further clarification.
How do I send a string output from a DAQ Board (NI- USB 6259) using LabVIEW? I want to send commands such as "CELL 0" or "READ" to a potentiostat device using LabVIEW.
Thanks
The 6259 doesn't do string output. It's a data acquisition board that's intended for reading/sourcing analog voltages or sending/receiving individual digital signals. It's not a communications device.
If you're really trying to send strings to this device, you probably need something more like an RS-232 or GPIB connection.
As eaolson said a DAQ is not intended to control devices. However it is an interesting project to enter the guts of the communication protocol. Doing it with a DAQ would require to:
Identify the protocol (GPIB or RS-232)
Make your cable from the DAQ output connector
For each command, generate the waveform in LabVIEW, by using the letters' ASCII code, stop bits, etc. This is the funniest part (INMHO, but I understand it's not everybody!)
Send it (using DAQ analog write VIs, you should find many examples for this)
The oscilloscope will be your best friend