Keen Electronics Key Fob

I stumbled across an old 2-buttoned key fob

The RF output is intended for 433.92 MHz but uses a SAW resonator and the exact resultant frequency flies around depending on temperature, pressure, and whether or not the tide is high on the opposite side of the planet.

The Product

It's a small keychain fob with two (2) buttons and a green LED. It features the company name Keen Electronics Ltd. (dissolved as of November 2025) with the phone number 01296 423203 on the front and a serial number sticker on the back reading 000984.

It's an old fob. The rubber buttons have become incredibly soft like chewing gum. When I press the button, it stays permanently deformed to my finger. Opening it up, it uses an NM21/23 12 VDC battery. The PCB is marked "AMTX2B-4-ER" which does yield some results but nothing especially technical. It seems like these are generic hardcoded fobs. The unit still works. The green LED appears strong but appears to flicker ever so slightly. When I shake it with the LED lighting up, I can see the actual LED strobing to the RF signal it's sending.

There are two (2) buttons which have completely lost their identity I will refer to as simply "left" or "right." The fob also indicates that pressing both buttons together is a "panic mode" which just serves as a third button.

The Radio

The fob transmits somewhere in the ballpark of 433.83 MHz in my case. The encoded data is done with a type of On-Off Keying (OOK) called Pulse Distance Modulation (PDM). The on pulses remain short at a fixed length, the distances between the pulses convey the data.

I did try my best to quantise the PHY durations but the quanta timing seems almost arbitrarily chosen. There is a wakeup pulse which is long, then a long distance, then begins consistently spaced on/off signals, then a distance different to the others. Essentially, there are 2 different on durations and 4 different gaps. The anomolous distances sorta-kinda match half distances so I crunched my findings down as such and I'm fine with that for now.

The SAW resonator means the output radio frequency flies all over the place during transmission but the most consistent pulse duration I measured was around 460 microseconds. Half that to make sense of the arbitrary timing; so 230 microseconds and pair them together when needed.

I wonder if the weird non-uniformity of the timing is a result of these fobs being manufactured as duplicators from another RF generator source and the signal was badly attentuated or something, instead of being directly programmed onto the board.

The Data

There are essentially three (3) different packets being sent; left button, right button, and both buttons pressed (for "panic" function).

Again, due to the weird timing, I have derived the following symbols:

"S" = 00111111111111111000000000000000
"0" = 1100
"1" = 1100000

Armed with this information, I can compile the left, right, and panic packets into the following stream of symbols:

S 10000111 10000011 10000000 00010101 01010000 01010100 00000000
S 10000111 10000011 10000000 00100101 01010000 01010100 00000000
S 10000111 10000011 10000000 00110101 01010000 01010100 00000000
                               ^^

Fortunately, my interpretation of the timing means it fits nicely into 7 complete bytes and we can see these are all identical other than 2 bits indicating the button.

Before we get too excited, bear in mind that the packet repeats a maximum 6 times. After the sixth packet, a final symbol "S" is appended.

Here is what a full transmission looks like:

The Protocol

A bit of digging around at some Texas Instruments ICs for PDM implementations, it seems to be common to encode this way for infrared remote controls, not necessarily with radio frequencies. Their page Infrared Remote Control Implementations (page 8) suggests what I call symbol "S" (for sync) they call the leading code which is defined by milliseconds instead of being quantised like the rest of the real data.

After a very short test, I conclude the following:

• There's no checksum
• There's no rolling code
• This is vulnerable to replay attacks
• Can be easily duplicated with a fob duplicator

To be continued

This is all I can find out from having access to a single fob. I will need access to the radio receiver and other fobs to toy with it more and figure out what bits I can change and investigate the following:

• What bits identify the fob ID?
• Are there other similarly encoded fobs with more button functionality?
• Is there perhaps a "master" ID that bypasses fob-specific IDs?
• Does the receiver support additional RF commands that the fobs don't transmit?
• Does the serial number label on the back of the fob have any relevance to the output of the code?