| View previous topic :: View next topic |
| Author |
Message |
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
 Posted: Tue Jul 01, 2025 3:11 pm |
 |
|
| temtronic wrote: | They could have used ANYTHING for the encryption !
All they've said is 64 bits. Could be simple or complex.
64 bits is 4 words, 8 bytes, 16 nybbles so 1 of 1,000s of possible encryptions may have been used. While it 'might' be KEYLOQ, it could just as easlily be some custom, inhouse software.
There is no way to know just by 'looking at the data stream'.
You might search the web since you know the remote control make and model. Perhaps someone else has done it ? Just because they used a PIC does NOT mean they used KEYLOQ.
One of the 'classic DINOSAUR' ways to encrypt data years ago was to save the data as a Wordperfect text document, then have Wordperfect translate into another language, save that, then use that file as the 'real' data. Anyone looking at the data couldn't figure out what it was ! You had to open the file in Wordperfect and translate into the original language.
Some times I miss the 'good old days' !! |
Thank you very much for your help, you are treating me like a friend. I need to think about this a little bit. I can compare hundreds of data in Excel and maybe get a clue. This damn remote control really pisses me off. |
|
 |
PrinceNai
Joined: 31 Oct 2016
Posts: 534
Location: Montenegro
|
|
| Posted: Tue Jul 01, 2025 3:49 pm |
|
|
| Quote: | | I need to control the load with the remote control data I shared above |
Why? Feel free to tell me it is none of my business, but what are you trying to control and what are those buttons supposed to do? Why can this be controlled only with those codes? From the outside it seems easier to reverse engineer the receiving part so it accepts the codes you decide it will accept.
I'd like to see you prove me wrong, but there is realistically a very small chance to break the code. The reason is simple. The whole algorithm was developed for one sole reason. To prevent people from breaking it. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9516
Location: Greensville,Ontario
|
|
| Posted: Tue Jul 01, 2025 4:01 pm |
|
|
aww.. but it's soooo much 'fun' staying up til 3 in the morning for 3-4 weeks, banging your head, saying THIS time it should work........
..then of course, it doesn't.
Not saying it can't be done BUT ... spend 3-4 days just surfing the web. A unit that old, odds are someone , somewhere might have hacked it.maybe....
Weird, sad thing is I'm thinking I'd like to replace a 1.44 FDD with a small flashdrive..how NUTS is that !!! |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Tue Jul 01, 2025 4:35 pm |
|
|
| PrinceNai wrote: | | Quote: | | I need to control the load with the remote control data I shared above |
Why? Feel free to tell me it is none of my business, but what are you trying to control and what are those buttons supposed to do? Why can this be controlled only with those codes? From the outside it seems easier to reverse engineer the receiving part so it accepts the codes you decide it will accept.
I'd like to see you prove me wrong, but there is realistically a very small chance to break the code. The reason is simple. The whole algorithm was developed for one sole reason. To prevent people from breaking it. |
There is actually no very valid reason. My passion is to break this remote control and make it a receiver unit and turn a light on and off or run an engine. My aim is the id and button data on the remote control and the rest is unnecessary data I have no business. I have researched on the net. Everyone is stuck at the point where they cannot decipher the 64 bit encrypted text. Nobody has been able to do this, maybe we could have done it and would have been the first. Or maybe there is someone who hacked this, or they did not share it, or there really is no one who hacked it. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Tue Jul 01, 2025 4:36 pm |
|
|
| temtronic wrote: | aww.. but it's soooo much 'fun' staying up til 3 in the morning for 3-4 weeks, banging your head, saying THIS time it should work........
..then of course, it doesn't.
Not saying it can't be done BUT ... spend 3-4 days just surfing the web. A unit that old, odds are someone , somewhere might have hacked it.maybe....
Weird, sad thing is I'm thinking I'd like to replace a 1.44 FDD with a small flashdrive..how NUTS is that !!! |
I agree with you, let's do something crazy and go through this 64 bit code. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9516
Location: Greensville,Ontario
|
|
| Posted: Tue Jul 01, 2025 5:46 pm |
|
|
| maybe read microchips an663 ? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Thu Jul 03, 2025 12:08 pm |
|
|
| temtronic wrote: | | maybe read microchips an663 ? |
This document is of no use to me. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9516
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 09, 2025 5:44 am |
|
|
Well if you're convinced the OEM did use KEELOQ, it's one of dozens of ANs that Microchip has published and cold be the beginning of a very,very long reading session to understand what you will have to do to 'break the code'.
As we've said before you have TWO problems. One, you don't KNOW which 'key hopping ' algorithm was used and two, what 'key' has been used.
To add more 'fun' the OEM cold have 'rearranged' the data BEFORE codehopping was done. That will make the task virtually impossible.
Odds are very good you'll never decode it. Did see ads for decoders on Amazon, and of course MC have a chip as well. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Wed Jul 09, 2025 7:19 am |
|
|
| Temtronic, I will evaluate all of them. There is no system in the world that is not broken. The important thing is knowing how to break it. I have different projects in my mind right now. I am writing codes with the keeloq algorithm. We can overcome this problem too. We should not be pessimistic. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9516
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 09, 2025 12:03 pm |
|
|
| curious, HOW do you KNOW it uses KELOQ ? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Thu Jul 10, 2025 6:10 am |
|
|
| temtronic wrote: | | curious, HOW do you KNOW it uses KELOQ ? |
The use of microchip, the use of Manchester and 64 bit encryption remind me of Keeloq. This is my hunch, maybe I'm wrong. When I examine this issue in depth, the white sheep and the black sheep will come out. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9516
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 10, 2025 8:40 am |
|
|
'hunch' not 'fact'...
Other micros can use 'KEELOQ' programs, modified for their instruction sets...
Manchester isn't part of the KEELOQ requirement, that I know of....
I've got 64 bit encryption that doesn't use 'KEELOQ'.... |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Thu Jul 10, 2025 9:53 am |
|
|
| temtronic wrote: | 'hunch' not 'fact'...
Other micros can use 'KEELOQ' programs, modified for their instruction sets...
Manchester isn't part of the KEELOQ requirement, that I know of....
I've got 64 bit encryption that doesn't use 'KEELOQ'.... |
Everything you said is true. Mine is just a prediction. There could be a different encryption method. The important thing is to find it. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
| Posted: Fri Jul 11, 2025 12:08 pm |
|
|
| I found a clue: When the same data is sent every time, the data doesn't change when read from the RF section. This means it's not encrypted with a dynamic key. I think if a variable key was always used, the RF section would have to be read differently each time a fixed data is sent. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 259
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
