Before I begin: The information in this post is for educational purposes only. I do not hold responsibility for what you do with this information or source code. Use at your own risk.
Obtaining The APK Locally
The link to the APK on the play store can be found here: https://play.google.com/store/apps/deta ... armnet.tc2
We can see that the file name is ‘com.alarmnet.tc2′, Just add .apk to the name and Google. You will find a dozen sites with the APK. You can also root your phone to gain access etc. but I will not cover that here.
Decompilg The APK
Now that we have the APK we need to decompile it. You can use the following tools to accomplish this:
- dex2jar: https://code.google.com/p/dex2jar/
With this tool, you can easily convert the .dex file inside the .apk file (it is just a .zip file!) back to a usable jar file.
Simply drag and drop the .dex file onto ‘d2j-dex2jar.bat’ and you’re done.
Next to decompile the Jar to readable source code I used:
- Jd-Gui: http://jd-gui.softpedia.com/
Again simply open the .jar now with this tool and you will see the decompiled source.
Understanding The Source
While I do recommend looking through the entire thing to get accustom to their setup, I will point out what is important.
Both of these files contain the service call data and connection flow that we will need to follow in our application. I really recommend studying these because their method of handling the connection is fairly convoluted in my opinion.
Making The Connection (Service Call Flow)
Now that we have the source, we can analyze the setup of the service calls and how they are handled. For one, we see the main service object can be found here:
Code: Select all
To make a login request, we have a two step process:
- AuthenticateUserLogin : Which does what it sounds like, it auths our login information.
- GetSessionDetails : Obtains information about our session. (ie. Session Id, Module Flags, Security Locations, User Info)
To even login, we are required to give the service some information:
- Our Application Id
- Our Application Version
Given that the Windows phone does not have an appId/version for this, we use the Android one to fake the call. In the case of the code I wrote, the version info was:
- Application Id: 34857971
- Application Version: 2.2.0
The next step is to keep the session activated and alive. After we login, the app creates a thread to keep pinging the service. Inside that thread, the app was calling KeepAlive and GetPanelMetaDataAndFullStatusByDeviceID.
Thankfully, we are given the nice usage of async callbacks for everything when we reference their service. So we can make a fairly decent setup that can be UI friendly.
Arming Our Security System (And Disarming..)
Next was seeing how we arm and disarm the system. Here I found that the call was made to ArmSecuritySystem. This handled both arming for away and stay modes. This takes a number of params which I am not 100% sure if the user id param was required or not. I would recommend not sending it at all if you do not have to. My examples sent it just to be safe when I was testing this setup.
Following suit, to disarm the system we have a similar call: DisarmSecuritySystem
Status Information And The Like
Finally, with the information obtained status codes and bitmasks were all that was left to obtain the information data. When querying for the panel status in the keep alive, we can get a number of results that mean different things (based on different security systems):
- 10200 – Disarmed
- 10211 – Disarmed (bypass)
- 10201 – Armed Away
- 10202 – Armed Away (bypass)
- 10205 – Armed Away (instant)
- 10206 – Armed Away (instant-bypass)
- 10203 – Armed Stay
- 10204 – Armed Stay (bypass)
- 10209 – Armed Stay (instant)
- 10210 – Armed Stay (instant-bypass)
- 10307 – Arming
- 10308 – Disarming
- 0 – Success
- -4502 – Invalid pin. (Yes, that is a negative result.)
- 4501 – Repoll Required (Command is currently scheduled.)
- 0 – Normal
- 1 – Bypassed
- 2 – Faulted
- 8 – Trouble
- 16 – Tampered
- 32 – Supervision Failed
When I first started working on this I made a simple test application which can be seen here:
After getting the test app to work fairly well, I moved to working on the demo phone app I created. Which can be seen here:
Getting it to work simply for myself was great. I was happy to get it in a somewhat working manner. However, I am by no means a Windows Phone developer. This was my first solo app project for the WP7 platform and I can honestly say my last. I am not a fan of Windows Phones at all and I have since gotten rid of mine and moved to Android.
About The Source Code
The source code is in a beta “working” state. Meaning, things are thrown together just to get it to work and test things out kind of state. I did not take the time to fully cleanup the code, it may [read: does] still have errors and problems. I cannot guarantee it will work for everyone and such. The following sources will be of my original test application (proof of concept) and the phone app.
I do wish that people at least honor me by giving me credits if you use this source code. I also do request that you do not sell your app, if you make one, for money. Honeywell offers this service free of charge on all other platforms, there is no reason to nickle and dime people for a simple feature-set like this.
Windows Proof of Concept Client: https://gitlab.com/atom0s/HoneywellWindowsPoC
Windows Phone 7 Proof of Concept App: https://gitlab.com/atom0s/HoneywellWP7PoC