Securing code?

A clever person would be able to replace the Flash chips without
disturbing the Battery backed MPU ran, and extract the contents of this
ram to be used in other copies of the system.



No you do not need to do a complete Flash chip replacement.

This is done by piggy backing the installed Flash chip with another
Flash device and moving the /CS to the new Flash.



This is a very simple way to hack the code.



Jim Ashby



Daniel wrote:

Nathan,



Doesn't taking this approach mean that if the module runs out of

battery it would stop working? The variable containing the key would

get a random value after the battery is removed or runs out, I imagine.



--- In rabbit-semi@yahoogroups.com,
"Nathan Johnston"

<nathan.johnston@...> wrote:

>

> A R4000 powerpoint presentation I was given last year said that it
had

> 32 bytes of internal battery backed RAM to store security keys. I
have

> not used one to personally verify this though.

>

> We previously did a job for a customer where there was a fairly
large

> risk of it being copied. Before loading the production code we
would run

> a program that in addition to performing calibration of the ADC's
etc it

> also loaded a key that ultimately got stored in battery backed ram
and

> was checked at powerup. It worked quite well. In one case one of
their

> units in India stopped functioning after the "curious" owners
decided to

> open up the unit and remove the core module :-)

• 
  
• 
  
   27
  
  
  New Members
  
  
  
  
• 
  
   1
  
  
  New Files
  
  
  
  

• 
  
• Rabbit
  
• Microprocessor architecture
  
• Microcontrollers
  
• Embedded module