CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Encrypted algorithm question
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
bulut_01



Joined: 24 Feb 2024
Posts: 281

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 6:01 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 6:53 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 12:48 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 1:18 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 3:01 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 3:19 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 4:11 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 16, 2025 5:01 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 9:10 am     Reply with quote

hmm, how big is the 'key' and the 'ID' ?
bulut_01



Joined: 24 Feb 2024
Posts: 281

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 4:21 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 4:44 pm     Reply with quote

yeesh 32 bytes for the key 'could' be AES-256. might want to start there ??
bulut_01



Joined: 24 Feb 2024
Posts: 281

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 5:44 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 5:59 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jul 17, 2025 6:10 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Jul 18, 2025 5:23 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 7 of 8

 
Jump to:  
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