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.
Related
I am trying to get CAN communication running via an external SBC (TLE9263) board.
Microcontroller: S32K312
Ext. SBC board: TLE9263_EVB_2
Without SBC, i.e., using a standard external CAN transceiver TJA1057GT, CAN communication is running.
With SBC, some messages are received once, but then the SBC transceiver goes down, and CANIF_E_FATAL Det error occurs (Call Stack).
I configured the SBC registers as follows: SBC registers configuration
The following values are observed on the SPI-MOSI signal:
41 00 - SUP_STAT_1
82 00 - HW_CTRL
81 1F - M_S_CTRL
84 07 - BUS_CTRL_1
85 00 - BUS_CTRL_2
83 82 - WD_CTRL
The above observed values are expected in my opinion. What could be the cause of communication not working?
Additionally (not sure if this is relevant), the Fail Output LEDs on the TLE9263 board, FO1 and FO3 are ON as soon as the board is powered, and FO2 is blinking, and this status of the LEDs remains the same when the software is run.
I am developing a program to connect my PC to Omron CJ2M PLC to send read / write commands.
As per my understanding, Omron PLCs can be communicated over 3 methods:
1) Hostlink,
2) FINS, (TCP or UDP) and
3) EIP.
My requirement here is to connect CJ2M through EIP, and send Read/Write commands over EIP(CIP) protocol.
Initally EIP communication needs to send 2 requests:
1) List Services and 2) Register Sessions
Register Sessions returns a handle which should be used in further communication over EIP.
I am successfully able to send List Services, Register Session and Forward Open (RR Data) and these are successfully replied by the Omron PLC. There is no problem in these 3 requests/responses.
Now I want to know which command/service need to be used to read the memory area of Omron (say DR 20 memory address).
I am sending service code 0x4d over RR Data, but it says "Vendor Specific Error" and then connection gets terminated.
I need protocol specification for Omron EIP or wireshark logs or some sniffed packets where a request / response is captured over EIP communication from PC to Omron PLC (no fins, no hostlink).
We can send requests to Omron EIP using "Send Unit Data" with service code 0x4d.
This service (0x4d) is used to send write request as per EIP documentation, but we can insert the Omron specific commands (FINS) to read the memory areas in command specific data.
0000 00 00 00 00 00 80 0e 00 01 00 80 00 02 00 00 00
0010 00 00 00 12 01 01 82 00 00 00 00 01
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.
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).
-> 5AF4013D
<- 00 /*Success*/
-> AA01
<- AFA8394ED57A5E83106B4EE72FD2BB0CC4
How to proceed from here?
I have been struggling about a week with this. I can select app from the card and get that first response with the 0xAA ("AFA8394ED57A5E83106B4EE72FD2BB0CC4" equivalent) but what to do after that?
Do i need to encrypt or decrypt the response with my App_auth_key (16bit) or what and then send it to the card?
Encryption which I use is AES.