Encrypted algorithm question

[bulut_01]

[temtronic]

I'd 'cheat'... have the received data sent to PC in a terminal program in CSV format. Once 65,000 'key 3 presses' have been received, import that data file into excel. It should be easy for excel to locate the two identical keyfob presses. Repeat for say key 2 pressed. Compare the 4 line ( 2 for key 3, 2 for key 2 ). only 2 bits should have changed.

This does presuppose that the OEM has used KEYLOQ in his program !

That's the main problem , you have to KNOW what the 'sender' did to unlock his 'key'.

[newguy]

I'm sorry. Just. No.

Encryption is used because it is quite secure. Even if the rolling code/nonce/salt rolled over every 65,536 attempts, you'd still need to *store* all 65,536 combinations *for every button press combination* the fob is capable of generating. At, what, 40+ characters per, that's a huge amount of data. How are you going to quickly search this huge database for the proper string, then act upon it without the delay being noticeable on an 8 bit PIC16F? Even for an 18F this would be a daunting task.

bulut_01: what TTelmah was telling you to do was to implement an encryption/decryption algorithm in whatever your code of choice is. For example, have a look at online versions, for example https://www.devglan.com/online-tools/text-encryption-decryption.

[bulut_01]

[temtronic]

We can't !

1st you don't KNOW what 'code hopping' algorithm was used
2nd you don't KNOW what the 'key' is.

Think of the 1st , like a blank key for the lock on your house. There's 100s of shapes and styles of cylinders for door locks, each needs a specific shaped key to fit it. You can't jam a Yale key into a Weiser lock.

2nd, the actual key has to have the correct number and cuts to fit the internal pins of the cylinder. house keys can have 6-7-8 'cuts' to align the pins ,allowing the cylinder to rotate , to unlock the door. A key with 8 'cuts' will NOT work in a 6 cut cylinder.

Your basic problem is two unknowns. The algorithm AND the key.

Now IF you could actually read the keyfob PIC, you might be able to reverse engineer the code BUT I suspect the PIC has been 'code protected' to prevent this as an obvious security precaution.

[Ttelmah]

The point is you have to have a clue.

You have to know what the source data is for one or more sequences.
Otherwise you can never tell that you have cracked it.
This was the point with Enigma. The Germans used some place names
for locations that were known, or sent multiple transmissions without
shifting the key used. They also used standard formats for some tranmissions,
with a standard intro header, so you could then try different keys till you
saw something recognidsed. If you have no clue to what the data is, you
can never crack it, since you could have the right key and still not know it.

People talking about 65536, are assuming a 16bit key. If it is Keeloq, not
the case. This is why the code needs to be efficiently written. Even an
extra nSec in each loop would add hours to doing a brute force solution.
Hundreds of trillions of calculations. However by no means undoable,
Given a modern PC in some cases can top 100GIPS, trying every solution
becomes quite doable. But not something you can do with a spreadsheet.

[temtronic]

Also...
just because the micro is a PIC, does NOT mean that KEYLOQ is used for the 'hopping' code !!!

There's a LOT of old Ford 'hotrods' that have Chevy engines in them !!!

[bulut_01]

Actually there is a misunderstanding, it is encrypted and sent with 64 bit keeloq. I am asking because I do not know how many different forms of this keeloq 64 bit encryption are there.

[gaugeguy]

The misunderstanding is you think it is trivial to break an encryption code meant to be secure.

[bulut_01]

[PrinceNai]

As I asked and said some time ago. Why is it an imperative that this "load" has to be switched on using exactly this keyfob? Does it need such security? Why don't you simply buy a new one? You can get a fob/receiver combo, encrypted somewhat, for 2€ from China. 15£ Keeloq style from England. Even if your time is worth 1c per hour (I'm not implying it is), you could probably buy a remote together with a new load on time saving alone, not to even mention escaping headaches.

[bulut_01]

[temtronic]

Your only hope is to contact the maker of the unit and see IF they will tell you what 'code hopping' algorithm they used and the key for it.

I really doubt they will.

I've reverse engineered many products in the past, but there's no way I can even begin to do what you want as the key is not known but more importantly neither is the 'hopping' algorithm.

Even then, knowing BOTH parts, the actual data could be encrypted. I did that 4 decades ago for an ultra high security communications protocol. made it hackerproof !

[bulut_01]

[temtronic]

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' !!