After my recent move to my partners house, I learned he has a security system that is manufactured through Honeywell. Within the first week of living at the new house he had set me up with my own security code and login to use the system so I can come and go freely as needed. Sadly, I learned quickly that my phone (Windows Phone, HTC Trophy) does not have any type of app to communicate with the system like iPhone, Android, and Blackberry do.
So I endeavored a bit to see what all the app does on the Android phone by getting my hands on the APK via Google. Doing a little research you can find the app on the Google market here:
https://play.google.com/store/apps/details?id=com.alarmnet.tc2
The URL tells us the name of the app file as well being:
com.alarmnet.tc2
So slap on the extension .apk and Google away to find the actual file.
Getting The Goods
The next step after obtaining the .apk file is getting it back to readable code. To do this I found a toolkit called dex2jar found here:
https://code.google.com/p/dex2jar/
With this, you can easily convert the .dex file inside the .apk (its just a .zip file) back to the usable .jar file.
Simply drag and drop the .dex onto the ‘d2j-dex2jar.bat’ and you’re done.
Next I used jd-gui.exe to decompile the .jar back to usable code, you can find that here:
http://jd-gui.softpedia.com/
With that you can load the .jar and then save all the sources via the File menu. This will produce the .java files that are readable source code again.
Whats Important To Us
Now that I was able to get the source back, I started looking for what would be useful to me. Quickly, I came across:
com\alarmnet\tc2\rcmobile\rcConn.java
com\alarmnet\tc2\rcmobile\rcSecure.java
Both of which have very useful information pertaining to the app. Through tracing functions in these two files I quickly found out that the application was communicating with a WCF service via SOAP calls. The service location is found here:
https://rs.alarmnet.com/tc21api/tc2.asmx
Call Flow — Making It Work
Given that I have the full src to the Android app now, I took time to analyze things to see if there was any small quirks I had to follow, and sure enough there are. To start, logging in is a two-step process:
AuthenticateUserLogin -> GetSessionDetails
The session details include information about the users access to the security system including:
- Session ID
- Module Flags
- Security Locations
- User Information
The Security Locations include information about each device that the user has access to (panels etc) inside that location. All of which are needed when making various other calls to the security service.
After being logged in, the session id returned has to be kept alive using another call:
KeepAlive
This call keeps the session active on the service end and allows us to keep making various other calls to the service without having to login again. From the look of it, sessions only have to be pinged once every 2 minutes as seen by the keep alive timer code here:
public void startKeepAliveTimer()
{
this.timer = new Timer();
this.cmdtimer = new CmdTimer();
this.timer.schedule(this.cmdtimer, 60000L, 120000L);
}
Next, we have to keep querying the panel for status information, arm status, etc. However I didn’t see a clear-cut method of how the Android app did this. So I instead assumed 10 seconds would be enough between each query. Which can be obtained using the service call:
GetPanelMetaDataAndFullStatusByDeviceID
Phase 1 — Trial and Error
My first night coding, I made a quick test app to see if I could really login to the service. Which I was greeted with the need of two more specific pieces of information. The login call looks like this:
AuthenticateUserLogin(username, password, applicationId, applicationVersion);
Clearly we do not have a real appId and appVersion for the Windows Phone since there is none. So we have to improvise and use what we have. Inside the Android app I found the Android values. The application id was found in a .java file with the line of code being:
KSoapUtils.createElementAndSetEscapedText(localElement3, "ApplicationID", "ipv", Integer.valueOf(34857971));
The application version was a little more tricky since its stored in the AndroidManifest.xml. Which is also encrypted separately. To decompile the xml I found a tool called apktool:
https://code.google.com/p/android-apktool/
To get the info that I needed here, you can use the command:
java -jar apktool.jar decode -s com.alarmnet.tc2.apk
This will decode just the resources which includes the needed AndroidManifest.xml file. Now that its decoded I found the version value near the top which was:
android:versionName=”2.2.0″
So now the login call can be made using:
AuthenticateUserLogin(this.txtUsername.Text, this.txtPassword.Text, 34857971, "2.2.0");
Next up was handling the returns. After some analysis, I figured that all commands return a base object that has a ResultCode and ResultData. From there I figured all returns expect ResultCode to equal 0 to be successful. Otherwise it was an error and then ResultData would be filled with the error string. This made coding the handlers a bit easy.
My resulting test project looked like this:
The project was simple and only included a few features which were:
- Login To Service
- Obtain Session Info
- Query Panel Status
- Query Zone Status’ (To see faults, trips, issues, etc.)
- Disarm, Arm (Away), and Arm (Stay) the system.
The disarming and arming of the system both use the users 4-digit pin-code to properly work as well.
Phase 2 — Phone Version
Today started phase 2 which was bringing the v1 beta onto the phone, with a more appealing look. For this I used the assets and resources from the Android version of the application for my phone app. After a few hours of tinkering and such, I found out that the service calls in the Windows Phone turned into async calls which was I not expecting. So I had to land up rewriting my base entirely to work with this. Although I prefer working with async anyway, it was just not expected.
After a bit of work, I made two basic screens that are fully functional so far which are the login and main security panel screens, seen here:
At this time I do not have any other features working or implemented. I do plan to add the usage log and the zone information screens soon, but outside that I do not have a system with cameras and other features to get those working.
I also do not have a AppHub developer account to push this onto the market place either. (It would be free, perhaps with ads or something to make some money for my time.) But at this time it was more of a project for myself.
Feel free to ask questions if you have any. š
My Brain.. 
Another TC 2.0 app for Windows phone here http://www.rightarmdevelopment.com/Articles/totalconnect