1. Attachments are working again! Check out this thread for more details and to report any other bugs.

Removing FOB Battery

Discussion in 'Gen 2 Prius Main Forum' started by jezroj, Jun 18, 2005.

  1. jezroj

    jezroj New Member

    Joined:
    Apr 16, 2005
    52
    0
    0
    Location:
    Sunnyside, California
    Vehicle:
    2005 Prius
    Is there any chance of the FOB loosing its programming if the battery is removed for any length of time?
     
  2. victor

    victor New Member

    Joined:
    May 18, 2004
    414
    2
    0
    Location:
    Gilching Bavaria Germany, & Drapanos, Crete, G
    Not that Ive heard of.
     
  3. DanMan32

    DanMan32 Senior Member

    Joined:
    Aug 27, 2004
    3,799
    26
    0
    Location:
    Tampa Bay, FL
    There's no programming in the fob, though it does store the last code it sent out, so that it can send the next psudo-random code that the Prius would be expecting.
    I believe the last code sent is non-volitile like with any other car fob, otherwise it would be useless and expensive to fix.
    Same with the Prius, which stores the last code it received from up to 4 (5 with SKS) fobs it has been paired with. Otherwise, again, if the aux battery were disconnected, that would be an expensive fix to get a fob paired with the car.
     
  4. jayman

    jayman Senior Member

    Joined:
    Oct 21, 2004
    13,439
    641
    0
    Location:
    Winnipeg Manitoba
    Vehicle:
    2004 Prius
    It's highly unlikely just changing the battery will "erase" anything. The FOB uses non-volatile memory to retain the "seed" value for the next hash operation. The hash in the FOB is in firmware so can't be erased if the battery is removed.

    I suppose if you're really worried about this though, look under the steering column and poke the SKS Disable button. The car transceiver will stop broadcasting until you enbable SKS again. This way you can change the FOB battery without worry.

    The 40 bit hash used not only knows the next "expected" value but the next 256 "expected" values. This is used to maintain synchronization between the car receiver and the FOB.

    Otherwise, in a scenario I'm sure happens quite a bit in the real world, you would be too far away from the car and force the FOB to transmit (Press a lock, unlock, or panic button on the FOB). Do that a couple of times, lose synchronization, and you're locked out of the car.

    So in a compromise between "good" security and convenience, the car has to know the next 256 "expected" values.

    As you can imagine, a 40 bit encoder, 4-5 slots that share the encoder, and a PRNG (Pseudo Random Number Generator) that must "know" the next 256 "expected" values, all take their toll from "real" security.

    You can check out a fascinating technical discussion of PRNG at Embedded Systems Programming:

    http://www.embedded.com//showArticle.jhtml...icleID=20900500

    The next article discusses SSL on public comms, but the concepts are relevant:

    http://www.embedded.com//showArticle.jhtml...icleID=45400043

    This is a common TI (Texas Instruments) rolling code transceiver:

    http://www.ti.com/rfid/docs/manuals/pdfSpe...TMS37122-TR.pdf