Return to Answer

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

BTW, is reverse engineering really needed or is gadget a known one? You have not provided the name/type/picture

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

Edit 220212

Looking over the dataset again, I think it is possible just to do some assumptions for the algorithm behind, some of them can be tested, some not, just because of lack of data.

1. I agree that remoteID is nibble#1, maybe hardcoded or as per DIP switch in remote
2. nibble#5 is switchID as you said, and I think its generated by algorithm. All sockets need to know independent from remote what switchID the master is, depending on send remoteID, specifically a "2" could be code for socket "D" or master. Assumption could be, that switchID for master is "remoteID ^ F" and "remoteID ^ 9" depending on bit1 at remoteIDs is set or not. The same works similar with bit2 set or not set for remoteID. Several other methods are possible, but cannot be verified due to lack of data with other remoteIDs. Maybe there is also a method that works for all remoteID, without any "if-clause".
3. I think, for actionCode there is not any roting code needed for proper work. When "A"-On is pressed, then pressing 3 other buttons, and again "A"-on it will send the same message again. For me the 4 options seems just obfuscation. At least for "2022" remote it's worth to try with only one code for "On" and "off" each. And if that is true, why not also for "2019" remote? This theory can be easily verified: switch on "A", press 3 times a button and remote is far away from socket, then again "A" off. When this repeated key is accepted, no rotating code is needed. However, this doesn't give any clue at the moment how action code is generated.

Edit 220213

In some articles on this remote I have found my assumption confirmed that no rolling code is needed to switch on/off. A single action code per remoteID should suffice. However the method to generate the action code is unknown, since almost 10 years now. Best information seems to be a semi-encryption method using table substitution here, "AnBan". Sometimes it is called Quigg GT-1000 protocol, details also unknown. As it comes to the point that a 14Pin chip inside generates the codes all discussions ends without better result. Maybe someone else being more clever will find out the details.

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

Edit 220212

Looking over the dataset again, I think it is possible just to do some assumptions for the algorithm behind, some of them can be tested, some not, just because of lack of data.

1. I agree that remoteID is nibble#1, maybe hardcoded or as per DIP switch in remote
2. nibble#5 is switchID as you said, and I think its generated by algorithm. All sockets need to know independent from remote what switchID the master is, depending on send remoteID, specifically a "2" could be code for socket "D" or master. Assumption could be, that switchID for master is "remoteID ^ F" and "remoteID ^ 9" depending on bit1 at remoteIDs is set or not. The same works similar with bit2 set or not set for remoteID. Several other methods are possible, but cannot be verified due to lack of data with other remoteIDs. Maybe there is also a method that works for all remoteID, without any "if-clause".
3. I think, for actionCode there is not any roting code needed for proper work. When "A"-On is pressed, then pressing 3 other buttons, and again "A"-on it will send the same message again. For me the 4 options seems just obfuscation. At least for "2022" remote it's worth to try with only one code for "On" and "off" each. And if that is true, why not also for "2019" remote? This theory can be easily verified: switch on "A", press 3 times a button and remote is far away from socket, then again "A" off. When this repeated key is accepted, no rotating code is needed. However, this doesn't give any clue at the moment how action code is generated.

Edit 220213

In some articles on this remote I have found my assumption confirmed that no rolling code is needed to switch on/off. A single action code per remoteID should suffice. However the method to generate the action code is unknown, since almost 10 years now. Best information seems to be a semi-encryption method using table substitution here, "AnBan". Sometimes it is called Quigg GT-1000 protocol, details also unknown. As it comes to the point that a 14Pin chip inside generates the codes all discussions ends without better result. Maybe someone else being more clever will find out the details.

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

BTW, is reverse engineering really needed or is gadget a known one? You have not provided the name/type/picture

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

Edit 220212

Looking over the dataset again, I think it is possible just to do some assumptions for the algorithm behind, some of them can be tested, some not, just because of lack of data.

1. I agree that remoteID is nibble#1, maybe hardcoded or as per DIP switch in remote
2. nibble#5 is switchID as you said, and I think its generated by algorithm. All sockets need to know independent from remote what switchID the master is, depending on send remoteID, specifically a "2" could be code for socket "D" or master. Assumption could be, that switchID for master is "remoteID ^ F" and "remoteID ^ 9" depending on bit1 at remoteIDs is set or not. The same works similar with bit2 set or not set for remoteID. Several other methods are possible, but cannot be verified due to lack of data with other remoteIDs. Maybe there is also a method that works for all remoteID, without any "if-clause".
3. I think, for actionCode there is not any roting code needed for proper work. When "A"-On is pressed, then pressing 3 other buttons, and again "A"-on it will send the same message again. For me the 4 options seems just obfuscation. At least for "2022" remote it's worth to try with only one code for "On" and "off" each. And if that is true, why not also for "2019" remote? This theory can be easily verified: switch on "A", press 3 times a button and remote is far away from socket, then again "A" off. When this repeated key is accepted, no rotating code is needed. However, this doesn't give any clue at the moment how action code is generated.

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

BTW, is reverse engineering really needed or is gadget a known one? You have not provided the name/type/picture

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

Edit 220212

Looking over the dataset again, I think it is possible just to do some assumptions for the algorithm behind, some of them can be tested, some not, just because of lack of data.

1. I agree that remoteID is nibble#1, maybe hardcoded or as per DIP switch in remote
2. nibble#5 is switchID as you said, and I think its generated by algorithm. All sockets need to know independent from remote what switchID the master is, depending on send remoteID, specifically a "2" could be code for socket "D" or master. Assumption could be, that switchID for master is "remoteID ^ F" and "remoteID ^ 9" depending on bit1 at remoteIDs is set or not. The same works similar with bit2 set or not set for remoteID. Several other methods are possible, but cannot be verified due to lack of data with other remoteIDs. Maybe there is also a method that works for all remoteID, without any "if-clause".
3. I think, for actionCode there is not any roting code needed for proper work. When "A"-On is pressed, then pressing 3 other buttons, and again "A"-on it will send the same message again. For me the 4 options seems just obfuscation. At least for "2022" remote it's worth to try with only one code for "On" and "off" each. And if that is true, why not also for "2019" remote? This theory can be easily verified: switch on "A", press 3 times a button and remote is far away from socket, then again "A" off. When this repeated key is accepted, no rotating code is needed. However, this doesn't give any clue at the moment how action code is generated.

Edit 220213

In some articles on this remote I have found my assumption confirmed that no rolling code is needed to switch on/off. A single action code per remoteID should suffice. However the method to generate the action code is unknown, since almost 10 years now. Best information seems to be a semi-encryption method using table substitution here, "AnBan". Sometimes it is called Quigg GT-1000 protocol, details also unknown. As it comes to the point that a 14Pin chip inside generates the codes all discussions ends without better result. Maybe someone else being more clever will find out the details.

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

BTW, is reverse engineering really needed or is gadget a known one? You have not provided the name/type/picture

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

is the next step in a sequence of on action like

f756
7441
d9c5
e3aa

the same, also when another action comes in between? Did you tried if action code is generated in some way by remote id, button id, 1-4 (0-3)? I think in learning mode it needs only to learn remote id, and other are known by algorithm used.

BTW, is reverse engineering really needed or is gadget a known one? You have not provided the name/type/picture

Edit 220205

so there is a counter# 0-3 to consider. Just an idea to work out: you have input remote id, button id, counter# and action will be calculated by CRC-16 (because of variability of codes) or whatever. To be clear: I'm not expert in that matter, just sharing my ideas as I'm working on similar issue.

Edit 220212

Looking over the dataset again, I think it is possible just to do some assumptions for the algorithm behind, some of them can be tested, some not, just because of lack of data.

1. I agree that remoteID is nibble#1, maybe hardcoded or as per DIP switch in remote
2. nibble#5 is switchID as you said, and I think its generated by algorithm. All sockets need to know independent from remote what switchID the master is, depending on send remoteID, specifically a "2" could be code for socket "D" or master. Assumption could be, that switchID for master is "remoteID ^ F" and "remoteID ^ 9" depending on bit1 at remoteIDs is set or not. The same works similar with bit2 set or not set for remoteID. Several other methods are possible, but cannot be verified due to lack of data with other remoteIDs. Maybe there is also a method that works for all remoteID, without any "if-clause".
3. I think, for actionCode there is not any roting code needed for proper work. When "A"-On is pressed, then pressing 3 other buttons, and again "A"-on it will send the same message again. For me the 4 options seems just obfuscation. At least for "2022" remote it's worth to try with only one code for "On" and "off" each. And if that is true, why not also for "2019" remote? This theory can be easily verified: switch on "A", press 3 times a button and remote is far away from socket, then again "A" off. When this repeated key is accepted, no rotating code is needed. However, this doesn't give any clue at the moment how action code is generated.