 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bulut_01
Joined: 24 Feb 2024
Posts: 280
|
|
 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: 280
|
|
| 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: 9536
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: 280
|
|
| 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: 9536
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: 280
|
|
| 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: 9536
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: 280
|
|
| 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. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9536
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: 280
|
|
| 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. I've added the RAW data and EEPROM data from the remote control to the Excel file. The explanations in the area highlighted in red here are approximate, not definitive. I'm attaching the remote's data diagram. The parts that will be useful to me are the remote control ID, channel information, and button information. The rest is not important.
Finally, I need to decode the remote control id + channel + button data in the 8 byte raw data. I need an algorithm for this.
remote control data diagram I found on the internet
exel download link:
https://www.dosyaupload.com/C5c/data_3.xlsx |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9536
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: 280
|
|
| 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.
note blowflish or could it be similar?
Common 64-Bit Block Size Encryption Algorithms
DES (Data Encryption Standard):
This was once the most widely used symmetric block encryption algorithm.
It has a 56-bit key length and operates on 64-bit blocks.
However, with today's computing power, a 56-bit key is no longer considered secure because it can be easily broken by brute-force attacks.
3DES (Triple DES / Triple Data Encryption Algorithm - TDEA):
This is a variant that applies the DES algorithm three times to address the vulnerability of DES.
It typically has key lengths of 112 or 168 bits (using two or three different DES keys), but the block size remains 64 bits.
It is slower than AES and still somewhat susceptible to birthday attacks due to its 64-bit block size, but it is still used in some older systems or for compatibility reasons (e.g., in financial applications).
Blowfish:
A block cipher algorithm designed by Bruce Schneier.
It has a 64-bit block size and supports key sizes ranging from 32 to 448 bits.
It was popular for a time due to its fast performance and free availability.
It can still be seen in some protocols today (e.g., older OpenVPN versions), but it is not considered as secure as AES due to its 64-bit block size.
IDEA (International Data Encryption Algorithm):
A block cipher algorithm with a 64-bit block size and a 128-bit key length.
It was once used in popular software such as PGP (Pretty Good Privacy). |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9536
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: 280
|
|
| 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 15 years ago? You should help me, temtronic. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9536
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
