 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bulut_01
Joined: 24 Feb 2024
Posts: 281
|
|
 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: 281
|
|
| 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: 9538
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: 281
|
|
| 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: 9538
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: 281
|
|
| 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.
Last edited by bulut_01 on Sun Jul 20, 2025 6:11 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9538
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: 281
|
|
| 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.
Last edited by bulut_01 on Sun Jul 20, 2025 6:12 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9538
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 17, 2025 9:10 am |
|
|
| hmm, how big is the 'key' and the 'ID' ? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 281
|
|
| Posted: Thu Jul 17, 2025 4:21 pm |
|
|
| temtronic wrote: | | hmm, how big is the 'key' and the 'ID' ? |
I've reorganized the Excel file for clarity.
Last edited by bulut_01 on Sun Jul 20, 2025 6:12 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9538
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 17, 2025 4:44 pm |
|
|
| yeesh 32 bytes for the key 'could' be AES-256. might want to start there ?? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 281
|
|
| Posted: Thu Jul 17, 2025 5:44 pm |
|
|
| temtronic wrote: | | yeesh 32 bytes for the key 'could' be AES-256. might want to start there ?? |
Our tariff does not fit AES 256.
Last edited by bulut_01 on Sun Jul 20, 2025 6:13 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9538
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 17, 2025 5:59 pm |
|
|
| you have to consider the age of the device ! if it's 10 years old, consider codes used 10-15 years ago. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 281
|
|
| Posted: Thu Jul 17, 2025 6:10 pm |
|
|
| temtronic wrote: | | you have to consider the age of the device ! if it's 10 years old, consider codes used 10-15 years ago. |
Which ones were used for 64-bit encryption
Last edited by bulut_01 on Sun Jul 20, 2025 6:13 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9538
Location: Greensville,Ontario
|
|
| Posted: Fri Jul 18, 2025 5:23 am |
|
|
Perhaps you can 'ask somewhere' on the Internet if anyone knows about the 'transmitter/ receiver' you have ? If you post the make/model of the unit, maybe Google can supply a few 'hits'. If you get really lucky, the programmer who cut the code might see your request and respond.I'm finding lot of sites on Facebook on old computers / languages, rather nice to see others like me !
Your new excel sheet shows a 32 byte 'key' but you talk about 64 bits( 8 bytes). so again huge problem is not knowing what the key actually is. Until you do, it'll be a losing battle. Also remember even knowing what the key is, the algorithm, could have been made ' in house', a custom piece of code. In which case highly unlikely you'll be able to decode it. |
|
|
|
|
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
