I want to use J2A040 JCOP 21-36k java cards to implement a smart card driven bitlocker-to-go solution using gidsapplet and OpenSC but when attempting to put a certificate on the card (certreq -new) I have not been able to get past the "The smart card is not fully personalized for use" error from windows.
This is the dump contents with gids-tool:
Dumping Files:
Found 5 entries in the masterfile
Directory: mscp
FileIdentifier: 0xa000
File: \cardid
FileIdentifier: 0xa012
DataObjectIdentifier: 0xdf20
Size: 16
File: \cardapps
FileIdentifier: 0xa010
DataObjectIdentifier: 0xdf21
Size: 8
File: \cardcf
FileIdentifier: 0xa010
DataObjectIdentifier: 0xdf22
Size: 6
File: mscp\cmapfile
FileIdentifier: 0xa010
DataObjectIdentifier: 0xdf23
Size: 0
Dumping containers:
no container found
Using pkcs15-init I am not able to create the meta structure as I receive Failed to create PKCS #15 meta structure: Incorrect parameters in APDU
This is the output of the pkcs15-init --create-pkcs15 -vvvvvvvvv starting at the gids driver portion:
trying driver 'gids'
card-gids.c:570:gids_match_card: called
card-gids.c:281:gids_select_aid: called
Got args: aid=00007FFC31591840, aidlen=9, response=0000007C6FD5EEF0, responselen=261
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
reader-pcsc.c:613:pcsc_lock: called
card-gids.c:2057:gids_card_reader_lock_obtained: called
card-gids.c:2065:gids_card_reader_lock_obtained: returning with: 0 (Success)
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:A4, P1:4, P2:0, data(9) 00007FFC31591840
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (15 bytes):
00 A4 04 00 09 A0 00 00 03 97 42 54 46 59 00 ..........BTFY.
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (22 bytes):
61 12 4F 0B A0 00 00 03 97 42 54 46 59 02 01 73 a.O......BTFY..s
03 40 01 C0 90 00 .#....
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
reader-pcsc.c:663:pcsc_unlock: called
card-gids.c:299:gids_select_aid: returning with: 0 (Success)
found AID
matched: GIDS Smart Card
card-gids.c:632:gids_init: called
card info name:'GIDS Smart Card', type:30003, flags:0x0, max_send/recv_size:255/256
card.c:1462:sc_card_sm_check: called
card->sm_ctx.ops.open 0000000000000000
card.c:1468:sc_card_sm_check: returning with: 0 (Success)
card.c:339:sc_connect_card: returning with: 0 (Success)
Using card driver GIDS Smart Card.
pkcs15-lib.c:313:sc_pkcs15init_bind: called
card.c:951:sc_card_ctl: called
card-gids.c:2019:gids_card_ctl: called
card_ctl(4) not supported
called; type=2, path=3f0050154946
card-gids.c:920:gids_select_file: called
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
reader-pcsc.c:613:pcsc_lock: called
card-gids.c:2057:gids_card_reader_lock_obtained: called
card-gids.c:2065:gids_card_reader_lock_obtained: returning with: 0 (Success)
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:A4, P1:8, P2:0, data(4) 0000007C6FD5F222
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (10 bytes):
00 A4 08 00 04 50 15 49 46 00 .....P.IF.
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (2 bytes):
6A 86 j.
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
reader-pcsc.c:663:pcsc_unlock: called
Incorrect parameters P1-P2
iso7816.c:578:iso7816_select_file: returning with: -1205 (Incorrect parameters in APDU)
card.c:776:sc_select_file: 'SELECT' error: -1205 (Incorrect parameters in APDU)
profile.c:336:sc_profile_load: called
Using profile directory 'C:\Program Files\OpenSC Project\OpenSC\profiles'.
Trying profile file C:\Program Files\OpenSC Project\OpenSC\profiles\pkcs15.profile
profile C:\Program Files\OpenSC Project\OpenSC\profiles\pkcs15.profile loaded ok
profile.c:383:sc_profile_load: returning with: 0 (Success)
profile.c:336:sc_profile_load: called
Using profile directory 'C:\Program Files\OpenSC Project\OpenSC\profiles'.
Trying profile file C:\Program Files\OpenSC Project\OpenSC\profiles\gids.profile
profile C:\Program Files\OpenSC Project\OpenSC\profiles\gids.profile loaded ok
profile.c:383:sc_profile_load: returning with: 0 (Success)
profile.c:395:sc_profile_finish: called
profile.c:438:sc_profile_finish: returning with: 0 (Success)
pkcs15-lib.c:420:sc_pkcs15init_bind: returning with: 0 (Success)
About to create PKCS #15 meta structure.
New Security Officer PIN (Optional - press return for no PIN).
Please enter Security Officer PIN: Please type again to verify: Unblock Code for New User PIN (Optional - press return for no PIN).
Please enter User unblocking PIN (PUK): Please type again to verify: card.c:415:sc_lock: called
reader-pcsc.c:613:pcsc_lock: called
card-gids.c:2057:gids_card_reader_lock_obtained: called
card-gids.c:2065:gids_card_reader_lock_obtained: returning with: 0 (Success)
card.c:455:sc_lock: returning with: 0 (Success)
pkcs15-lib.c:774:sc_pkcs15init_add_app: called
pkcs15-lib.c:4172:sc_pkcs15init_qualify_pin: called
pkcs15-lib.c:4191:sc_pkcs15init_qualify_pin: returning with: 0 (Success)
pkcs15-lib.c:4172:sc_pkcs15init_qualify_pin: called
pkcs15-lib.c:4191:sc_pkcs15init_qualify_pin: returning with: 0 (Success)
Add virtual SO_PIN('Security Officer PIN',flags:B2,reference:-1,path:'3f005015')
card.c:951:sc_card_ctl: called
card-gids.c:2019:gids_card_ctl: called
card-gids.c:605:gids_get_serialnr: called
card-gids.c:386:gids_read_gidsfile: called
card-gids.c:216:gids_get_DO: called
Got args: fileIdentifier=a000, dataObjectIdentifier=df1f, response=00000250F5BCD1C0, responselen=65000
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:CB, P1:A0, P2:0, data(4) 0000007C6FD3ECE0
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (10 bytes):
00 CB A0 00 04 5C 02 DF 1F 00 .....\....
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (147 bytes):
DF 1F 81 8D 01 6D 73 63 70 00 00 00 00 00 00 00 .....mscp.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 A0 00 ................
00 00 00 00 00 00 00 00 00 00 63 61 72 64 69 64 ..........cardid
00 00 00 00 00 20 DF 00 00 12 A0 00 00 00 00 00 ..... ..........
00 00 00 00 00 00 63 61 72 64 61 70 70 73 00 00 ......cardapps..
00 21 DF 00 00 10 A0 00 00 00 00 00 00 00 00 00 .!..............
00 00 63 61 72 64 63 66 00 00 00 00 00 22 DF 00 ..cardcf....."..
00 10 A0 00 00 6D 73 63 70 00 00 00 00 00 63 6D .....mscp.....cm
61 70 66 69 6C 65 00 00 00 23 DF 00 00 10 A0 00 apfile...#......
00 90 00 ...
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
card-gids.c:311:gids_read_gidsfile_without_cache: called
Identifiers of cardid is fileIdentifier=a012, dataObjectIdentifier=df20
card-gids.c:216:gids_get_DO: called
Got args: fileIdentifier=a012, dataObjectIdentifier=df20, response=0000007C6FD4ECE0, responselen=65538
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:CB, P1:A0, P2:12, data(4) 0000007C6FD3ECB0
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (10 bytes):
00 CB A0 12 04 5C 02 DF 20 00 .....\.. .
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (21 bytes):
DF 20 10 4D 55 E8 C6 5A C5 F4 49 4A F9 29 6E 96 . .MU..Z..IJ.)n.
EB 83 89 90 00 .....
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
card-gids.c:394:gids_read_gidsfile: returning with: 0 (Success)
card-gids.c:624:gids_get_serialnr: returning with: 0 (Success)
card.c:961:sc_card_ctl: returning with: 0 (Success)
pkcs15-lib.c:3143:sc_pkcs15init_add_object: called
add object 00000250F5C1B2D0 to DF of type 8
Append object
pkcs15-gids.c:109:gids_emu_update_any_df: called
pkcs15-gids.c:112:gids_emu_update_any_df: returning with: 0 (Success)
pkcs15-lib.c:3187:sc_pkcs15init_add_object: returning with: 0 (Success)
pkcs15-lib.c:2943:sc_pkcs15init_update_dir: called
dir.c:163:sc_enum_apps: called
called; type=2, path=3f002f00
card-gids.c:920:gids_select_file: called
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:A4, P1:8, P2:0, data(2) 0000007C6FD5E7F2
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (8 bytes):
00 A4 08 00 02 2F 00 00 ...../..
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (2 bytes):
6A 86 j.
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
Incorrect parameters P1-P2
iso7816.c:578:iso7816_select_file: returning with: -1205 (Incorrect parameters in APDU)
card.c:776:sc_select_file: 'SELECT' error: -1205 (Incorrect parameters in APDU)
dir.c:171:sc_enum_apps: Cannot select EF.DIR file: -1205 (Incorrect parameters in APDU)
pkcs15-lib.c:2971:sc_pkcs15init_update_dir: returning with: -1205 (Incorrect parameters in APDU)
pkcs15-lib.c:3922:sc_pkcs15init_update_file: called
path:3f0050154946; datalen:128
called; type=2, path=3f0050154946
card-gids.c:920:gids_select_file: called
apdu.c:554:sc_transmit_apdu: called
card.c:415:sc_lock: called
card.c:455:sc_lock: returning with: 0 (Success)
apdu.c:521:sc_transmit: called
apdu.c:371:sc_single_transmit: called
CLA:0, INS:A4, P1:8, P2:0, data(4) 0000007C6FD5E932
reader 'Broadcom Corp Contacted SmartCard 0'
reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (10 bytes):
00 A4 08 00 04 50 15 49 46 00 .....P.IF.
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (2 bytes):
6A 86 j.
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
Incorrect parameters P1-P2
iso7816.c:578:iso7816_select_file: returning with: -1205 (Incorrect parameters in APDU)
card.c:776:sc_select_file: 'SELECT' error: -1205 (Incorrect parameters in APDU)
pkcs15-lib.c:3944:sc_pkcs15init_update_file: Failed to select file: -1205 (Incorrect parameters in APDU)
pkcs15-lib.c:920:sc_pkcs15init_add_app: returning with: -1205 (Incorrect parameters in APDU)
card.c:465:sc_unlock: called
reader-pcsc.c:663:pcsc_unlock: called
Failed to create PKCS #15 meta structure: Incorrect parameters in APDU
pkcs15-lib.c:430:sc_pkcs15init_unbind: called
Pksc15init Unbind: 0:0000000000000000:1
card.c:356:sc_disconnect_card: called
card-gids.c:656:gids_finish: called
Broadcom Corp Contacted SmartCard 0:SCardDisconnect returned: 0x00000000
card.c:378:sc_disconnect_card: returning with: 0 (Success)
ctx.c:906:sc_release_context: called
reader-pcsc.c:900:pcsc_finish: called
I am not committed to these tools and am open to any suggestions.
It seems the issue the whole time was activclient smart card drivers.
I edited the registry key for my specific smart card: (HKLM\Software\Microsoft\Cryptography\Calais\Smartcards\ and changed the 80000001 string value to the default windows driver (C:\Windows\System32\msclmd.dll) and I am able to load applets, load keys, and utilize these cards for bitlocker encryption.
Related
I want to understand why EDNS(0) resource records contains an extra octet? I read RFC 6891 and RFC 1035. It says nothing about case when RDLENGHT == 0 but RDATA == "\0".
To test this here python code
import binascii
import socket
def send_udp_message(message, address, port):
"""send_udp_message sends a message to UDP server
message should be a hexadecimal encoded string
"""
message = message.replace(" ", "").replace("\n", "")
server_address = (address, port)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
sock.sendto(binascii.unhexlify(message), server_address)
data, _ = sock.recvfrom(4096)
finally:
sock.close()
return binascii.hexlify(data).decode("utf-8")
def format_hex(hex):
"""format_hex returns a pretty version of a hex string"""
octets = [hex[i:i+2] for i in range(0, len(hex), 2)]
pairs = [" ".join(octets[i:i+2]) for i in range(0, len(octets), 2)]
return "\n".join(pairs)
message = "AA AA 01 00 00 01 00 00 00 00 00 01 " \
"07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 "
# EDNS(0) resource record
message += "00 00 " # NAME
message += "29 00 " # TYPE
message += "FF 00 00 80 " # TTL
message += "00 00 " # RDLENGTH
# message += "00" # RDATA
response = send_udp_message(message, "8.8.8.8", 53)
print(format_hex(response))
Dns query returns here error. But if uncomment RDATA line it returns success.
You misread section §6.1.2 of RFC 6891, so the RFCs are not "lies".
It says:
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
so 6 pieces of information while your code has only 5 pieces:
# EDNS(0) resource record
message += "00 00 " # NAME
message += "29 00 " # TYPE
message += "FF 00 00 80 " # TTL
message += "00 00 " # RDLENGTH
# message += "00" # RDATA
You are missing the CLASS between TYPE and TTL, hence things are not interpreted the way you think they are.
You are also misreading how the bytes work for the name.
It is not:
00 00 NAME
29 00 TYPE
FF 00 00 80 TTL
00 00 RDLENGTH
but really:
00 NAME (root domain per EDNS(0) specification, which is a sole zero)
00 29 TYPE (41, per specification)
00 FF CLASS (255, considered as payload)
00 00 80 00 TTL, read as 00 = EXTENDED-CODE, 00 = VERSION (mandatory), 80 = DO set plus everything else 0 as the final 00 byte, per specification
00 RDLENGTH
and the final item RDLENGTH is then not properly formatted per the RFC 1035 specification as it is 2 bytes (16 bits).
Once you comment your last line, RDLENGTH becomes 00 00 and then is valid.
And there is indeed no RDATA part in your message.
What you believe being a 00 value in RDATA is in fact the last byte of RDLENGTH but you did not parse the stream correctly.
Had you used dnspython as advised to you, you would have seen the problem immediately with the proper mapping of fields:
In [1]: import dns
In [2]: import dns.message
In [10]: stream = 'AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00 00'
In [11]: data=''.join(chr(int(x, base=16)) for x in stream.split(' '))
In [12]: m = dns.message.from_wire(data)
In [13]: print m
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
Had you wanted to do that you could have simulated the expected bytes stream that way:
(starting from your message)
In [31]: m = dns.message.from_wire(data)
In [32]: print m
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
(creating a new one to look like yours)
In [39]: mm = dns.message.make_query('example.com.', 'A', use_edns=0, payload=255, want_dnssec=True)
In [40]: mm.id=43690
In [41]: print mm
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
(now looking at its wire representation)
In [46]: print ' '.join(hex(ord(d)) for d in mm.to_wire())
0xaa 0xaa 0x1 0x0 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x1 0x7 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x3 0x63 0x6f 0x6d 0x0 0x0 0x1 0x0 0x1 0x0 0x0 0x29 0x0 0xff 0x0 0x0 0x80 0x0 0x0 0x0
Comparing with your bytestream:
dnspython: AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00 00
you: AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00
Note the missing final 00 being in your commented line.
This shows that existing good libraries, as dnspython is, really help sometimes better understanding RFCs or other specifications. And in the world of DNS there are many RFCs, sometimes conflicting between each other, with ambiguous parts, etc. So using existing libraries for tests and/or studying their source code really helps, if you want this advice.
Have tried to establish the SSL connection to the Linux server machine from an STB client device. Am getting the following SSL error,
error:1408F10B:lib(20):func(143):reason(267) (find reason(code) at openssl/ssl.h)
On checking with openssl command, am getting the following information,
CONNECTED(00000003)
write to 0x7ee98 [0x8a153] (148 bytes => 148 (0x94))
0000 - 16 03 00 00 8f 01 00 00-8b 03 00 50 40 64 2c 41 ...........P#d,A
0010 - 53 23 c1 e1 9a dd e3 40-61 b3 71 cb 38 fe ba c9 S#.....#a.q.8...
0020 - 6b d7 b4 00 0d 21 88 19-6a 7c 56 00 00 64 c0 14 k....!..j|V..d..
0030 - c0 0a 00 39 00 38 00 37-00 36 00 88 00 87 00 86 ...9.8.7.6......
0040 - 00 85 c0 0f c0 05 00 35-00 84 c0 13 c0 09 00 33 .......5.......3
0050 - 00 32 00 31 00 30 00 9a-00 99 00 98 00 97 00 45 .2.1.0.........E
0060 - 00 44 00 43 00 42 c0 0e-c0 04 00 2f 00 96 00 41 .D.C.B...../...A
0070 - 00 07 c0 11 c0 07 c0 0c-c0 02 00 05 00 04 c0 12 ................
0080 - c0 08 00 16 00 13 00 10-00 0d c0 0d c0 03 00 0a ................
0090 - 00 ff 01 ...
0094 - <SPACES/NULS>
read from 0x7ee98 [0x85c03] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
write to 0x7ee98 [0x8f610] (7 bytes => 7 (0x7))
0000 - 15 03 00 00 02 02 28 ......(
3069535440:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1516869657
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Exact error am getting is 3069535440:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:.
Please have someone help to resolve this issue?
As you can see in the error information you provided there is a routines:SSL3_GET_RECORD:wrong version error. It seems to me that you try to use SSL3 although the Sever and/or Client is not supporting this SSL-Version.
Try to change the used method and try again.
EDIT: The protocol is supported due to Verify return code with Protocol SSLv3 being 0.
I'm working to get useful data from a VISA (such as PAN, expiry date...) credit card using a list of AIDs I got stuck.
I have been able to access to all the data manually. Using the next tutorial: http://www.openscdp.org/scripts/tutorial/emv/reademv.html
>>00 A4 04 00 07 A0 00 00 00 03 10 10 00
In ASCII:
<<o<EM>„<BEL> <0><0><0><ETX><DLE><DLE>¥<SO>P<EOT>VISA¿<FF><ENQ>ŸM<STX><VT><LF><0>
In Hexadecimal:
<<6F 19 84 07 A0 00 00 00 03 10 10 A5 0E 50 04 56 49 53 41 BF 0C 05 9F 4D 02 0B 0A 90 00
After that I used:
>>33 00 B2 01 0C 00 //sfi1, rec1
...
...
>>33 00 B2 10 FC 00 //sfi31, rec16
I continued with the tutorial and learned that the proper way to obtain the data was using GPO (Get Processing Options) command. And tried that next:
>>80 A8 00 00 0D 83 0B 00 00 00 00 00 00 00 00 00 00 00 00 // pdo = 83 0B 00 00 00 00 00 00 00 00 00 00 00 which suposse to be the correct one for VISA.
<< 69 85
So the condition of use is not satisfied.
>> 80 A8 00 00 02 83 00 00 //pdo= 83 00 that should work with every non visa card
<< 80 0E 3C 00 08 01 01 00 10 01 04 00 18 01 03 01 90 00
If this response is correct and it looks quite well for me as it starts by 80 and ends by 90 00, I am not able to identify AFL which I think that would make me possible to determine the PAN, expiry date... Can somebody help me?
The FCI that you received in response to the select command (00 A4 0400 07 A0000000031010 00) decodes to
6F 19 (File Control Information (FCI) Template)
84 07 (Dedicated File (DF) Name)
A0000000031010
A5 0E (File Control Information (FCI) Proprietary Template)
50 04 (Application Label)
56495341 ("VISA")
BF0C 05 (File Control Information (FCI) Issuer Discretionary Data)
9F4D 02 (Log Entry)
0B0A (SFI = 11; # of records = 10)
This FCI does not include any PDOL (processing options data list). Consequently, you need to assume a default value for the PDOL (which is an empty list for your card type). Consequently, the PDOL-related data field in the GET PROCESSING OPTIONS command must be empty:
83 00
Where 0x83 is the tag for PDOL-related data and 0x00 is a length of zero bytes.
Thus, the correct GPO command is (as you already found out):
80 A8 0000 02 8300 00
You got the response
800E3C00080101001001040018010301 9000
This decodes to
80 0E (Response Message Template Format 1)
3C00 (Application Interchange Profile)
08010100 10010400 18010301 (Application File Locator)
Consequently, the Application File Locator contains the following three entries:
08010100: SFI = 1, first record = 1, last record = 1, records involved in offline data authentication = 0
10010400: SFI = 2, first record = 1, last record = 4, records involved in offline data authentication = 0
18010301: SFI = 3, first record = 1, last record = 3, records involved in offline data authentication = 1
Consequently, you can read those record with the READ RECORD commands:
00 B2 010C 00
00 B2 0114 00
00 B2 0214 00
00 B2 0314 00
00 B2 0414 00
00 B2 011C 00
00 B2 021C 00
00 B2 031C 00
During a fresh installation, I accidentally formatted a disk containing datas. I have tried using some tools: testdisk, foremost, but I did not get good results. (see my unsuccessful post on superuser).
So I have decided to read some docs about ext2 filesystem structure, and I could get some results:
The deleted partition have a directory tree like that:
dev
|-scripts
|-projects
|-services
|-...
Medias
|-downloads
|-Musique
|-...
backup
...
So, based on the ext2 directory entry format:
Directory Entry
Starting_Byte Ending_Byte Size_in_Bytes Field_Description
0 3 4 Inode
4 5 2 Total size of this entry (Including all subfields)
6 6 1 Name Length least-significant 8 bits
7 7 1 Type indicator (only if the feature bit for "directory entries have file type byte" is set, else this is the most-significant 8 bits of the Name Length)
8 8+N-1 N Name characters
I tried to find some datas matching this structure.
I used this script:
var bindexOf = require('buffer-indexof');
var currentOffset=0;
var deviceReadStream = fs.createReadStream("/dev/sdb");
deviceReadStream.on('error',function(err){
console.log(err);
});
deviceReadStream.on('data',function(data){
var dirs = ["dev","scripts","services","projects","Medias","downloads","Musique","backup"];
dirs.forEach(function(dir){
dirOctetFormat = new Buffer(2);
dirOctetFormat.writeUInt8(dir.length,0);
dirOctetFormat.writeUInt8(2,1);// type is directory
dirOctetFormat= Buffer.concat( [dirOctetFormat, new Buffer(dir)]);
var offset = bindexOf( data, dirOctetFormat );
if( offset >= 0 ){
console.log( dir + " entry found at offset " + (currentOffset + offset) );
}
});
currentOffset += data.length;
});
}
I found data which seems to be the directory entry of the dev directory:
===== Current offset: 233590226944 - 217.5478515625Gio ======
scripts entry found at offset 233590227030
services entry found at offset 233590227014
projects entry found at offset 233590228106
If it is the case, I got the inode numbers of its children directories: scripts, projects, services,...
But I do not know what to do with that!
I tried to deduce the location of these inodes, based on this guide,
but as I was unable to find a superblock of the deleted filesystem, I just have to make guesses about the block size, the number of blocks, ...
and that seems a little bit fuzzy to me to hope obtaining a result.
So could you have some intervals for all values needed to obtain the offset of an inode, and a more formal formula to get this offset?
If you have only erased the partition table (or modified it) you can still get your data, if data has not been reused for something else.
ext2 filesystems have a MAGIC number in superblock, so to recover your partition you have only to search for it. I did this on one machine and was able to recover not one, but seven partitions in one disk. You have some chances to get invalid numbers, but just search for that magic. Magic number is defined in include/uapi/linux/magic.h and value is #define EXT2_SUPER_MAGIC 0xEF53 (it's found at offset #define EXT2_SB_MAGIC_OFFSET 0x38 ---from file include/linux/ext2_fs.h)
To search for the superblock, just try to find 0xef53 at offset 0x38 in one sector of the disk, it will mark the first block of the partition. Be careful, that superblock is replicated several times in one partition, so you'll find all the copies of it.
Good luck! (I had when it happened to me)
Edit (To illustrate with an example)
Just see the magic number in one of my own partitions:
# hd /dev/sda3 | head -20
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 40 62 08 00 00 87 21 00 26 ad 01 00 f6 30 15 00 |#b....!.&....0..|
00000410 1d 31 08 00 00 00 00 00 02 00 00 00 02 00 00 00 |.1..............|
00000420 00 80 00 00 00 80 00 00 90 1f 00 00 cf 60 af 55 |.............`.U|
00000430 fc 8a af 55 2d 00 ff ff 53 ef 01 00 01 00 00 00 |...U-...S.......|<- HERE!!!
00000440 36 38 9d 55 00 00 00 00 00 00 00 00 01 00 00 00 |68.U............|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00000460 46 02 00 00 7b 00 00 00 5a bf 87 15 12 8f 44 3b |F...{...Z.....D;|
00000470 97 e7 f3 74 4d 75 69 12 72 6f 6f 74 00 00 00 00 |...tMui.root....|
00000480 00 00 00 00 00 00 00 00 2f 00 61 72 67 65 74 00 |......../.arget.|
00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 02 |................|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 93 54 99 ab |.............T..|
000004f0 aa 64 46 b3 a6 73 94 34 a3 79 46 28 01 01 00 00 |.dF..s.4.yF(....|
00000500 0c 00 00 00 00 00 00 00 e5 61 92 55 0a f3 02 00 |.........a.U....|
00000510 04 00 00 00 00 00 00 00 00 00 00 00 ff 7f 00 00 |................|
00000520 00 80 10 00 ff 7f 00 00 01 00 00 00 ff ff 10 00 |................|
Remember it is on offset 0x38 counted from the block origin, and assume the super block is the second block (block 0 reserved for bootcode, so it will be block 1, with two sectors per block, to make 1k blocksize) in the partition, so you'll have to rewind 0x438 bytes from the beginning of the magic number to get the partition origin.
I have run the command on my whole disk, getting the following result:
# hd /dev/sda | grep " [0-9a-f][0-9a-f] 53 ef" | sed -e 's/^/ /' | head
006f05f0 ee 00 00 11 66 0a 00 00 53 ef 00 00 11 66 2d 00 |....f...S....f-.|
007c21d0 55 2a aa 7d f4 aa 89 55 53 ef a4 91 70 40 c1 00 |U*.}...US...p#..|
20100430 fc 8a af 55 2d 00 ff ff 53 ef 01 00 01 00 00 00 |...U-...S.......|
2289a910 0f 8f 4f 03 00 00 81 fe 53 ef 00 00 0f 84 ce 04 |..O.....S.......|
230d4c70 0a 00 00 00 1c 00 00 00 53 ef 01 00 00 00 00 00 |........S.......|
231b7e50 a0 73 07 00 00 00 00 00 53 ef 0d 00 00 00 00 00 |.s......S.......|
23dbd230 d5 08 ad 2b ee 71 07 8a 53 ef c2 89 d4 bb 09 1f |...+.q..S.......|
25c0c9e0 06 00 00 00 00 4f 59 c0 53 ef 32 c0 0e 00 00 00 |.....OY.S.2.....|
25d72ca0 b0 b4 7b 3d a4 f7 84 3b 53 ef ba 3c 1f 32 b9 3c |..{=...;S..<.2.<|
25f0eab0 f1 fd 02 be 28 59 67 3c 53 ef 9c bd 04 30 72 bd |....(Yg<S....0r.|
Clearly, there are much more uninteresting lines in this listing than the ones we need. To locate the one interesting here, we have to do some computing with the numbers. We have seen that sectors are 512 bytes long (this is 0x200 in hex) and we can have the superblock magic at offset 0x438, so we expect valid offsets to be at 0xXXXXXX[02468ace]38 only. Just select the lines with offsets ending in that expression, and you'll get the first superblock valid (in the third line) at offset 0x20100430.
Substract 0x430 to give the byte offset of the partition (0x20100000, and then, divide the result by 0x200, giving 0x100800, or 1050624)
# fdisk -l /dev/sda | sed -e 's/^/ /'
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DF97DAD4-727D-4BB3-BD7B-3C5A584A2747
Device Start End Sectors Size Type
/dev/sda1 2048 526335 524288 256M EFI System
/dev/sda2 526336 1050623 524288 256M BIOS boot
/dev/sda3 1050624 18628607 17577984 8.4G Linux filesystem <-- HERE!!!
/dev/sda4 18628608 77221887 58593280 28G Linux filesystem
/dev/sda5 77221888 85035007 7813120 3.7G Linux filesystem
/dev/sda6 85035008 104566783 19531776 9.3G Linux filesystem
/dev/sda7 104566784 135817215 31250432 14.9G Linux swap
/dev/sda8 135817216 155348991 19531776 9.3G Linux filesystem
/dev/sda9 155348992 1953523711 1798174720 857.4G Linux filesystem
The problem here is that Corba invocation does not return and none of exception is thrown when corba server is stopped.
In my case, there is only one multiple-thread corba proxy(Window), monitoring one backend corba server. The IDL of corba server is:
void run()
void echo();
The proxy checks backend's health via echo heartbeat invocation. The proxy would classify backend as DOWN state if corba exception is thrown in echo. This procedure works in most time but the backend is shut down.
1) If i shutdown backend machine, the echo throw exception immediately.
2) If I stop backend corba process, the echo invocation is hang and no return, not exception at client side. The client can not go future any more.
None of run invocation occur in above two cases.
The log with 'ORBDebugLevel 10' shows proxy completes echo request sending, and netstat showns there do one TCP connection between proxy and backend machine though the backend corba server process is stopped(I admit the backend server is disordered or bad programmed). But as proxy, how it avoid blocked by individual invocation failure if it neither return, nor throw exception?
Below are two logs, with default strategy:
TAO (276|1592) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY i
nvocation
TAO (276|1592) - Transport_Cache_Manager_T::is_entry_available_i[828], true, sta
te is ENTRY_IDLE_AND_PURGABLE
TAO (276|1592) - Cache_IntId_T::recycle_state, ENTRY_IDLE_AND_PURGABLE->ENTRY_BU
SY Transport[828] IntId=00A64ABC
TAO (276|1592) - Transport_Cache_Manager_T::find_i, Found available Transport[82
8] #hash:index {-1062676757:0}
TAO (276|1592) - Transport_Connector::connect, got an existing connected Transpo
rt[828] in role TAO_CLIENT_ROLE
TAO (276|1592) - Muxed_TMS[828]::request_id, <4>
TAO (276|1592) - GIOP_Message_Base::dump_msg, send GIOP message v1.2, 60 data by
tes, my endian, Type Request[4]
GIOP message - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 04 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 6c 00 06 9c b5 00 00 00 00 00 RST...l.........
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (276|1592) - Transport[828]::drain_queue_helper, sending 1 buffers
TAO (276|1592) - Transport[828]::drain_queue_helper, buffer 0/1 has 72 bytes
TAO - Transport[828]::drain_queue_helper (0/72) - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 04 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 6c 00 06 9c b5 00 00 00 00 00 RST...l.........
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (276|1592) - Transport[828]::drain_queue_helper, end of data
TAO (276|1592) - Transport[828]::cleanup_queue, byte_count = 72
TAO (276|1592) - Transport[828]::cleanup_queue, after transfer, bc = 0, all_sent
= 1, ml = 0
TAO (276|1592) - Transport[828]::drain_queue_helper, byte_count = 72, head_is_em
pty = 1
TAO (276|1592) - Transport[828]::drain_queue_i, helper retval = 1
TAO (276|1592) - Transport[828]::make_idle
TAO (276|1592) - Cache_IntId_T::recycle_state, ENTRY_BUSY->ENTRY_IDLE_AND_PURGAB
LE Transport[828] IntId=00A64ABC
TAO (276|1592) - Leader_Follower[828]::wait_for_event, (follower), cond <00B10DD
8>
With static Client_Strategy_Factory "-ORBTransportMuxStrategy EXCLUSIVE"
2014-Sep-03 16:34:26.143024
TAO (6664|5612) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY
invocation
TAO (6664|5612) - Transport_Cache_Manager_T::is_entry_available_i[824], true, st
ate is ENTRY_IDLE_AND_PURGABLE
TAO (6664|5612) - Cache_IntId_T::recycle_state, ENTRY_IDLE_AND_PURGABLE->ENTRY_B
USY Transport[824] IntId=00854ABC
TAO (6664|5612) - Transport_Cache_Manager_T::find_i, Found available Transport[8
24] #hash:index {-1062667171:0}
TAO (6664|5612) - Transport_Connector::connect, got an existing connected Transp
ort[824] in role TAO_CLIENT_ROLE
TAO (6664|5612) - Exclusive_TMS::request_id - <3>
TAO (6664|5612) - GIOP_Message_Base::dump_msg, send GIOP message v1.2, 60 data b
ytes, my endian, Type Request[3]
GIOP message - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 03 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 55 00 0d 7a 85 00 00 00 00 00 RST...U..z......
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (6664|5612) - Transport[824]::drain_queue_helper, sending 1 buffers
TAO (6664|5612) - Transport[824]::drain_queue_helper, buffer 0/1 has 72 bytes
TAO - Transport[824]::drain_queue_helper (0/72) - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 03 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 55 00 0d 7a 85 00 00 00 00 00 RST...U..z......
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (6664|5612) - Transport[824]::drain_queue_helper, end of data
TAO (6664|5612) - Transport[824]::cleanup_queue, byte_count = 72
TAO (6664|5612) - Transport[824]::cleanup_queue, after transfer, bc = 0, all_sen
t = 1, ml = 0
TAO (6664|5612) - Transport[824]::drain_queue_helper, byte_count = 72, head_is_e
mpty = 1
TAO (6664|5612) - Transport[824]::drain_queue_i, helper retval = 1
TAO (6664|5612) - Leader_Follower[824]::wait_for_event, (follower), cond <009009
10>
I understand this might be thread and ORB model problem. I tried some client strategy:
static Client_Strategy_Factory "-ORBTransportMuxStrategy EXCLUSIVE -ORBClientConnectionHandler RW"
This can reduce frequency of problem occurrence, but can not resolve problem complete.
This is similar to my experience 6 years ago. In that case, a invocation is send in one thread of client. Before receiving response, this thread is reused for sending another corba request due to reactor pattern. This case seems different to the case post here since it is only one corba invocation. My impression of thread stack is somewhat like:
server.anotherInvocation() //the thread is used for another invocation.
...
server::echo() //send 1st corba invocation
....
orb-run()
The problem is that it is OS dependent when the network stack will detect the disconnect of the server, sometimes it never happens. Much better and safer is to set a RELATIVE_RT_TIMEOUT_POLICY_TYPE policy to force a timeout on the invocation, see ACE_wrappers/TAO/tests/Timeout for an example how todo this.