 |
 |
| View previous topic :: View next topic |
| Author |
Message |
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
 Posted: Sun Jul 13, 2025 5:17 am |
 |
|
| Is this is the actual data from the receiver 'RF section' If so easy to understand. |
|
 |
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Sun Jul 13, 2025 6:01 am |
|
|
| temtronic wrote: | | Is this is the actual data from the receiver 'RF section' If so easy to understand. |
Is it easy to decipher the data I shared in Excel?
Yes, it's real data. The RF module output goes into the logic analyzer, and from there, Manchester decodes it, which is the manchester decoded version of the raw data I shared.
Is it easy to decipher the password? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Sun Jul 13, 2025 7:08 am |
|
|
UP BUTON
0000000002010B000000000071E7F021020100204B
DOWN BUTON
0000000002010B000000000071E7F021020100402B
look at last 4 bytes.
UP is 204B
DN is 402B
it should be easy to decode those as 'up and 'dn'.
Every byte before is the same, so mask that off.
Simply press every key, grab last 4 bytes, make a 'table'. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Sun Jul 13, 2025 7:20 am |
|
|
| temtronic wrote: | UP BUTON
0000000002010B000000000071E7F021020100204B
DOWN BUTON
0000000002010B000000000071E7F021020100402B
look at last 4 bytes.
UP is 204B
DN is 402B
it should be easy to decode those as 'up and 'dn'.
Every byte before is the same, so mask that off.
Simply press every key, grab last 4 bytes, make a 'table'. |
I found the above button data on the net as an example.
remote control out exel datas
The issue is not this part, but to decrypt the encrypted data I shared in Excel and reveal this 42-bit data. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Sun Jul 13, 2025 7:05 pm |
|
|
You really need to go to Microchip's website and download the 'zip' file that has several application notes and tech briefs about KEELOQ(NOT all !). You'll need to 'consent' , to open up some of the files.
IF the xmit PIC does use KEELOQ, it's a SW based version .
Search their website appnotes for ALL KEELOQ info !
You'll probably spend a week just reading all the information !
Having read 3 or 4 , still not convinced you can 'break the code' and I don't KNOW that the OEM is using KEELOQ. So far KEELOQ only sends 4 bits of 'user data', which would be 4 'buttons'.
I did see a 'KEELOQ decoder for $138 CDN and several 'reports' about how HARD it is( virtually impossible'.......
As a start, press every key and see what the data is |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Mon Jul 14, 2025 2:10 am |
|
|
| temtronic wrote: | You really need to go to Microchip's website and download the 'zip' file that has several application notes and tech briefs about KEELOQ(NOT all !). You'll need to 'consent' , to open up some of the files.
IF the xmit PIC does use KEELOQ, it's a SW based version .
Search their website appnotes for ALL KEELOQ info !
You'll probably spend a week just reading all the information !
Having read 3 or 4 , still not convinced you can 'break the code' and I don't KNOW that the OEM is using KEELOQ. So far KEELOQ only sends 4 bits of 'user data', which would be 4 'buttons'.
I did see a 'KEELOQ decoder for $138 CDN and several 'reports' about how HARD it is( virtually impossible'.......
As a start, press every key and see what the data is |
The clear text I found online above doesn't use Keeloq to encrypt data. That's how I understand it. The important thing is to find out which encryption method is being used. It seems the latest encryption method here isn't Keeloq. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Mon Jul 14, 2025 5:33 am |
|
|
one thing to try, is to 'probe' the receiver's pins to see IF there's a 'test' pin. Some designers will have this 'test' pin and use it to send 'data' to confirm the device is 100% working. similar to the OBD-II and CANbus ports on vehicles, it allows access to 'inside' the chip.
from one of MC's KEELOQ papers....
KeeLoq hopping code utilises a 66-bit transmission code, of which 32 bits are encrypted. In the encrypted section alone, there are almost 4 billion possible code combinations, which would take approximately 17 years to fully scan. The transmitted passwords cannot be re-used regularly, to prevent interception and unlawful access. Once a passcode has been used, it will not be valid again until approximately 65,000 other valid codes have been used. In normal usage scenarios, it would take more than 20 years for a code to become valid again.
...
your data is 64 bits ( you show as 8 bytes )....so that suggests it isn't KEELOQ. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Mon Jul 14, 2025 5:45 am |
|
|
| temtronic wrote: | one thing to try, is to 'probe' the receiver's pins to see IF there's a 'test' pin. Some designers will have this 'test' pin and use it to send 'data' to confirm the device is 100% working. similar to the OBD-II and CANbus ports on vehicles, it allows access to 'inside' the chip.
from one of MC's KEELOQ papers....
KeeLoq hopping code utilises a 66-bit transmission code, of which 32 bits are encrypted. In the encrypted section alone, there are almost 4 billion possible code combinations, which would take approximately 17 years to fully scan. The transmitted passwords cannot be re-used regularly, to prevent interception and unlawful access. Once a passcode has been used, it will not be valid again until approximately 65,000 other valid codes have been used. In normal usage scenarios, it would take more than 20 years for a code to become valid again.
...
your data is 64 bits ( you show as 8 bytes )....so that suggests it isn't KEELOQ. |
What you said is very true, I agree. As you said, there is no pinout on the receiver, as you mentioned, canbus etc., etc. What are your suggestions on this matter? Using the remote control text here, we can find out how it is encrypted.? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Mon Jul 14, 2025 6:36 am |
|
|
you can't.well not easily.
consider the 20+- 'UP' button presses. there is NO 'pattern'. nothing to even suggest which bits are device ID, 'key' bits, or actual user data( key pressed ).
while you've grouped the data into bytes, I don't consider the data to be IN byte format. it's 64 bits of data and NO way of KNOWING which bit does what !
On one project I did 'reverse engineer', the actual bits used to control the remote devices were embedded in the data stream as odd/even pairs.Made for an interesting challenge to decode ! |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Mon Jul 14, 2025 6:51 am |
|
|
| temtronic wrote: | you can't.well not easily.
consider the 20+- 'UP' button presses. there is NO 'pattern'. nothing to even suggest which bits are device ID, 'key' bits, or actual user data( key pressed ).
while you've grouped the data into bytes, I don't consider the data to be IN byte format. it's 64 bits of data and NO way of KNOWING which bit does what !
On one project I did 'reverse engineer', the actual bits used to control the remote devices were embedded in the data stream as odd/even pairs.Made for an interesting challenge to decode ! |
Under these circumstances, what is your suggestion? It seems this damn remote control is going to give me a lot of trouble. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Mon Jul 14, 2025 8:07 am |
|
|
Look at your 'project', decide what you NEED it to do. Then scan the 'net' for a ready made solutions or easy 'hacks'.
I buy those 4chnl RF wireless relay boxes with 2 key fobs for less than $15 CDN. Great for all sorts of small projects.
If you need a handheld remote to control 'things', get a universal one, buy or build a receiver to control 'this and that'. TONS of info on the web about 'hacking' them !
or...
you could spend 1,000s of hours, drink a swimming pool full of coffee,now sport a gray beard and less hair and STILL not be ANY closer to 'decoding the data'......
I'm pretty sure this project has lost it's 'fun' status. Some times you have to say 'NO'. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Tue Jul 15, 2025 12:41 pm |
|
|
| temtronic wrote: | Look at your 'project', decide what you NEED it to do. Then scan the 'net' for a ready made solutions or easy 'hacks'.
I buy those 4chnl RF wireless relay boxes with 2 key fobs for less than $15 CDN. Great for all sorts of small projects.
If you need a handheld remote to control 'things', get a universal one, buy or build a receiver to control 'this and that'. TONS of info on the web about 'hacking' them !
or...
you could spend 1,000s of hours, drink a swimming pool full of coffee,now sport a gray beard and less hair and STILL not be ANY closer to 'decoding the data'......
I'm pretty sure this project has lost it's 'fun' status. Some times you have to say 'NO'. |
Hey, Temtronic, no need to be pessimistic. I managed to read the code by reverse engineering the receiver circuit. The EEPROM is not protected by code! That's good news! I read the EEPROM data and transferred it to Excel. I saved the remote control's 3-channel data to the receiver circuit. I think EEPROM addresses 20 and 30 are doing the encryption. I'm guessing the 0A0 address is the remote's ID information. The 0F0 address is the counter constantly changing. I'm looking forward to your feedback on this map.
note: The red rows are the same repeated data.
exel dowload link
https://www.dosyaupload.com/2I0z/eeprom_data.xlsx |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Tue Jul 15, 2025 1:28 pm |
|
|
Hard to believe someone didn't 'code protect' their PIC !!
Since you have the EXE, you can load that into MPLAB or similar and see how the program works. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 268
|
|
| Posted: Tue Jul 15, 2025 2:31 pm |
|
|
| temtronic wrote: | Hard to believe someone didn't 'code protect' their PIC !!
Since you have the EXE, you can load that into MPLAB or similar and see how the program works. |
There is code protection in the main program. There is no code protection in the eeprom data. I am asking, based on your experiences, if the data here can help us decrypt the password. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9524
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 16, 2025 5:31 am |
|
|
Still don't think it's possible.
It's not just the key you need but also the encryption algorithm.
Anyone using 'encryption' usually adds several 'layers' to really frustrate hackers.
If 20 and 30 are the 'encryption' , you don't know if the bytes are in the correct sequence. It's easy for a programmer to swap 'odds ' for 'evens' or merge good bytes with dummy bytes.
ie: 1234 is the true code.... 2143 is the odd/even data that you see. trying to decode 2143 gets you nothing as 1234 is the REAL data.
ie:5678 is the true code.... 5A6B7C8D is the 'merged' data. Again, using that, doesn't ever work as 5678 is the real data.
looking at the data though eep adrs 40 appears to be channel data, 4th byte follows channel number.
when you format the data, it'd be a lot easier to read if done byte,space,byte,space..
query. is the receiving PIC a 17LF1512 like the transmitter ? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
