Author Topic: Trane XL950 Thermostat  (Read 38192 times)

Offline RichardTSchaefer

  • Master Member
  • *******
  • Posts: 9432
  • Karma: +716/-133
    • RTS Services Plugins
Re: Trane XL950 Thermostat
« Reply #30 on: May 07, 2013, 12:15:46 pm »
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.

Offline groovydude

  • Newbie
  • *
  • Posts: 13
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #31 on: May 17, 2013, 01:23:38 pm »
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.

Offline leifmb

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #32 on: June 08, 2013, 01:49:16 pm »
I'd like to so I can try to link it to my Control4 system!!!


Offline leifmb

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #33 on: June 09, 2013, 11:59:24 am »
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.

Offline Dominic

  • Sr. Newbie
  • *
  • Posts: 34
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #34 on: December 16, 2013, 05:02:19 pm »
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?

Offline groovydude

  • Newbie
  • *
  • Posts: 13
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #35 on: January 01, 2014, 08:33:47 am »
I stopped working on it some time ago, but I'm not against collaborating with someone on this.

Offline phorkus

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #36 on: February 26, 2014, 12:30:46 am »
Hello all, a few observations on the Trane Comfort Link II Thermostat:

1. It's embedded Linux.  It is definitely possible to extract the updates and figure out what's "really" going on here.
2. If we can extract it, we can probably alter it.  (Barring a digital signature of some form).
3. 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!

Offline micro98

  • Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #37 on: March 05, 2014, 09:58:08 am »
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 .

Offline ekrboi

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #38 on: May 13, 2014, 01:53:43 pm »
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.

Code: [Select]
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 - https://en.wikipedia.org/wiki/ROT13) 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.
« Last Edit: May 13, 2014, 04:35:42 pm by ekrboi »

Offline phorkus

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #39 on: May 15, 2014, 11:04:43 am »
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:

Code: [Select]
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?


Offline ekrboi

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #40 on: May 16, 2014, 05:30:32 pm »
Ouch. it sucks she broke it but at least you have a "guinea pig" now. Do you happen to have the hardware to solder to the nand so you can read/write? that would be awesome. I have been able to run some commands as root!  ;D
I have been able to unpack > modify > repack and run the 3.0 update.  For now I am playing with the updater portion (b_138271353801) by injecting my own script into init.d. My goal at the moment is to dump the nand. I had the first success last night and was able to dump out some common things. I didn't learn tooo much more than I already knew from them but something is better than nothing. The script ran way too early in the boot process so syslog wasn't  even up yet. Below is that info. For anyone who did not know... the tstat is based on the Freescale IMX35PDK: i.MX35 Product Development Kit.. there is a plethora of info on their website.

Quote
offsets of NAND "partitions"
0x00000000-0x00200000 : "nand.redboot"
0x00200000-0x00700000 : "nand.kernel"
0x00700000-0x10100000 : "nand.rootfs"
0x10100000-0x29100000 : "nand.upgrade"
0x29100000-0x40000000 : "nand.factory"  <- im guessing this is going to hold the magic data we want to get our hands on.

Quote
output of uname -a
Linux ComfortControl 2.6.26-466-ga04670e #1 Thu Oct 17 01:35:01 CDT 2013 armv6l unknown

Quote
output of ps aux
  PID  Uid        VSZ Stat Command
    1 root       2800 SW  init       
    2 root            SW< [kthreadd]
    3 root            SW< [ksoftirqd/0]
    4 root            SW< [watchdog/0]
    5 root            SW< [events/0]
    6 root            SW< [khelper]
   89 root            SW< [kblockd/0]
   92 root            SW< [cqueue]
  100 root            SW< [mxc_spi.0]
  120 root            SW< [kmmcd]
  127 root            SW< [mc13892/0]
  190 root            SW  [pdflush]
  191 root            SW  [pdflush]
  192 root            SW< [kswapd0]
  234 root            SW< [aio/0]
  239 root            SW< [nfsiod]
  865 root            SW< [mtdblockd]
  894 root            SW< [rpciod/0]
  896 root            SW< [mmcqd]
  908 root            SW  [mxc_ts]
  909 root            SW  [pdflush]
  912 root       2800 SW  init       
  913 root       2800 SW  /bin/sh /etc/rc.d/rcS
  935 root       1600 SW< udevd --daemon
 1717 root       2800 RW  /bin/sh /etc/rc.d/init.d/filesystems start
 1740 root       2804 RW  ps aux

Quote
whoami - root

id - uid=0(root) gid=0(root)

as you can see the system is barely booted at the point I was in last night. Since I am injecting before the update actually runs I can just hit cancel when it gets to that point so pretty much no chance of bricking.... getting there... I need to get it to load the mtd kernel module.. load the "partitions" and then dump them with the following..

Quote
   #dump the nand partitions
   ###0x00000000-0x00200000 : "nand.redboot"
   nanddump -f /media/sd-mmcblk0p1/mtd0 /dev/mtd0
   
   ###0x00200000-0x00700000 : "nand.kernel"
   nanddump -f /media/sd-mmcblk0p1/mtd1 /dev/mtd1

   ###0x00700000-0x10100000 : "nand.rootfs"
   nanddump -f /media/sd-mmcblk0p1/mtd2 /dev/mtd2

   ###0x10100000-0x29100000 : "nand.upgrade"
   nanddump -f /media/sd-mmcblk0p1/mtd3 /dev/mtd3

   ###0x29100000-0x40000000 : "nand.factory"
   nanddump -f /media/sd-mmcblk0p1/mtd4 /dev/mtd4

I think a wiki is a great idea. Im going out of town for the weekend so I can't do it just yet.  I have attached a zip with the outputs that actually returned things. The logs are named after the command ran as you can see from my "payload" below.

Quote
   ###dump all the things!
   dmesg > /media/sd-mmcblk0p1/dmesg
   df > /media/sd-mmcblk0p1/df
   du > /media/sd-mmcblk0p1/du
   free > /media/sd-mmcblk0p1/free
   id > /media/sd-mmcblk0p1/id
   ps aux > /media/sd-mmcblk0p1/ps
   uname -a > /media/sd-mmcblk0p1/uname
   whoami > /media/sd-mmcblk0p1/whoami
   wreep -h > /media/sd-mmcblk0p1/wreep
   boardrev -r > /media/sd-mmcblk0p1/boardrev
   lsmod > /media/sd-mmcblk0p1/lsmod


EDIT:
PS.. i noticed last night that dropbear (the ssh server) is started with the -w argument. -w = no root login. So the only way in even with the password on a "stock" firmware will be with the raptor21 user.. which from groups file doesn't have much permissions. One thing at a time though.. Hopefully once SSH'd into the raptor21 acct I/we can exploit something to escalate privileges. Ideally I could modify the jffs2 image in the update and remove the -w switch from the init.d script that loads dropbear... but I have not had the balls to do that yet =P

My "end goal" at the moment is to be able to format a portion of the SD card as an ext partition that the tstat can use,  inject into one of the startup scripts in the jffs2 img in the update and then install it so that  when it boots it will attempt to mount the ext2 partition on the  sd card and run an "init.sh" script from it if it exists.... then we can put anything we want to do/run on the card and start it from the script. I think that's the safest way as it doesn't modify the stock firmware much..  the init.sh script could do something like killall dropbear > adduser > restart dropbear etc. thoughts?

Quote
Phorkus -
 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. 

Ill have to give the clii_logs dir a try.. the VM image and compiler sound awesome! keep us updated. Also let me know what you can figure out from IDA... I had to stop staring at it.. it was making my brain hurt haha. It made me REALLY appreciate high level languages! The functions I listed the other day are pretty short.. so im sure that someone who understands assembly will have no problem identifying exactly what it does to generate the password before issuing the 'passwd' cmd.

I have never tried to "hack" into anything before.. im having a blast with this =) I wish I had a second one... the GF gives me the "look" everytime I stick an SD card into it... ill be in the dog house if I break it =P
« Last Edit: May 16, 2014, 07:05:49 pm by ekrboi »

Offline ekrboi

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #41 on: May 16, 2014, 06:58:16 pm »
Well im looking at the XXL upgrade binary with IDA to see how it handles the flashing of the nand.

Code: [Select]
.text:0000B748
.text:0000B748 ; =============== S U B R O U T I N E =======================================
.text:0000B748
.text:0000B748
.text:0000B748 ; load_nand_modules(void)
.text:0000B748                 EXPORT _Z17load_nand_modulesv
.text:0000B748 _Z17load_nand_modulesv                  ; CODE XREF: proceedWithUpgradeCallback(_GtkWidget *,_GdkEvent *,void *)+18Cp
.text:0000B748
.text:0000B748 var_4           = -4
.text:0000B748
.text:0000B748                 STR     LR, [SP,#var_4]!
.text:0000B74C                 SUB     SP, SP, #4
.text:0000B750                 LDR     R3, =upgrade_from_nandpart_scheme
.text:0000B754                 LDR     R0, [R3]        ; s1
.text:0000B758                 LDR     R1, =a1         ; s2
.text:0000B75C                 BL      strcmp
.text:0000B760                 CMP     R0, #0
.text:0000B764                 BNE     loc_B774
.text:0000B768                 LDR     R0, =aFound5Partitio ; "Found 5 partitions in installed system\n"...
.text:0000B76C                 BL      g_print
.text:0000B770                 B       loc_B7BC
.text:0000B774 ; ---------------------------------------------------------------------------
.text:0000B774
.text:0000B774 loc_B774                                ; CODE XREF: load_nand_modules(void)+1Cj
.text:0000B774                 LDR     R0, =aFound3Partitio ; "Found 3 partitions in installed system\n"...
.text:0000B778                 BL      g_print
.text:0000B77C                 LDR     R0, =aModprobeModarg ; "modprobe modargspart -r"
.text:0000B780                 MOV     R1, #1
.text:0000B784                 BL      _Z7sysCallPKci_0 ; sysCall(char  const*,int)
.text:0000B788                 LDR     R0, =aModprobeMxc_nd ; "modprobe mxc_nd2 -r"
.text:0000B78C                 MOV     R1, #1
.text:0000B790                 BL      _Z7sysCallPKci_0 ; sysCall(char  const*,int)
.text:0000B794                 MOV     R0, #1          ; seconds
.text:0000B798                 BL      sleep
.text:0000B79C                 LDR     R0, =aModprobeModa_0 ; "modprobe modargspart cmdline='NAND 1GiB"...
.text:0000B7A0                 MOV     R1, #1
.text:0000B7A4                 BL      _Z7sysCallPKci_0 ; sysCall(char  const*,int)
.text:0000B7A8                 LDR     R0, =aModprobeMxc__0 ; "modprobe mxc_nd2"
.text:0000B7AC                 MOV     R1, #1
.text:0000B7B0                 BL      _Z7sysCallPKci_0 ; sysCall(char  const*,int)
.text:0000B7B4                 MOV     R0, #2          ; seconds
.text:0000B7B8                 BL      sleep
.text:0000B7BC
.text:0000B7BC loc_B7BC                                ; CODE XREF: load_nand_modules(void)+28j
.text:0000B7BC                 ADD     SP, SP, #4
.text:0000B7C0                 LDMFD   SP!, {PC}
.text:0000B7C0 ; End of function load_nand_modules(void)
.text:0000B7C0
.text:0000B7C0 ; ---------------------------------------------------------------------------


Code: [Select]
.rodata:0000E058 aModprobeModa_0 DCB "modprobe modargspart cmdline='NAND 1GiB 3,3V 8-bit:2M(nand.redbo"
.rodata:0000E058                                         ; DATA XREF: load_nand_modules(void)+54o
.rodata:0000E058                                         ; .text:off_B7DCo
.rodata:0000E058                 DCB "ot),5M(nand.kernel),250M(nand.rootfs),400M(nand.upgrade),-(nand."
.rodata:0000E058                 DCB "factory)'",0
.rodata:0000E0E2                 ALIGN 4
.rodata:0000E0E4 aModprobeMxc__0 DCB "modprobe mxc_nd2",0
.rodata:0000E0E4                                         ; DATA XREF: load_nand_modules(void)+60o
.rodata:0000E0E4                                         ; .text:off_B7E0o

so..

modprobe modargspart cmdline='NAND 1GiB 3,3V 8-bit:2M(nand.redboot),5M(nand.kernel),250M(nand.rootfs),400M(nand.upgrade),-(nand.factory)'         <-- pseudo partition setup?
modprobe mxc_nd2  <- nand handling module
<dump mtd's commands>
modprobe modargspart -r
modprobe mxc_nd2 -r




guess ill have to give it a shot!

EDIT:

Quote
truncated output of 'ls -la /dev'

drwxr-xr-x    6 root     root        12700 May 16 23:37 .
drwxr-xr-x   18 root     root         1024 May 16 23:37 ..
drwxr-xr-x    6 root     root          140 May 16 23:37 .udev
lrwxrwxrwx    1 root     root            4 May 16 23:37 XOR -> null
crw-r--r--    1 root     root     192,   0 May 16 23:37 cliimac0
crw-------    1 root     root       5,   1 May 16 23:37 console
crw-rw----    1 root     root      10,  62 May 16 23:37 cpu_dma_latency
drwxr-xr-x    3 root     root           60 May 16 23:37 disk
lrwxrwxrwx    1 root     root            3 May 16 23:37 fb -> fb0
crw-rw----    1 root     root      29,   0 May 16 23:37 fb0
crw-rw----    1 root     root      29,   1 May 16 23:37 fb1
crw-rw----    1 root     root     249,   0 May 16 23:37 fsl_shw
crw-rw-rw-    1 root     root       1,   7 May 16 23:37 full
crw-rw----    1 root     root      89,   0 May 16 23:37 i2c-0
crw-rw----    1 root     root      89,   1 May 16 23:37 i2c-1
drwxr-xr-x    2 root     root          100 May 16 23:37 input
crw-r-----    1 root     kmem       1,   2 May 16 23:37 kmem
crw-rw----    1 root     root       1,  11 May 16 23:37 kmsg
brw-r-----    1 root     disk       7,   0 May 16 23:37 loop0
brw-r-----    1 root     disk       7,   1 May 16 23:37 loop1
brw-r-----    1 root     disk       7,   2 May 16 23:37 loop2
brw-r-----    1 root     disk       7,   3 May 16 23:37 loop3
brw-r-----    1 root     disk       7,   4 May 16 23:37 loop4
brw-r-----    1 root     disk       7,   5 May 16 23:37 loop5
brw-r-----    1 root     disk       7,   6 May 16 23:37 loop6
brw-r-----    1 root     disk       7,   7 May 16 23:37 loop7
crw-r-----    1 root     kmem       1,   1 May 16 23:37 mem
brw-r-----    1 root     users    179,   0 May 16 23:37 mmcblk0
brw-r-----    1 root     users    179,   1 May 16 23:37 mmcblk0p1
crw-rw----    1 root     root      90,   0 May 16 23:37 mtd0
crw-rw----    1 root     root      90,   1 May 16 23:37 mtd0ro
brw-r-----    1 root     disk      31,   0 May 16 23:37 mtdblock0
crw-rw----    1 root     root     253,   0 May 16 23:37 mxc_ipu
crw-rw----    1 root     root     251,   0 May 16 23:37 mxc_ipu_pf
crw-rw----    1 root     root      10,  61 May 16 23:37 network_latency
crw-rw----    1 root     root      10,  60 May 16 23:37 network_throughput
crw-rw-rw-    1 root     root       1,   3 May 16 23:37 null
crw-rw----    1 root     root     250,   0 May 16 23:37 pmic
crw-rw-rw-    1 root     tty        5,   2 May 16 23:37 ptmx
drwxr-xr-x    2 root     root            0 Jan  1  1970 pts
crw-rw----    1 root     tty        2, 176 May 16 23:37 ptya0
crw-rw----    1 root     tty        2, 177 May 16 23:37 ptya1
crw-rw----    1 root     tty        2, 178 May 16 23:37 ptya2
crw-rw----    1 root     tty        2, 179 May 16 23:37 ptya3
<truncated>
crw-rw----    1 root     tty        2, 174 May 16 23:37 ptyze
crw-rw----    1 root     tty        2, 175 May 16 23:37 ptyzf
brw-r-----    1 root     disk       1,   0 May 16 23:37 ram0
lrwxrwxrwx    1 root     root            4 May 16 23:37 ramdisk -> ram0
crw-rw-rw-    1 root     root       1,   8 May 16 23:37 random
lrwxrwxrwx    1 root     root            4 May 16 23:37 rtc -> rtc0
crw-r--r--    1 root     root     254,   0 May 16 23:37 rtc0
lrwxrwxrwx    1 root     root            7 May 16 23:37 sd-mmcblk0 -> mmcblk0
lrwxrwxrwx    1 root     root            9 May 16 23:37 sd-mmcblk0p1 -> mmcblk0p1
crw-rw----    1 root     root     153,   0 May 16 23:37 spidev1.0
crw-rw-rw-    1 root     tty        5,   0 May 16 23:37 tty
crw--w----    1 root     tty        4,   0 May 16 23:37 tty0
crw--w----    1 root     tty        4,   1 May 16 23:37 tty1
crw--w----    1 root     tty        4,  10 May 16 23:37 tty10
<truncated>
crw-rw----    1 root     tty        3, 254 May 16 23:37 ttyee
crw-rw----    1 root     tty        3, 255 May 16 23:37 ttyef
crw-rw----    1 root     root     207,  16 May 16 23:37 ttymxc0
crw-rw----    1 root     root     207,  17 May 16 23:37 ttymxc1
crw-rw----    1 root     root     207,  18 May 16 23:37 ttymxc2
crw-rw----    1 root     tty        3,   0 May 16 23:37 ttyp0
crw-rw----    1 root     tty        3,   1 May 16 23:37 ttyp1
crw-rw----    1 root     tty        3,   2 May 16 23:37 ttyp2
<truncated>
crw-rw----    1 root     tty        3, 173 May 16 23:37 ttyzd
crw-rw----    1 root     tty        3, 174 May 16 23:37 ttyze
crw-rw----    1 root     tty        3, 175 May 16 23:37 ttyzf
crw-rw----    1 root     root      10,  63 May 16 23:37 ubi_ctrl
crw-rw-rw-    1 root     root       1,   9 May 16 23:37 urandom
crw-rw----    1 root     tty        7,   0 May 16 23:37 vcs
crw-rw----    1 root     tty        7, 128 May 16 23:37 vcsa
crw-rw----    1 root     root      81,  16 May 16 23:37 video16
crw-rw----    1 root     root      10, 130 May 16 23:37 watchdog
crw-rw-rw-    1 root     root       1,   5 May 16 23:37 zero

full output over there if interested -> http://pastebin.com/zB395fne


« Last Edit: May 16, 2014, 08:54:18 pm by ekrboi »

Offline ekrboi

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #42 on: May 18, 2014, 01:24:15 pm »
Have not been able to get nanddump to work for some reason, but dd does. =)


mtdblock0-dd - bootloader - uboot
mtdblock1-dd - kernel - duh...
mtdblock2-dd - main - system... duh...
mtdblock3-dd - upgrade partition  - storage for settings and things during an upgrade.
mtdblock4-dd - factory - 16,777,216 bytes of absolutely NOTHING. FF FF FF FF FF.....
« Last Edit: May 18, 2014, 01:33:12 pm by ekrboi »

Offline ekrboi

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #43 on: May 21, 2014, 01:40:00 am »
So instead of making a full VM with toolchains and SDKs that will be huge to distribute I have made a script you can run after setting up your own VM. Plus this way doesn't step on anyones licenses. You will have to grab the SDK from Freescales website which will require you to sign up (free) and the accept their agreement.

I used VirtualBox running on my Xubuntu 14.04 x64 system and installed Xubuntu 14.04 (i386) in the VM.  grab it from there -> http://mirror.anl.gov/pub/ubuntu-iso/CDs-Xubuntu/14.04/release/xubuntu-14.04-desktop-i386.iso It should work on all Ubuntu variants but I personally like Xubuntu. I think it's safer to stick with an x86(i386) ubuntu version because I borked up my x64 install after forcing it to install soo many i386 libs that the LTIB needs. I think ubuntu 10.04 was the "norm" when the SDK was released. It took a bit of work to get it to work with 14.04. That's what the script is for, so nobody else has to figure this crap out haha.

 I gave it 15gb total and after all said and done ive got around 5gb free space. Once Xubuntu is installed in the VM go ahead and sudo apt-get update && sudo apt-get upgrade and bring the system up to current. Then install the VBoxGuestAdditions and reboot the VM You should be looking at a totally up to date fresh install with a full screen.

Then go grab the SDK from Freescale. -> https://www.freescale.com/webapp/Download?colCode=L2.6.31_09.12.01_SDK_SOURCE&prodCode=IMX35PDK&appType=license&location=null&fpsp=1&Parent_nodeId=1240327141887725998192&Parent_pageType=product

I just placed it on the desktop and extracted it. you will need to run the install script (./install) and accept its terms. then tell it where to put it. I did /home/imx/Desktop (imx is the vm username) and it will install to a folder called ltib on your desktop.

Copy my script into the new ltib folder, chmod +x it and run it.. I have tested it twice from a clean system so it works.



« Last Edit: May 21, 2014, 01:48:40 am by ekrboi »

Offline micro98

  • Newbie
  • *
  • Posts: 12
  • Karma: +0/-0
Re: Trane XL950 Thermostat
« Reply #44 on: May 21, 2014, 08:38:44 am »
Quote
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. 

Looking at a file called /bin/ciliilogger... it scans the SD card for a file called "mode.cliilog" if found it will run debug logs. looks intresteing...