Break IC, Recover MCU, Microcontroller Reverse Engineering

Archive for September, 2012

In hardware implementation, security fuses are physically located on the chip die. This could mean a separate memory cell located next to the main memory array, or even far from it. For example, this is the case for all Microchip PIC MCU and Atmel AVR MCU. In both cases, the security is not very high as the fuses can be easily found and disabled by one or another method. Meantime, some methods require very expensive equipment and even if the people who want to break MCU processor knows where the fuse is, he will not be able to reset it until he gets access to such equipment and learns how to use it.

Extract MCU Firmware from program memory and data memory after remove the tamper resistance system of microcontroller and replicate the code to new MCU;

Some manufacturers intentionally do not provide any programming specifications for their MCU microcontrollers. That does not give very good protection on its own, and only slightly increases the cost of microcontroller reverse engineering, because this MCU firmware can be extracted by observing the signals applied to the IC chip during programming in a development kit or in a universal programmer.

Obviously, for the highest security, the system would not have any programming interface at all, and would not provide any access to stored data. This is normally the case for Mask ROM microcontrollers and smartcards. The only practical ways of attack chip flash in this case would be either to microprobe the data bus to recover the information or use power analysis and glitch attacks to exploit any vulnerability in software.

Relatively high security can be obtained when a microcontroller is user programmable but does not provide any read-back facility – only verify and write check, for example in the NEC 78K0S family Flash microcontrollers.

Of course this should be implemented properly to avoid the situation where the microprocessor decryption can force the system to verify one byte at a time. In this case he would need on average 128 attempts per byte (28 × 0.5) and assuming the byte access cycle is 5 ms it will take him less than a day to extract the contents of the memory, which is usually between 4 Kb and 64 Kb. Even if the verify operation is applied to large blocks of data, the mcu firmware extraction could try glitch attacks to reduce the cycle to a single byte.

Read MCU Code out from embedded and secured flash memory and eeprom memory can help to recover the content from master microcontroller;

Another memory type used in all Microcontroller MCUs (mainly as a register file memory and operational memory) is SRAM. It is also used in secure microcontroller MCUs such as the Dallas DS5002FP and JAVA iButtons where the information should disappear quickly if atampering attempt is sensed. An SRAM memory cell consists of six transistors, four of which create a flip-flop while the other two are used for accessing the cell inside the array.

SRAM memory offers very good security protection, as the information from it can be easily erased by disconnecting the power supply if the alarm is triggered. Performing invasive or semi-invasive MCU Crack is very problematic because any attempt to extract microcontroller code surface would very likely destroy the data. For example, decapsulation requires very strong acids to be used which a

re conductive and cannot be used on a powered up chip. Even if chip atmega2561v attacker manages to access the die, the state of its transistors cannot be observed optically. Microprobing is difficult because the internal wires are buried under top metal bit-lines, ground and power supply wires. The only practical way to access the memory is from the rear side of the chip die, but this requires more expensive equipment and a highly skilled IC Attacker.

Meantime, there are some semi-invasive techniques that allow observation of the memory state, but require special laser scanning microscopes. At the same time non-invasive mcu attacks can be used to exploit any problems that might exist in the memory interface, as happened with the Dallas Semiconductor secure microcontrolle. 

Data remanence could cause some problems to SRAM security as well. At temperatures below 0˚C some samples of the SRAM chips retain information for hours. But, in general, SRAM memory offers a very good level of protection and low-temperature attacks can be avoided by placing temperature sensors into the secure module enclosure as in the IBM 4758 cryptoprocessor.