It seems to be rijndael, which is pretty well known.
The first message from babyware is encrypted with the IP module password.
The reply from the module will provide a new key.
The next message from babyware will be encrypted with the new key.
See the code in PAI ip_connection.py#L132
Thank you! I missed that 
It now works for me.
Iāve got the SP (spectre protocol guide) which I used for getting the full packet decoding. Iām not sure how it then differs for other panel types. But fromnit I was able to get the cyclicic packets for zone and panel status etc.
I have it all working in a python script based on the work Tertuish has done.
Iām not sure if itās too specific for your project, but it might help with some of the guesses youāve made.
Happy to share it or help out.
Hey David,
Thanks - The SP uses a very different serial protocol than the EVO, however Iāve had lots of success with the EVO specific protocol. The discussions are more around the 16-byte header thatās prefixed to any panel specific messages when using the IP100/IP150 modules. That I believe is the same (or very similar) for both SP/MG & EVO panels.
Tertius has done great work on this, but like with me itās more tracing that true knowlege of what that header does. So far weāve gotten quite a bit of info on how the IP message header works but most of it is unfortunately still guess work.
Appreciate the assistance!
Hi there,
Iāve got more help for you regarding paradox_ip_messages.py. In your structure ip_payload_connect_response:
IDX MEANING
00 Login status
0x00 = Successful login
0x01 = Invalid password
0x02, 0x04 = User already connected
01-16 Encryption key (16 bytes)
17-18 Hardware version as seen on web interface, e.g. 00 20 = Hardware 020
19-20 IP firmware version. e.g. 01 34 = 1.34
21-24 IP module serial number, e.g. 70 12 34 56 = Serial No 70123456
If the value at index 21 = 0x70 then it's an IP100, if it's 0x71 it's an IP150.
Hope that helps
Yes it will. Do you wish to do a Pull Request or I may integrate this directly?
I think you can integrate it directly. My primary language is C#, otherwise I would have interacted with your repo a lot earlier Also my work is around the EVO and not MG/SP. So iāll stick to shooting you some messages and youāre welcome to integrate as you see fit.
In a previous version I had parsers that were aligned with EVO (but will require some minor changes). That can be resurrected.
Hi guys,
I own Evo 192 with the old IP150.
Iāve been looking at this topic for quite a while and as java developer Iām willing to help making native OH binding for Paradox alarms system but I may need some help in the ālower levelā stuff like packet headers, etc as I have no much experience with such. 
So far Iāve started to get used to the ESH framework and created a simple binding which reads emails from paradox, which are sent to a technical account and parses them into things and channels. I know itās a bit complicated approach and also it depends on working connection to internet and google service so I donāt like it much and I would like to āspeakā directly with the IP150 interface.
Could you point me to the correct place in the python code so I can start developing something very simple like āread partition states and present them in OH thing channelsā use case just to get the feeling about how such project should look like?
Also what is the flow of communication? Are there stages of packets for example - send login data, receive response, send partition status retrieval request, receive data, etcā¦ ?
Thanks in advance for anything which could help me start with that. Meanwhile in free time I will probably look into some python course to get used to the language.
Cheers,
K.
I also have an EvO192 with an older IP150. Iāve done a lot of work in figuring out how the communications work, so feel free to check out my dropbox: https://www.dropbox.com/sh/dztab03vwdmw8ya/AABNac4VglpRPQMMHVh5myCea?dl=0
EVO_Technical_Info_vXXXXX.xlsx is where I document all my findings. You can look at the IP150 sheet that shows you the correct login sequence. EVO_UDSProtocol.pdf documents the serial communication but Iāve found some issues with this in the past, so rather focus on the same info I have in my .XLSX file as Iāve duplicated the serial protocol and the sheet and corrected it as Iāve found issues.
Iāve found something else, but I would like someone to verify: During IP login when command 0xF2 is sent (the second request to the IP150), you typically get a payload of 1 byte in the response. It seems it has the following values:
<-- HEADER -----------------------------------> <-- PAYLOAD ->
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 00 01 .. 15
AA 01 00 01 38 F2 00 00 03 EE EE EE EE EE EE EE 00 EE .. EE
^^
Notice that value in the first byte of the payload:
It seems it has the following values:
0x00: IP module not in use
0x01: IP web page in use
0x02: PC software in use
This is based on me trying to connect while iām in the web page or in Babyware/Winload.
Hi Jean,
thanks for sharing ! Appreciate your progress.
Today I had enough time to test a simple āmainā application which just attempts to do a login.
It seems that I cannot use non-encrypted channel so I have to either figure out how to encrypt my payload or somehow disable the encryption on Paradox site. Do you have any clue about this?
As a side note I also figured that when Iām logged on from BabyWare when executing my program, I receive in the header response byte[4]=0x70 instead of 0x78 or 0x79.
Iāve just checked in my main method in Java which attempts to connect to Paradox. If someone sees any obvious error please let me know. I donāt have experience with AES so I used encryption from Cipher in SDK as proposed on the internet.
The thing that bothers me is that when using the password I extend the byte array to 16 bytes with 0x00 for the bytes after the password lengthā¦
Here is the repo:
Cheers,
K.
No all these apps that connect, that are self written do so without encryption.
Babyware is not the the best for Wireshark as the encryption canāt be turned off. Winload is better.
Hi David,
so does that mean that Evo supports both methods and I can use either of them (with and without encryption) no matter what or I need to explicitly disable encryption on the Evo side?
Cheers,
K.
The EVO supports both encrypted and unencrypted. I have an EVO192 can do both methods. Furthermore the byte[4] response is a flags byte. The majority of those flags are unknown, but bit 0 determines encryption. The fact that you are receiving 0x70 (binary 01110000) vs 0x78 (binary 01111000) and 0x79 (binary 01111001) isnt really that important, other than bit 0. Notice with 0x70 & 0x78 bit 0 is equal to zero, meaning no encryption. 0x79 (bit 0 = 1) meaning encryption.
I can look at your code, but in the meantime can you confirm which EVO panel you have as well as the firmware versions of both your EVO & IP150 please.
For starters I think you dont fully understand the login process. Have a look at my document called EVO_Technical_Info_v1_0_4.xlsx at https://www.dropbox.com/sh/dztab03vwdmw8ya/AABNac4VglpRPQMMHVh5myCea?dl=0
There is a sheet called āLog In-Out Sequenceā. You need to fully understand how that process works. Your IP header is wrong to begin with. Bytes 01 & 02 in the IP header indicates the payload length, and for the first message to the IP150 itās the password length. Therefor you cannot āhard codeā bytes 01 & 02 in the IP header message as it varies every time you send a message. That payload length always indicates the UNENCRYPTED payload length. So even if you work with encryption, the values in bytes 01 & 02 is the unencrypted payload length.
Futhermore change byte 04 to a value of 0x08. That seems to be a standard on my IP150 when sending unencrypted. (again bit 0 being 0). Of course we dont know what the other 7 bits do, but make sure you have bit 0 = 0.
Finally, I doubt encryption is as simple as you have in that code. Please check https://github.com/jpbarraca/pai/blob/master/paradox_crypto.py That file details the full encryption/decryption in Python. I converted this to C# code and it works perfectly for my IP150. But again, youād need to fully understand what youāre sending and receiving. So start with unencrypted first as itās a lot easier.
As a suggestion from one of the other users, use Winload for tracing. Babyware only does encrypted payloads. Winload has the option to disable encryption in the COM.ini file under āIPEncrypted=Falseā.
Feel free to send me more questions as Iām happy to help.
Hi Jean,
Thanks for the hints and for looking into the code !
I think I understand the process and looked at it exactly from your excel attempting to execute the first send/receive stage. I know that at some point I will need to create structures with modifiable fields for the dynamic bytes like the payload length byte but for now I just want to see that I can execute simple chain like the logon procedure.
Tried with 0x08 for byte 4 in the beginning with no success. Iāll see if I can sniff the traffic with Winload to make sure Iām sending the same stuff like it does.
Will update the topic once I have more info.
Cheers,
K.
Ok but is byte [01] matching your password length? Because in your code you attempt to send a value that does not match your password length.
If you can send me the bytes you are sending and the response I might be able to determine what the issue is.
Does any code on here help. It covers the login and has all the packets used.