I found some information on the Trane website that might help, here is the link:
http://www.trane.com/Residential/Questions/What-is-the-ComfortLink-II-control
and they do mention control through Z wave. Hope this helps!
[quote=“arlane05, post:21, topic:168631”]I found some information on the Trane website that might help, here is the link:
http://www.trane.com/Residential/Questions/What-is-the-ComfortLink-II-control
and they do mention control through Z wave. Hope this helps![/quote]
I read that. I think they’re only referencing z-wave enabled lights and appliances. I do not think the XL950 has a z-wave chip in it. I think it’s only web enabled.
I still have yet been able to figure out if we’d be able to use it.
Unfortunately, I just found the answer to the Z-Wave chip question on Nexia’s website (formally Schlage Link) 
Under the “compatibility” menu for the ComfortLink II [url=http://nexiahome.com/Products/ProductDetail.aspx?model=ComfortLinkII]http://nexiahome.com/Products/ProductDetail.aspx?model=ComfortLinkII[/url] it states:
“ComfortLink II control does not have Z-Wave but integrates seamlessly with the Nexia home automation system via a wireless (802.11) home network.”
So, for whatever reason, Trane must have wanted to solely partner with Nexia on this thermostat, because without a z-wave chip, the ComfortLink II can’t be paired with any other z-wave controller like Vera as far as I can see. The CL2 can still be controlled from a computer or smart phone free of charge within the confines of your own wireless network, but without a Nexia subscription, you wouldn’t be able to remotely monitor/control your thermostat. I’m just so against the $8.99 subscription fee when you can run these devices free of charge with other z-wave controllers like Vera. This was a pretty big disappointment to me finding out the CL2 doesn’t have it’s own z-wave chip.
After doing some further reading, Trane and Schlage are both brands owned by Ingersoll Rand. It makes total sense now why the Trane ComfortLinkII was only designed to work on the Nexia Home Intelligence System – they’re all a part of the same company.
[quote=“IwantSSH, post:16, topic:168631”]I recently purchased a XL950 ComfortLink II, and as my user name suggests I want SSH access to this device 
After poking around the latest firmware update, I found what appears to be an /etc/shadow file listing roots hashed and salted password. I have attached it to this message as this forum thinks its a link.
I have been attempting to crack the password using John the Ripper but so far it has been unsuccessful. Hopefully someone with more resources may be able to get at this password. I am also curious why “pcap” is installed on the machine, is our thermostat watching us??? :)[/quote]
Hello,
I am in the same boat as you. I would like to gain root access to the XL950 as well. Have you made any progress on logging in via SSH yet? There must be some Linux expert that can help! I know the traditional way of gaining access to Linux is via the bootloader (LiLo or Grub); in fact that method is well documented around the internet and is fairly easy to do. Unfortunately there doesn’t seem to be a bootloader step visible when the XL950 is powered on. Perhaps, that step is just not echoed to the screen but is still happening. Not sure how to see it to stop it and make the changes necessary to the filesystem to gain access. Anyways, I just wanted to add my 2cents and see if anyone here has had success. Thanks!
No I have not yet found a solution. I do have a nexia bridge that I haven’t activated, so I might set it up and see if it can communication with my Vera2 without paying the fee. It gives me a couple months of free use so that might give me some time to make it all work.
For anyone still watching this, I just got an email fro Nexia:
Great news! We are pleased to announce that your Trane ComfortLink II Control now provides you with the ability to remotely monitor and control your home's heating and cooling at no charge to you! Yes, this means you will no longer have to pay a monthly subscription fee to manage your Trane ComfortLink II Control. In fact, you can manage all of your Trane ComfortLink II Controls at no charge!You do not need to take any action to take advantage of this subscription change. We have already made the change to your account and you will no longer be billed for using Nexia™ Home Intelligence. A monthly subscription fee of $8.99 will apply if you choose to add a Nexia Home Bridge and Z-Wave® devices to your account.
So, for those with this thermostat, you can sign up with Nexia and control it for free. Once you add their home bridge, then you start paying a monthly fee. They have an iPhone and Android app so we can control it remotely.
I still would like to be able to control it in one place from Vera. But at least we can do it for free.
That is great news, I have been using Nexia for just the T-stat for a few months and it works great. I have not received this e-mail, is this info on their web site?
Hey, has anyone been able to login to the XL950 yet through SSH or Web (non Nexia)?
A couple months ago I tried cracking the device. Seems like they secured it pretty tight to protect their money-making subscription interests. The communication between the t-stat and host is ssl encrypted. I have a few more ideas left up my sleeve, but haven’t had the chance, nor do I know when I will, to return to it.
An approach to hacking this is to see if you can hack an upgrade. Hopefully they do not sign them … In that case you might be able to change the contents and open up a direct access to the the thermostat.
This is possible, but would require the ability to create a JDFS image to load onto the device. I was able to figure out how to read and make changes to the one in the upgrade, but those changes were only written to temporary memory. I wasn’t able to figure out how to write to a new JDFS image.
Since my last post, I experimented with some packet captures. My idea was perhaps if we can determine the communication protocols, we could remotely issue our own commands directly to the TSTAT. I did a MITM attack on the TSTAT and pulled a packet capture. Seems as though all the communication is propietary. Couldn’t make any sense about it.
This leads to another thought. Would it be possible to create a small program that would essentially take Vera commands and access the Nexia website to update the TSTAT that way? I’m not very familiar with LUUP, so not sure if this is feasible. If anyone is interested in trying, I’ll assist however I can.
I’d like to so I can try to link it to my Control4 system!!!
I was thinking the exact same method- write a script that third party interfaces could command. The program would then access the Nexia interface and simply make the prescribed changes. It adds an extra layer and lag but it should be possible to do.
Wonder if anyone got anywhere with this? I was able to mount the two image files from the latest update (3.0) on a linux system and have been poking around. Has anyone been successful at this at all?
I stopped working on it some time ago, but I’m not against collaborating with someone on this.
Hello all, a few observations on the Trane Comfort Link II Thermostat:
- It’s embedded Linux. It is definitely possible to extract the updates and figure out what’s “really” going on here.
- If we can extract it, we can probably alter it. (Barring a digital signature of some form).
- We can also mess it up pretty badly, which is not a great idea in a $900 thermostat :-).
Addressing the first point:
In order to extract the updates, you will need a Linux, Mac OS X host, or something like the 7zip File Manager for Windows. I’m using Linux for ease of use and simplicity. The updates are really just tar.gz files (compressed archives) with a different file name. If you extract them, you will get a set of files that are two kernel images with initrds (an initrd file is an initial RAM disk for boot), a manifest file, build number (version) file, and a compressed root file system.
PLEASE NOTE THAT YOU WILL NEED TO DO THESE STEPS AS THE “root” USER!
The reason for this is that some of the operations are privileged operations (like mounting disk images). I’ve used Ubuntu 12.04LTS in these examples.
The sequence of commands to extract this from the archive are:
mkdir extracted
tar -xzf rsup_138271353801.tar.gz -C extracted
If we look at the list of files that were extracted, we get:
a_138271353801 b_138271353801 c_138271353801
d_138271353801 e_138271353801 m_138271353801
v_138271353801
Linux also provides us a excellent way to examine what a file might really be with the “file” command.
phorkus@services:~/Trane_Comfort_Link_II/extracted$ file *
a_138271353801: u-boot legacy uImage, Linux-2.6.26-466-ga04670e, Linux/ARM, OS Kernel Image (Not compressed), 1998776 bytes, Thu Oct 17 02:35:10 2013, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x80377065, Data CRC: 0x444BD40E
b_138271353801: gzip compressed data, was “rootfs.ext2”, from Unix, last modified: Thu Oct 17 02:59:46 2013
c_138271353801: Linux jffs2 filesystem data little endian
d_138271353801: u-boot legacy uImage, Linux-2.6.26-466-ga04670e, Linux/ARM, OS Kernel Image (Not compressed), 1850060 bytes, Fri Oct 25 11:30:05 2013, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x0A1BF3DC, Data CRC: 0xDE2425B3
e_138271353801: data
m_138271353801: ASCII text
v_138271353801: ASCII text
If we examine the content of the files, we find that:
- v_138271353801 is a version file containing the specific build numbers of the various components.
- m_138271353801 is a manifest file formatted in XML that also contains an embedded file which describes the file sizes and and a SHA1 hash of the segment file. You can get the SHA1 hash by doing a “sha1sum *” in the extracted directory.
- a_138271353801 and d_138271353801 are the kernels that boot the device. They are both viable from what I can see and uncompressed if you should like to load them up using something like IDA Pro (Interactive Disassembler Professional). We can see that the device has RAM starting at the 0x80000000 paragraph in the 32 bit ARM memory space, which would imply that there is a peripheral region that could be in either the 0x20000000, 0xD0000000 or other non-standard paragraph.
- b_138271353801 is a gzip compressed root file system for the device. We’ll extract this in a moment.
- c_138271353801 is a JFFS file. The JFFS means Journalling Flash File System in this case, so this is where the unit stores its unit unique information. We’ll extract that too and have a look at it.
Next up, we want to extract the root file system with the following sequence of commands:
cat b_138271353801 | gunzip -d -c > b_uncompressed
If we look at the file now using the file command we see:
b_uncompressed: Linux rev 0.0 ext2 filesystem data, UUID=00000000-0000-0000-0000-000000000000
Excellent! Now let’s mount the file system so we can examine it.
mkdir mnt
mount -o ro b_uncompressed mnt
If you are running as the root account, you will now be able to browse the file system under the extracted/mnt directory. The extracted information confirms this is a pretty standard looking embedded ARM Linux distribution:
drwxrwxr-x 2 root root 2048 Oct 17 02:59 bin
drwxrwxr-x 6 root root 3072 Oct 17 02:59 dev
drwxrwxr-x 5 root root 1024 Oct 17 02:59 etc
drwxr-xr-x 2 root root 1024 Nov 20 2007 home
drwxr-xr-x 3 root root 2048 Oct 17 02:59 lib
lrwxrwxrwx 1 root root 11 Oct 17 02:59 linuxrc → bin/busybox
drwx------ 2 root root 2651136 Oct 17 02:59 lost+found
drwxr-xr-x 7 root root 1024 Oct 17 02:35 mnt
drwxr-xr-x 2 root root 1024 Nov 20 2007 opt
drwxr-xr-x 2 root root 1024 Nov 20 2007 proc
drwxrwxr-x 2 root root 1024 Oct 17 02:59 root
drwxr-xr-x 2 root root 1024 Oct 17 02:59 sbin
drwxr-xr-x 2 root root 1024 Nov 20 2007 sys
drwxrwxrwt 2 root root 1024 Nov 20 2007 tmp
drwxrwxr-x 9 root root 1024 Oct 17 02:59 usr
drwxr-xr-x 11 root root 1024 Oct 17 02:59 var
-rw-r–r-- 1 root root 7900 Oct 17 02:38 xmlwf.1
Before we start digging in to this root file system, let’s mount the JFFS2 file system, also. You will need to get the jffs2-dump.py script by Igor Skochinsky to dump the contents easily (or hack your kernel to allow you to mount a non-MTD JFFS2 filesystem). It can be obtained at: http://code.ohloh.net/file?fid=G5dAYwrgEVirRINJHms-GWLem5c&cid=Q23-rTiawxw&s&fp=17006&mp&projSelected=true#L0
I saved it in the “extracted/jffs” directory and named it “jffs2-dump.py”
The commands to extract the JFFS2 image are:
mkdir jffs
cp ~/Downloads/jffs2-dump.py jffs/ (Or where ever you put the downloaded file).
cd jffs
python ./jffs2-dump.py …/c_138271353801
This will spew a lot of information, and create a directory called “extracted/jffs/root” and a file called “extracted/jffs/log.txt”. This is the actual root file system that the device runs from under normal operating mode, from the look of things.
If you want to play with the binaries in the system, you can also install ARM emulation (through qemu) and run the commands to see what they do. Be warned, running them as root might be a REALLY BAD idea since some of these might try to format things or poke at hardware in your PC.
apt-get install qemu binfmt-support qemu-user-static
update-binfmts --display (This shold spew lots of emulation information)
cp /usr/bin/qemu-arm-static extracted/jffs/root/usr/bin/
Next you will need to replace the text files that JFFS uses to create links with “real” Linux links for the libraries and binaries. You can do this using this script from the “extracted/jffs/root/” directory. I named it “fixbins.sh” and ran it using “bash ./fixbins.sh”
#!/bin/bash
cd lib
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /lib/cat $fileName”
ln -sf /lib/cat $fileName $fileName
done
chmod +x *
cd …
cd bin
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /bin/cat $fileName”
ln -sf /bin/cat $fileName $fileName
done
chmod +x *
cd …
cd sbin
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /sbin/cat $fileName”
ln -sf /sbin/cat $fileName $fileName
done
chmod +x *
cd …
cd usr/lib
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /usr/lib/cat $fileName”
ln -sf /usr/lib/cat $fileName $fileName
done
chmod +x *
cd …/…
cd usr/bin
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /usr/bin/cat $fileName”
ln -sf /usr/bin/cat $fileName $fileName
done
chmod +x *
cd …/…
cd usr/sbin
REPLACELIST=file * | grep ASCII | cut -f 1 -d ":"
for fileName in ${REPLACELIST[@]}
do
echo “Linking $fileName to /usr/sbin/cat $fileName”
ln -sf /usr/sbin/cat $fileName $fileName
done
chmod +x *
cd …/…
In order to test this let’s chroot into the virtual device’s file system and poke around a bit. (From the “extracted/jffs/” directory)
root@ubuntu:/home/phork/Trane_Comfort_Link_II/extracted/jffs# chroot root /bin/ash
BusyBox v1.6.1 () Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
/ $ ls -l
drwxr-xr-x 2 root root 4096 Feb 26 04:04 bin
drwxr-xr-x 6 root root 4096 Feb 26 03:59 dev
drwxr-xr-x 6 root root 4096 Feb 26 03:59 etc
drwxr-xr-x 3 root root 4096 Feb 26 03:59 home
drwxr-xr-x 5 root root 4096 Feb 26 04:00 lib
-rw-r–r-- 1 root root 11 Feb 26 03:59 linuxrc
drwxr-xr-x 7 root root 4096 Feb 26 03:59 mnt
drwxr-xr-x 2 root root 4096 Feb 26 03:59 opt
drwxr-xr-x 2 root root 4096 Feb 26 03:59 proc
drwxr-xr-x 4 root root 4096 Feb 26 04:08 root
drwxr-xr-x 2 root root 4096 Feb 26 04:04 sbin
drwxr-xr-x 2 root root 4096 Feb 26 03:59 sys
drwxr-xr-x 2 root root 4096 Feb 26 03:59 tmp
drwxr-xr-x 10 root root 4096 Feb 26 03:59 usr
drwxr-xr-x 11 root root 4096 Feb 26 03:59 var
/ $ uname -a
Linux ubuntu 2.6.32 #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 armv7l unknown
Well now! That looks pretty good! What else can we learn about this system from here?
I’ve looked for the normal stuff and didn’t find anything that was an “easy” way in. I did locate a password that looks like it’s the normal ADMIN password for the control protocol stuff “Cold,2100”. It was in the flash file in the /root directory of the JFFS image. What does it do? I’m not sure yet :-).
Enjoy the information, and please post any follow up information about this lovely thermostat that you might find!
Thanks!
Not sure if anyone tried opening the unit up and looking for a place to connect a serial cable and see if your able to boot into a single usermode and just changed the root password .
I have one of these awesome thermostats! I have done some digging and figured I would post what I have found. I started by dumping everything I could from the update package as others have done. I then wasted some time trying some attacks on the md5crypt password hashes with my couple of GPU’s with hashcat. I then realized that you can dump syslog and dmesg to an sd card on the XL from one of them menus on the tstat. I quickly noticed the following in the syslog.
May 11 07:12:20 auth.info passwd: Password for raptor21 changed by root
May 11 07:12:20 user.notice XCC: Changing password for raptor21
May 11 07:12:20 user.notice XCC: Password for raptor21 changed by root
May 11 07:12:20 user.notice wifi_arm: Sending select for 192.168.0.185...
May 11 07:12:20 local0.info udhcpc[2407]: Sending select for 192.168.0.185...
May 11 07:12:20 user.notice CLIILOG: Log Directory: /media/sd-mmcblk0p1/clii_logs/
May 11 07:12:20 user.notice wifi_arm: Lease of 192.168.0.185 obtained, lease time -1
May 11 07:12:20 local0.info udhcpc[2407]: Lease of 192.168.0.185 obtained, lease time -1
May 11 07:12:20 auth.info passwd: Password for root changed by root
May 11 07:12:20 user.notice XCC: Changing password for root
May 11 07:12:20 user.notice XCC: Password for root changed by root The passwords are changed when it boots. So even if I could cracking those hashes in the shadow file, it would likely be pointless. I can however see from the log that XCC is what is changing the password at boot time. I didn’t find an xcc binary in the filesystem, but there is scc. (hint: scc is XCC). Since I figured whatever was running that command would have to run the passwd command I grep’d the whole filesystem for “passwd” and hit the /bin/scc binary. It is a rather large binary (22MB) and from the looks of it runs the show and took IDA forever to analyze. I ended up leaving it to analyze and went to bed. Anyways… I have almost no knowledge of IDA (and assembly for that matter) other than what it does haha so I am learning as I go. the fun starts at 0x291D28 which is “Argon::Cheetah::AccountManagement::User::Context::start(void)”. now like I said I am a total noob at this but It seems to be loading and manipulating some strings. There is some pseudocrypto (ROT13 - ROT13 - Wikipedia) going on in there. And then it looks like it gets passed to “Argon::Cheetah::AccountManagement::User::Context::setPassword(char const*)” (0x291BC0) which then goes through some more things before using “Argon::Cheetah::AccountManagement::User::Context::setLinuxPassword(char const*, char const*)” (0x291964).
That’s as far as I have made it. I need to get a better handle on assembly before I can go any further. Ill do my best to try and turn it into pseudocode and try to understand it better. Though I have a feeling that some things will be loaded from offsets stored in the flash that just wont be in update files. I could be wrong though. Gotta head back to work… so this post is done for now. Ill add some other things I found later on this evening.
If someone with the ability to dump the flash can open theirs up and dump it that would be awesome.
So, as it happens, my darling almost 3 year old daughter pulled our Trane XL off the wall and broke the touch screen. I ordered a replacement, but my wife wasn’t fond of going without heat for too long (in Feb mind you), so I now have a “spare” thermostat to experiment on! As soon as time permits, I’m planning on implementing a “fake relay” module (Looks like a Dallas 1 wire to me), and see about figuring out what this beastie really does.
Thank you for the Reverse Engineering information! I’ll fire up IDA on the binaries and see what I can make of them (I’m a professional RE / Hardware/Software Engineer by trade, so I might have some better luck on this since I have to stare at x86 and ARM code often). I will post any results of interest here. Based on the line:
May 11 07:12:20 user.notice CLIILOG: Log Directory: /media/sd-mmcblk0p1/clii_logs/
I think it might be possible to add a SD card with the directory clii_logs on it, in a fat32 partition, and see if it writes interesting things there (like passwords, seeds, hashes, etc.). I’ll see about setting up a full emulated environment and package it as a VM for folks once I figure out how to do so. Anyone interested in a compiler image, as well, to write custom “applets” for the XL? I know I’d love to know how to install additional applications, and since it’s Linux with XML configuration files, I think it’s most likely very possible to do.
Anyone want to setup a project for this and start a Wiki for knowledge share, etc? Or should we just keep posting here?