I am trying to read data from sony felica card using pc/sc transparent session and transceive data object.
The response I am getting is for a read without encryption command is
c0 03 00 90 00 92 01 00 96 02 00 00 97 82 00 + Data
But according to the protocol, the response should be
c0 03 00 90 00 92 01 00 96 02 00 00 97 + Data
I am unable to figure out the last 82 00 appended in the response from the card.
Now when I try to authenticate with the card I get
c0 03 01 6F 01 90 00
which is a error in pc/sc. I want to resolve these extra bytes 82 00 which I believe will solve the issue with all the commands which require authentication and encryption.
The response data is BER-TLV encoded (see PC/SC 2.02, Part 3).
In BER-TLV encoding there are several possibilities to encode tag 0x97 with two octets of data 0xD0D1, e.g.:
97|02|D0D1 -- short form (see parsed)
97|8102|D0D1 -- long form with one octet with length (see parsed)
97|820002|D0D1 -- long form with two octets with length (see parsed)
97|83000002|D0D1 -- long form with three octets with length (see parsed)
...
Your reader is using two octets for sending the length of ICC Response data object (which is perfectly valid).
You should parse the response properly...Good luck!
PS: The above means, that the Data part of your truncated responses still contains one extra byte with the response length (i.e. Len|Data)
Related
I have a program that decrypts a ciphertext (which I don't control) using this example from the go docs: https://pkg.go.dev/crypto/cipher#NewCBCDecrypter
The problem is this part:
// If the original plaintext lengths are not a multiple of the block
// size, padding would have to be added when encrypting, which would be
// removed at this point. For an example, see
// https://tools.ietf.org/html/rfc5246#section-6.2.3.2
My original plaintext length is indeed not a multiple of the block size, so I need to remove the padding. How can I do this? If I do not remove the padding, I can not decompress the plaintext because of https://github.com/golang/go/issues/47809 which go maintainers made clear is very strict about gzip compliance on purpose. Currently my workaround is to invoke gunzip as a shell command which can successfully decompress the plaintext (ignoring the trailing padding).
I checked the ietf link but I found no examples (or at least no go examples)
It turns out the encrypter and decrypter have to agree on a padding scheme in advance. In my case, the encrypter was using the padding scheme described here: https://www.rfc-editor.org/rfc/rfc5652#section-6.3
In other words, the plaintext is padded with 0x01 if there is one byte of padding, 0x02 0x02 if there are 2 bytes of padding, 0x03 0x03 0x03, etc.
So for a toy example, assume block size is 4 bytes. Here are some example plaintexts:
plaintext ... plaintext with padding
01 01 03 03 03
01 02 01 02 02 02
01 02 03 01 02 03 01
01 02 03 04 01 02 03 04 04 04 04 04
Therefore, I was able to remove plaintext padding using:
func removePadding(pt []byte) []byte {
padLength := int(pt[len(pt)-1])
return pt[:len(pt)-padLength]
}
See also: https://crypto.stackexchange.com/a/2805
I will give you some information first!
I am currently trying to decode the server data socket.io sends as response to the client (when using Http long-polling) as I am trying to intercept the communication. I don't have access to the client-side socket instance.
Though I would like to be able to have the same JSON data the client-socket instance would end up with!
The content type of the socket.io responses is: 'application/octet-stream'
Calling Response.body() on the Response object returns the following Buffer:
<Buffer 00 01 02 08 ff 34 32 5b 22 75 70 64 61 74 65 55 73 65 72 73 52 6f 6f 6d 22 2c 7b 22 72 6f 6f 6d 22 3a 22 48 65 69 6c 69 67 74 75 6d 22 2c 22 75 73 65 ... 83 more bytes>
Calling Response.text() on the Response object returns the following string:
☺☻�42["updateUsersRoom",{"room":"Heiligtum","userid":13132,"imgthumb":"thumb_ffkqOEBwQXbf_pngfindcomrealisticspiderwebpngpng.png"}]
Now you might think that Response.text() looks okay-ish, however it is very 'inconsistent'. There are these random "broken" characters like '☺☻�42' every here and there and sometimes it even sends mutliple messages per response.
What I've tried is using the decode methods of both socket.io-parser and engine.io- parser, trying to feed it the data Request.body() returned. However it always returns:
{ type: 'error', data: 'parser error' }
I tried digging through the engine.io source code as well, trying to find out how they handle responses but I simply can't get it to work. This might require some deeper knowledge about socket.io, but I hope somebody can help me!
Thank you in advance.
I am hoping someone can help,
I am trying to write an NDEF URI message to a felica type card to store a link to a web resource. I am using a ACR1252U reader from advanced card systems.
Block 0 is for attribute data
Block 1 onwards is user data where I would like to store the ndef record.
Does any one have an example of an encoded command to send to the card ie what should be written in block 0 and maybe a sample ndef message encoded to suit
ie
Default:
Block 0 data: {10h, 01h, 01h, 00h, 09h, 00h, 00h, 00h, 00h, 00h, 01h, 00h, 00h, 00h, 00h, 1Ch} is meant to be for the attribute data but I am not sure this is correct for a NDEF record
i have then written to block 1
D1 01 13 55 01 69 74 64 69 73 63 6F 76 65 72 79 2E 63 6F 6D 2E 61 75
which should be a URI (WWW) type NDEF record with payload itdiscovery.com.au
when I try to scan the card with NFC tools (android) it detects the card type enter image description here
BUT no ndef message or record - I am not sure if i have to specify the service type and location etc. I am at a bit of a loss ANY INSIGHT APPRECIATED.
Refer this flowenter image description here
I am trying to set RFH2Header type to a message string. But it's not appending to the message.
Please help. Thanks in advance!!!!
Is My approach is correct ?? If i check in response queue, RFH Property gets added to bytes message.
String message1 = "MQ Message header test";
Message message11 = session.createTextMessage(message1);
MQRFH2 header = new MQRFH2();
ByteArrayOutputStream out = new ByteArrayOutputStream ();
DataOutput dout = new DataOutputStream(out);
header.write(dout);
byte[] outheaders = out.toByteArray();
byte[] bArray = message1.getBytes("UTF-8");
BytesMessage responseMessage = session.createBytesMessage(); // throws JMSException
responseMessage.writeBytes(outheaders);
responseMessage.writeBytes(bArray);
responseMessage.setJMSType("MQRFH2");
responseMessage.setJMSCorrelationID("12345678900000");
responseMessage.setJMSDeliveryMode(2);
responseMessage.setJMSPriority(4);
responseMessage.setJMSReplyTo(queue);
responseMessage.setStringProperty("JMS_IBM_Format", "MQRFH2");
responseMessage.setIntProperty("JMS_IBM_Encoding", MQConstants.MQENC_NATIVE);
responseMessage.setIntProperty("JMS_IBM_Character_Set", 1208);
responseMessage.setIntProperty("JMS_IBM_PutApplType", 11);
producer.send(responseMessage);
My output looks like below in response queue.., Please help , how to set header to a string
00000 4D 51 20 4D 65 73 73 61--67 65 20 68 65 61 64 65 |MQ Message heade|
00010 72 20 74 65 73 74 52 46--48 20 00 00 00 02 00 00 |r testRFH ......|
00020 00 24 00 00 00 00 00 00--00 00 20 20 20 20 20 20 |.$........ |
00030 20 20 00 00 00 00 00 00--04 B8 | .......� |
Not very clear about the question but in any case the following may be useful to you.
RFH2 is MQ specific while JMS is a standard. A MQ JMS application can not explicitly set RFH2 data as JMS message header. MQ JMS client internally sets the required RFH2 headers to build a JMS message while the message is being sent. The application can only set message body and a number of JMS properties using setJMSxxxx and user defined properties using setxxxProperty methods. For example the snippet below sets a string type property called MyStringProperty.
responseMessage.setStringProperty("MyStringProperty", "SomeString Data");
RFH2 data will be a stream of bytes with a fixed header part and variable data part as described here:http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032000_.htm?lang=en. Hence you need to create BytesMessage if you want to send RFH2 data as part of message body.
I am using snmpV3 adapter and passing V2 traps to it by using commands as below. It looks like the range for type u (i.e. unsigned) is upto (2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e. 4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483647
Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
Where as for:
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483648
Above command generates following log:
enter code heretrace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
Refer to:
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
I have discovered various problems with net-snmp over the years. This is apparently one more. The standards are quite clear. RFC 2578 defines Unsigned32 as follows:
-- an unsigned 32-bit quantity
-- indistinguishable from Gauge32 Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
As noted, this is identical to Gauge32, which is identical to Gauge in SNMPv1 (RFC 1155):
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
The encoding is correct; all integers within SNMP are encoded as signed, meaning a value above 2^31-1 must be encoded in 5 bytes. Thus the proper translation of the encoding is:
42 Type: Gauge32 or Unsigned32
05 Length: 5 bytes
00 80 00 00 00 Value: 2^31
net-snmp is incorrectly decoding the value.