??? 02/27/08 08:03 Modified: 02/27/08 08:04 Read: times |
#151511 - Couldn\'t you do that in another way Responding to: ???'s previous message |
Consider, for example, the way in which "ONCE" mode is done.
Knowing the state of nPSEN doesn't help much, but I suspect it would be necessary in order to defeat one or another method of cracking the MCU. Failing to provide nPSEN would certainly not HELP an attacker. The old Motorola single-chippers had an externally visible bus that provided access to what's inside, despite the fact they couldn't access external resources at all, thereby allowing one to observe when the internal bus went tristate, which enabled one to "jam" instructions into the MCU. One did have to know what, basically, happens inside the MCU, but once that was learned, cracking 'em was not impossible. In fact, one could jam instructions that loaded a program into internal RAM and then executed it, dumping the code via a port. MOT apparently built their MCU's as though they were on a PCB. RE |
Topic | Author | Date |
Obtaining maximum code security | 01/01/70 00:00 | |
Worth it ? | 01/01/70 00:00 | |
Protection with Patents | 01/01/70 00:00 | |
the value... again... | 01/01/70 00:00 | |
"OCR"ing a Design | 01/01/70 00:00 | |
It's a brave man | 01/01/70 00:00 | |
Specialist secure micros | 01/01/70 00:00 | |
this is a different form of security | 01/01/70 00:00 | |
Huge NREs? | 01/01/70 00:00 | |
What if you don't bond out nPSEN? | 01/01/70 00:00 | |
why not drop !EA | 01/01/70 00:00 | |
Don't Drop !EA! | 01/01/70 00:00 | |
Couldn\'t you do that in another way | 01/01/70 00:00 | |
Eliminating /EA | 01/01/70 00:00 | |
The value of PSEN | 01/01/70 00:00 | |
not only... | 01/01/70 00:00 | |
Brute-force copying | 01/01/70 00:00 | |
well, maybe... | 01/01/70 00:00 | |
Erase on tamper detect | 01/01/70 00:00 | |
Make the chip hard to access | 01/01/70 00:00 | |
It's quite impractical... | 01/01/70 00:00 | |
few thousand dollars ... Not at all | 01/01/70 00:00 |