Encrypted algorithm question

[bulut_01]

Hello forum friends, I have an raw unencrypted code and an encrypted hex version. I want to decrypt hex the encrypted version of this code.

unencrypted raw data

[temtronic]

without the 'key' you could spend decades figuring it out.
encrypted has 17 bytes
'raw' data has 43 (?) bytes ?

might be off light green on white is hard on my eyes.

question though WHAT' is the data format? bytes, words, bits ? You need to know what the data represents. a 'byte' could be ADC output or maybe 8 different switch positions.

do either of those data have checksums attached to them ?

There's a lot of unknown information that is missing.

one 'helper' would be to have at least 3 sets of data to look at, might see a pattern. There are online resources that may help.

[bulut_01]

[bulut_01]

[newguy]

In all seriousness, you're very likely not going to be able to decrypt the data. You must know the key in order to have any chance at all of success.

The RF module is adding a 'salt' (nonce) to the data stream as evidenced by the 3 completely different sets of data that result from pressing the same button 3 times.

If the RF module has a passthrough mode you should be able to accomplish your goal.

[bulut_01]

[temtronic]

having 3 different data for the same keypress is understandable when you consider the device is probably using 'rolling key' technology.
something Microchip developed decades ago (4 ??) to prevent 'hackers' from using a generic keyfob from opening your garage door

in a nutshell , when the fob is programmed by the receiver, they are linked by the 'key' that's embedded in the datastream. No other keyfob can send the proper data. since every transmission the data stream is different, the hacker

[bulut_01]

[newguy]

Passthrough = simply pass through the data without adding a nonce and encrypting. Like a wired connection, just pass the data through.

You need to realize that you cannot. I'll say that if it's at all possible, you won't be able to do it without the RF module's manufacturer giving you help, but there's virtually no chance of them doing so, as that would equate to a security breach that would allow all electronic assemblies which use their transceiver to be hacked/breached.

In any serious security application it's not sufficient to simply encrypt the payload data. That allows something called a replay attack: a bad actor can listen to the communication and simply replay it in order to do something: open a garage door or unlock a vehicle for example. That's why a salt / nonce (n[umber] once) is also inserted into the payload before encryption. This nonce is used once and only once. That's why your 3x button presses gave you 3 entirely different data streams. The nonce is typically incremented for each transmission. They're typically at least 16 bits and more commonly 32 bits or more. Pairing a transmitter to a receiver involves a reset of the nonce. The next time the receiver gets a transmission, it remembers what the nonce was the last time, and the nonce should be 1 greater than that. Sometimes a transmitter and receiver can get out of sync. Perhaps you pressed your garage door opener's button accidentally when you were out of range. If you pressed it several times, the receiver isn't necessarily going to trust that it's "you" when you do come into range. That's why you may have noticed that you need to press the button to open your garage 3 or 4 times before it actually starts to open. That's because the nonce the receiver decrypted wasn't 1 or 2 higher than it was expecting: it was more than that. Pressing it a few times in a row allows the receiver to see that the nonce it is receiving is monotonic despite the unexpected gap, and that "you" are "you" and thus trustworthy.

You cannot decrypt the data for a simple reason: security. And brute force attempts will take forever and a day. If you want to add an RF transmitter/receiver to a project, you'll need to implement something entirely new, as the one you're trying to hack has thankfully implemented basic security.

[bulut_01]

Here I want to find the seed used to encrypt data. I looked on the net and there are claims of those who can hack this rolling key. The aim here is not to hack anything, but to control something on the remote control. Every system has a vulnerability. I want to believe that this rolling key data can be solved.

[temtronic]

yes, it can be solved but.... if like Microchip's version though....

Once the system has responded to a valid code, about
65,000 valid codes will have to be received before the
same code will be used again. If the remote control is
used eight times daily, 22 years will pass before the
system responds to the same code again - once!
Therefore, a retransmitted code (like when a code
grabber is used) will never activate the system.

Above was taken from their application brief about 'Keeloq' which has 64 bit key

So to 'crack the key', you just need to compare the keyfobs key over 65,000 times,recording each attempt and result. I'd modify a fob to electronically press the same key,say 1 per second ? There's probably some internal timings to a keyfob...

[bulut_01]

[temtronic]

takes about 18hrs @1 per second....

your problem is you do not KNOW how the 'key' is generated. Keyloq is only one of 1,000s of ways to do 'rolling code'

It's based on 16bits...... could easily have 32 or 64, then the number gets, well really,really BIG.
Microchip do have good 'apnotes' about this so you can 'reverse engineer' but far simpler to just take a 50 cent PIC and replace the current keyfob micro with YOUR programmed PIC.

[bulut_01]

[temtronic]

1st look for the repeating pattern

once you have that, you need to figure out HOW the 'key' was generated.
Say it's a 16 bit key.
1) 16 bits treated as a 'word'
2) 16 bits treated as 2 'bytes'
3) 16 bits treated as 4 'nybbles'
4) 16 bits treated as 16 'bits'

last 3 have 'variations; in computing the key. IE #3 could be after some 'math', 1st nybble, then 3rd, then 4th, then 2nd as the sequence to create the 'key' as a 'word'. the rcvr has to rearrange the nybbles then undo the math...

If you know the make/model of the keyfob micro, start with the manufacturer. If the OEM just used the MFR's suggested code , you might get lucky. However most OEMs use their OWN key generating code, obviously to prevent hackers from getting in !
Can it be done ? Yes, reverse engineering is possible. Unless you've got a LOT of time on your hands, I suggest replacing the keyfob micro with one of yours.