The Hardware

While I may analyze the original fob at some point, for the time being I shall work from the aftermarket fob. Opening the casing reveals a rather simple circuit (front, back) - battery contacts, four buttons, a smattering of passives, an oscillator, the main control chip, 8 test points, and an antenna trace running around the perimeter of the PCB.

Rather unhelpfully, the control IC is unmarked, so either I'll need to wait until I can look at the original fob to find any clues, or try to find what I need online.

As a note, it should be easy enough for me to replace the buttons with an electrical solution controlled by an ESP8266 or similar - I may end up doing this some day. For the time being, however, I have nothing to glean from the hardware in my fob.

Research

A quick look at the Amazon listing for my fob already tells me what models of fobs it replaces: KBRASTU15, CWTWB1U758, and CWTWB1U821. Matching other listings, my specific model is the KBRASTU15. This is actually an FCC ID, so that's my next lead.

This fccid.io listing is a rather useful, providing original FCC images and documents. Unfortunately, the internal images are low enough resolution to prevent reading the IC silkscreen. Interestingly, the aftermarket fob has a small fraction of the part count of the original fob, while still functioning perfectly. The most useful available document is the Technical Description. This is where we start to get somewhere.

In essence, the fob emits a wakeup sequence 'A', followed by sequence 'B' repeated as long as the button is pressed. The structure of these sequences is also described - sufficient to say, it uses a rolling code system. Importantly for my analysis, the encoding method of the signal is given (though interestingly their diagram annotations seems to be incorrect).

With this information in hand, I ordered a cheap RTL-SDR (a Nooelec NESDR Mini 2+).

SDR Analysis

The radio, being a North American model, operates at 315MHz. Using Universal Radio Hacker, I began capturing examples of locking and unlocking signals. Using the software is outside the scope of this post, but I found some YouTube videos by the software author that proved to be useful - it's not hard to learn to use.

Ultimately, I ended up trimming down 4 'B' sequences each of locking and unlocking (that is, different presses, not repeats during the same press). I also opted not to include the preamble and header of these 'B' sequences, as these are the same for any fob and include no actual information.

The resulting signals varied in length and followed no apparent repeating format - this is where the encoding scheme described in the FCC documents comes in. Fortunately, URH allows specifying and chaining encoding schemes, as well as calling external software to decode the data. As I am not dealing with a large amount of data, I wrote a quick bash script to decode the data:

#!/bin/bash

lc=''

while IFS= read -r -n1 c; do

        if [ "${c}" == '' ]; then
                break
        fi

        if [ "${c}" != "${lc}" ] && [ "${lc}" != '' ]; then
                echo -n "${lc}" # Deal with the last character
                lc="${c}"
        elif [ "${lc}" == "${c}" ]; then
                if [ "${c}" == '0' ]; then
                        echo -n '1'
                else
                        echo -n '0'
                fi
                lc=''
        elif [ "${lc}" == '' ]; then
                lc="${c}"
        fi

done <<<"${1}"

exit

This does the trick, and all the data has a uniform length of 67 bits. While the document specifies 66 bits, perhaps the aftermarket keyfob adds an extra bit. In any case, this extra trailing bit is always 0.

Finally we have something like this:

The top four entries are when locking, the bottom four when unlocking. The highlighted segments from left to right, as per the technical document, are:

encrypt
serial number
function code
verify code

It can easily be seen how the intent of the button press is not encrypted, but is part of the function code near the end. Also, the serial is correctly defined, as it does not change at any point. I am not sure what the verify bits are present for - perhaps if an error occurs the encoding scheme would result in a non 0 result (though this is purely speculation).

What we know now is that the keyfob does indeed use a rolling code algorithm, though not which one (web searches do not seem to specify).

More Research

I do not have access to the original keyfob at this time, so some image searching may be in order. Several leads appeared:

None of them appear especially legible, so the first thing I can do is compare the logo on the OEM fob to existing rolling code chip manufacturers. As it happens, Microchip is the company in question, producing the widely documented Keeloq product line ((leaked spec sheet)[http://keeloq.narod.ru/decryption.pdf]). Looking at their product lines, it becomes clear that the original fob used the HCS361 chip. My aftermarket chips must be using a knockoff or unmarked version of this.

6.7 KiB Raw Blame History

The Hardware

Research

SDR Analysis

More Research

6.7 KiB

Raw Blame History