Open dfiore1230 opened 1 year ago
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
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
Apologies for my ignorance
Im not sure how to take this forward, but happy to help pull data and poke around anyway i can
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 ;)
Any of these help?
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.
IC11 - Reads AEJW
Big is a bit more difficult, including an enhanced pic for ref
one more in hopes this is a bit easier to read
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
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.
Yes it seems like the following to me
16UF 15323 SL (and some sort of logo) 1905J29
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
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.
Can you guide me towards how to dump a ton of data on this ?
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
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
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
}
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.
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.
@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
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