Analysis of a 2005 Nissan Altima Remote Keyfob

William Floyd — Fri, 08 Jan 2021 00:00:00 +0000

I got my first car a few months ago - a decidedly beat up North American 2005 Nissan Altima. It came with a remote keyfob, but something was shorting internally, and the battery would drain within a matter of hours. I ordered a two-pack of aftermarket fobs from Amazon, paired them no problem, and that was that.

After a while though, I got to thinking, how might I connect my car to my Home Assistant system? I am reluctant to tap into the CAN bus directly, so instead I am going to investigate utilizing the same method as my remote fob. Specifically, I want to program my own “fob” using an Arduino and a RF transmitter (spoiler: I cannot, at least for now).

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 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 seem 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, but the main one was this:

None of the text appears 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). Looking at their product lines, it becomes clear that the original fob uses the HCS361 chip. My aftermarket chips must be using a knockoff or unmarked version of this.

Hurray, we know what chip we’re up against, what algorithm it uses, and how to get the information of an existing fob. What we do not know is how to program our own chip (or software equivalent). This is where things get a lot more involved than I have the expertise to do.

What would be required would be the Nissan manufacturer code for this series of fobs. Try as I might, these do not seem to have leaked online, nor have any other manufacturers as far as I can tell. Speculating, perhaps those that have access to these codes either keep them to themselves for ethical reasons, or because there is financial incentive to keeping this information private. Clearly there are Chinese manufacturers who know what this key is, because it would have been required in order to program this fob.

Key Problem

So how might I find this manufacturer key? Curiously, I cannot even find reference to Nissan ever using KeeLoq, so that does not bode well. Trawling the recent NA Nissan git leak doesn’t reveal anything related to such a key. The consensus seems to be that a power analysis of the receiver is required to determine the manufacturer key. While apparently not difficult for the researchers, it is beyond my means at this stage. I am certainly not the first one to try this.

The way forward would seem to buy a spare ECU for my vehicle and to use a ChipWhisperer and attempt to learn how to do power analysis. I don’t have the time or resources (or frankly the need) to do that for now, so I think this is where my journey ends. I’ll update this if ever I can get my hands on the manufacturer key and do anything more with this.

DIY 'Smart' Coffee Maker

William Floyd — Sun, 05 Jul 2020 00:00:00 +0000

I have recently (last couple months) been getting into home automation, specifically using Home Assistant. I also wanted to get a coffee maker that used K-Cups. Thus the goal was born - to get a coffee maker working with Home Assistant, such that I could automate it to fit my morning routine.

I first searched for new coffee makers, looking to see what the easiest ones would be to hack into and automate. I got so far as adding a sleek new brand name model to my Amazon cart, but thankfully reason and frugality prevailed! Instead, I opted to swing by the local Goodwill the next day, to see what secondhand options might be available. As luck would have it, I found a no-frills, single button coffee maker for the princely sum of $4, and I was on my merry way.

Later that evening, opening the black box up (thankfully I had the correct triangular screwdriver head), I found very easily hackable innards.

The control board (front, back) is very simple - two buttons in parallel, an LED, and a couple resistors. I’m not quite sure what the logic is upstream (it un/latches on each press), but the buttons short to ground, and this is something I can work with. The control board has wires for ground, signal, and 5V, in that order.

The ordeal of hacking into the thing, and my missteps trying to do so, is rather boring really, but it produced this:

The brains I added was a Wemos D1 Mini (thanks, Aliexpress!), with a 3.3V<->5V converter between to sense when the coffee maker is on, and also turn on a mosfet to short the button to ground. I initially had issues with the coffee maker turning on whenever I plugged the D1 Mini in, but a pulldown resistor solved this.

I also opted for an external USB plug - this allows me to possibly reflash this without opening the enclosure, and also meant I did not need to splice into the mains line inside, which I was reluctant to do.

I initially flashed and programmed the coffee maker with Tasmota, but almost immediately opted to use ESPHome instead. I like Tasmota and ESPHome, I was just able to get more fine control of the setup using ESPHome in this instance, especially concerning the button logic.

The (important) code is as follows:

binary_sensor:
  - platform: gpio
    device_class: power
    internal: true
    id: power_on
    pin: D2
    
switch:
  - platform: gpio
    pin: D1
    id: relay
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "Coffee Maker"
    icon: "mdi:coffee-maker"
    lambda: |-
      if (id(power_on).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay
    turn_off_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay

The beauty of the way in which I can detect signals and simulate a button press is that ESPHome senses when I use the physical button, and updates accordingly. I can use the coffee maker absolutely as normal, the ‘Smart’ part of it is optional.

The rest of my setup using this coffee maker is somewhat outside the scope of this post, but it includes using Tasker on my phone to run a ‘Wakeup’ automation on Home Assistant, which will - along with turning on my bed-head lamp, and switching my monitor on before putting it to sleep - check if I turned on a ‘Morning Coffee’ user input. If I remembered to prep my coffee the night before, and turned on the switch, I will wake up to a hot cup of coffee (or, the sound of a coffee-in-progress). I can also command Alexa and Google Assistant to do my bidding and make me a coffee. At least someone does what I want…

Truly, we are living in the future.