Reverse Engineering My Home Security System: Decompiling Firmware Updates(markclayton.github.io)
markclayton.github.io
Reverse Engineering My Home Security System: Decompiling Firmware Updates
https://markclayton.github.io/reverse-engineering-my-home-security-system-decompiling-firmware-updates.html
7 comments
I don't want to sound rude but there isn't anything substantial in this article - the author just found a way to extract the firmware image and mount the Linux filesystem that's in it. No actual exploits or reverse-engineering of the device's software itself.
Not rude at all -- it's a good first step though. In my opinion, it does need a bigger payoff at the end -- so close but they posted too soon. They should've also responsibly disclosed the script on github as well (eh, maybe).
> it's a good first step though
Not only is it a good first step, but since the product clearly runs Linux, the author should be able to download all GPL source code from Honeywell. Being able to build the device firmware yourself from source is hugely beneficial to understanding the structure of the firmware and can even help in understanding the behaviour of the device.
If Honeywell aren't providing a GPL archive for the Tuxedo with the kernel and any GPL licensed user-space programs, they are violating the GPL.
I'm not sure the author is aware that the source code for these should be freely available from Honeywell
Not only is it a good first step, but since the product clearly runs Linux, the author should be able to download all GPL source code from Honeywell. Being able to build the device firmware yourself from source is hugely beneficial to understanding the structure of the firmware and can even help in understanding the behaviour of the device.
If Honeywell aren't providing a GPL archive for the Tuxedo with the kernel and any GPL licensed user-space programs, they are violating the GPL.
I'm not sure the author is aware that the source code for these should be freely available from Honeywell
Honeywell does have a number of opensource projects, with tuxdeo touch being one of them http://www.security.honeywell.com/opensource/
True. Though Honeywell can elect to mail you the source code printed on flash cards without any particular order.
I don't remember what the GPL3 says, but the GPL2 (Linux is under GPL2) says something like "a medium customarily used for software interchange" must be provided.
Is running software/application in the Linux environment deem it a derivative work? Does Honeywell have to adhere to a GPL if they aren't modifying the Linux kernel?
It's not clear to me that they would need to follow GPL.
It's not clear to me that they would need to follow GPL.
Yes, the licensing terms are on distribution, not on modification. They have to provide the source, even if it's not been modified.
They have to provide the source for the kernel and whatnot - but if the interesting stuff is in userspace applications which aren't derivatives of copyleft code, they don't have to provide the source for _those_
> but if the interesting stuff is in userspace applications which aren't derivatives of copyleft code
Of course. Honeywell can run their own proprietary applications on top of a Linux/GNU system. I didn't mean to imply that you could request the source code to every program running on the device.
However they need to provide the source code for any GPL licensed portions. IIRC they should also provide build scripts so you can create a firmware image yourself.
Of course. Honeywell can run their own proprietary applications on top of a Linux/GNU system. I didn't mean to imply that you could request the source code to every program running on the device.
However they need to provide the source code for any GPL licensed portions. IIRC they should also provide build scripts so you can create a firmware image yourself.
GPL only requires providing build scripts for GPL software. In this case it means they can't strip kernel makefiles from the kernel source to make it harder to build independently.
> 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?!
I guess that's just a mindset, but I see proprietary extensions created and used everywhere.
Especially in the context of firmware, I never once made any assumptions about this being a default file-format, nor that tooling for this extension was a path was worth digging deeper into.
Ironically the author has found lots of good tools I didn't know about which more or less should automatically reveal this, before he himself arrives at this conclusion.
Facepalm, indeed.
I guess that's just a mindset, but I see proprietary extensions created and used everywhere.
Especially in the context of firmware, I never once made any assumptions about this being a default file-format, nor that tooling for this extension was a path was worth digging deeper into.
Ironically the author has found lots of good tools I didn't know about which more or less should automatically reveal this, before he himself arrives at this conclusion.
Facepalm, indeed.
I spent the whole post thinking "binwalk ..." ... "binwalk -erM ..." to myself. Clever searching for github repos though, that was a good find.
The Tuxedo Touch is a glorified pin-pad to the actual security panel, so it may be a stretch to call this the "security system". However it would be trivial to MiTM arm/disarm codes if you could run code on it and it's the interface to home automation, which could be interesting if anything is hooked up.
I've done that exact "let's prepend a header" thing before. For a past project, each stage of the build and packaging process resulted in an increasingly-difficult to use "by hand" file that was increasingly-friendly to downloaders, flashers, and CMS systems. Each system wanted its own file header or format (one, for example, disliked Debian files and insisted that we post a gzipped tarball for some reason).
Aside from a stage that encrypted the firmware, if you knew the structures being prepended to the file, you could "undo" all of that with a little bit of perl.
Aside from a stage that encrypted the firmware, if you knew the structures being prepended to the file, you could "undo" all of that with a little bit of perl.
Title is rather misleading. Sounds like it is going to be some interesting binary to source code decompilation, but all the author does is extract some files from an archive.
excellent uses of memes, Mark :)