 |
 |
| View previous topic :: View next topic |
| Author |
Message |
david90
Joined: 25 Feb 2006
Posts: 23
|
| capturing serial data |
 Posted: Wed Dec 31, 2008 3:10 am |
 |
|
I have a device that outputs serial data and I need to use a pic to capture the serial data. The serial data length is 44 bit/frame. I need to capture the frame so that I can use it later to detect when the device output that same exact serial data string.
I need to know what is the best way to do this. I'm thinking of configuring a timer according to the serial data baud rate so that it overflows and run an ISR to capture each serial data bit. Is it a good idea? |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Dec 31, 2008 4:13 am |
|
|
| To get effective help, you should add some details of the involved serial data format, e. g. bit rate, sync or async protocol. |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Wed Dec 31, 2008 1:00 pm |
|
|
The only information that I have is the bit rate which I see on the scope. The serial data idles at 12V but I will have a conversion circuit to bring it down to 5V.
Other than that I know nothing about it. My goal is just pretty much capture it and use for comparison in the future to detect that same serial data string. I have some ideas on how to write a program to blindly capture the frame but it's probably not the best so that's why I'd like to hear some of yours. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Wed Dec 31, 2008 4:37 pm |
|
|
| david90 wrote: | The only information that I have is the bit rate which I see on the scope. The serial data idles at 12V but I will have a conversion circuit to bring it down to 5V.
Other than that I know nothing about it. My goal is just pretty much capture it and use for comparison in the future to detect that same serial data string. I have some ideas on how to write a program to blindly capture the frame but it's probably not the best so that's why I'd like to hear some of yours. |
Since you don't mention a separate clock signal, I'll assume that this is a self-clocking signal. Normal 8-bit ASYNC is also self-clocking, but the clock only gets to drift for 8 bits after the Start bit, so it is not hard to get the receiver's clock to stay in sync with the signal. But your frame is 44 bits long. If you used the same self-clocking strategy, timing from a Start bit, then the receiver's baud rate would need to be about 8 times more accurate than the typical Async. Now you might consider re-syncing to the data transitions in the received signal. That is all well and good as long as there are data transitions. But arbitrary data can go a long time without any transitions. Now if the nature of the signal you are receiving is such that there is some limit on the length of no-transition data (a run-length-limited code), then you could use re-syncing reliably. But if not, then re-syncing may fail on long runs of no-transitions. You clearly can't use the UART since you don't have fixed start and stop bits every 8 data bits. So you would have to capture this data by timing and sampling. The whole trick will be in how you sync to the data. Is there a pre-amble? Or does the data just start out from a known idle state, going right to a fixed Start bit? Is the data rate slow enough for sampling by software? I would guess that anything more than 100 uSec per bit cell would be doable in software.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Jan 01, 2009 4:04 am |
|
|
I'd guess, that this is not '44bits', but _45_. Remember that normal async serial, ends each character with a stop bit, which is the same high level, as the 'idle'. I'd suspect you will find this is normal async, using non-standard signalling voltages, 7bits per character, one start, one stop. Five characters sent, giving 44bit times of signal below the idle level.
If you study the data, and I am 'right', you will find that every 9th bit is high (the stop between the successive characters), and then the next bit is low. So you will see:
1111.......0xxxxxxx10xxxxxxx10xxxxxxx10xxxxxxx10xxxxxxx1.......
The last '1', is the final stop bit, and then the line carries on idling high.
If so, this will be readable by the normal serial routines in the PIC. 
Best Wishes
Happy New Year |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Fri Jan 02, 2009 6:02 pm |
|
|
To be more clear, I have attached the scope capture of the actual frames that I would to detect.
here is one
here is the other
I have a car with keyless entry, and I would like it to beep whenever I quickly press my key fob's (remote) lock or unlock button twice. Currently it doesn't beep when I press the lock/unlock button. The captured images above were captured from my keyless entry receiver module serial data line. The module output serial data in image1 when I press lock twice and image 2 when I press unlock twice.
Considering that I don't care what the serial data means or its protocol, what is the easiest way to record and detect these two frame?
I read that my car uses "controller area network" to network so these frame might follow CAN frame format. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Fri Jan 02, 2009 9:06 pm |
|
|
| Quote: | | ...I have a car with keyless entry, and I would like it to beep whenever I quickly press my key fob's (remote) lock or unlock button twice. Currently it doesn't beep when I press the lock/unlock button. The captured images above were captured from my keyless entry receiver module serial data line. The module output serial data in image1 when I press lock twice and image 2 when I press unlock twice... |
Are you sure this is repeatable? Most modern keyless entry systems use a rolling code which changes on every button push. Through encryption the receiver can tell if the code it receives is a valid "next" code. Once a valid code has been received, the receiver will not respond to that code again - not until the rolling code has wrapped all the way around its very long cycle.
If the keyless entry worked in a repeatable fashion, sending the same code every time you pressed the same key, then it would be an easy matter for an attacker to hide a receiver in a parking lot and capture anyone's "unlock" code. Then all they would have to do is follow you home, and when you leave, the attacker only needs to replay what he recorded and he is in your car. A rolling code prevents this kind of attack, and is pretty much standard in the industry. I would be very surprised if your keyfob did not use a rolling code of some sort.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Sat Jan 03, 2009 3:02 am |
|
|
| The rolling code function is performed in the keyless entry receiver module. If I press a button on my key fob and everything is valid, I would get the serial data posted above. If not, then nothing would come out of the serial data line. |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jan 03, 2009 3:43 am |
|
|
The rolling code is performed by both the transmitter, and receiver modules. The transmitter moves forward by one code, every time the button is pushed, the receiver knows the next few codes from the last one received, and will accept any in this window. Hence, if you take the transmitter, go out of range of the receiver, and push the button a number of times, the receiver will then refuse to accept the code from the transmitter. Some have a 'recovery' mode, where if they receive typically three correct codes in sequence, they will then acceptt the new starting point, while others require a key unlock, once the sequence is lost.
If your transmitter is only producing the two codes shown, then the system is remarkably insecure.
Realistically, if the code sequence is fixed, and you want to just accept the patterns shown, the way to do it, is to program an interrupt on change, reset a timer on the first edge, then record the count from timer, on each subsequent edge. Then just compare the list of times, to a list stored in your decoder.
A few 'frills' will need to be added (if the timer overflows, then you have 'missed' part of a sequence, so go back to the initial 'waiting' condition), but in general this is failry basic code. The same approach, is used by systems like 'learning' remotes, and some basic code approaches to this, have been posted in the past.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Jan 03, 2009 5:52 am |
|
|
As far as I know, many older rolling code algorithms have been decoded, they are known at least by car burglars. An about 40 bit code actually can't provide strong cryptography.
The shown bit stream seems to be near to 2400 baud, I didn't see at first look, if it can fit any usual UART frame. But it's sufficient slow to capture it by oversampling and decode it in software, if it doesn't. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Sat Jan 03, 2009 7:17 am |
|
|
| FvM wrote: | | As far as I know, many older rolling code algorithms have been decoded, they are known at least by car burglars. An about 40 bit code actually can't provide strong cryptography. |
Just because the block of data sent over the air is only about 40 bits, that does not mean the key is limited to that size. It is possible to have a strong encryption algorithm based on a 128-bit key and use that algorithm to encrypt a 16-bit word. Cracking the resulting 16-bit code would amount to finding the 128-bit key, which can be next to impossible. Of course you could just try every 16-bit code until you get one that works, but the only way to try a code is to send it to the receiver and see if the receiver responds correctly. It is an easy matter to make the receiver limit the speed with which an attacker can probe it. After a few wrong guesses, it could time-out for a minute or so. That would make it very difficult to try even a mere 65536 different codes.
By looking at the scope displays, it seems that the first half of the packet is the same. This is probably where the keyfob identifies itself. This is necessary to do in the clear when you have several different keyfobs that must be handled by a single receiver. The receiver needs to keep track of each keyfob's place in the rolling code sequence separately. Then the last half can be the encrypted rolling code. Anyway, it is easy to test out if any rolling code thing is happening here. Just do the same thing twice and see if the waveform is identical all the way through.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Jan 03, 2009 8:09 am |
|
|
| Quote: | | Just because the block of data sent over the air is only about 40 bits, that does not mean the key is limited to that size. It is possible to have a strong encryption algorithm based on a 128-bit key and use that algorithm to encrypt a 16-bit word. |
Not quite right, I think. The encrypted message complexity is limited according to the transmitted data length, or more exactly to the continuous message length evaluated by the receiver (may be from more than one consecutive packet). With short messages, there's basically an option to determine the encryption scheme more easily. You have to know the number of evaluated consecutive packets to determine the effective key length.
Generally, I assume, that the key would be decoded by watching correct transmissions rather than trial, so there is no time-out issue.
Personally, I'm not engaged with code hacking, this is just my estimation of involved cryptographic strength, and it may be wrong, of course. |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Mon Jan 05, 2009 1:35 pm |
|
|
| RLScott wrote: | | FvM wrote: | | As far as I know, many older rolling code algorithms have been decoded, they are known at least by car burglars. An about 40 bit code actually can't provide strong cryptography. |
Just because the block of data sent over the air is only about 40 bits, that does not mean the key is limited to that size. It is possible to have a strong encryption algorithm based on a 128-bit key and use that algorithm to encrypt a 16-bit word. Cracking the resulting 16-bit code would amount to finding the 128-bit key, which can be next to impossible. Of course you could just try every 16-bit code until you get one that works, but the only way to try a code is to send it to the receiver and see if the receiver responds correctly. It is an easy matter to make the receiver limit the speed with which an attacker can probe it. After a few wrong guesses, it could time-out for a minute or so. That would make it very difficult to try even a mere 65536 different codes.
By looking at the scope displays, it seems that the first half of the packet is the same. This is probably where the keyfob identifies itself. This is necessary to do in the clear when you have several different keyfobs that must be handled by a single receiver. The receiver needs to keep track of each keyfob's place in the rolling code sequence separately. Then the last half can be the encrypted rolling code. Anyway, it is easy to test out if any rolling code thing is happening here. Just do the same thing twice and see if the waveform is identical all the way through. |
The waveform is identical after pressing the keyfob 's lock/unlock button. IMO, the serial data captured above is just a command sent by the keyless entry receiver to the car's computer telling it to unlock the doors. This doesn't mean that my car doesn't use rolling code. The keyless entry receiver module processes the rolling code algorithm and what comes out of it are just commands. That's why the serial data is the same everytime I press keyfob.
There is always a possibility that I'm wrong so I'm open to all ideas. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Jan 05, 2009 2:34 pm |
|
|
| david90 wrote: | | ...The keyless entry receiver module processes the rolling code algorithm and what comes out of it are just commands. That's why the serial data is the same everytime I press keyfob.... |
OK, you must be right. Your test confirmed it. So it is back to detecting a serial data stream. By my count, there are 34 bit cells in one packet. If your scope picture shows 2 msec per division, then it appears that a bit cell is about 400 usec. This is plenty slow enough for software sampling.
Assuming the clock on your PIC and the clock on the keyless entry receiver are both quite accurate, then just wait in a tight loop for the first transition. Even if your PIC was running a 4 MHz crystal, you could still catch the first transition to within 4 usec, which is a small fraction of the 400 usec for a bit cell. Then measure out 200 usec to put yourself in the middle of the first bit cell. Then measure out successive 400 usec intervals and sample the logic level after each time-out. Do that 34 times and you have your 34 bits.
If you have something else to do during the capture time, then you could use CCP Input Capture to capture each transition. Reduce each period to the nearest multiple of 400 usec., and you have another unambiguous representation of the bit pattern.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Thu Jan 08, 2009 12:25 pm |
|
|
| RLScott wrote: | | david90 wrote: | | ...The keyless entry receiver module processes the rolling code algorithm and what comes out of it are just commands. That's why the serial data is the same everytime I press keyfob.... |
OK, you must be right. Your test confirmed it. So it is back to detecting a serial data stream. By my count, there are 34 bit cells in one packet. If your scope picture shows 2 msec per division, then it appears that a bit cell is about 400 usec. This is plenty slow enough for software sampling.
Assuming the clock on your PIC and the clock on the keyless entry receiver are both quite accurate, then just wait in a tight loop for the first transition. Even if your PIC was running a 4 MHz crystal, you could still catch the first transition to within 4 usec, which is a small fraction of the 400 usec for a bit cell. Then measure out 200 usec to put yourself in the middle of the first bit cell. Then measure out successive 400 usec intervals and sample the logic level after each time-out. Do that 34 times and you have your 34 bits.
If you have something else to do during the capture time, then you could use CCP Input Capture to capture each transition. Reduce each period to the nearest multiple of 400 usec., and you have another unambiguous representation of the bit pattern. |
Thanks for the help. I still have a question regarding on how to store the data. After I get my 34 bits, what is the best form to store the bits in so that it is easy to work with when I try to detect the same waveform? I think what i'm asking is what is the best data structure to store the data in considering that I will use this data for comparison. |
|
|
|
|
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
