I´m trying to access the Information on a Mifare Smartcard(iso14443A) over a Omnikey 5321 CL reader.
I tried to use the smartcard lib, but it uses an other iso standard.
For accessing the Card I have to set a Application ID ( 3x hex), a key (32 int), keyid (hex).
You can still use smartcard lib, but you have to configure the reader to use the MIFARE mode instead of the T-CL variant of 14443 protocol.
If I remember corectly, the Omnikey workbench provides a graphical configuration tool for that purpose.
I strongly recommend to study Omnikey contactless smart card readers developer guide, especially the section MIFARE emulation mode, for serious work.
(I have no idea, what a one byte Application ID means in Mifare context, and what value 3x is supposed to represent.)
I am busy with similar process, however after searching I found this example:
https://github.com/santigimeno/node-pcsclite
EDIT
In fact I actually got this one working
https://github.com/pokusew/nfc-pcsc
It returns the following:
ACS ACR122 0 card detected {
atr: <Buffer 3b 8f 80 01 80 4f 0c a0 00 00 03 06 03 00 01 00 00 00 00 6a>,
standard: 'TAG_ISO_14443_3',
type: 'TAG_ISO_14443_3',
uid: '767aec7e'
}
Related
I'm developing an application that require a client authentication to a server using a smart card.
As a guide, i'm tracing a normal web authentication with a browser and i've seen that the SSL/TLS packet containing the "Certificate Verify" structure is created using the signing session of the card.
Analizing the CCID-APDU packet sent to the card reader i've seen this dump:
6f 05 01 00 00 00 41 00 01 00 00 2a 80 86 00 01 01 00 00 01 ff ff ........
The answer of this command is actually the content sent to the 'Certificate Verify' SSL/TLS structure.
The strange thing is that the APDU command sent is
00 2a 80 86 00
Looking at the APDU documentation this is a "PSO: DECIPHER" command but shouldn't it be a signature command? (00 2A 9E 9A xx)
Would anyone be able to clarify this behavior?
Tnx
PSO DECIPHER shares with signature generation that it applies the private key. It is significantly simpler, since it is restricted to one data block, i. e. the command data field of the APDU. PSO CDS for Compute Digital Signature has lots of additional complications like chaining (data split to several commands), hashing (with various algorithms to use), padding (with various padding schemes) to ensure correct data length etc.
So it seems, that your analyzed solution is optimized for the specific scenario required, and as many optimizations clarity is somewhat reduced as side effect.
After some mucking about, I have got a pybluez script to connect to an AVRCP profile on various devices, and read the responses.
Code snippet:
addr="e2:8b:8e:89:6c:07" #S530 white
port=23
if (port>0):
print("Attempting to connect to L2CAP port ",port)
socket=bluetooth.BluetoothSocket(bluetooth.L2CAP);
socket.connect((addr,port))
print("Connected.")
while True:
print("Waiting on read:")
data=socket.recv(1024)
for b in data:
print("%02x"%b,end=" ")
print()
socket.close()
The results I'm getting when I press the button on the earpiece are as follows:
Attempting to connect to L2CAP port 23
Connected.
Waiting on read:
10 11 0e 01 48 00 00 19 58 10 00 00 01 03
Waiting on read:
20 11 0e 00 48 7c 44 00
Waiting on read:
30 11 0e 00 48 7c 46 00
Waiting on read:
40 11 0e 00 48 7c 44 00
After careful reading of the spec, it looks like I'm seeing PASSTHROUGH commands, with 44 being the "PLAY" operation command, and 46 being "PAUSE" (I think)
I don't know what the 10 11 0e means, apart from the fact that the first byte appears to be some sort of sequence number.
My issue is threefold:
I don't know where to find a list of valid operation_ids. It's
mentioned in the spec but not defined apart from a few random
examples.
The spec makes reference to subunit type and Id, (which would be the
48 in the above example) again without defining them AFAICT.
There is no mention of what the leading three bytes are. They may
even be part of L2CAP and nothing directly to do with AVRCP, I'm not
familiar enough with pybluez to tell.
Any assistance in any of the above points would be helpful.
Edit: For reference, the details of the AVRCP spect appears to be here: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=119996
The real answer is that the specification document assumes you have read other specification documents.
The three header bytes are part of the AVCTP transport layer:
http://www.cs.bilkent.edu.tr/~korpe/lab/resources/AVCTP%20Spec%20v1_0.pdf
In short:
0: 7..4: Incrementing transaction id. 0x01 to 0x0f
3..2: Packet type 00 = self contained packet
1 : 0=request 1=response
0 : 0=PID recognized 1: PID error
1-2: 2 byte bigendian profile id (in this case 110e, AVRCP)
The rest is described in the AVRCP profile doc, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=119996
I don't find the documentation to be amazingly clear.
I have provided a sample application which seems to work for most of the AVRCP devices I have been able to test:
https://github.com/rjmatthews62/BtAVRCP
I am trying to use UPDATE BINARY command using APDU command for modify IMSI code, but The response is 98 04.
A0 A4 00 00 02 3F 00 -> SELECT MF
A0 A4 00 00 02 7F 20 -> Select DF_GSM
A0 A4 00 00 02 6F 07 ->Select EF_IMSI
A0 D6 00 00 09 [08 79 03 30 60 00 61 33 23] -> UPDATE IMSI FOR RANDOM NUMBER
when doing this I get the following response 98 04 and it is not modified.
According to the documentation The response 98 04 can mean the following:
access condition not fulfilled
unsuccessful CHV verification, at least one attempt left
unsuccessful UNBLOCK CHV verification, at least one attempt left
authentication failed
How I can change IMSI?
Thank you.
From 3GPP-TS-11.011 - You have to verify ADM first in order to update EF_IMSI. See link. Typically only the network has the "password". Otherwise anyone with the password can impersonate the identity of someone else's SIM card.
EF_IMSI Update Conditions
In order to update IMSI file on SIM , UPDATE command header and data part should be generated according GSM 03.48 specification. For the SIM file structure 31.102 is the specification.
Command header parameters should be obtained from SIM vendor. Minimum security Level parameter will definitely enforce encryption and cryptographic cHecksum usage for securing the command data, because real SIM card card manager expects MSL parameters something like that 0x25, so KiC and KiD key values are required.
You need first to Verify CHV (PIN1 for IMSI).
Use the following APDU and replace your PIN1 value.
-> A0 20 00 01 08 31 32 33 34 FF FF FF FF
<- 90 00
Caution: If you use wrong PIN value, it will be disabled after 3 times.
I am currently porting code that uses a USB device from Windows to Linux.
I've thoroughly tested the original application and I'm pretty sure that the device works well. I implemented the USB interface on Linux using hidapi-libusb and there are times when the returned data from the device is missing at least a byte.
Once it happens, all the returned values are missing that much data. I more or less have to disconnect and reconnect the USB device in order to make the USB device read data correct. I'm starting to think that maybe the first byte is sometimes returned as 00 and Linux ignores it. It usual occurs on successive reads.
For example:
I send get register state and I expect 10 data available for USB read. Byte 5 is the number of the data.
Expected:
00 00 01 02 00 08 42 (Data 8)
00 00 01 02 00 09 42 (Data 9)
Actual:
00 00 01 02 00 08 42 (Data 8)
00 00 02 00 09 42 ab (Data 9)
Data 9's packet number becomes wrong because it is missing a byte. I've tried changing to hidapi-hidraw, and it happens significantly less. I've checked the hexdump of the hidraw of the device (/dev/hidraw0), and it is consistent with the data I am getting in my application. I've tried using memory leak detection tools and no leaks/corruption is detected.
Is this a Linux problem (3.2.0-4-amd64) or is it possibly the device?
The pseudo code of my application is just:
Initialize HIDAPI and device related
Connect to device using HIDAPI
Write USB command
Read USB command (done multiple times if write expects multiple data)
Parse data
Repeat 3 and 4 until all commands are performed
Free memory and close HIDAPI.
Things I've tried:
Ensure no delay is between read and writes
Add flushing of read data before writing (sometimes catches stray data)
Add a really long timeout (five seconds) on flushing of read data - significantly reduces the problem at a big cost.
I've been playing around with capturing the input from my keyboard device:
/dev/input/by-path/platform-i8042-serio-0-event-kbd
for me, and I was wondering if there was any specification for what it returns, using
od -tx1 /dev/input/by-path/platform-i8042-serio-0-event-kbd
to listen. I'm curious mostly due to the behavior of certain keys; the meta, arrow keys, numpad forward slash.
0520300 ac 9d 86 4c 6b 0f 04 00 04 00 04 00 (db) 00 00 00
0520320 ac 9d 86 4c 8c 0f 04 00 01 00 (7d) 00 00 00 00 00
0520340 ac 9d 86 4c 95 0f 04 00 00 00 00 00 00 00 00 00
Every other key I've looked at so far has the two bytes in parentheses as matching values, is there any reason these are special?
/dev/input/by-path/platform-i8042-serio-0-event-kbd is just a symlink to /dev/input/eventX event device file. Data can be read from event device files as
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
defined in /usr/include/linux/input.h.
Possible values of type are prefixed with EV_.
Possible values of code depend on type. They are prefixed with KEY_ or BTN_ or REL_ or so on.
Possible values of value depend on both type and code. For example for key-press events value equals 1 and for key-release events 0.
You can examine event data with:
evtest /dev/input/eventX
where X is the event device number of your keyboard (or any other event device). One key press or release normally emits three events (EV_MSC, EV_KEY and EV_SYN).
Some keys have unusual scan codes...
From: http://www.beyondlogic.org/keyboard/keybrd.htm (with edits) :
Now there's 101 keys and 8 bits make 256 different combinations, thus you only need to send one byte per key, right?
Nope. Unfortunately, a handful of the keys found on your keyboard are extended keys, and thus require two scan codes. These keys are preceded by a E0 (hex). But it doesn't stop at two scan codes either. How about E1,14,77,E1,F0,14,F0,77! Now that can't be a valid scan code? Wrong again. It's happens to be sent when you press the Pause/Break key. Don't ask me why they have to make it so long! Maybe they were having a bad day or something?