Searching \ for 'Code hopping with PICS' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Code hopping with PICS'.

Truncated match.
PICList Thread
'Code hopping with PICS'
1994\12\13@162736 by crocontroller discussion list

flavicon
face
Hi everybody

I am trying to develop a code hopper alarm remote control system using the
PIC16C54 or PIC16C56 micro.

Is there anybody else doing the same or who can help at all?

Regards

Werner Terreblanche
South Africa


EMAIL : spam_OUTwterrebTakeThisOuTspamactive.co.za

-----------------------------------------------------------------------

1994\12\14@105058 by tom

flavicon
picon face
Werner Terreblanche Wrote ;

> I am trying to develop a code hopper alarm remote control system using the
> PIC16C54 or PIC16C56 micro.
>
> Is there anybody else doing the same or who can help at all?
>
I offer the following for comments;

One way of producing a code hopper is as follows:-

1) Both transmitter and receiver contain an identical
  (psuedo) random number generator, and at installation they are put
  in sync i.e. both know what the last number was (have a learn mode
  on the rx, fire off the tx, presto there in sync).

2) Have the rx respond to the NEXT (x) random numbers i.e.

             rx a code
             try and match to next rand
              if fails try again (x) times

  This would be the rx window and needs to be large enough (contain
  sufficient tries) to account for accidental activation of the tx
  when out of range of the rx, as this would otherwise put the two out
  of sync.

3) on the tx each activation causes the next random number to be used
  on the rx each successful match causes the next random number to be
  used.

This way once a code has been used it will not be repeated for the
maximum iterations of the random number generator. any 'replay' device
would fail because it would simply play back a code that was not within
the match window.

Use the E2prom pic (16c84) or have an eeprom connected to the pic to
store the last number used (next random seed).

the following is a code segment of an 8 bit psuedo random generator,
this will give 0 to 255 in random order without repeating for 255
iterations, this could be expanded to a 16bit easily.

Each time it is called it requires the last number as the seed for the
next number.

;*******************************************************************************
**
; Code segment by Gary Whittaker 1993,  << Pubic Domain >>                     *
*
;          .....garyKILLspamspam@spam@advtech.demon.co.uk
**
;-------------------------------------------------------------------------------
**
; l_rand & rand must be defined as variables
**
; CALL this routine for each successive random number
**
;*******************************************************************************
**

;******* next random number routine expects seed (last rand) in l_rand,
;******* returns in next randome number in l_rand
;******* uses a 4 bit xor with rotate left (bits 3,4,5,7)

next_rand       MOVF    l_rand,w
               MOVWF   rand            ;take a copy (leaving one in w)
               BCF     rand,.3         ;set up xor bits 3+5
               BCF     rand,.5
               BTFSC   rand,.4         ;mov bits 4+7 into 3+5 ready for
               BSF     rand,.3         ;the xor
               BTFSC   rand,.7
               BSF     rand,.5
               XORWF   rand,w          ;xor 3+4,5+7 into 3+5
               MOVWF   rand
               BCF     rand,.3         ;clear xor bit 3
               BTFSC   rand,.5         ;mov bit 5 into 3 ready for xor
               BSF     rand,.3
               XORWF   rand,same       ;xor 3+5 into 3
               BCF     status,carry    ;set carry to result
               BTFSC   rand,.3
               BSF     status,carry
               RLF     l_rand,same     ;rotate next into l_rand
               BCF     status,carry    ;clear carry for safety

               RETLW   .0

;*******************************************************************************
*
end
__
  TAK

1994\12\14@225157 by crocontroller discussion list

flavicon
face
{Quote hidden}

Hmmmm..... I press my car-alarm transmitter a lot when walking down the
street (just for scientific purposes, of course :-) and I suspect that I may
have some sort of code-hopping system since the installer had to have both
transmitters when he installed the receiver (I think).

mike

1994\12\15@223244 by crocontroller discussion list

flavicon
face
Michael Bender wrote (regarding code-hopping remote controls):

> Hmmmm..... I press my car-alarm transmitter a lot when walking down the
> street (just for scientific purposes, of course :-) and I suspect that I may
> have some sort of code-hopping system since the installer had to have both
> transmitters when he installed the receiver (I think).

Typically each remote has a unique fixed code, and the reciever has to be
programmed for the remotes.  There is usually a switch on the alarm somewhere
to enable programming.

Eric

1994\12\16@001256 by crocontroller discussion list
flavicon
face
| Michael Bender wrote (regarding code-hopping remote controls):
|
| > Hmmmm..... I press my car-alarm transmitter a lot when walking down the
| > street (just for scientific purposes, of course :-) and I suspect that I may
| > have some sort of code-hopping system since the installer had to have both
| > transmitters when he installed the receiver (I think).
|
| Typically each remote has a unique fixed code, and the reciever has to be
| programmed for the remotes.  There is usually a switch on the alarm somewhere
| to enable programming.

What do you think the chances are that one of my remotes could be used
to activate another receiver? I would hope that each receiver and
transmitter from the same company have at least a fixed manufacturer
code, and then a portion of the rest of the code that was variable
based on the matching of the two units.

mike

1994\12\16@022542 by crocontroller discussion list

flavicon
face
>
> What do you think the chances are that one of my remotes could be used
> to activate another receiver? I would hope that each receiver and
> transmitter from the same company have at least a fixed manufacturer
> code, and then a portion of the rest of the code that was variable
> based on the matching of the two units.
>
> mike
>

Some manufacturers of remote controllers use encoder IC's entented for
simple remote control applications and not for high security environments.
These devices typically send only about 12 bits and that's it!

I once made a device that could read the code transmitted by the Tx and then
retransmit that same code at a later time (Using a PIC by the way!)  This
device could easily be used by thief to for example open a car with central
lock.  That is why I am interested in developing a code hopping system.

Regards

Werner
wterrebspamKILLspamactive.co.za

1994\12\16@130627 by crocontroller discussion list

flavicon
face
On Fri, 16 Dec 1994, Werner Terreblance wrote:

> Some manufacturers of remote controllers use encoder IC's entented for
> simple remote control applications and not for high security environments.
> These devices typically send only about 12 bits and that's it!

 This is the way my Ungo transmitter is made. It has a 144049 buffer
with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
and that is connected to a 145026 encoder which transmits nine bits.

 Wouldn't be that hard for a thief with a little ee knowledge to hook a
PIC up to it and cycle thru the possible combinations...

>
> I once made a device that could read the code transmitted by the Tx and then
> retransmit that same code at a later time (Using a PIC by the way!)  This
> device could easily be used by thief to for example open a car with central
> lock.  That is why I am interested in developing a code hopping system.

 You might also want to look into one way encryption ciphers(hash
tables) there was a discussion on the cypherpunks mailing list several
months back about using one way functions in security applications.

  Brian

------------------------------------------------------------------------------
"Everyone is a prisoner holding their own key."    | finger .....blaneKILLspamspam.....seanet.com
   -- Journey                                     | PGP 2.6 email accepted
------------------------------------------------------------------------------

1994\12\16@141219 by crocontroller discussion list

flavicon
face
>>
>> What do you think the chances are that one of my remotes could be used
>> to activate another receiver? I would hope that each receiver and
>> transmitter from the same company have at least a fixed manufacturer
>> code, and then a portion of the rest of the code that was variable
>> based on the matching of the two units.
>>
>> mike
>>
>
>Some manufacturers of remote controllers use encoder IC's entented for
>simple remote control applications and not for high security environments.
>These devices typically send only about 12 bits and that's it!
>
>Werner


FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
combinations, but the base and the remote only have eight DIP switches in
them for setting your code.  When I called them up and said, "Hey, where are
these gizillions of codes?"  all they would say was, "It's in dere".

Are they saying the R/T have fixed code prefixes inside?  Would they
distribute matching sets to the same areas?  That would be bad.  Who's to
say they don't do this?

Anyone have any hard information on this?

- JohnR

--
John R. Haggis            EraseMEhaggisspam_OUTspamTakeThisOuTnetcom.com
Millennium Research
(408) 269-1814 vox
(408) 269-9323 fax

1994\12\16@161440 by crocontroller discussion list

flavicon
face
>
John R. Haggis wrote:

> FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
> combinations, but the base and the remote only have eight DIP switches in
> them for setting your code.  When I called them up and said, "Hey, where are
> these gizillions of codes?"  all they would say was, "It's in dere".
>
> Are they saying the R/T have fixed code prefixes inside?  Would they
> distribute matching sets to the same areas?  That would be bad.  Who's to
> say they don't do this?
>
> Anyone have any hard information on this?
>
> - JohnR
>

Even if they do have longer codes than just the eight bits, the code could
still be sampled by a fast microprocessor in much the same manner as the
multiple IR remote control devices work which "learns" a code.  Unless the
code is different every time you press the button, there will be an easy
option to decipher the code.  I have experimented with this and it is
definetely possible.

Regards

Werner Terreblanche
wterrebspamspam_OUTactive.co.za

1994\12\16@162305 by crocontroller discussion list

flavicon
face
>
> On Fri, 16 Dec 1994, Werner Terreblance wrote:
>
> > Some manufacturers of remote controllers use encoder IC's entented for
> > simple remote control applications and not for high security environments.
> > These devices typically send only about 12 bits and that's it!
>
>   This is the way my Ungo transmitter is made. It has a 144049 buffer
> with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
> and that is connected to a 145026 encoder which transmits nine bits.
>
>   Wouldn't be that hard for a thief with a little ee knowledge to hook a
> PIC up to it and cycle thru the possible combinations...
>

There's an ad in the latest Nuts & Volts magazine for just such a device.
Of course, only lock smiths and car repossesion professionals ;-) can
buy them.  It claims that in a mere 10 minutes, 90% of all car alarms
on the market can be "silenced".

Perhaps there *is* money for EE's on "the dark side".

cje

--
Chris Elmquist, N0JCF           On Dr. McCoy's tombstone: "He's dead Jim".
@spam@chriseKILLspamspamn0jcf.com
KILLspamn0jcfKILLspamspamamsat.org

1994\12\17@011301 by tom

flavicon
picon face
> >
> John R. Haggis wrote:
>
> > Are they saying the R/T have fixed code prefixes inside?  Would they
> > distribute matching sets to the same areas?  That would be bad.  Who's to
> > say they don't do this?
> >
> > Anyone have any hard information on this?
Batching sets to an area would be uneconomical given the sales rates of alarms.
There are at least half a dozen different coding chips on the market, each uses
a slightly different way of producing the code.
_Most_ of them use at least 12 bit code.
A couple of Motorola devices use 3-way sensing on the inputs
i.e. pos, neg, or floating input gives a code differ.
Thats 12 x 3 x,,, er, who's got a calculator ? :)

Now if you did it with a PIC, you could have 8 bits user selected and a couple
of locs. with random nos pre-programmed. Mix and match before transmitting and
have the decode routine learn it's relevant Tx code. That gives you 24 bit code
with one 8 way dil-switch. Then transmit the code twice, the second time
inverted and code samplers will just fall over.

Then Werner wrote ;
> >
>
> Even if they do have longer codes than just the eight bits, the code could
> still be sampled by a fast microprocessor in much the same manner as the
> multiple IR remote control devices work which "learns" a code.  Unless the
> code is different every time you press the button, there will be an easy
> option to decipher the code.  I have experimented with this and it is
> definetely possible.

Possible, but an unrealistic time-scale. The micro does'nt have to be fast BTW
'cos the code is not transmitted all that fast, a PIC running at 8 Meg would
still take, from memory over 3 hours to cycle.
__
  TAK

More... (looser matching)
- Last day of these posts
- In 1994 , 1995 only
- Today
- New search...