Hacker for Hire

Tearing Into a Linear GD004-Z

So after 2 years, my z-wave garage door opener bit the dust. I’m a little disappointed because I really feel like it should have lasted longer. As I wait for the other one to arrive, I decided it would be fun to start pulling apart the existing on (it’s broken, right?).

I should note that when I say “broken” I mean that it will no longer lift and lower the associated garage door. The system continues to generate beeps, but the LED never flashes and the door fails to open. Most of my research into the forums seem to indicate this is a common problem and the only resolution is to have the vendor send you a replacement one (so far, I think that’s still probably the best path).

First things first, let’s open it up and see what we have. Removing 4 screws on the back is easy enough:

back plate

And reveals the following layout:

board

My interest is instantly drawn to the SENSOR UART pins (populated!!!) as a first place to go. If you’ve ever read anything from Embedded Device Hacking, many hardware manufactures will attach associated serial ports to these sytems for testing and debugging access. It appears the same is true for this manufacture.

Initially, I went for broke, and just dropped my Bus Pirate on to see if I’d get lucky:

bus pirate

No such luck … nothing back, no luck with auto baudrate detection … nothing. So it was time to break out the scope. I’ve had an OpenScope MZ that’s been begging to cut it’s teeth on something so put the oscillicope on the TX pin and futzed with trying to get something (anything really) out of the system for an hour or so with no luck. It was about this time I noticed that my red power LED was no longer working and I couldn’t seem to deterime why (everything else seemed to have power on the board).

At this point, I turned to looking at the two jumpers on the sytem. Fortunately, there were only two paths to brute force on it, and jumping both of them resulted in actually getting some reading over the scope

scope

Huzzah! That looks like some serial data if I’ve ever seen it. Now that I’d managed to figure out my combination, I went back to the bus pirate and performed an auto baud rate analysis and it arrived at 19200. Time to fire up some fun with the live serial port monitor; the associated BP settings are:

setting value
mode UART
bps 19200
bits & parity 8, None
stop bits 1
rx polarity 1
output 2 (normal)

And finally…

terminal uart

Well, that’s neat. Pushing the button in test mode results in the following (noisy) output:

LEDs TEST
LEDs TEST DONE
WARNING LAMP TEST
ADC:0x0e18 - WARNING LAMP SENSE -- FAILED
WARNING BUZZER SOUND
ADC:0x0738 - WARNING BUZZER SENSE -- PASSED
RELAY TOGGLE
WALL SWITCH SENSE -- WALL SWITCH IS PRESSED
WALL SWITCH SENSE -- WALL SWITCH IS PRESSED
R345 interface test started.
R345 RECEIVER INTERFACE TEST -- FAILED
Z-Wave interface test started.
Z-WAVE MODULE INTERFACE TEST -- FAILED

Sadly, test mode is boring and basically just a continual loop of doing the above things. I should note that I’m not 100% certain of the accuracy of the above output - but if it’s right, it would clearly explain why my controller doesn’t work in any useful fashion. Another interesting note is the R345 RECEIVER INTERFACE listed. I’d venture a guess that this is the communication between the controller and the door open/close sensor.

So leaving the BP on and rebooting the system with out the jumpers in place, we get the following:

UART>(2)
Raw UART input
Any key to exit

Power up
App version=2.0.0
EEPROM version=4
EEPROM:TILT SN=00887c
Application firmware by Siva Kathan, Martin Mucciarone, and Mi Jin Park. Z-Wave firmware by Steve Boyle.

The “firmware by” line is only printed after holding the associated button on the board for about 10 seconds and then releasing once you get to a series of beeps that follow in a row.

I also tried putting the BP in transparent bridge mode to see if there was any way to interact with the system, but sadly, it does not appear that there is a direct method of input at this point in time. I’ve considered pulling off the associated firmware images via the ICSP headers (there’s one for PIC and one for Z-WAVE), but that will be an exercise for a later date since this damn thing keeps beeping and there’s only so much I can stand.

Malduino Elite Expansion Pins

I finally got enough time to get to actually play with my Malduino Elite which is a pretty sweet open source USB rubber duck. After dorking around with the base code as well as the Hack A Day code, I wanted to know what else I could do with those expansion pins.

Here’s the details I believe that I have correct - though I recommend you check before you burn out your own stuff, reference information pulled from the ATmega32U4:

  +-----------------------------------+
  | TOP                               |
  |    +------------------------+   O | GND
  |    | ON                     |     |
  |    |   +-+  +-+  +-+  +-+   |   O | VCC+ (5V-USB)
  |    |   | |  | |  | |  | |   |     |
  |    |   | |  | |  | |  | |   |   O | PIN09 - SCLK
  |    |   | |  | |  | |  | |   |     |
  |    |   | |  | |  | |  | |   |   O | PIN10 - MOSI
  |    |   +-+  +-+  +-+  +-+   |     |
  |    |    1    2    3    4    |   O | PIN11 - MISO
  |    |                        |     |
  |    +------------------------+   O | RESET
  |                                   |
  +-----------------------------------+

UPDATE 20170803: Jhonti has confirmed it :)

ESP8266 and SSDP

I recently picked up an Adafruit Feather HUZZAH with the intent of gluing it together with the SmartThings eco system. This presented an initial problem of needing to do SSDP based communications since that's how SmartThings likes to do LAN based communications. After digging a bit, it becamse clear I was going to have to make some modifications to the library.

Site Move

Well, the time has finally arrived that I am going to ditch Wordpress. Wordpress has just become too much of a headache anymore for just maintaining a place where I can complain about things or keep technical notes for myself and I’m no longer interested in having to fight the security beast; I’ll leave that to the young guns at github.io. My hope is that this will encourage me to get back into documenting my escapades since the last posts have always just been because I was updating Wordpress to prevent some new hack.

Building / Publishing the MS Band Light

Wyatt • • Rants

Today I’m releasing my “first” android application into the store. I say first because it’s not the first I’ve written, but it’s the first one that I’ve actually decided might actually be slightly beneficial to someone else so I put it into the store. When the app goes live, I’ll add a link and all that other fun stuff. In the mean time, you can check out details about what the app can / can’t do and the things I learned along the way here.

UPDATE1:

The link is live: https://play.google.com/store/apps/details?id=org.hackerforhire.msbandlight

Things I Learned While Building This Application

veho Muvi K-Series Research

Wyatt • • Rants

I recently picked up a veho Muvi K-Series action camera … and the application on Android didn’t work for anything. So I started down my own path.

Rather than put all the details here, I decided that I was going to primarily work out of a git repo (after the jump) in the event that I decided anything worthwhile should be developed to work with the camera over wifi. What I found was a couple of key points:

Due to the fact that the camera’s quality was kind of terrible (random blocks of video would just jump in and out) and the SD card that was shipped with it was broken and wouldn’t function in anything, I decided to send it back. But I’ve collected all of my comments, code, research, etc. into the muvi_kseries_research repository for anyone else that would like to poke, prod, or build their own application for whatever reason. Enjoy and let me know if you found anything helpful.

Python Zlib … Son I Am Disapoint

Wyatt • • Rants

Every now and then, I find myself digging through some arbitrarily compressed binary and in IDA, when you have to keep doing it over and over again, you should write a script or a loader to handle that (as any good programmer would). So I started wiring up a loader in python and thought that I’d use the zlib library to decompress things … boy was I wrong.  Not only did zlib fail to actually work correctly (because it can’t actually handle ZIP files, more on that in a moment), but the error messages were basically the same low-level messages you got out of zlib’s internal functions. Really? This is the best we can do right now? What I tried:

[wyatt@lazarus:~/Downloads]$ zip derp.zip Untitled\ drawing.png
[wyatt@lazarus:~/Downloads]$ cat Whatsnew.txt derp.zip > file.out
[wyatt@lazarus:~/Downloads]$ python
Python 2.7.3 (default, Apr 10 2013, 06:20:15)
[GCC 4.6.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
import struct
import zlib
f = open(‘file.out’,‘rb’)
c = f.read()
f.close()
offset = c.find(‘PK’)
uncmp_size = struct.unpack("<l",c[offset+22:offset+22+4])
z = zlib.decompressobj()
out = z.decompress(c[offset:],int(uncmp_size[]))
Traceback (most recent call last):
File "", line 1, in
zlib.error: Error –3 while decompressing: incorrect header check

This of course fails because zlib doesn’t actually work right with zip files (you’ll find a vauge note to such things in the ) and of course … I should have really known that ZIP isn’t actually zlib. Instead of trying to be clever, I decided to give up and be lazy. What actually worked:

import subprocess
subprocess.call([‘7z’,‘e’,‘file.out’])
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)</p>

Processing archive: file.out

Extracting Untitled drawing.png

Everything is Ok

Size: 24513
Compressed: 22290

So yes … apparently this is the best we can do with the zlib library.