| ??? 05/04/05 21:05 Modified: 05/04/05 21:08 Read: times |
#92943 - Individual sector security bits removal Responding to: ???'s previous message |
UM10109_1.pdf (P89LPC932A1 User Manual) on page 123 said:
Table 104: Sector Security Bytes (SECx) bit description 0 MOVCDISx - MOVC Disable. Disables the MOVC command for sector x. Any MOVC that attempts to read a byte in a MOVC protected sector will return invalid data. This bit can only be erased when sector x is erased. 1 SPEDISx - Sector Program Erase Disable x. Disables program or erase of all or part of sector x. This bit and sector x are erased by either a sector erase command (ISP, IAP, commercial programmer) or a 'global' erase command (commercial programmer). 2 EDISx Erase Disable ISP. Disables the ability to perform an erase of sector x in ISP or IAP mode. When programmed, this bit and sector x can only be erased by a 'global' erase command using a commercial programmer. This bit and sector x CANNOT be erased in ISP or IAP modes. It means, to prevent readout of the code it is enough to set bit 0, and perhaps set bit 1 to prevent some kind of tampering with it. Both these bits are erased together with erasing the sector. Unfortunately, it says nothing on effect of these bits on data readout using parallel programming nor ICP, but I believe it would work (otherwise it would have no reason to implement, would it?) Do you have any information regarding PP/ICP? Jan Waclawek |
| Topic | Author | Date |
| ISP-AES(or other tiny encryption)for LPC | 01/01/70 00:00 | |
| so it works? | 01/01/70 00:00 | |
| re so it works? | 01/01/70 00:00 | |
| could it be | 01/01/70 00:00 | |
| TEA | 01/01/70 00:00 | |
| re could it be? | 01/01/70 00:00 | |
| double-xor | 01/01/70 00:00 | |
| LPC935 | 01/01/70 00:00 | |
| TEA | 01/01/70 00:00 | |
| Tea time! | 01/01/70 00:00 | |
| TEA time ;) | 01/01/70 00:00 | |
More tea | 01/01/70 00:00 | |
| Please clarify requirements | 01/01/70 00:00 | |
| what i want, Dan | 01/01/70 00:00 | |
| Looks like you are set then | 01/01/70 00:00 | |
| to Dan | 01/01/70 00:00 | |
| Re: to Dan | 01/01/70 00:00 | |
| Mode of operation | 01/01/70 00:00 | |
| I underdstand now., thanks | 01/01/70 00:00 | |
| better done in hardware | 01/01/70 00:00 | |
| what about this? | 01/01/70 00:00 | |
| what are you making | 01/01/70 00:00 | |
| theft has to be prevented | 01/01/70 00:00 | |
| either or | 01/01/70 00:00 | |
| FM is just a "vehicle"... | 01/01/70 00:00 | |
| but a diesel | 01/01/70 00:00 | |
| it's easy | 01/01/70 00:00 | |
| again, why | 01/01/70 00:00 | |
| unsecure? | 01/01/70 00:00 | |
| yes | 01/01/70 00:00 | |
| Individual sector security bits removal | 01/01/70 00:00 | |
| lockbits | 01/01/70 00:00 | |
| Now i understand! | 01/01/70 00:00 | |
| same thing | 01/01/70 00:00 | |
| what am i making? | 01/01/70 00:00 | |
| be careful | 01/01/70 00:00 | |
| why GSM? | 01/01/70 00:00 | |
| FM | 01/01/70 00:00 | |
| FM | 01/01/70 00:00 | |
| for the xor method to work | 01/01/70 00:00 | |
| RC4 | 01/01/70 00:00 | |
| RC4 | 01/01/70 00:00 | |
| A reminder | 01/01/70 00:00 | |
| encryption | 01/01/70 00:00 | |
| pgpi.org | 01/01/70 00:00 | |
| ok thanks jez | 01/01/70 00:00 |