 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
 Posted: Sun Jun 29, 2025 6:44 am |
 |
|
| temtronic wrote: | 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. |
I have such a keeloq solving algorithm, will it work for me?
| Code: | keeloqNLF(a, b, c, d, e):
return (d + e + a*c + a*e + b*c + b*e + c*d + d*e + a*d*e + a*c*e + a*b*d + a*b*c) % 2;
#---- KEELOQ: Decrypt
def keeloqDecryptCalcLSB(data, keybit):
nlf = keeloqNLF((data>>30)%2, (data>>25)%2, (data>>19)%2, (data>>8)%2, (data>>0)%2)
lsb = (keybit ^ (data>>31) ^ (data>>15) ^ nlf) % 2
return lsb
def keeloqDecryptKeybit(data, keybit):
return ((data & 0x7FFFFFFF)<<1) ^ keeloqDecryptCalcLSB(data, keybit)
def keeloqDecrypt(data, key):
for round in range(0,528):
keybit = (key >> ((591-round) % 64)) % 2
data = keeloqDecryptKeybit(data, keybit)
return data |
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9503
Location: Greensville,Ontario
|
|
| Posted: Sun Jun 29, 2025 6:58 am |
|
|
go ahead and try it ?
I have no idea if the keyfob micro is using 'keeloq' for it's key generator.
You'll have to 1st create a database of 65,000+ keypresses save to a PC, say as an excel datasheet.csv.
without the database, it's probably not realistic you can decode the 'key'. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Sun Jun 29, 2025 7:17 am |
|
|
| temtronic wrote: | go ahead and try it ?
I have no idea if the keyfob micro is using 'keeloq' for it's key generator.
You'll have to 1st create a database of 65,000+ keypresses save to a PC, say as an excel datasheet.csv.
without the database, it's probably not realistic you can decode the 'key'. |
The findings of my research are that keeloq is encrypted with 64 bits, so keeloq is correct |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9503
Location: Greensville,Ontario
|
|
| Posted: Sun Jun 29, 2025 12:28 pm |
|
|
| so the keyfob has what model PIC in it ? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Sun Jun 29, 2025 12:41 pm |
|
|
| temtronic wrote: | | so the keyfob has what model PIC in it ? |
16LF1512 |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Sun Jun 29, 2025 1:31 pm |
|
|
''The secure key generation scheme is a more advanced key generation scheme. When using the normal key generation scheme, the key is generated from the serial number and the manufacturer code. Since the serial number is transmitted in any packet, part of the key generation scheme is always exposed. However, an even more secure method is to generate a random number (called a "seed"). Depending on the length of the seed, there are three key generation schemes: 32-bit seed, 48-bit seed, and 60-bit seed. The seed is not transmitted during normal operation. The only time the seed is transmitted is during the learning/pairing phase. Therefore, the information used to generate the encryption key is kept secret. Some implementations take the security level even further by only allowing the seed to be transmitted for a limited time (the time the system is armed) and then disabling this feature.''
I found this information on the net. Could there be a situation like sending keys in the controller's familiarization mode? Can this information enlighten us? |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Sun Jun 29, 2025 1:45 pm |
|
|
Is the key I drew in red necessary for us to decode the code? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9503
Location: Greensville,Ontario
|
|
| Posted: Sun Jun 29, 2025 5:10 pm |
|
|
You main problem is you don't know for sure WHICH 'key hopping' code is IN the PIC.
I won't 'assume' it is KEYLOQ.
quik fix.... buy a 16LF1512, cost is $1- $1.50... cut your code,swap for the fob unit, done in a day and it works..... |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Mon Jun 30, 2025 1:48 am |
|
|
| temtronic wrote: |
quik fix.... buy a 16LF1512, cost is $1- $1.50... cut your code,swap for the fob unit, done in a day and it works..... |
Let's say I took a pic. Which code should I upload and how should I test it? Can you explain it more? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9503
Location: Greensville,Ontario
|
|
| Posted: Mon Jun 30, 2025 7:02 am |
|
|
1st, you reverse engineer the keyfob.That'll give you a schematic of which PIC pins do what....probably 4 for the 4 keys, 1 for transmit data, 1 for an LED ?
2nd, you cut code to see if a key was pressed, then transmit a 'data stream'. The format of the 'data stream' is up to you but should be comatible with the receiver( which I assume you already have built ?). There is no 'code to download'.. YOU have to do this yourself.
odds are the keys are on a port with interrupts on it, I'd have to DL the datasheet to see.
the hardest part will be to remove the current PIC and solder in the new one. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Mon Jun 30, 2025 7:13 am |
|
|
| temtronic wrote: | 1st, you reverse engineer the keyfob.That'll give you a schematic of which PIC pins do what....probably 4 for the 4 keys, 1 for transmit data, 1 for an LED ?
2nd, you cut code to see if a key was pressed, then transmit a 'data stream'. The format of the 'data stream' is up to you but should be comatible with the receiver( which I assume you already have built ?). There is no 'code to download'.. YOU have to do this yourself.
odds are the keys are on a port with interrupts on it, I'd have to DL the datasheet to see.
the hardest part will be to remove the current PIC and solder in the new one. |
I did not understand what kind of benefit these explanations will have in decrypting the incoming data (key) |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Mon Jun 30, 2025 7:29 am |
|
|
The remote control tda5150 rf module is sending data, pic communicates with 5150 spi and keeloq data is sent from there, the data coming out of pic is the same as the data I read from the logic analyzer, there is no problem, it is sent with 64 bit encryption, I have also published the raw and unencrypted version above, here is the remaining encrypted data to be decrypted and made meaningful
button uses ioc interrupt
16f1512 communicates with tda5150 with software spi and sends data.
 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19881
|
|
| Posted: Mon Jun 30, 2025 7:41 am |
|
|
The big problem is that you do not know what the format of the incoming
data before encryption is. Without some clue to this you can never decode
it, since you could have the right code, and not know is is right.....
This was the key to the enigma decryption, that some of the senders
were using names of places and events that when a test decode gave these
gave a clue that this might be right.
If you are sure the data is keeloq encrypted, and you knew something
about the nature of the source data, then the way to do this is a
brute force solution. You take the blocks of incoming data, and use a PC
to run through every solution, looking for whatever the 'clue' is in the
output. 64bit is quite a short encryption, and even a basic PC could run
every solution in a few hours.
Trying to crack without a clue, is basically a 'hiding to nowhere'. |
|
|
bulut_01
Joined: 24 Feb 2024
Posts: 246
|
|
| Posted: Mon Jun 30, 2025 7:51 am |
|
|
| Ttelmah wrote: | The big problem is that you do not know what the format of the incoming
data before encryption is. Without some clue to this you can never decode
it, since you could have the right code, and not know is is right.....
This was the key to the enigma decryption, that some of the senders
were using names of places and events that when a test decode gave these
gave a clue that this might be right.
If you are sure the data is keeloq encrypted, and you knew something
about the nature of the source data, then the way to do this is a
brute force solution. You take the blocks of incoming data, and use a PC
to run through every solution, looking for whatever the 'clue' is in the
output. 64bit is quite a short encryption, and even a basic PC could run
every solution in a few hours.
Trying to crack without a clue, is basically a 'hiding to nowhere'. |
Thank you for your information, master. The problem is, which program should I install on my PC and how should I do the 64 bit decoding? I need more detailed information and help on these issues. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19881
|
|
| Posted: Mon Jun 30, 2025 7:58 am |
|
|
You would just write one. Need to use an efficient compiled language,
not an interpreter. C, C++, Rust, Go, or something similar. |
|
|
|
|
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
