Unblock code PIN with APDU commands: error "67 00" --> Wrong length - authentication

By using WinsCard.dll, I want to use APDU commands to reset PIN code and set a new into the smartcard. But when I launch these commands, I obtain error "67 00" ("Wrong length").
My APDU commands:
// First command, I verify the code PUK (return "90 00")
00 20 00 02 08 36 35 32 34 39 38 37 36
// Second command, I try to set a new code PIN into the card
00 2C 03 01 0C 36 35 32 34 39 38 37 36 31 32 33 34
For second command:
36 35 32 34 39 38 37 36 -> code PUK
31 32 33 34 -> new code PIN
After some searches, the only explanation that I have found is that the "Lc" parameter was wrong. But, in my case, it is equal to "0C", and the length of my data is "0C".
So, I don't understand where is my error.
Have you got an idea?
Thank you very much for your help!
Note:
If I reset the code PIN without put a new PIN (it restores previous code PIN), it works fine:
00 20 00 02 08 31 38 39 30 31 36 39 32
// Reset code PIN
00 2C 03 01 00

Using the RESET RETRY COUNTER command (INS = 0x2C) with P1 = 0x03 means that you want to reset the retry counter without setting new reference data (i.e. a new PIN). If you want to set new reference data (a new PIN) when resetting the retry counter, you could try (depending on what your card supports)
P1 = 0x00 (for the format you tried):
00 2C 00 01 0C 36 35 32 34 39 38 37 36 31 32 33 34
P1 = 0x02 (only the new reference data is sent):
00 2C 02 01 04 31 32 33 34

Your length should be 0x10. Plz refer below example:
A0 2C 00 01 10 3636303535333132 31323334 FFFFFFFF
Command : A0 2C 00 01 10
Input Data : 36 36 30 35 35 33 31 32 31 32 33 34 FF FF FF FF
Output Data : none
Status : 90 00
here 3636303535333132 is unblock key and 31323334 is new pin

Related

How to establish a TLS coonection in TLS-PSK mode between a USIM sim card as client and a server?

I want to establish a tls connection between my sim card and a server in TLS-PSK mode. to achive this, as far as I understood, First I have to send a push command to open a BIP channel, then establish a CAT_TP link by sending another push command and then sim card will start the TLS handshake. So first I want to send a push command to my sim card to open a BIP channel. To do this, the push command will be OPEN CHANNEL command. But first I'm testing this process by sending the OPEN CHANNEL command to sim card via sim card reader to see how it works. I have a sample file which I'm following that first sends an envelope SMS-PP with the following content:
81488346 \
84 44\ ;Connection parameter tag
81 03 014001\ ;Command details TLV
82 02 8182\ ;Device identities TLV
35 01 03\ ;Bearer description TLV: default
39 02 0514\ ;Buffer size TLV
47 14 13696E7465726E65742D656E7472657072697365\ ;Network Access Name
0D 07 xxxxxxxxxxxxxx\ ;login name
0D 07 xxxxxxxxxxxxxx\ ;password
3C 03 021964\ ; UICC/terminal interface port number
3E 05 xxxxxxxxxx ;IP address
in sample file it ciphers the above content by sim card's keys and it's RAM TAR value and sends the ciphered data by an envelope command like this:
Command : 80 C2 00 00 8A
Input Data : D1 81 87 02 02 82 81 06 02 80 01 8B 7D 40 05 81
: 12 50 F3 96 F6 22 22 22 22 22 22 22 6D 02 70 00
: 00 68 15 16 39 12 12 00 00 01 F0 BD C0 49 B4 0C
: EB A9 7C 4B 04 32 17 BE A7 2F DA AC 70 93 36 73
: 83 FD AC 64 CA 9B 34 9C 2B E6 31 24 A0 D5 11 09
: 00 3E E3 F5 43 4B 55 77 98 E5 08 40 A4 CE A9 52
: 3E E1 38 6B 44 AC 73 1E 3B CD 49 32 92 B2 C3 22
: 25 02 68 90 FD F5 06 23 97 0D BD 5B 1D DE 25 F1
: FD 4C 75 C8 37 AC B0 15 05 25
Then it fetches the push sms via a FETCH command and after that get the terminal response with TERMINAL RESPONSE command to see if everything went ok. and finally fetches the open channel with the FETCH command and it says once OPEN CHANNEL is done, card sends CLIENT HELLO to the server to start the TLS handshake.
Now I want to implement this but at the first step, where I should send the envelope, I expect to get 9146 as status word which means everything was ok. but I get 6200 which means "State of non-volatile memory is unchanged".
Why do I get this respnse? And basically what is the proper way to open a BIP channel and then stablish a CAT-TP link?
You should first send the TERMINAL PROFILE command. With this command, you'll let the UICC know what the terminal is capable of. In this command, you should indicate that the terminal is capable of handling PROACTIVE commands. You can read more about this in ETSI TS 102223

Unpacking jPOS ISO8583

I am having this error when I am generating transaction with Magnetic stripe card. Could you suggest what is the problem here?
<receive>
<iso-exception>
org.jpos.iso.IFB_LLLCHAR: Problem unpacking field 54 (java.lang.ArrayIndexOutOfBoundsException: 86) unpacking field=54, consumed=86
org.jpos.iso.ISOException: org.jpos.iso.IFB_LLLCHAR: Problem unpacking field 54 (java.lang.ArrayIndexOutOfBoundsException: 86) unpacking field=54, consumed=86
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:340)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:468)
at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:965)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:735)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:344)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:76)
</iso-exception>
--- header ---
0000 00 00 00 00 00 .....
--- data ---
0000 02 00 70 38 04 80 20 80 3F 04 16 94 96 10 03 32 ..p8.. .?......2
0010 13 38 00 00 00 00 00 00 01 88 00 00 00 00 30 11 ..8............0.
0020 11 27 11 28 00 21 00 37 94 96 10 03 32 13 38 00 .'.(.!.7....2.8.
0030 D2 00 89 EC 49 D2 C2 B5 6B 2A 00 39 35 30 30 30 ....I...k*.95000
0040 30 32 30 34 39 36 F0 D2 EB A5 2B 2F AE 2E 00 06 020496....+/....
0050 30 30 30 30 35 30 000050
We have not been fully aware of BITMAP structure at first field. There are 64 bits with and if there are not 64 i.e 62 bits with starting 1, that means 1st and 2nd fields are not presented. Bitmap never starts with 0 so as long as it starts with 1 we need to add incomplete sequence prior to that with zeros.

MTIP MP92 Test 1 Scenario 1 - Card Indicates that it does not support Contactless

I'm running M-TIP MP92 Test 01 Scenario 01. The objective of the test is:
"To ensure that the terminal terminates the transaction when the card indicates that it does not support Contactless - M/Chip".
What I don't understand, is how a card indicates this. My terminal as it is right now is processing beyond the Get Processing Options step, which results in a failure from my testing tool. I've looked through the data being exchanged between the card and the tool up to that point, but I don't understand where this is.
Select (2PAY.SYS.DDF01)
Request : 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
Class :00
Ins :A4
P1 :04
P2 :00
Lc :0E
Data :32 50 41 59 2E 53 59 53 2E 44 44 46 30 31
Application: 2PAY.SYS.DDF01
Le :00
Response: 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 04 30 60 87 01 01 90 00
Data : 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 04 30 60 87 01 01
Tag 6F : File Control Information (FCI) Template
Tag 84 : Dedicated File (DF) Name : 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31
PPSE Directory File Name = 2PAY.SYS.DDF01
Tag A5 : File Control Information (FCI) Proprietary Template
Tag BF 0C: File Control Information (FCI) Issuer Discretionary Template
Tag 61 : Application Template
Tag 4F : Application Identifier (AID) : A0 00 00 00 04 30 60
Tag 87 : Application Priority Indicator : 01
Byte 1 bit 8 = 0 Application may be selected without confirmation of cardholder
bit 7-5= 000 RFU
bit 4-1= 0001 Order number in which the application is to be listed: 1
SW1 SW2 : 90 00 (SW_OK)
Select (Maestro)
Request : 00 A4 04 00 07 A0 00 00 00 04 30 60 00
Class :00
Ins :A4
P1 :04
P2 :00
Lc :07
Data :A0 00 00 00 04 30 60
Application: Maestro
Le :00
Response: 6F 2F 84 07 A0 00 00 00 04 30 60 A5 24 50 09 4D 50 39 32 20 76 32 20 32 BF 0C 16 5F 50 13 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32 90 00
Data : 6F 2F 84 07 A0 00 00 00 04 30 60 A5 24 50 09 4D 50 39 32 20 76 32 20 32 BF 0C 16 5F 50 13 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32
Tag 6F : File Control Information (FCI) Template
Tag 84 : Dedicated File (DF) Name : A0 00 00 00 04 30 60
Tag A5 : File Control Information (FCI) Proprietary Template
Tag 50 : Application Label : 4D 50 39 32 20 76 32 20 32
Text value = MP92 v2 2
Tag BF 0C: File Control Information (FCI) Issuer Discretionary Template
Tag 5F 50: Issuer URL : 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32
Text value = COLLIS\*/MP92\*/2.2
SW1 SW2 : 90 00 (SW_OK)
Get Processing Options
Request : 80 A8 00 00 02 83 00 00
Class :80
Ins :A8
P1 :00
P2 :00
Lc :02
Data :83 00
Le :00
MCHIP Card Unique Key Derivation Results
PAN: 67 99 99 89 00 00 00 60 92 7F
PAN Sequence Number: 01
Cryptogram Version No.: 10
ICC Master Key AC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
Derived Card Unique Key: 9D A1 13 AD 92 46 DC 04 85 92 3B 86 94 08 DC DF
ICC Master Key SMC: CE 29 3B 8C C1 2A 97 73 79 EF 25 6D 76 10 94 92
Derived Card Unique Key: 68 62 A7 40 F8 3E FE 97 E5 04 0D FB 10 85 46 CE
ICC Master Key SMI: 46 64 94 2F E6 15 FB 02 E5 D5 7F 29 2A A2 B3 B6
Derived Card Unique Key: 10 C4 F7 DF 68 75 B0 E5 EF 80 C7 AB 3B 80 9B F8
ICC Master Key IDN: 94 C5 3B 6B 15 07 7F CB E5 40 7F 43 B5 AB FB 80
Derived Card Unique Key: AB 51 29 16 AE 08 1A 25 DF 76 D0 3E EC 9E 6B 40
Response: 77 16 82 02 19 00 94 10 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00 90 00
Data : 77 16 82 02 19 00 94 10 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00
Tag 77 : Response Message Template Format 2
Tag 82 : Application Interchange Profile [M/Chip, PayPass] : 19 00
Byte 1 bit 8 = 0 RFU
bit 7 = 0 Offline static data authentication is NOT supported
bit 6 = 0 Offline dynamic data authentication is NOT supported
bit 5 = 1 Cardholder verification is supported
bit 4 = 1 Terminal risk management is to be performed
bit 3 = 0 Issuer authentication is supported using GENERATE AC command
bit 2 = 0 On device cardholder verification is NOT supported
bit 1 = 1 Combined DDA / GENERATE AC supported
Byte 2 bit 8 = 0 Only Mag Stripe profile supported [PayPass]
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 94 : Application File Locator (AFL) : 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00
AFL (1) = 08 01 01 00
SFI (decimal) = 1
Start record = 1
End record = 1
Number of records needed
for offline data authentication = 0
AFL (2) = 10 01 01 01
SFI (decimal) = 2
Start record = 1
End record = 1
Number of records needed
for offline data authentication = 1
AFL (3) = 18 01 02 00
SFI (decimal) = 3
Start record = 1
End record = 2
Number of records needed
for offline data authentication = 0
AFL (4) = 20 01 02 00
SFI (decimal) = 4
Start record = 1
End record = 2
Number of records needed
for offline data authentication = 0
SW1 SW2 : 90 00 (SW_OK)
This Card Profile MP 92 due to AIP tag 0x82 Byte 2 Bit 8 - EMV Contactless NOT supported (i.e. Only Mag Stripe profile supported [PayPass] in your traces).
According to MasterCard rules, M/Chip Contactless-Magstripe should not be supported for Maestro cards in Europe.
This restriction should be indicated for Maestro Contactless RID/AID profile in Tag 0x9F1D Byte 3 Bit 8. Tag 0x9F1D Byte 3 should be 0x80 i.e Contactless-Mastripe not supported.
When you fix your Maestro terminal profile the Terminal Kernel should reject this Contactless card and ask to use Chip as expected by this test scenario.

Finding Macintosh file's attributes

I will illustrate a use case of my issue.
I have here two files which happen to be the Finder 7.5.5 and Finder 8.1 from legacy Mac OS versions.
If I use Cmd + I I get the following information:
Version:
7.5.5, © Apple Computer, Inc. 1983-96
System 7.5 Version 7.5.3
and
Version:
8.1, Copyright Apple Computer, Inc. 1983-97
Mac OS 8.1
I want to extract these information programatically. However, I am not even sure where it is being hold.
In a small Objective-C project (Foundation) I did the following for the 7.5 file:
NSString * finder7 = [[NSString alloc] initWithString:#"/Users/me/Desktop/Finder7"];
NSFileManager * fileManager = [NSFileManager defaultManager];
NSError * error = nil;
NSDictionary * attr = [fileManager attributesOfItemAtPath:finder7 error:&error];
NSLog(#"%#", attr);
This is the output:
2013-09-25 10:53:30.224 GetAttributes[1164:903] {
NSFileCreationDate = "1996-01-15 12:00:00 +0000";
NSFileExtensionHidden = 0;
NSFileGroupOwnerAccountID = 20;
NSFileGroupOwnerAccountName = staff;
NSFileHFSCreatorCode = 1296122707;
NSFileHFSTypeCode = 1179534418;
NSFileModificationDate = "1996-01-15 12:00:00 +0000";
NSFileOwnerAccountID = 501;
NSFileOwnerAccountName = me;
NSFilePosixPermissions = 493;
NSFileReferenceCount = 1;
NSFileSize = 0;
NSFileSystemFileNumber = 4384377;
NSFileSystemNumber = 234881026;
NSFileType = NSFileTypeRegular;
}
As you can see, there is no reference to version or copyright. I can't open the "app's content" because legacy applications obviously don't have it.
So I figured it could be an extended attribute, so I got the console and did this:
$ ls -l#
-rwxr-xr-x# 1 me staff 0 15 Jan 1996 Finder7
com.apple.FinderInfo 32
com.apple.ResourceFork 503994
-rwxr-xr-x# 1 me staff 3631000 16 Dec 1997 Finder8
com.apple.FinderInfo 32
com.apple.ResourceFork 502012
com.apple.metadata:kMDItemFinderComment 42
Then I found these entries in each of them:
$ xattr -l com.apple.FinderInfo Finder7
(...)
00077AE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00077AF0 00 00 32 07 55 80 00 00 00 05 37 2E 35 2E 35 25 |..2.U.....7.5.5%|
00077B00 37 2E 35 2E 35 2C 20 A9 20 41 70 70 6C 65 20 43 |7.5.5, . Apple C|
00077B10 6F 6D 70 75 74 65 72 2C 20 49 6E 63 2E 20 31 39 |omputer, Inc. 19|
00077B20 38 33 2D 39 36 00 00 00 2B 00 00 00 00 00 00 00 |83-96...+.......|
(...)
$ xattr -l com.apple.FinderInfo Finder8
(...)
00077330 06 46 69 6E 64 65 72 00 00 00 00 00 00 36 08 10 |.Finder......6..|
00077340 80 00 00 00 03 38 2E 31 2B 38 2E 31 2C 20 43 6F |.....8.1+8.1, Co|
00077350 70 79 72 69 67 68 74 20 41 70 70 6C 65 20 43 6F |pyright Apple Co|
00077360 6D 70 75 74 65 72 2C 20 49 6E 63 2E 20 31 39 38 |mputer, Inc. 198|
00077370 33 2D 39 37 00 00 00 26 01 08 10 80 00 06 46 69 |3-97...&......Fi|
00077380 6E 64 65 72 00 00 00 00 00 00 00 00 00 00 00 00 |nder............|
(...)
I never really used extended attributes, specially in a development. So here I need some light. I see the version numbers are in different positions. How can I get this information straight like the OSX Finder does? I spent several minutes to do it manually and still is not clear to me how the version is stored. Is there other place I can find this information or am I going in the right direction?
Are there Objective-C or C solutions that will do this so I don't need to reinvent the wheel?
I appreciate the help!
I also tried checking rsrc. Found an easter egg just before the version number.
The information is stored in the extended attribute com.apple.ResourceFork. You can use a tool like DeRez to decompile the information.
If you want to programatically access the resource fork, there is the Resource Manager API, but pretty much everything there is deprecated for 10.8. The resource type for version information is the 'vers' resource.

How to extract exponents and modulus from SSH-RSA key files

http://www.faqs.org/rfcs/rfc4253.html
::http://www.faqs.org/rfcs/rfc4251.html
Does anyone know the SSH key file format?
!! UPDATE
!! The base64 function I was using doesn't work. After running the key file through a different function (mozilla's built in atob()) the data fit into the specifications listed above.
I have rsa key files created with puttygen, but I must be missing something critical. Here is the hex of the public section:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25
00 00 00 10 1c 1c 57 3f 4f 58 63 69 38 ad 19 35
b5 28 3d 78 53 35 53 6c 15 0e 69 23 ac 17 14 84
21 29 13 07 36 62 90 26 37 93 73 17 28 b8 ce 95
c3 11 24 21 61 b7 82 d9 04 42 97 f8 27 c3 44 06
46 ca e8 a3 a3 34 d7 3c c3 95 13 dd 16 1b 2c 29
7c 35 19 5f c2 7a 17 d5 14 0d 26 36 27 18 71 67
8d 9c 5b c4 7d
first 4 bytes are UINT 7, the number of bytes inthe following string "ssh-rsa" but the format stops making sense after that. It SHOULD be followed by two MPINT but they lengths don't add up for the 3rd value.
Thanks!
It's in ASN.1 syntax. You should be able to use an ASN.1 parser along with the specs for the file contents to decipher it.