Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Honeywell 2GIG-KEY2E-345 Keyfob #2584

Open
dfiore1230 opened this issue Aug 2, 2023 · 21 comments
Open

Support for Honeywell 2GIG-KEY2E-345 Keyfob #2584

dfiore1230 opened this issue Aug 2, 2023 · 21 comments
Labels
device support Request for a new/improved device decoder feedback request for more information; may be closed id 30d if not received

Comments

@dfiore1230
Copy link

I am looking to add support for the 2GIG-KEY2E-345 Keyfob

https://2gig.com/product/encrypted-4-button-keyfob-remote-key2e/

I have created the associated captures for the buttons (top left - button 1, top right -button 2, bottom left -button 3, bottom right -button 4) and a readme file and created the associated pr in the rtl_433_tests

Im not quite sure how i can create the proper support, happy to assist anyone that can offer me guidance.

thanks
Dave

@dfiore1230
Copy link
Author

PR Here - merbanan/rtl_433_tests#456

@zuckschwerdt
Copy link
Collaborator

zuckschwerdt commented Aug 2, 2023

We need to check how this relates to the other 2Gig products (https://github.com/merbanan/rtl_433/issues?q=2gig)

It looks like the known protocol (70). I.e. this will show raw data:
rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=150,l=150,r=400'
or the existing decoder with:
rtl_433 -R 70:vv

Existing decoder and notes are here: https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell.c

@dfiore1230
Copy link
Author

dfiore1230 commented Aug 2, 2023

We need to check how this relates to the other 2Gig products (https://github.com/merbanan/rtl_433/issues?q=2gig)

It looks like the known protocol (70). I.e. this will show raw data: rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=150,l=150,r=400' or the existing decoder with: rtl_433 -R 70:vv

Existing decoder and notes are here: https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell.c

Button 1:

honeywell_decode: : {72} dd fd fb e7 25 2c c2 85 1e
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {88} ff fe dd fd fb e7 25 2c c2 85 1e

Button 2:

honeywell_decode: : {72} bf c9 0e e7 25 ba a6 5f 41
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {88} ff fe bf c9 0e e7 25 ba a6 5f 41

Button 3:

honeywell_decode: : {72} 96 a2 f5 22 25 17 80 3f 8a
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {88} ff fe 96 a2 f5 22 25 17 80 3f 8a

Button 4:

honeywell_decode: : {72} 06 e2 5d e0 25 ae 56 aa d1
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {88} ff fe 06 e2 5d e0 25 ae 56 aa d1

2GIG-KEY2E-345

@dfiore1230
Copy link
Author

Apologies for my ignorance

Im not sure how to take this forward, but happy to help pull data and poke around anyway i can

@zuckschwerdt
Copy link
Collaborator

We would have expected shorter codes and more "structure" -- the codes look so very random?
Ah, yes, you said "encrypted-4-button-keyfob" :)

The codes are good though. The last 16 bit are a CRC-16, poly 0x8005 init=0x4c57 (the init might indicate that we didn't exactly match the production of the CRC).

We can add this to the decoder, but the encrypted bytes will need some serious poking to reveal anything. Either inspect the hardware for clues what that encryption might be or produce many codes and look at some screen fulls long enough ;)

@dfiore1230
Copy link
Author

Any of these help?
IMG_1446
IMG_1447
IMG_1448

@zuckschwerdt
Copy link
Collaborator

It does. The big one (U1 = "µC") labeled with "A" should be a PIC or similar and the one below (IC11) should be ROM?
Can you spell out what the lettering on those is? Maybe shine a light very flat to the chips to make the etching more visible.

@dfiore1230
Copy link
Author

IC11 - Reads AEJW

Big is a bit more difficult, including an enhanced pic for ref

IMG_1449

@dfiore1230
Copy link
Author

one more in hopes this is a bit easier to read
IMG_D6F2E8C62586-1

@zuckschwerdt
Copy link
Collaborator

zuckschwerdt commented Aug 2, 2023

Interesting the "AEJW" SOT-23-8 is actually a Radio Transmitter!
It's the MAX7044AKA+T: https://www.mouser.de/datasheet/2/609/MAX7044-3130830.pdf

@zuckschwerdt
Copy link
Collaborator

Is that something like 16UF 15323? Too hard to make out :( The hope here is to find the chip reference and see if it got AES features -- would be bad news.

@dfiore1230
Copy link
Author

Yes it seems like the following to me

16UF 15323
SL (and some sort of logo)
1905J29

@dfiore1230
Copy link
Author

dfiore1230 commented Aug 2, 2023

Googling leads me to believe that 2Gig is using 128-bit AES encryption

one of their other sensors calls it out here: https://www.alarmgrid.com/products/2gig-co8e

@zuckschwerdt
Copy link
Collaborator

zuckschwerdt commented Aug 2, 2023

We can guess the chip is a type of PIC16F15323 -- I don't think it has AES, but maybe they did it in software?
https://ww1.microchip.com/downloads/en/DeviceDoc/PIC16_L_F15313_23_Data_Sheet_40001897C.pdf

It will be very hard to reverse this encryption. But if you can grab enough codes then you could spot some cleartext, maybe a counter or something.

@dfiore1230
Copy link
Author

Can you guide me towards how to dump a ton of data on this ?

@zuckschwerdt
Copy link
Collaborator

Just rund rtl_433 -R 70:vv and capture the output. Maybe use rtl_433 -R 70:vv -F log:logfile.txt or if you also want to monitor the output rtl_433 -R 70:vv -F log:logfile.txt -F kv

@dfiore1230
Copy link
Author

dfiore1230 commented Aug 3, 2023

Seems -F log:filename is not a valid format (at least using brew install on mac)

i was able to grab this:

pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {44} 02 a4 c7 f7 a5 f0 : 00000010 10100100 11000111 11110111 10100101 1111
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {64} ff fe af d5 b3 80 85 a0
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {35} 49 8f ef 4b e0 : 01001001 10001111 11101111 01001011 111
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] { 4} 00        : 0000
pulse_slicer_manchester_zerobit(): Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater
bitbuffer:: Number of rows: 1
[00] {33} 35 3d d0 8f 80 : 00110101 00111101 11010000 10001111 1

not sure if the binary is helpful or not

@gdt gdt added the device support Request for a new/improved device decoder label Sep 26, 2023
@klohner
Copy link
Contributor

klohner commented Jan 9, 2024

BitBench

Here's a decoder that seems to get this data. There's a CRC-8005, but I can't see much info in the AES encoded data.

decoder {
    name=2GIG-KEY2E-345,
    modulation=OOK_PCM,
    short=132,
    long=132,
    reset=300,
    preamble={24}555556,
    match={24}555556,
    bits=176,
    symbol_zero={2}8,
    symbol_one={2}4,
    get=ID_128-AES?:@0:{32}:%08x,
    get=|0x25|?:@32:{8}:%02x,
    get=STATUS_128-AES?:@40:{16}:%04x,
    get=CRC-8005:@56:{16}:%04x
}

@gdt
Copy link
Collaborator

gdt commented Jun 4, 2024

What's the status and plan? Seems like someone should file a PR to add the above flex, commented to explain that there's a lot that's encrypted.

@gdt gdt added the feedback request for more information; may be closed id 30d if not received label Jun 4, 2024
@klohner
Copy link
Contributor

klohner commented Jul 19, 2024

I'd think we'd need a lot more sample data from device owners to make further progress. Hopefully the previous flex decoder would make gathering these codes easy. @dfiore1230?

Do successive key presses on the same remote send different codes? I would assume this to be so. And if so, I'd think we'd need to build up a long sequential list of those rolling variations to see if we can figure out some pattern to the encryption.

Regarding encryption, I can't find that 2GIG has specified the encryption method they use other than "eSeries Encrypted Technology" (Also see bottom of https://www.alarmgrid.com/blog/products/2gig-dw10e for an "Alarm Grid" reference to this). The previous Alarm Grid reference to "AES" may be an assumption because the (incompatible) Honeywell "SiX Series" encrypted signals on 2.4 GHz apparently use 128-bit AES.

If there is an encryption key, it seems to be static for all the 2GIG eSeries devices since pairing them with the base unit only requires the user to put the base into pairing mode and press any button on the remote for it to learn the device.

@dfiore1230
Copy link
Author

@klohner I put this unit away in a drawer and havent spent anytime looking at it. Happy to dig it out and run any tests youd like to try and get this working. Please let me know what you need and happy to help.
-Dave

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
device support Request for a new/improved device decoder feedback request for more information; may be closed id 30d if not received
Projects
None yet
Development

No branches or pull requests

4 participants