Home Automation Hub Forensics

In Part 1: Introduction to Hardware and Embedded Forensics I went over some tools I am using to perform hardware and embedded forensics analysis. In Part 2: UART Intro. and Sniffing UART with a Logic Analyzer we were able to get root on a home automation hub.

Now for Part 3: Home Automation Hub Forensics, which is this post we are going to go over getting root access on another home automation unit, and then proceed to perform some initial forensic analysis.

Why I decided to perform analysis on this particular unit is because it functions as both a home automation hub and also a wifi router. It seems more practical to me vs. purchasing a wifi router and a home automation hub. I hate duplicate devices so this all-in-one unit is nice.

Before we were able to obtain Root access I need to open the device and take a look at its inside. Right away I noticed the UART pinout. They were nice and labeled for me and allowed for easy access.

In this image I have already connected the female jumper wires to the TX, RX and GND pins.

Silvrback blog image

And here you can see the connection is made to my Shikra so I am ready to talk to the device over serial.

Silvrback blog image

So now that we are connected we can simply connect to the device once it powers up. In this case I kept hitting Enter and in due time I was dropped into a login prompt. The problem with this is that it was password protected. I tried some simple passwords like root, admin, etc. but none of them seemed to work.

Then I remembered when I setup the device there was a default password already configured in the device. I can't verify is these are unique, but my password was haars (if I recall correctly). So I decided to use root as the user and haars as the password and guess what?

Silvrback blog image

If you change the internal password of your device that same password will follow forward so if you change yours from haars to helloworld you would use root as the username and helloworld as the password.

I also wanted to mention that at least on my device SSH seemed to be enabled by default and I was able to SSH into that same root account with the preconfigured user/password (root/haars) so you really wouldn't even need to go to the extent I did with the hardware to get the same level of access. In either case, we will continue as if SSH was not enabled.

Once connected I started to poke around a bit.

Silvrback blog image

cat /proc/mtd

dev: size erasesize name mtd0: 00100000 00020000 "uboot-env0"
mtd1: 00100000 00020000 "uboot-env1"
mtd2: 00100000 00020000 "sb0"
mtd3: 00100000 00020000 "sb1"
mtd4: 02e00000 00020000 "rootfs"
mtd5: 00600000 00020000 "kernel_standby"
mtd6: 02e00000 00020000 "rootfs_standby"
mtd7: 01000000 00020000 "rootfs_data"
mtd8: 00100000 00020000 "log"
mtd9: 00100000 00020000 "cal"
mtd10: 00100000 00020000 "man"
mtd11: 00500000 00020000 "SNIP_Data"
mtd12: 000e0000 00020000 "uboot0"
mtd13: 00100000 00020000 "uboot1"

I dumped mtd4, rootfs, which is the squashfs firmware file.

Once we have this we can unpack it and look at the filesystem contents and review all of the data.

I will look at this more in the next post.