I'm writing an web server with Lisp to handler HTTPS request. I followed TLS 1.2 and already completed the handshake process. The Cipher Suite I chose is TLS_RSA_WITH_RC4_128_SHA. I already calculated client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key. These keys seems are correct, because I can decrypt "Finished" message from browser and validate the data inside. I also validate the HMAC of the record layer. Then I send a "Change Cipher Spec" and "Finished" from server. So far everything seems working fine.
Then I got the message from browser start with #(23 3 3 1 61 ...). 23 means it's an application data. #(3 3) means TLS 1.2. #(1 61) means length is 256+61=317 which is correct because the data left is really 317 bytes long. Here comes my question: I decrypted these 317 bytes with RC4 using the "client_write_key" then I got data like #(148 104 81 182 67 111 28 201 202 50 207 57 126 209 19 ...) which can't be converted to text. I thought I should get something like GET / HTTP/1.1. What do I get wrong?
Thanks.
RC4 is a stream cipher and, according to RFC 5246, section 6.2.3.1, "For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet."
So, the first record you decrypt is the FINISHED message and the first application data you decrypt should be with the RC4 state as it was left after decrypting the FINISHED message.
Related
I received the the following IAD after processing the GPO command, my question then, how is the 9F10 EMV token constructed? Here is the token.
06010A03A020000F04000000000000000000006232E4F9
I am required to send only the CVR portion to the acquiring switch.
Looking at the cryptogram version I assume this is from a Visa card. The TLV is 9F10 17 06010A03A020000F04000000000000000000006232E4F9 ?
17 is the total length of the data
06 is the length of issuer descretionary data
01 is derivation key index
0A is the cryptogram version (10 in this case ).
03 Length of CVR
A02000 is the CVR here
From EMV 4.3 Book 3 Common Core Definitions, Application Specification, November 2011, Page 206, C7.2
The CVR has a fixed length of 5 bytes (10 hexadecimals characters) that are the bytes 4-8 included of Issuer Application Data, EMV tag 9F10.
The 3 first bytes of 9F10 being the following.
b1 the length
b2 derivation key index
b3 the cryptogram version
It seems however that the format of this field might vary between schemes.
I read here that EVM cards will sign some transaction data.
I would like to do this with my card, using my phone, and verify that the signature on the result is correct.
To start, I issued this command ("request APDU"):
00:A4:04:00:0E:32:50:41:59:2E:53:59:53:2E:44:44:46:30:31:00
One of the "Application IDs" was this:
A00000038410
So then I issued this command ("Select Payment application"):
00:A4:04:00:07:A0:00:00:00:03:10:10:00
and it returned this "Processing Options Data Object List (PDOL)":
9F66049F02069F37045F2A02
I read here how to decode this, because I couldn't find the official spec anywhere:
9F6604 - the tag 9f 66 represents the terminal transaction qualifiers
9F0206 - tag 9f 02 stands for authorized amount. The PDOL list must have the amount, authorized, coded into 6h bytes added to it.
9F3704 - tag 9f 37 stands for unpredictable number, thus encode such a number in 4 bytes and add it to the list
and here how to decode this:
5F2A02 - TX currency code
I understand the next step is to run "Get Processing Options" but this is where I got stuck. I tried:
80:A8:00:00:02:83:00:00
80:A8:00:00:12:83:10:01:02:03:04:05:06:07:08:01:02:03:04:05:06:07:08:00
80:A8:00:00:12:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
80:A8:00:00:02:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
All gave back a result of 6D:00 (Instruction code not programmed or invalid).
I tried looking in "emv book 3" and "emv book 4" but neither seem to contain the relevant information.
What do I need to do next in order to make a transaction, sign, and check the result?
Your GPO commands needs to provide the PDOL values requested by the card. The requested tags are:
9F66 - 4 bytes
9F02 - 6 bytes
9F37 - 4 bytes
5F2A - 2 bytes
So the commands needs to provide these in the same order, with expected lengths.
Assuming you want to send the following sample values:
9F66: 11223344
9F02: 112233445566
9F37: 11223344
5F2A: 1122
Your GPO command will look like this:
80A800001283101122334411223344556611223344112200
Where the PDOL data is 11223344112233445566112233441122.
Hope this helps
If PDOL found in response of select application, here you need to pass the value of PDOL tags in GPO command,
can find a very good article Here. hope it helps.
I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
In the SSL client, I am receiving a serverHello message with tampered message length like below.
"16 03 00 00 35 02 00 08 00... "
Here, "00 08 00" is message length which is coming as 2048 bytes. But in the next record, it sends "serverCertificate & serverHelloDone" messages.
So, in the client side, it waits to read 2048 bytes. but messages "serverHello, serverCertificate, serverHelloDone" are not having 2048 bytes combinedly. So, still client waits to read pending message (socket is blocking socket). So, it just waits in recv and never comes out.
I would like to know how applications should handle this situation. Is there any way in SSL protocol, we can identify this. If not possible, how applications should handle this situation to come out ?
Thank you !
Regards
Satish.