 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bulut_01
Joined: 24 Feb 2024
Posts: 271
|
|
 Posted: Wed Jul 16, 2025 6:01 am |
 |
|
| temtronic wrote: | 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 ? |
yes pic 18f26k22 |
|
 |
bulut_01
Joined: 24 Feb 2024
Posts: 271
|
|
| Posted: Wed Jul 16, 2025 6:53 am |
|
|
| Reading eeprom data gave us the advantage of knowing the real form of the incoming data, such as the remote control ID, channel information, etc. When the incoming data is decoded, the data in the template will appear. Without this information, we did not know what kind of data was coming |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9528
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 16, 2025 12:48 pm |
|
|
It'd be easier to decode if you put a space after each byte of data.
ee adr 30.... is 'interesting' when you put in the spaces !
ee adr 40.. ,4th byte appears to be the channel number
ee adr fo... , might be a check sum ?
a better ? format would be to have the ee dat horizontally( with a space) and 'key presses' vertically. that way it's easier to see how eep data changes when keys are pressed. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 271
|
|
| Posted: Wed Jul 16, 2025 1:18 pm |
|
|
| temtronic wrote: | It'd be easier to decode if you put a space after each byte of data.
ee adr 30.... is 'interesting' when you put in the spaces !
ee adr 40.. ,4th byte appears to be the channel number
ee adr fo... , might be a check sum ?
a better ? format would be to have the ee dat horizontally( with a space) and 'key presses' vertically. that way it's easier to see how eep data changes when keys are pressed. |
In light of the new information, I haven't been able to form a decipherment of the 8-byte encrypted data. I'm wondering if the information in the eeprom gives us any hope. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9528
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 16, 2025 3:01 pm |
|
|
well ,if you had to 'program' the remote to the receiver, then the remote's ID info should be stored in the EEProm data.
As well the 'key', if used , might be there..... |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 271
|
|
| Posted: Wed Jul 16, 2025 3:19 pm |
|
|
| temtronic wrote: | well ,if you had to 'program' the remote to the receiver, then the remote's ID info should be stored in the EEProm data.
As well the 'key', if used , might be there..... |
Yes, I mentioned that too. EEPROM addresses 20 and 30 could be the key. Address 0A0 could be the remote control ID. How can I use an algorithm to process these 8 bytes of data to obtain the ID and channel information? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9528
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 16, 2025 4:11 pm |
|
|
get a space between the bytes of data. Then you'll may see a 'pattern', based on chnl/key pressed. It gets EASY to see when laid out this fashion.
IE. If the controller turns on a relay with 1st key press, then off for the second key press, I'd expect to see a byte change for 'channel' and another byte for 'on vs off'. Now for on/off this could happen at the bit level.
A lot depends on how complex the remote is ( number of buttons, features, etc.) and who programmed the system.
On my remote energy control system, EVERYTHING is done at the bit level as 5 decades ago we used Assembler and memory was expensive.
On a later 'control panel', I got lazy, used BASIC ( prePIC ! ) and used bytes not bits, it was easier and faster to code. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 271
|
|
| Posted: Wed Jul 16, 2025 5:01 pm |
|
|
| temtronic wrote: | get a space between the bytes of data. Then you'll may see a 'pattern', based on chnl/key pressed. It gets EASY to see when laid out this fashion.
IE. If the controller turns on a relay with 1st key press, then off for the second key press, I'd expect to see a byte change for 'channel' and another byte for 'on vs off'. Now for on/off this could happen at the bit level.
A lot depends on how complex the remote is ( number of buttons, features, etc.) and who programmed the system.
On my remote energy control system, EVERYTHING is done at the bit level as 5 decades ago we used Assembler and memory was expensive.
On a later 'control panel', I got lazy, used BASIC ( prePIC ! ) and used bytes not bits, it was easier and faster to code. |
I understand everything you're saying. What algorithm should I use to decrypt the encrypted raw data coming from the remote control? We know the remote's ID, channel, and key information from the EEPROM information. |
|
|
|
|
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
