Lpc2000

B3 in ARM7TDMI-S reference manual does not address the issue I raised.

The response from Philips is what you would expec.  Philips is not the
only manufacturer that produces devices with flash memory.  The other
manufacturs do change their technology too.

Unlike Philips, they publish the programming algorithm so that we all
can evaluate it for what it is worth.  Philips programming algorithm
has no safeguards whatsoever with respect to what happens when code
fails -- not just user code, but the supplied boot loader code too.

I do not know of any other manufacturer who sells you 128K flash and
at the same time demands that reserve 8K or 12K of this for the sole
use by the manufacturer, to install code that will enable the device
to accessed from the outside world, but with no garantees whatsoever.

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> wrote:
>
> Jaya,
> 
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
> 
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
> 
> This should give you a good idea why the bootcode is not available in
> source code:
> 
> ----  quote  -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
> 
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
> 
> ----  end quote  -------
> 
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing. 
> 
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
> 
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
> 
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
> 
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
> 
> As long as you post your assumptions, non-applicable bootloaders ....
> 
> Bob
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> >
> > --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> > > Reverse disassembly of bootloader is of no use in hacking the chip.
> > > Regards
> > 
> > If this is true, Philips would have provided us with source for the
> > boot loader.
> > 
> > You do not expect Philips to build defects into the boot loader.  It
> > does not follow however that there are no defects, or that they cannot
> > be exploited.
> > 
> > In a regime where obscurity is critical component of security,
> > exposing internals is a high security risk.
> > 
> > Jaya
> >
>