Draft
Conversation
This was referenced Dec 27, 2022
Collaborator
Author
|
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
|
Collaborator
Author
|
@jpbarraca You are a crypto guru. Please take a look. Maybe you will see something interesting. |
Contributor
|
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. |
Collaborator
|
Will take a look |
Contributor
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? |
Contributor
|
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 |
Collaborator
Author
|
Most of the communication is not encrypted =) And I have found the difference in connection initialization. Now let me alter the code. |
Contributor
|
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... |
Collaborator
Author
|
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 |
Contributor
|
This might be interesting too... This is the initial (power on) exchange between IP150+ and EVO192. |
Collaborator
Author
No it is not.
|
Contributor
|
@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. |
Collaborator
Author
|
My latest commit? I did not commit anything related to encryption. |
Contributor
Ok, good. But why does the panel return 00 as last byte of the response for the |
Contributor
On the serial_encryption branch I mean. |
Collaborator
Author
This I do not know.
In serial encryption branch I only added unit tests. |
Contributor
|
Excluding excluding E0 FF * messages, this is the full power-on exchange (well, until it becomes relatively stable, with "pings" every two seconds): |
Contributor
|
I'm very confused now... I get some errors, see here: https://pastebin.com/MCkV2cbR |
Collaborator
Author
|
Two options:
You can raise log verbosity in PAI and see raw messages. |
Contributor
It seems there are two unknown messages: |
Collaborator
Author
Hah. Weird events. |
Collaborator
Author
|
Most probably it is because clock is not set up. Live event came with zero date. |
|
Kudos, SonarCloud Quality Gate passed!
|
Contributor
Correct, setting the time fixed the problem. |
Collaborator
Author
|
I fixed it yesterday |
Contributor
|
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. |
yozik04
force-pushed
the
serial_encryption
branch
from
1ed393f to
725423f
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
yozik04
added a commit
that referenced
this pull request
Apr 3, 2026
Add (len-3)%16 block-size guard and checksum verification so decrypt_serial_message correctly returns b"" for all BabyWare compact E0 FE frames, including those ≥ 18 bytes where the old code would attempt AES decryption and return garbage. Add unit tests using real PR #337 captures (EVO192 v7.70 power-on sequence): 27/36/47/50-byte BabyWare compact frames as regression vectors, plus framing and mixed-sequence tests. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implements the full E0 FE encrypted serial protocol used by EVO panels with firmware ≥ 7.50.000, including: - AES-256-ECB encrypt/decrypt helpers in crypto.py with 0xEE padding - make_serial_key() key derivation (PC password padded to 32 bytes) - EncryptedSerialTransport wrapping outgoing writes transparently - SerialConnectionProtocol: checksum-scan framing for full-AES frames, length-byte framing for BabyWare compact frames; decrypts on arrival - New SERIAL_ENCRYPTED config flag (applies to serial and bare-IP) - Hardened decrypt_serial_message: rejects BabyWare compact frames via (len-3)%16 guard and checksum pre-validation to prevent garbage output - --serial mode in ip150_connection_decrypt for offline capture decode - Full unit test suite including real PR #337 captures (EVO192 v7.70) - docs/serial_encryption.md protocol reference
yozik04
force-pushed
the
serial_encryption
branch
from
ccb3031 to
a126be2
Compare
…words - panel.py: guard against 1-byte messages reaching message[1] access - serial_encryption.py: zero-pad integer passwords to 4 digits (matches Panel.encode_password behavior; affects users with PASSWORD < 1000) - tests: add make_serial_key integer/string/length coverage
|
| from paradox.lib.crypto import decrypt_serial_message, encrypt_serial_message | ||
|
|
||
| # PC password "1234" padded to 32 bytes with 0xEE | ||
| PC_PASSWORD = b"1234" |
Collaborator
Author
|
@lpaolini This might work. Claude wrote the code. Inspired by https://github.com/ispyisail/paradox-ip150-esp32 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.