Serial encryption #337
Draft
Serial encryption #337
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 27, 2022
|
Regarding captures. Initially we do a InitiateCommunication round: Lines 140 to 144 in 3d8e502
RX translates to: See differences in the response to @yozik04 EVO192 fw 6.90 inline. Then with encrypted protocol Babyware sends:
In unencrypted serial we used to send StartCommunication packet. Lines 165 to 170 in 3d8e502 5f 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 80
|
|
@jpbarraca You are a crypto guru. Please take a look. Maybe you will see something interesting. |
|
I'll be able to provide a simultaneous IP and serial capture of the same conversation in about a week. It could prove useful for trying to understand how it works. IP150 might either support encryption or bypass it using some special command. If it supports encryption, it would be interesting to repeat the experiment with an IP150 running a very old firmware version. Let's see what we get with the one I'm receiving in a few days, which will be a pretty new version, unfortunately. |
|
Will take a look |
Ok, I've got some fresh hardware to test.
I'm now able to capture simultaneous serial (using Logic) and IP traffic (using WireShark) between IP150+ and either BabyWare or PAI. Any requests? |
|
Here's a dump of the serial conversation from IP150+ to EVO192 v.7.70.1 using PAI, correlated with the PAI log. TX is to the panel |
|
Most of the communication is not encrypted =) And I have found the difference in connection initialization. Now let me alter the code. |
|
I think I found something interesting. Compare the very first two messages exchanged. Via IP150+: Via Serial: They are exactly the same, except the second last byte of the response (the last before the checksum), which is different. Then the next command sent to the panel is: Which succeeds via IP150+ (with the following response) and fails via serial (with no response). It looks like the panel already knows it's talking to an authorized device (the IP150+)... I think key is to look at what happens before this exchange, when the IP150+ boots up. Perhaps it authenticates once and then the rest of the conversation is in cleartext... |
|
or maybe they did an exception for IP150 because for serial we send CommunicationSourceIDEnum as Winload_Direct=1 and IP Module sends Winload_IP=2 pai/paradox/hardware/parsers.py Lines 56 to 68 in 3d8e502 pai/paradox/hardware/common.py Lines 74 to 88 in 3d8e502 |
|
This might be interesting too... This is the initial (power on) exchange between IP150+ and EVO192. |
No it is not.
|
|
@yozik04 I tried your latest commit and we've some BIG progress! Connection is now established, data is exchanged over serial and logs match to as when connecting via IP150. However, after 5 minutes connection is lost and it's not resumed, not even restarting PAI. |
|
My latest commit? I did not commit anything related to encryption. |
Ok, good. But why does the panel return 00 as last byte of the response for the |
On the serial_encryption branch I mean. |
This I do not know.
In serial encryption branch I only added unit tests. |
|
Excluding excluding E0 FF * messages, this is the full power-on exchange (well, until it becomes relatively stable, with "pings" every two seconds): |
|
I'm very confused now... I get some errors, see here: https://pastebin.com/MCkV2cbR |
|
Two options:
You can raise log verbosity in PAI and see raw messages. |
It seems there are two unknown messages: |
Hah. Weird events. |
|
Most probably it is because clock is not set up. Live event came with zero date. |
|
Kudos, SonarCloud Quality Gate passed!
|
Correct, setting the time fixed the problem. |
|
I fixed it yesterday |
|
The main issue now is that the panel v.7.70 kicks PAI out after 5 minutes (only when using the serial connection) and it doesn't allow reconnection. This smells like an authentication issue... |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Recently we have seen more users trying to use serial connection with firmwares using encrypted serial connection. Looks that encrypted protocol for EVO and SP/MG branches is the same.
Currently we have encrypted captures for Babyware serial connection to:
Example request:
Colors:
Response looks absolutely the same.
I have added a test that has many packet payloads to try.