I am testing sending APDU commands on S3's and S4's.
On my S3 I send out the APDU and get back 9000.
Knowing that my response also has 8 bytes of data i do:
80C0000010
On my S4 I send out the same APDU as above and get 6108 (61 data available - 08 , 8 bytes of data)
Sending out 80C0000010 or 80C0000000 both return 6F00 (internal error).
The S4 is up to date running 4.3.
My suspicion is that something is going wrong in the version of SEEK my S4 is running as I have this working on other devices.
Has anyone else experienced this issue and have any resolution or any suggestions of things for me to try?
It would be nice to have the exact APDU, but what you're seen is caused by a more strict implementation of ISO7816 on the S4 than on the S3. When you expect data in return (case 2, case 4 APDUs), then the ISO7816-4 mandates the use of the Le byte, which you set to 00.
Try adding 0x00 as Le byte at the end of your APDU, it should work on both the S3 and the S4.
Related
I'm trying to communicate with a bluetooth thermometer. It's not BLE, it uses serial ports. I've made it as far as receiving REQ signals from the device, but it requires a ACK signal or it cuts the connection after a few seconds.
The problem is, I can't decipher what the ACK signal is supposed to be. Going off the documentation, it says:
<ACK Format> ADH,01H
<REQ Format> ADH,00H,n
The third byte of REQ is the can be multiplied by 0.01310547 to get the voltage of the battery
<Data Format> ADH,03H,1EH," IRSTP3xx.yyy.HhhSss,nnn,tt.t"+0D+0A
xx: LotNo.(base 16) "01"~"FF"
yyy: S/N(base 16) "001"~"FFF"
...
...
Nothing in the Data Format mentions the first 3 bytes(?) either.
That's pretty much all I've got to work with. I'm trying decoding REQ with different encodings like ascii and utf-8 to see if I can get it to match the REQ format, and then use that same encoding to format and send ACK, but I haven't had any luck.
Is the format just in some kind of standard notation that I'm not familiar with?
The H apparently stands for hexidecimal.
ADH is a two byte message, the first byte being a hex A and the second a hex D. I have not seen that notation before.
I have tested several javacards (Feitian D11CR, Infineon JTOP, G&D Smart Cafe) over T=0 and here is what I have observed.
If applet returns some data in case 4 APDU, the JCRE signals with SW 0x61XX that there is data available which terminal should retrieve using GET RESPONSE APDU.
However, if applet returns some data in case 2 APDU and Le does not match number of bytes to be returned, JCRE signals with error SW 0x6CXX, instructing that the same C-APDU has to be resent with correct Le.
For legacy reasons there are terminals who know how to handle 0x61XX, but fail to handle 0x6CXX response. Is there a way how to force JCRE to handle case 2 APDUs using 0x61XX (GET RESPONSE) method?
This behavior is given by the T=0 protocol where the length of data bytes transmitted must be fixed from the beginning of the TPDU exchange (i.e. the interface device decides it) -- in contrast to T=1/T=CL where the response length is left open for the card to decide.
Which causes trouble when the interface device sends an unacceptable value as data bytes length for Case 2 command -- the card can not transmit a different number of data bytes and has to send a special status word instead.
In T=0 the command cases are transmitted this way (very simplified):
Case 1:
CLA INS P1 P2 00, card responds with: SW1 SW2
Case 2:
CLA INS P1 P2 P3,
card responds with:
[ P3 bytes of response data ] SW1 SW2 if the actual length of response data equals P3
6C XX if value of P3 is unacceptable
Case 3:
CLA INS P1 P2 P3 [P3 bytes of command data], card responds with: SW1 SW2
Case 4:
CLA INS P1 P2 P3 [P3 bytes of command data], card responds with: 61 YY
CLA C0 00 00 YY card responds with: [YY bytes of response data] SW1 SW2
See ISO 7816-3, section "Command-response pair transmission by T=0" for exact details.
(In theory,) to workaround that (i.e. to prevent JCRE from sending the 6C XX status word), you would have to implement all Case 2 commands as Case 1 commands (i.e. do not call the APDU.setOutgoing()), return 61 XX status word and implement the GET RESPONSE command yourself (JCRE should pass this command to your process() method if it does not have it's own response data).
This brings some unnecessary overhead for terminal supporting 6C XX.
Some additional (random) notes:
user-level processing of extra GET RESPONSE command in process() method just worked for me. I did not check the JC specifications regarding this, YMMV.
it is a pity you can't use T=1
the workaround proposed above is just a theory. I've never implemented that approach (but I am definitely interested in the results you might get)
Hope this answer makes some sense...good luck!
There is a trick for Feitian and Infinion cards how to force 0x61XX response in "case 2" APDUs where Le=0x00 - the trick is to call setIncomingAndReceive(). This, however, will not work with other Le values (calling setIncomingAndReceive() with positive Le will cause error).
For compatibility reasons I ended up implementing 0x61XX support in the applet. So if the Le received does not match the length to be returned, the applet buffers the response in RAM and returns SW 0x61XX. When the GET RESPONSE APDU is received by process(), the Le will match the length buffered and the data will be returned using setOutgoingAndSend().
I've been reading the rfc 7252 for a while and I am probably blind but I can't find how can I send a simple number (integer or float) when you answer a get request for a ressource (for example the sensor /light, where do you write it in the packet.
I think it's in the payload, so I tried to send this packet :
the option content-format text/plain, charset=utf-8, length 1
then I write 255(0xff) in the packet
then I write 0x34 in the packet (payload part).
But obviously it's not working, first I don't think I should use this option (probably another one but I can't find the good one to send either integer or float number), I'm not sure though if I'm in the right way and not sure anymore of what I am doing tbh, so that's why I'm asking.
Thanks for help,
Good bye
EDIT : Here are more info :
I'm using microcoap on arduino, using an ethernet cable between computer/arduino mega 2560.
wireshark info
After reviewing your Wireshark trace and seeing the response in Copper I think I see the problem. When you say that the Content-format is text/plain you are saying that you are sending ASCII data across. You say you send [0xFF 0x34] in your post, but in the trace you are actually sending is [0xFF 0x33]. Copper is showing you exactly what you are sending: 0xFF doesn't resolve as ASCII here and 0x33 is the ASCII for 3, which is shown in the Wireshark trace and in your Copper output window. If you want to send 2 raw bytes of data that shouldn't be interpreted as text you want to set your Content-format to be application/octet-stream.
I've never worked with bluetooth before. I have to sends data via BLE and I've found the limit of 20 bytes per chunk.
The sender is an Arduino and the receiver could be both an Android or a Node.js app on a pc.
I have to send 9 values, stored in float values, so 4 bytes * 9 = 36 bytes. I need 2 chunks for all my data via BLE. The receiving part needs both chunks to process them. If some data are lost, I don't care.
I'm not expert in network protocols and I think I have to give each message an incremental timestamp so that the receiver can glue the two chunks with the same timestamp or discard the last one if the new timestamp is higher. But I'm not sure how to do a checksum, if I really need it or not, if I really have to care about it, or if - for a simple beta version of my system - I can ignore all those problems..
Does anyone can give me some advice? Like examples of similar situations handled with BLE communication?
You can get around the size limitation using the "Read Blob Request" of ATT. It allows you to read an attribute and also give an offset. So, you can use it to read the attribute with an offset of 0, if there's more than ATT_MTU bytes than you can request again with the offset at ATT_MTU*1, if there's still more ATT_MTU*2, etc... (You can read it in 3.4.4.5 of the Bluetooth v4.1 specifications; it's in the 4.0 spec too but I don't have that in front of me right now)
If the value changes between request, I'm not sure how you could go about detecting such a change. You could have the attribute send notifications when there's a change to interrupt the process in case the value changes in the middle of reading it.
I work on a bluetooth communication between samsung Galaxy tab and a custom device.
On the custom device there is a PIC32 (Microchip) and a bluetooth RN-42. The communication between the PIC and RN-42 is serial (UART).
When I use text protocol all is working fine but with binary protocol the frame sent by the custom device are truncated (8 bytes are missing).
If I add 8 bytes at the end of the frame, complete answer is received by the client.
I have made some tests with several clients (Galxy tab, macbook...) and the result is the same.
I have verified on debug mode than all bytes are sent by the PIC32.
Is someone has encountered this kind of problem ? Any help will be appreciate.
The problem was in the PIC UART configuration.
I have added this line and now it works.
UARTSetFifoMode(UART2, UART_INTERRUPT_ON_TX_NOT_FULL | UART_INTERRUPT_ON_RX_NOT_EMPTY);