I'm trying to read the data off a contactless Mastercard Paypass card.
So I submit a SELECT PPSE command using 2PAY.SYS.DDF01. Here is my command APDU:
00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
In the APDU Response I get the error "6A82", which is "file not found".
I'm stuck, Can anyone help me to read data from the paypass card?
Related
I'm trying to store a Buffer into a bytea type column. I'm using a Postgres database and I have successfully connected to this database with node-postgres. I am able to update any other field, but I just can't find out what the syntax is to properly store a Buffer.
At the moment, there are already images in that database, that were written with a different system and language. I am not able to to re-use this system to achieve what we need.
The output of those existing images is also a Buffer:
<Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 04 38 00 00 04 38 08 06 00 00 00 ec 10 6c 8f 00 00 00 04 73 42 49 54 08 08 08 08 7c 08 64 88 00 ... 13315 more bytes>
And I have prepared the an image that should overwrite this value:
<Buffer 75 ab 5a 8a 66 a0 7b fa 67 81 b6 ac 7b ae 22 54 13 91 c3 42 86 82 80 00 00 03 52 52 11 14 80 00 00 2a 00 00 00 2a 02 00 00 00 00 14 48 3e 9a 00 00 00 ... 3153 more bytes>.
All good, so far.
I now need to use the proper SQL UPDATE statement, but I have not been able to figure that out. I have found some answers suggesting converting it using .toString('hex') and prepending it with \\x, but this does not result in the same value format.
My update statement now looks something like this (where imageData is the second Buffer example above):
await pool.query(
`UPDATE image
SET data = '${imageData}'::bytea
WHERE id = '00413567-fdd7-4765-be30-7f80c2d8ce57'`
)
Some requirements:
I can not use an external file
I can not use a different value format
I can not use a different tech stack
I have a clean Kona112 Javacard and I'm going to a put a Receipt key into it and then I want to delete it from the card or replace its value.
Step 1: I tried to create a new key on the card with Key Version == 0x71 (Quoted from GP UICC Configuration v1.0.1: "Key Version number '71' with Key Identifier '01' is reserved for the Receipt Key, which is a DES key"):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 B5 75 C3 8D 89 DC F9 B1 74 CC 1E 93 C4 45 C8 2C 03 CD 80 0F EC EA 8D 6F 8F BF 7D D0 // PUT KEY
<-- 6A 80
==> Quoted from GP UICC Configuration v1.0.1: "6A80 = ISO compliant standard status word for Algorithm not supported"
Step 2: As I received "Algorithm not supported" error, I enabled Delegated Management on my card and retried step #1:
[Select ISD]
[Successful Mutual Authentication]
[Proprietary APDU command to enable Delegated Management]
--> 84 D8 00 01 1F 71 80 10 1A F6 96 45 2A ED 66 86 75 DF FC 8B 59 55 6D 0B 03 CD 80 0F 87 03 E4 1A 8D AB 90 EC
<-- 71 CD 80 0F 90 00
Good! I successfully put the Receipt key in the card.
Step 3: Now, I want to delete it:
[Select ISD]
[Successful Mutual Authentication]
--> 80 E4 00 00 06 D0 01 01 D2 01 71 // Delete APDU Command to delete a key with Key ID = 01 and Key Version = 71
<-- 6A 80
As you see above, I received 6A 80 error status words. It is mentioned in the answer of my other question (and also in GP UICC Configuration v1.0.1) that the Key Deletion feature is optional.
So in step #4 I tried to replace the key with another value.
Step 4: I changed P1 in PUT Key APDU command from 0x00 (create key) to 0x71 (overwrite):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 71 01 1F 71 80 10 E9 06 6B 8E D8 05 50 34 D5 A7 71 3B 81 CB BE 7A 03 CD 80 0F 91 0D BC E9 96 25 7E 89
<-- 6A 88
==> Quoted from GP UICC Configuration v1.0.1: "6A88 = Referenced data not found"
Well, that's weird, I received "Referenced data not found". So I tried the PUT Key command with P1 = 0X00 (Create Key) again:
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 31 35 5C 0C E3 27 FD D5 8B 6B AE 37 56 CA 0D F2 03 CD 80 0F 0B EB 16 CF FF CE 4C 09
<-- 69 85 // Conditions of used not satisfied.
Well, I tried both cases of step #3 (P1 = 0x00 and P1 = 0x71) with disabled Delegated Management too, but nothing changed and I respectively received 0x6A80 and 0x6A88.
What's wrong? How can I fix the delete or modify this key?
Note that I tried all the steps in secure channel with SecurityLevel = 0x03 too. Nothing changed.
Update:
I tried to list the available keys in the card using GET DATA APDU command with Key Info Template tag, but I only can see ISD ENC, MAC and KEK keys in the APDU Response (For both DM enabled and DM Disabled.
--> 80 CA 00 E0 00
<-- E0 12 C0 04 01 01 80 10 C0 04 02 01 80 10 C0 04 03 01 80 10 90 00
One idea: The receipt key (and you also have to store a token key) might be linked to a application security domain. Select the Security Domain with Token Verification privilege and the Security Domain with Receipt Generation
privilege, maybe they are different from the ISD. I assume also that during [Proprietary APDU command to enable Delegated Management] a new application security domain (ASP) was created. Try the select these new security domains and list there all the keys using the key template flag and execute then your PUT KEY operations against one of these security domains. GET STATUSis the command to be used for listing the SDs. All the existing OS tools like GPShell and GlobalPlatformPro can do this.
I'm trying to generate a midi file (with jsmidgen) and I'm able to output it with node this way :
fs.writeFileSync('test.mid', file.toBytes(), 'binary');
That midi file is working perfectly. Then I'm trying to generate it from a browser and I download it with FileSaver.js this way :
let blob = new Blob([file.toBytes()], {type: "audio/midi"});
saveAs(blob, "test.mid");
That midi file is corrupted. I tried various blob content types without success and I've also validated that the file.toBytes() output is the same in both circumstances. I compared both hex outputs it looks like an encoding issue but I'm not able to find how to fix this.
Hex code from the good file (save in Node with fs)
4d 54 68 64 00 00 00 06
00 00 00 01 00 80 4d 54
72 6b 00 00 00 5e 00 90
3c 5a 40 80 3c 5a 00 90
3e 5a 40 80 3e 5a 00 90
40 5a 40 80 40 5a 00 90
41 5a 40 80 41 5a 00 90
43 5a 40 80 43 5a 00 90
45 5a 40 80 45 5a 00 90
47 5a 40 80 47 5a 00 90
48 5a 40 80 48 5a 81 00
90 3c 5a 00 90 40 5a 00
90 43 5a 81 00 80 3c 5a
00 80 40 5a 00 80 43 5a
00 ff 2f 00
Hex code from the bad file (FileSaver/Blob) :
4d 54 68 64 00 00 00 06
00 00 00 01 00 c2 80 4d
54 72 6b 00 00 00 44 00
c2 90 3c 5a 40 c2 80 3c
5a 00 c2 90 3e 5a 40 c2
80 3e 5a 00 c2 90 40 5a
40 c2 80 40 5a 00 c2 90
41 5a 40 c2 80 41 5a 00
c2 90 43 5a 40 c2 80 43
5a 00 c2 90 45 5a 40 c2
80 45 5a 00 c2 90 47 5a
40 c2 80 47 5a 00 c2 90
48 5a 40 c2 80 48 5a 00
c3 bf 2f 00
Is there something wrong with the way I'm using Blob or could I try another approach?
The code I used to generate the midi file is the first example on the jsmidgen page, the one playing a C major scale.
Do you need to use Blob specifically? If not, then you can use btoa.
I use jsmidgen as a primary dependency for my module(which acts as a wrapper and does some other things) and I faced a similar issue hence came up with this:
const bytes = file.toBytes();
const b64 = btoa(bytes);
const uri = 'data:audio/midi;base64,' + b64;
const link=document.createElement('a');
link.href=uri;
link.download = 'music.mid';
link.click(); // this will start a download of the MIDI byte string
I ve documented this in the context of my module with a working JS Bin in there too: https://scribbletune.com/documentation/core/midi
I have been receiving an odd/unknown message while attempting to communicate with some bittorrent peers. In this particular case I am in the middle of downloading pieces and all of a sudden this new/odd message pops up in front of a piece response.The message is odd because it doesn't appear to follow the protocol, all messages are supposed to look like this
'<length prefix><message ID><payload>'
length prefix is 4 bytes, message id is 1 byte and the payload. I am including a capture to show what I mean, on line 509 of the capture you will
see a request for a piece, on line 510 you will see the beginning of the response.
The first 4 bytes of the response are 00 00 00 00, ie 0 length message (Which is causing me issues), the next 4 bytes are the actual length of the message which is 30. The actual response to the piece request starts on line 513, so I get the piece I was requesting but this new/odd message is messing me up. I'm certain I can find a workaround but I would really like to understand what this means.
Also, I have no idea what the actual message means, and cannot find any information about it anywhere.
Here is the Wireshark capture.
https://1drv.ms/u/s!Agj06pa-wu0tnFqsYn_KnHmVz3x2
Data from packet 510:
0000 00 00 00 00 00 00 00 1e 14 01 64 35 3a 61 64 64 ..........d5:add
0010 65 64 36 3a 63 f2 7a 48 17 f4 37 3a 64 72 6f 70 ed6:c.zH..7:drop
0020 70 65 64 30 3a 65 ped0:e
00 00 00 00 4 bytes keep-alive message
00 00 00 1e message length 30 bytes
14 message type extended message (BEP10)
01 extended message ID = 1 as specified by the previous extension handshake: ut_pex
64 35 3a 61 64 64 65 64 36 3a 63 f2 7a 48 17 f4 37 3a 64 72 6f 70 70 65 64 30 3a 65
d5:added6:c.zH..7:dropped0:e
ut_pex message data (bencoded)
d
5:added
6:c.zH..
7:dropped
0:
e
ut_pex message data (bencoded with added white space)
The first 4 bytes of the response are 00 00 00 00, ie 0 length message (Which is causing me issues)
The bittorrent spec says
Messages of length zero are keepalives, and ignored.
I am unable to unzip file in linux centos. Getting following error
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
As you are mentioning jar in your comments we can consider this a programming question ;-)
First of all you should try to validate your file. If available you can even compare the checksum provided for this file and / or the filesize with the location you downloaded it from.
To verify the zip file on a low level you can use this command:
hexdump -C -n 100 file.zip
This will show you the first 100 bytes of the zips structure which will look similar to this:
00000000 50 4b 03 04 0a 00 00 00 00 00 88 43 65 47 11 7a |PK.........CeG.z|
00000010 39 1e 15 00 00 00 15 00 00 00 0e 00 1c 00 66 69 |9.............fi|
00000020 6c 65 31 69 6e 7a 69 70 2e 74 78 74 55 54 09 00 |le1inzip.txtUT..|
00000030 03 0f 05 3b 56 2f 05 3b 56 75 78 0b 00 01 04 e8 |...;V/.;Vux.....|
00000040 03 00 00 04 e8 03 00 00 54 68 69 73 20 69 73 20 |........This is |
00000050 61 20 66 69 6c 65 0a 1b 5b 31 37 7e 0a 50 4b 03 |a file..[17~.PK.|
00000060 04 0a 00 00 |....|
The first two byte of the file have to be PK, if not the file is invalid. Some bytes later you will find the name of the first file stored. In this example it is file1inzip.txt.