Update: A few people were kind enough to correct me on some of my terminology. Where appropriate, 'decompiling' has been replaced with 'extracting'. My apologies if that confused or mislead anybody :) Updated post is here

A few weeks ago I got a home security system installed. The package included a 7-inch tablet called the Honeywell Tuxedo that mounts on the wall. It’s basically a primary controller for the security system. Given what’s been going on in the IoT space and just my pure curiosity, it didn’t take long before the poking and prodding began. My first approach was to treat it like a standard penetration test, identifying network services, lighting testing the web application and enumerating the attack surface. After the first two days of testing in my spare time, the thought occurred that it would suck to ruin the device by testing it too heavily. Nothing like breaking your system and telling support it’s because you fuzzed it to death.

Instead of investigating from the outside in, I decided to take a different approach and start looking at reverse engineering the firmware. However, as a penetration tester I’m completely out of my comfort zone; but there’s a first time for everything so bear with me.

Reading through the documentation of the Tuxedo there is a capability to install software updates via SD card. I also found where you can download the latest software update for the device. I couldn’t find any available source code on the web so perhaps this avenue is a good first step. At the time of this writing the latest software update is v5.3.9.0.

The software downloads as a ZIP, and when extracted reveals an executable. Extracting the .exe shows the HDR files mentioned on the website, but what is an HDR file? I was expecting something like a .bin, and running file just shows they are data files. Not a lot of help.

bullz3ye@ubuntu:~/honeywell$ unrar x TUXW_V5.3.9.0_CN.exe UNRAR 5 .30 beta 2 freeware Copyright ( c ) 1993 -2015 Alexander Roshal Extracting from TUXW_V5.3.9.0_CN.exe Extracting ProgCV.hdr OK Extracting seconboot.hdr OK Extracting app1.hdr OK Extracting app2.hdr OK Extracting app3.hdr OK Extracting MCU.hex OK All OK bullz3ye@ubuntu:~/honeywell$ ls app1.hdr app2.hdr app3.hdr honeywell.log MCU.hex ProgCV.hdr seconboot.hdr TUXW_V5.3.9.0_CN.exe TUXW_V5.3.9.0_CN.zip bullz3ye@ubuntu:~/honeywell$ file *.hdr app1.hdr: data app2.hdr: data app3.hdr: data ProgCV.hdr: data seconboot.hdr: data

I spend entirely too much time googling what an HDR file is and how to decompress/extract/open it. Apparently an HDR is a high-dynamic-range image used for photography or something. I’m thinking, maybe Honeywell has some proprietary packaging tool that uses actual images for software updates?

What really reinforced this thought pattern was when using strings I get tons of references to a Linux environment.

bullz3ye@ubuntu:~/honeywell$ strings *.hdr | grep Linux Linux-2.6.31-207-g7286c01 Uncompressing Linux... Welcome to Freescale Semiconductor Embedded Linux Environment No Linux %s Ramdisk Image Linux bullz3ye@ubuntu:~/honeywell$ strings *.hdr | grep bash bash bash Ubashbug bashbug dabash .bash_history .bash_history getopt-parse.bash & getopt-test.bash getopt-parse.bash getopt-test.bash bullz3ye@ubuntu:~/honeywell$ strings *.hdr | grep passwd passwd passwd bullz3ye@ubuntu:~/honeywell$ strings *.hdr | grep Freescale Freescale Semiconductor, Inc. Welcome to Freescale Semiconductor Embedded Linux Environment CPU: Freescale i.MX35 at1 %d MHz

How did an embedded linux environment get packaged/compiled into a literal image file? I was getting somewhere though using strings to grep for more keywords. Perhaps there really is a file system in all this. At the very least I know I’m dealing with an embedded linux environment, know the kernel version, and can later read up on Freescale to get an idea of my target and the build process. I continue to use strings in order to try and put the pieces together.

At the same time, I couldn’t find a single reference point between files with extension HDR and embedded linux or Honeywell. I started looking for any references regarding Honeywell Tuxedo code at all to see if I could get any indication as to what these files are and how they are used. I didn’t find much at all, but finally doing a search for honeywell app2.hdr I run across a repo in Github that saved the day.

Two shell scripts exists, yitiaolong.sh and vam_dailybuild.sh, both appear to have something to do with the compilation process.

VAM apparently stands for VISTA Automation Module and is related to the Tuxedo. A youtube video shows the same interface that is on my Tuxedo device. Long story short these scripts had a wealth of useful information, but I’ll try to highlight some of the key points.

The code above shows project path to the Tuxedo source code and a project called Barracuda (which I’ve yet to dig into). A separate search shows that Barracuda is the web server of choice for the device, and is a separate task all together. Of course the first thing I do it try to access the source code but apparently the acssvn.honeywell.com site no longer exists. There were other past references to the Tuxedo project path online, leading me to think that at one point this repository was publicly available. Either way I can’t access it now.

Later I come across a slideshow with a reference to the subdomain above and it reads:

Here is what we have: acssvn.honeywell.com is their internal link to their version control system, which must mean that the github scripts are intended for internal usage. Are these the scripts used to compile their internal software updates? If so, why is it publicly available? It doesn’t seem to come from a formal Honeywell github repo, just a normal user…perhaps an employee?

I read through both scripts, and at the end of yitiaolong.sh it shows the files that I’ve extracted from the .exe being copied to an ftp.

Okay so these scripts definitely have something to do with the software updates. Going up a bit in the code I see this the following:

It looks like the source code is pushed into a root JFFS2 file system (perhaps that Freescale embedded environment), and the file system is generated into a binary. We now know that app2.jffs2 exists somewhere within the app2.hdr file, which is a JFFS2 file system compiled with Freescale tool ‘sumtool’. However, there is a bit of a grey area between how app2.jffs2 turns into app2.hdr and where the rest of the files come from. Lines 55 through 59 shows a python script named header.py that appends a string somewhere in app.jffs2? Let’s take a look at the actual app2.hdr.

bullz3ye@ubuntu:~/honeywell$ head -10 app2.hdr appl000�����w�Fri Oct 07 13 :09:51 2016app2.jffs2TUXW_V5.3.9.0APPTUXEDOPLUSVA��2�v7P6R�W ���i ' �Drop_Cache�����d5�����6R�W6R�W6R�W����w^x^�UMlU�u����ր�O [ E {(( ����B ( ��� ( EQ���ec/� { ��nR [ BJJT����P�!H� R�������!�J��� | �?��6�<3o�ͼ�yo2���

Objdump wasn’t recognizing the file format so I just used head and less to see if that header does exists. At least we can draw the conclusion that some form of header is being prepended to the data file using header.py, is responsible for changing the extension. Still the question remains, is HDR some custom file type?

I decide to step away for a bit since I don’t have access to header.py, and that extension is really sending me for a loop. About an hour later it occurs to me that what if the .hdr extension stands for ‘header’ and wasn’t the name of any valid file type?! What if it’s just a JFFS2 file system renamed to indicate that a header has been included for the sake of installation?

bullz3ye@ubuntu:~/honeywell$ binwalk app2.hdr DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 128 0x80 JFFS2 filesystem, little endian

What the f###…I should have done that to begin with.

Well, at least we know what we are dealing with here. JFFS2 is a popular file system, and we can use dd to extract it out.

bullz3ye@ubuntu:~/honeywell$ dd bs = 1 skip = 128 if = app2.hdr of = app2.jffs2 130211540 +0 records in 130211540 +0 records out 130211540 bytes ( 130 MB, 124 MiB ) copied, 119 .978 s, 1 .1 MB/s bullz3ye@ubuntu:~/honeywell$ file app2.jffs2 app2.jffs2: Linux jffs2 filesystem data little endian

Now that we’ve got the file system, let’s mount it. You can’t mount it like a standard loopback device, but have to create a fake flash device first.

bullz3ye@ubuntu:~/honeywell$ sudo modprobe mtdram total_size = 32768 erase_size = 256 bullz3ye@ubuntu:~/honeywell$ sudo modprobe mtdblock bullz3ye@ubuntu:~/honeywell$ sudo mkdir -p /mnt/disk bullz3ye@ubuntu:~/honeywell$ sudo dd if = app2.jffs2 of = /dev/mtdblock0 dd: writing to '/dev/mtdblock0' : No space left on device 65537 +0 records in 65536 +0 records out 33554432 bytes ( 34 MB, 32 MiB ) copied, 0 .211631 s, 159 MB/s bullz3ye@ubuntu:~/honeywell$ sudo mount -t jffs2 /dev/mtdblock0 /mnt/disk

Let’s mount and cd into /mnt/disk…

Yes! The first thing I go for now is /etc/shadow or some credentials but it turns out that the Linux environment folders are empty.

bullz3ye@ubuntu:/mnt/disk$ ls -ldh */ drwxr-xr-x 2 root root 0 Oct 7 2016 bin/ drwxr-xr-x 2 root root 0 Oct 7 2016 dev/ drwxr-xr-x 6 root root 0 Oct 7 2016 etc/ drwxr-xr-x 4 root root 0 Oct 7 2016 home/ drwxr-xr-x 5 root root 0 Oct 7 2016 lib/ drwxr-xr-x 2 root root 0 Oct 7 2016 mdns/ drwxr-xr-x 8 root root 0 Oct 7 2016 mnt/ drwxr-xr-x 5 root root 0 Oct 7 2016 opt/ drwxr-xr-x 2 root root 0 Oct 7 2016 proc/ drwxr-xr-x 2 root root 0 Oct 7 2016 root/ drwxr-xr-x 2 root root 0 Oct 7 2016 sbin/ drwxr-xr-x 2 root root 0 Oct 7 2016 sys/ drwxrwxrwt 2 root root 0 Oct 7 2016 tmp/ drwxr-xr-x 2 root root 0 Oct 7 2016 usr/ drwxr-xr-x 2 root root 0 Oct 7 2016 var/ drwxr-xr-x 2 root root 0 Oct 7 2016 vidrec/

This leaves the executables, which are apparently ELF 32-bit LSB ARM executables. Based on the file names, these are definitely the executables that facilitate the processes running on the Tuxedo tablet, specifically the files tuxedo, TotalConnect, and SDCardStatus are interesting. tuxedo has to be the core binary, and TotalConnect must be used to interface with the product’s Honeywell Total Connect 2.0 application. Between this and the empty folders, I assume (at least in this case) that the software update doesn’t replace the entire file system but just the proprietary ELF binaries.

Taking a step back, I repeat this process of binwalk-ing the hdr files; extracting it’s contents to gather as much info as I can. Through this I discover a ton of useful information for going forward, including certificates, Makefiles, and some CRC32 polynomial tables. The next step is to figure out how to reverse engineer and decompile the binaries, starting with tuxedo for further analysis. That will likely be a part 2 to this post, but I’ve got a lot of work cut out for me.

Conclusion:

Starting from a software update, and some critical thinking, I was able to decompile the firmware update for my Honeywell Tuxedo. As a result, I have access to the proprietary binaries, and additional components that make up the device. My next two approaches are:

Reverse engineer the binaries in an attempt to discovery exploitable vulnerabilities, and learn more about the device. Set up a test environment to execute the binaries so I can actively identify the attack surface, fuzz where possible, and really dig into it.

I hit a few bumps in the road along the way but hey that’s how you learn. Thanks for taking the time to read and definitely feel free to give feedback! Below are some good links that were extremely helpful along the way.

https://blog.bramp.net/post/2012/01/24/hacking-linksys-e4200v2-firmware/ https://wiki.securityweekly.com/Reverse_Engineering_Firmware_Primer