Sorry om een oud topic boven te halen, maar ben je hier ooit verder in geraakt?
Ik ben hier namelijk zelf ook mee bezig, maar misschien is er al een oplossing.
Ik had ook eerst de java app gedecompiled, maar daar zitten heel wat stukken in die niet gedecompileerd geraken, ik heb dan maar een groot stuk van de bytecode manueel terug omgezet naar java, maar er zitten nog wat fouten in. Wel ontdekt dat die driver files niet zo zeer drivers zijn, maar eerder een soort binary weergave van de mogelijke messages/protocol van het systeem. Een beetje protobuf-achtig. Echter heet dit systeem blijkbaar '(n)Ace', wat waarschijnlijk iets proprietary van UTC is, want hier is verder niets over te vinden. De meeste code doet ook gewoon wat directe byte array transformaties, dus mogelijk is dit automatisch geport uit een andere taal.
De feitelijke communicatie start idd met een soort fixed welkomst bericht, daarna zend het paneel zijn identiteit (waarna de juiste driver file wordt geladen) en daarna wordt een security key afgesproken voor de sessie. Dit wordt gedaan op basis van de master encryption key (zelf in te stellen, standaard is dit 000000000000000000000000). Dit process werkt ongeveer zo:
- Client genereert wat random data en gebruikt die als de helft van de sessie key en verstuurd dit (geencrypteerd met de master key) naar de ontvanger (=alarmsysteem)
- Alarmsysteem genereert de andere helft en verstuurd die nu terug naar de ontvanger.
- Beide hebben nu de 2 helften die de sessie encryptiesleutel vormen.
Hetzelfde systeem/protocol wordt eigenlijk voor alle communicatie kanelen gebruikt (zelfs ultraconnect, wat eigenlijk gewoon als een soort relay server werkt). Via de seriele poort (usb) is er wel geen encryptie, dus dan kan je eventueel directe replays doen van bepaalde commando's, maar de inhoud van de commando's zal nog steeds niet duidelijk zijn.
c0 is steeds de message delimiter.
Ik kan nu de informatie van de areas opvragen, maar de meeste andere commando's geven errors omdat mijn manuele omzetting van bytecode naar java niet helemaal correct is gebeurd. Er zijn ook veel meer messages in die driver file dan wat er mogelijk is met de app, dus waarschijnlijk wordt dit ook voor de ATS8500 software enzo gebruikt.
Het doel is trouwens dat ik het uiteindelijk kan integreren in mijn domotica systeem en dan hoef ik niet meer die gatlelijke en buggy app van aritech zelf te gebruiken. Aritech loopt hier werkelijk hopeloos achter op de concurrentie.