Secured MCU Breaker Experts!

Posts Tagged ‘recover chip protected information’

The first useful thing to say about a PIC16C505 is that it has no data EEPROM. The part carries 1024 twelve-bit words of one-time program memory and 72 bytes of RAM, and nothing else that survives a power cycle. A request to recover its EEPROM is therefore always a request for something else, and finding out which of three things is meant takes less time than quoting the wrong job.

The memory map, as it actually is

Program memory occupies a single array of 1024 words, addressed by a ten-bit counter, with the configuration word outside that range and reached by a separate command. RAM is 72 bytes, volatile, and gone when the supply drops. There is no byte-writable array, no EEPROM data sheet section, and no EEADR register on this die. The 14-pin package exposes twelve I/O lines, one of which doubles as the programming voltage input, and that is the entire storage and access story.

Three things people mean by “the EEPROM”

The third row is not pedantry. Products built around this part usually keep calibration constants, hour meters and serial numbers in an external serial memory precisely because the microcontroller cannot store them, so the number the customer actually needs is often in the 93C46 and not in the PIC at all. Recovering the PIC first and discovering this afterwards is a week lost.

How to tell in ten minutes

Look at the board, not the part. A 93C46 sits on three or four lines with a chip select, and its pins are labelled CS, CLK, DI and DO. A 24C02 sits on two lines with pull-ups and no chip select. Either one can be read in circuit with a clip and a USB bridge, without touching the microcontroller, and without any risk to a device that still works. If there is no such part, the storage is inside the PIC and the OTP array is the target.

What recovery means in each case

For the external memory, recovery is a bus read and a decode: the contents come out as a byte stream whose field layout has to be inferred from how the firmware uses it, which is where the program image helps. For the OTP array, recovery means an array read, and the route depends on whether the code-protect bit is set. With protection clear the answer is an in-circuit read in minutes; with it set the route is the physical one described in breaking an IC and priced accordingly.

The mistake that costs a device

Reading an external EEPROM in circuit is safe. Reading the PIC in circuit on a live board is not always, because the programming voltage has to reach a pin that the rest of the circuit may be driving. On a 14-pin baseline part in a working product, the conservative sequence is to lift the programming pins rather than trust the surrounding logic, and where the board cannot be disturbed the part comes off. The trade-off between the two is the same one that governs in-circuit reads on the 12F509.

Where the 93C46 route ends

An external serial memory is easy to read and hard to interpret. The bytes come out in the order the firmware wrote them, which is rarely the order the customer expects, and the field boundaries exist only in the program that reads them. Two days of work is typical: an hour at the clip, and the rest matching offsets against the code. That is also the point at which the microcontroller image stops being an optional extra, because the layout of the external memory is defined by the code inside the PIC, and a partial decode is worse than no decode when the values feed a calibration.

Quoting it honestly

A quote for “PIC16C505 EEPROM recovery” that does not name which memory is being recovered is a quote for a guess. The honest version lists the three possibilities, prices the cheap one first, and states that the microcontroller read may turn out to be unnecessary. That is also the version that survives contact with the customer’s purchasing department, because it can be approved in stages. The older 18-pin parts in PIC16C52 and PIC16C54A are in the same position, and the same question applies to them.