I use a CardReader to communicate to a SIM-card.
For example, I need to get an IMSI from the SIM card.
To do this I send some commands (SELECT 3F00/7F20/6F07):
A0 A4 00 00 02 3F 00
A0 A4 00 00 02 7F 20
A0 A4 00 00 02 6F 07
and here I send READ BINARY command
A0 B0 00 00 09
and after that I receive 90 00 --> Ok - normal ending of the command.
Hey! And where is my IMSI stored?? How can I catch data, which were read by "A0 B0 00 00 09" command?
If I try "A0 C0 00 00 00" command (GET RESPONSE) I will get an Error.
You don't need to send Get Response Command "A0 C0 00 00 00" after Read Data.
There are 9 bytes of data in reply to your Read Data Command "A0 B0 00 00 09".
Related
I'm using Akka Streams to create a TCP server using akka.stream.scaladsl.TLS with client certificate authentication. I'm working on creating an echo server as a first proof of concept.
In the meantime, I'm new to Scala/Akka/Akka Streams and so I created a similar server and TCP client in Python to provide tooling in testing my work in Scala. The Python server/client are functional using client cert authentication. When connecting to the server, the client takes the following steps:
Creates and configures an SSLContext
Creates a socket using socket.create_connection()
Wraps the socket with the SSLContext using SSLContext.wrap_socket(). This creates the peer connection
Once connected, prints the server certificate
Infinite loop asking for input and sending each input to the server
I believe I have the server completed using Akka Streams and akka.stream.scaladsl.TLS, but when I attempt to connect using my Python client the client never gets past connecting to the peer using context.wrap_socket(sock, server_hostname=host). The server successfully binds the TCP connection and creates the corresponding IncomingConnection object. The client/server also never timeout (the client just sits awaiting the handshake?).
My biggest problem is that I see no information from my TLS BidiFlow, akka.stream.scaladsl.TLS. I have no idea what step in the handshake I'm stuck at, which makes troubleshooting very difficult.
Is there any way to output some information throughout the TLS handshake process? It seems as though all of the functionality is encapsulated and I don't know if there's any way to troubleshoot.
Otherwise, I'm attempting to troubleshoot with openssl and get the following:
bash$ openssl s_client -connect myserver.com:443 -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x7fd914100080 [0x7fd915001000] (318 bytes => 318 (0x13E))
0000 - 16 03 01 01 39 01 00 01-35 03 03 e3 ff 5d fb 26 ....9...5....].&
0010 - 15 e3 32 89 37 e2 cb 95-f5 00 bd df 13 3d ae a6 ..2.7........=..
0020 - d7 37 db 4e 80 19 63 ad-d6 6c f1 00 00 98 cc 14 .7.N..c..l......
0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a .....0.,.(.$....
0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4 .....k.j.9.8....
0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26 .........2...*.&
0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f .......=.5...../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31 .#.3.2.....E.D.1
0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04 ...A............
00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15 ................
00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00 .........t......
00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c .....:.8........
00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16 ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05 ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11 ................
0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03 .#.....&.$......
0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee ................
0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03 ..............
SSL_connect:unknown state
At which point openssl just hangs.
The Akka TLS support uses the built in Java TLS support behind the scenes, so to get debug output for TLS you'll have to enable debugging for that. It can be done through passing a system property to the JVM when starting it like so -Djavax.net.debug=all
Ultimately I found that the ssl-config logging is very sparse and wasn't helpful to resolving my issue. It does provide some debugging information but not much. Much better for debugging the TLS handshake is to use the -Djavax.net.debug=all flag when running the JVM. However, even this provides mixed results. For example, the resulting error I received is that the server couldn't find a matching cipher suite. Eventually I resolved my issue by realizing that when creating the input streams for my keystore/truststore I was specifying my path incorrectly.
Note for anyone coming across this: if you specify your keystore and truststore incorrectly the resulting input streams will be null and SSLContext.init will happily use these and provide an error that is unrelated to the keystore/truststore! This was very difficult to troubleshoot due to the incorrect error handling in SSLContext.
When using Desfire native wrapped APDUs to communicate with the card, which parts of the command and response must be used to calculate CMAC?
After successful authentication, I have the following session key:
Session Key: 7CCEBF73356F21C9191E87472F9D0EA2
Then when I send a GetKeyVersion command, card returns the following CMAC which I'm trying to verify:
<< 90 64 00 00 01 00 00
>> 00 3376289145DA8C27 9100
I have implemented CMAC algorithm according to "NIST special publication 800-38B" and made sure it is correct. But I don't know which parts of command and response APDUs must be used to calculate CMAC.
I am using TDES, so MAC is 8 bytes.
I have been looking at the exact same issue for the last few days and I think I can at least give you some pointers. Getting everything 'just so' has taken some time and the documentation from NXP (assuming you have access) is a little difficult to interpret in some cases.
So, as you probably know, you need to calculate the CMAC (and update your init vec) on transmit as well as receive. You need to save the CMAC each time you calculate it as the init vec for the next crypto operation (whether CMAC or encryption etc).
When calculating the CMAC for your example the data to feed into your CMAC algorithm is the INS byte (0x64) and the command data (0x00). Of course this will be padded etc as specified by CMAC. Note, however, that you do not calculate the CMAC across the entire APDU wrapping (i.e. 90 64 00 00 01 00 00) just the INS byte and data payload is used.
On receive you need to take the data (0x00) and the second status byte (also 0x00) and calculate the CMAC over that. It's not important in this example but order is important here. You use the response body (excluding the CMAC) then SW2.
Note that only half of the CMAC is actually sent - CMAC should yield 16 bytes and the card is sending the first 8 bytes.
There were a few other things that held me up including:
I was calculating the session key incorrectly - it is worth double checking this if things are not coming out as you'd expect
I interpreted the documentation to say that the entire APDU structure is used to calculate the CMAC (hard to read them any other way tbh)
I am still working on calculating the response from a Write Data command correctly. The command succeeds but I can't validate the CMAC. I do know that Write Data is not padded with CMAC padding but just zeros - not yet sure what else I've missed.
Finally, here is a real example from communicating with a card from my logs:
Authentication is complete (AES) and the session key is determined to be F92E48F9A6C34722A90EA29CFA0C3D12; init vec is zeros
I'm going to send the Get Key Version command (as in your example) so I calculate CMAC over 6400 and get 1200551CA7E2F49514A1324B7E3428F1 (which is now my init vec for the next calculation)
Send 90640000010000 to the card and receive 00C929939C467434A8 (status is 9100).
Calculate CMAC over 00 00 and get C929939C467434A8A29AB2C40B977B83 (and update init vec for next calculation)
The first half of our CMAC from step #4 matches the 8 byte received from the card in step #3
Sry for my English,- its terrible :) but it's not my native language. I'm Russian.
Check first MSB (7 - bit) of array[0] and then shiffting this to the left. And then XOR if MSB 7 bit was == 1;
Or save first MSB bit of array[0] and after shiffting put this bit at the end of array[15] at the end (LSB bit).
Just proof it's here:
https://www.nxp.com/docs/en/application-note/AN10922.pdf
Try this way:
Zeros <- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SessionKey <- 00 01 02 03 E3 27 64 0C 0C 0D 0E 0F 5C 5D B9 D5
Data <- 6F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
First u have to encrypt 16 bytes (zeros) with SesionKey;
enc_aes_128_ecb(Zeros);
And u get EncryptedData.
EncryptedData <- 3D 08 A2 49 D9 71 58 EA 75 73 18 F2 FA 6A 27 AC
Check bit 7 [MSB - LSB] of EncryptedData[0] == 1? switch i to true;
bool i = false;
if (EncryptedData[0] & 0x80){
i = true;
}
Then do Shiffting of all EncryptedData to 1 bit <<.
ShiftLeft(EncryptedData,16);
And now, when i == true - XOR the last byte [15] with 0x87
if (i){
ShiftedEncryptedData[15] ^= 0x87;
}
7A 11 44 93 B2 E2 B1 D4 EA E6 31 E5 F4 D4 4F 58
Save it as KEY_1.
Try bit 7 [MSB - LSB] of ShiftedEncryptedData[0] == 1?
i = false;
if (ShiftedEncryptedData[0] & 0x80){
i = true;
}
Then do Shiffting of all ShiftedEncryptedData to 1 bit <<.
ShiftLeft(ShiftedEncryptedData,16);
And now, when i == true - XOR the last byte [15] with 0x87
if (i){
ShiftedEncryptedData[15] ^= 0x87;
}
F4 22 89 27 65 C5 63 A9 D5 CC 63 CB E9 A8 9E B0
Save it as KEY_2.
Now we take our Data (6F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
As Michael say's - pad command with 0x80 0x00...
XOR Data with KEY_2 - if command was padded, or KEY_1 if don't.
If we have more like 16 bytes (32 for example) u have to XOR just last 16 bytes.
Then encrypt it:
enc_aes_128_ecb(Data);
Now u have a CMAC.
CD C0 52 62 6D F6 60 CA 9B C1 09 FF EF 64 1A E3
Zeros <- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SessionKey <- 00 01 02 03 E3 27 64 0C 0C 0D 0E 0F 5C 5D B9 D5
Key_1 <- 7A 11 44 93 B2 E2 B1 D4 EA E6 31 E5 F4 D4 4F 58
Key_2 <- F4 22 89 27 65 C5 63 A9 D5 CC 63 CB E9 A8 9E B0
Data <- 6F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CMAC <- CD C0 52 62 6D F6 60 CA 9B C1 09 FF EF 64 1A E3
C/C++ function:
void ShiftLeft(byte *data, byte dataLen){
for (int n = 0; n < dataLen - 1; n++) {
data[n] = ((data[n] << 1) | ((data[n+1] >> 7)&0x01));
}
data[dataLen - 1] <<= 1;
}
Have a nice day :)
I have SCL011 Card Reader and need to read/write Mifare 1k cards. But I just can't get over Authentification step....
Card Reader should handle Mifare 1k cards:
Antenna ISO/IEC 14443 compliant design
Baudrate up to 848 Kbps
Supported standards:
ISO/IEC 14443-4 Typ A & B
MIFARE: Classic 1K and 4K, DESFire, Ultralight, MIFARE Plus
FeliCa™
NFC forum tag type 1, 2, 3, 4
iCLASS UID*
I have also updated to the latest firmware (1.20)
http://support.identive-group.com/dfu_fw.php?OS=windows&readerno=85
card is connected and I can read the UID of the card with ff ca 00 00 00
I have also tried to read the sector directly without authorization ff b0 00 00 10 and I get message:
69 82 : Command not allowed. Security status not satisfied.
it means I need authorize myself, but if I try ff 82 00 00 06 ff ff ff ff ff ff or any other standard keys I always get back:
69 88 : Command not allowed. SM data objects incorrect.
funny thing is, that I can read and write this card without problems with my Nexus and Lumia phones...
What I'm doing wrong? Thanks for any help!
keys I have already tried:
* ff 82 00 00 06 ff ff ff ff ff ff
* ff 82 00 00 06 a0 b0 c0 d0 e0 f0
* ff 82 00 00 06 a1 b1 c1 d1 e1 f1
* ff 82 00 00 06 a0 a1 a2 a3 a4 a5
* ff 82 00 00 06 b0 b1 b2 b3 b4 b5
* ff 82 00 00 06 4d 3a 99 c3 51 dd
* ff 82 00 00 06 1a 98 2c 7e 45 9a
* ff 82 00 00 06 00 00 00 00 00 00
* ff 82 00 00 06 d3 f7 d3 f7 d3 f7
* ff 82 00 00 06 aa bb cc dd ee ff
Solution: Please google/search "Multiprotocol contactless mobile reader, Reference manual" or "SCL01X Multiprotocol contactless stationary reader".
It is a very nice references to start with SCL reader's APDUs. There are some examples inside.
Answer: In your case P2 value in the APDU Command incorrect and you got SW1SW2 = 0x6988 - "Key number not valid".
Where P2 can have the following values (please refer to MIFARE documentation from NXP for
further details on what is key A and Key B):
• 0x60 to use the Key A
• 0x61 to use the Key B
I write the following bytes into a file named disk.img
FA 8D 36 1B 7C E8 01 00 F4 AC 3C 00 74 0C B4 0E
BB 07 00 B9 01 00 CD 10 EB EF C3 4D 61 79 20 74
68 65 20 66 6F 72 63 65 20 62 65 20 77 69 74 68
20 79 6F 75 21 0D 0A 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..enough zero to make the size of file 512bytes.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
The above bytes are proper instructions and magic number that should work when loading into the boot sector. But after I executed "qemu-X86_64 disk.img", error happens.
Error -13 while loading disk.img
Does anyone know how to solve the problem or what is the reason that might lead to this error?
Thank you!
I don't know if you can fill an image with just anything and expect it to work just because you have 55 AA in the correct place. Since you seem to be writing a bootloader make sure your code thinks it is executing at the correct place. It should be in offset 0x7C00 (if I remember this correctly, double check that). You set it by writing the line [org 0x7C00] at the top of your assembly file.
Also I'm not sure you can have only a 512 byte file. Try to make the disk image bigger than that using something like dd if=/dev/zero of=disk.img bs=512 count=2000 and then just copy your bootloader to the first part of the disk using dd again.
Also, you should use the -hda or -fda tags, so it would be qemu -hda disk.img. -hda means hard drive image, and -fda means floppy disk image.
I need to pull RAM information from several cpuz reports and put them into a csv for reporting reasons.
below is an example text file (snipped) which contains the text i want to extract.
I want to extract all the text following the lines beginning with DIMM but only where the next line begins with tab and SMBus address, and going down to nominal voltage. I'd then like to split them into columns (although I only really care about the type, size and max bandwidth)
the resultant csv would have the following columns (and 2 rows in this example)
computer name (from file name), Dimm #, smbus address, memory type, manufacturer, etc.
However I have fallen at the first, extraction phase. I was using sed but fell over at this multiline command:
sed -n -e 'N;/DIMM #\t*[0-9]\r\n\t/,/Nominal/p' cpuz-FHD505.txt
for some reason it only picks up the DIMM #2 block.
what sed statement should I use to just give me the two dimm blocks up to the line including Nominal voltage?
to be honest I'm probably going to give up and write this in python anyway as I'm more familiar, but I'd love to know where I've screwed up on this multiline sed statement.
cpuz output:-
Chipset
-------------------------------------------------------------------------
Northbridge Intel i845G rev. A1
Southbridge Intel 82801DB (ICH4) rev. 01
Memory Type DDR
Memory Size 1024 MBytes
Memory Frequency 132.9 MHz (1:1)
CAS# latency (CL) 2.0
RAS# to CAS# delay (tRCD) 3
RAS# Precharge (tRP) 3
Cycle Time (tRAS) 6
DRAM Idle Timer 16
Memory SPD
-------------------------------------------------------------------------
DIMM # 1
SMBus address 0x50
Memory type DDR
Manufacturer (ID) Infineon (C1494E46494E454F)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number 64D64320GU6B
Serial number 075ADD21
Manufacturing date Week 56/Year 03
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
XMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC # frequency
JEDEC #1 2.0-3-3-6-n.a. # 133 MHz
JEDEC #2 2.5-3-3-7-n.a. # 166 MHz
DIMM # 2
SMBus address 0x51
Memory type DDR
Manufacturer (ID) Samsung (CE00000000000000)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number M3 68L6423ETN-CB3
Serial number 060EFC37
Manufacturing date Week 54/Year 04
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
XMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC # frequency
JEDEC #1 2.0-3-3-6-n.a. # 133 MHz
JEDEC #2 2.5-3-3-7-n.a. # 166 MHz
DIMM # 1
SPD registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 80 08 07 0D 0A 02 40 00 04 60 70 00 82 08 00 01
10 0E 04 0C 01 02 20 C0 75 70 00 00 48 30 48 2A 40
20 75 75 45 45 00 00 00 00 00 3C 48 30 2D 55 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
40 C1 49 4E 46 49 4E 45 4F 08 36 34 44 36 34 33 32
50 30 47 55 36 42 20 20 20 20 20 20 01 4A 03 38 07
60 5A DD 21 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
90 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
DIMM # 2
SPD registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 80 08 07 0D 0A 02 40 00 04 60 70 00 82 08 00 01
10 0E 04 0C 01 02 20 C0 75 70 00 00 48 30 48 2A 40
20 80 80 45 45 00 00 00 00 00 3C 48 30 2D 55 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 27
40 CE 00 00 00 00 00 00 00 01 4D 33 20 36 38 4C 36
50 34 32 33 45 54 4E 2D 43 42 33 20 4E 45 04 36 06
60 0E FC 37 00 58 39 42 36 37 30 30 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 03 B2 10 09 19 FF FF FF FF FF 05 12 05 FF FF
90 00 03 B2 10 09 39 FF FF FF FF FF 02 20 18 FF FF
A0 00 03 B2 10 09 19 FF FF FF FF FF 04 23 54 FF FF
B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Monitoring
-------------------------------------------------------------------------
Mainboard Model 07E4h (0x00000148 - 0x00024680)
LPCIO
-------------------------------------------------------------------------
LPCIO Vendor SMSC
LPCIO Vendor ID 0x55
LPCIO Chip ID 0x6D
Config Mode I/O address 0x2E
Config Mode LDN 0x8
Config Mode registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20 6D 01 09 00 04 00 2E 00 00 00 00 00 00 00 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Hardware Monitors
-------------------------------------------------------------------------
Hardware monitor SMSC EMC6D10X
Voltage 0 0.00 Volts [0x0] (+1.5V)
Voltage 1 1.47 Volts [0x7D] (CPU VCORE)
Voltage 2 3.26 Volts [0xBE] (ATX +3.3V)
Voltage 3 5.10 Volts [0xC4] (ATX +5V)
Voltage 4 11.98 Volts [0xBF] (ATX +12V)
Temperature 0 0°C (32°F) [0x0] (Diode 1)
Temperature 1 24°C (75°F) [0x18] (Internal)
Temperature 2 33°C (91°F) [0x21] (Diode 2)
Fan 0 1455 RPM [0xE7F] (FANIN0)
Register space SMBus, base address = 0x0FC00
SMBus request channel 0x0, address 0x2E
output:
DIMM # 2
SMBus address 0x51
Memory type DDR
Manufacturer (ID) Samsung (CE00000000000000)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number M3 68L6423ETN-CB3
Serial number 060EFC37
Manufacturing date Week 54/Year 04
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
Give this a try:
sed -n ':a; /^DIMM/,/^[[:blank:]]*Nominal Voltage/ N; /^DIMM/,/[[:blank:]]*Nominal Voltage/ ! d ;/[[:blank:]]*Nominal Voltage/ {/[[:blank:]]*Nominal Voltage/p;d}; ba' cpuz-FHD505.txt
awk -vRS="" -F"\n" '/DIMM/&&$2~/SMBus/{
for(i=1;i<=NF;i++) {
print $i
# from here, you process the columns you need
}
}' file