I suppose it's probably good to remind people that there's a reason the "lock the program from reading its own flash" security bits exist. They were added at the same time as the boot block was added since individual blocks could then be written with arbitrary code without erasing other security protected blocks. This exploit is not new, though. Aren't there notes in the data sheets (or app notes) that specifically mention that both the security bits for external reads as well as internal reads need to be set to avoid this situation? I seem to recall running across specific documents that covered this. -Adam On Tue, Aug 30, 2011 at 6:50 AM, Peter wrote: > This is scary and has implications for all PICs and other > MCUs which are capable to read their own code space in > despite of "page lock bits" being set. > > http://www.openpcd.org/images/HID-iCLASS-security.pdf > > -- Peter > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .