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.
Related
I need to be able to inspect ts packets (looking at video PID 481) and determine whether the packet contains an IDR frame. My understanding is that I need to look for a NAL unit start code, and then something else after that to signify it's the start of an IDR frame. Please can someone clarify?
Here's an example of a packet that I think is an IDR frame, but need to be able to prove it from the payload data:
* Packet 2
---- TS Header ----
PID: 481 (0x01E1), header size: 12, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 1
Adaptation field: yes (8 bytes), payload: yes (176 bytes)
Discontinuity: 1, random access: 1, ES priority: 0
PCR: 0x000000013A5
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 31 07 D0 00 00 00 08 7E E5 00 00 01 E0 00 00 84 C0 0A 31 00 05
E5 CD 11 00 05 AD 8D 00 00 00 01 09 10 00 00 00 01 67 64 00 29 AC D9 40
78 04 4F DE 02 94 04 04 05 00 00 03 00 01 00 00 03 00 32 E6 80 00 F4 24
00 04 F5 8A 49 30 0F 8B 16 CB 00 00 00 01 68 FA A7 CB 00 00 01 06 00 05
95 6C 60 E4 85 80 00 00 01 06 05 FF FF F5 DC 45 E9 BD E6 D9 48 B7 96 2C
D8 20 D9 23 EE EF 78 32 36 34 20 2D 20 63 6F 72 65 20 31 34 38 20 2D 20
48 2E 32 36 34 2F 4D 50 45 47 2D 34 20 41 56 43 20 63 6F 64 65 63 20 2D
20 43 6F 70 79 72 69 67 68 74 20 32 30 30 33 2D 32 30 31 36
Its not possible to tell from that packet. It is however VERY likely it is an IDR. I say its likely, because looking at the NALUs, I can see an AUD 00 00 00 01 09, an SPS 00 00 00 01 67 a PPS 00 00 00 01 68 then an SEI 00 00 01 06
The SEI however takes the remaining bytes of the packet, You will need to continue reading packets from that PID until you fine the next NALU and see if its an IDR.
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.
I'm demuxing one program stream file and I can't figure out what one PES packet is carrying. (see picture below).
Stream ID is 0xE0, so it is a video stream. Since I'm reading a program stream file, it is the only video stream. As you can see, the packet length is 0x9C, the next byte 0x80 tells us that first two bits are '10', as expected and PES_scrambling_control, PES_priority, data_alignment_indicator, copyright and original_or_copy are all 0 (not set). The next byte 0x09 tells us that we have DSM_trick_mode_flag and PES_extension_flag set. The next byte 0x78 is PES header length. If we skip PES header, we will be at the first byte in the framed area containing 33 bytes. It begins with 00 37 B0... These 33 bytes should be skipped when demuxing, but I can't figure out why. Any comment or suggestion is very welcome.
PES packet picture
PES packet hex values as text:
00 00 01 e0 00 9c 80 09 78 00 52 40 09 ac 00 3f
40 00 22 00 d7 c0 00 e2 00 da 20 04 8a 00 62 60
02 36 00 46 10 0e a1 00 28 50 01 b9 00 d9 d0 09
cd 00 67 30 0f a3 00 44 b0 04 6b 00 8f b0 0d e7
00 64 f0 00 57 00 41 70 09 d7 00 a7 70 0d 5f 00
73 f0 0c 40 80 f8 88 00 b0 80 23 88 06 68 80 38
88 0b a8 80 be 08 07 b0 80 b3 f0 0a 10 80 67 70
08 90 80 b6 70 03 10 80 7f b0 09 00 80 f1 b0 0f
2f 00 37 b0 09 77 00 a4 70 0e 37 00 ca 70 07 47
00 b1 b0 03 33 00 3e 30 06 bd 00 77 50 05 2d 00
15 50
I have an OTI Copni device and I need to install a .cap file to this Copni device. So I have JCOP tools with Eclipse and I try to upload and install. It then gives this the indicated error. I presume this is happening because of a failed authentication.
cm> /term "winscard:4|SCM Microsystems Inc. SDI011G Contactless Reader 0"
--Opening terminal
> /card -a a000000003000000 -c com.ibm.jc.CardManager
resetCard with timeout: 0 (ms)
--Waiting for card...
ATR=3B 88 80 01 00 73 C8 40 00 00 90 00 62 ;....s.#....b
ATR: T=0, T=1, Hist=0073C84000009000
=> 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
(21592 usec)
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 20 17 3F 00 73 4A 06 07 2A ...n.G. .?.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 C2 3F 4B C4 BE B6 E5 58 00 .P....?K....X.
(43622 usec)
<= 00 00 32 98 00 09 30 97 06 25 01 02 00 10 68 6C ..2...0..%....hl
E3 CA 2C 2B 4D 2C 4B 0D 0E 62 5F 8C 90 00 ..,+M,K..b_...
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EB FC 66 BC FA 30 91 58 5B 51 FA .......f..0.X[Q.
0C 46 D7 43 C9 .F.C.
(12557 usec)
<= 69 85 i.
Status: Conditions of use not satisfied
jcshell: Error code: 6985 (Conditions of use not satisfied)
jcshell: Wrong response APDU: 6985
Unexpected error; aborting execution
Can someone tell me how to upload a .cap file to this device?
Try ext-auth mac instead, the smart card is probably in the state OP_SECURE, which means that at minimal command MAC is required.
As JCOP tools is not publicly available nor open source, I'd suggest you try a publicly available piece of software instead:
https://github.com/martinpaljak/GlobalPlatform#globalplatform-from-openkms
(as the name of the github repository implies this is self-promotion)
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.