9S12 ram based bootloader.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

9S12 ram based bootloader.

4,876 Views
PadelisGR
Contributor III

Hi,

 

I am wondering if i can load a ram bootloader in a protected 9s12 using BDM to read the contents of the flash module.

The BDM is unlocked. There are tools out there that supposely "unlock" the flash module using BDM without erasing the contents.

Is this "unlock" procedure known or is it something like what i am thinking above?

Can someone give me some hints on that? I am thinking to buy a USBBDM and write a custom software to do what i want.

Labels (1)
Tags (2)
10 Replies

2,112 Views
lama
NXP TechSupport
NXP TechSupport

There are two terms: protection and security. If the MCU is secured the only possibility how to access the flash is mass erase of the device, unsecuring and then you can load new content into the MCU. (If you do not use SW backdoor key in the SW which is already loaded in the MCU)

When the device is protected, then it means some part of the flash is protected from accidental write to it. The protection can only be extended to larger range of the memory area. There is a possibility to unprotect the flash but it requires specific programming approach via BDM when you have to reprogram protection byte stored in the FLASH and reset the MCU to be FPROT loaded by new value.

For example, S12G MCU datasheet says about protection:

The (unreserved) bits of the FPROT register are writable with the restriction that the size of the protected

region can only be increased. While the RNV[2:0] bits are writable, they should be left in an erased state.

During the reset sequence, the FPROT register is loaded with the contents of the P-Flash protection byte

in the Flash configuration field at global address 0x3_FF0C located in P-Flash memory (see Table 24-4)

as indicated by reset condition ‘F’ in Figure 24-13. To change the P-Flash protection that will be loaded

during the reset sequence, the upper sector of the P-Flash memory must be unprotected, then the P-Flash

protection byte must be reprogrammed. If a double bit fault is detected while reading the P-Flash phrase

containing the P-Flash protection byte during the reset sequence, the FPOPEN bit will be cleared and

remaining bits in the FPROT register will be set to leave the P-Flash memory fully protected.

Trying to alter data in any protected area in the P-Flash memory will result in a protection violation error

and the FPVIOL bit will be set in the FSTAT register. The block erase of a P-Flash block is not possible if

any of the P-Flash sectors contained in the same P-Flash block are protected.

Best regards,

Ladislav

2,112 Views
PadelisGR
Contributor III

So you think that i can use hardware BDM commands to program the FPROT register and then reset the MCU?

0 Kudos

2,112 Views
lama
NXP TechSupport
NXP TechSupport

Hi,

the question is whether the MCU is secured or flash is protected. (see Flash Protection/Security Field in the data sheet)

1) If protected: FPROT can't be reprogrammend. The only protection byte stored in flash can be reprogrammed. This byte is automatically copied into FPROT register during reset. Then just reset the MCU and the flash is unprotected.

2) If secured: In this case the only possibility how to make internal resources accessible is to mass erase the MCU. For this purpse you can use without any problems CodeWarrior debuger or www.pemicro.com unsecure12. These two tools can help you to unsecure the MCU and you do not want to use your own code. However, the content of lost.

The device is after mass errase secured. Then after reset the content of the address FF0F is copied to the FSEC register. The content of the address 0xFF0F after mass erase is 0xFF which, using FSEC register pattern sets bits SEC to 11 which means the device is secured. So, if you want to be able to use device after mass erase you have to program the address 0xFF0F to the value which has bits SEC set to the value 10 unsecured. (Flash Security Register (FSEC)). This is the only way how to unsecure the device because all bits in the FSEC register are readable but are not writable.

Another way how to unsecure the device is to use unsecure command from CodeWarrior debugger or unsecure program from www.pemicro.com pages.

If you use USB multilink you have to use unsecure Option MultilinkCyclonePro->Unsecure in the CodeWarrior Hiwave Debugger.

or you can use external usecure program which can be downloaded from pemicro pages.

Unsecure_12 (8060 KB): Utility which unsecures HCS12 devices via P&E's BDM Interfaces such as Cyclone-PRO, USB-ML-12, and BDM-Multilink. .

http://www.pemicro.com/downloads/download_file.cfm?download_id=16

Unsecure_12 Help Files (20 KB)  This .hlp file describes the use and operationg of the Unsecure_12 program which is used with P&E's interface devices to unsecure proeviously secured HCS12 microcontrollers.

http://www.pemicro.com/downloads/download_file.cfm?download_id=14

memories will be erased.

If you want to do it youurself then you can use as a clue command file which can be found in the p&e_erase_unsecure_hcs12.cmd command file of the CodeWarrior. The CodeWarrior (standard edition) can be downloaded from Fresscale pages and works like proffesional for 30 days. Then it has some limitations.

A content of p&e_erase_unsecure_hcs12.cmd  command file is:

// ver 1.1 (7/7/04)

// HCS12X Core erasing + unsecuring command file:

// These commands mass erase the chip then program the security byte to 0xFE (unsecured state).

// Evaluate the clock divider to set in ECLKDIV/FCLKDIV registers:

// An average programming clock of 175 kHz is chosen.

// If the oscillator frequency is less than 10 MHz, the value to store

// in ECLKDIV/FCLKDIV is equal to " oscillator frequency (kHz) / 175 ".

// If the oscillator frequency is higher than 10 MHz, the value to store

// in ECLKDIV/FCLKDIV is equal to " oscillator frequency (kHz) / 1400  + 0x40 (to set PRDIV8 flag)".

// Datasheet proposed values:

//

// oscillator frequency ECLKDIV/FCLKDIV value (hexadecimal)

//

//  16 MHz                              $49

//   8 MHz                               $27

//   4 MHz                               $13

//   2 MHz                               $9

//   1 MHz                               $4

define CLKDIV 0x49

FLASH RELEASE   // do not interact with regular flash programming monitor

//mass erase entire flash – all flash blocks

reset

wb 0x03c 0x00 //disable cop

wait 20

wb 0x100 CLKDIV  // set FCLKDIV clock divider

wb 0x104 0xFF    // FPROT all protection disabled

wb 0x105 0x30    // clear PVIOL and ACCERR in FSTAT register

wb 0x102 0x00    // clear the WRALL bit in FTSTMOD

wb 0x105 0x02

wb 0x102 0x10    // set the WRALL bit in FTSTMOD to affect all blocks

ww 0x108 0xFFFE

ww 0x10A 0xFFFF

wb 0x106 0x41    // write MASS ERASE command in FCMD register

wb 0x105 0x80    // clear CBEIF in FSTAT register to execute the command

wait 20          // wait for command to complete [tenths of seconds]

//mass erase eeprom

wb 0x110 CLKDIV  // set ECLKDV clock divider

wb 0x114 0xFF    // EPROT all protection disabled

wb 0x115 0x30    // clear PVIOL and ACCERR in ESTAT register

wb 0x112 0x00    // clear the WRALL bit in FTSTMOD

wb 0x115 0x02

ww 0x118 0x0C00  // write to EADDR eeprom address register

ww 0x11A 0x0000  // write to EDATA eeprom data register

wb 0x116 0x41    // write MASS ERASE command in ECMD register

wb 0x115 0x80    // clear CBEIF in ESTAT register to execute the command

wait 20          // wait for command to complete

//reprogram Security byte to Unsecure state

reset

wb 0x03c 0x00            //disable cop

wait 20

wb 0x102 0x00    // clear the WRALL bit in FTSTMOD

wb 0x105 0x02

wb 0x100 CLKDIV  // set FCLKDIV clock divider

wb 0x100 CLKDIV  // set FCLKDIV clock divider

wb 0x104 0xFF    // FPROT all protection disabled

wb 0x105 0x30    // clear PVIOL and ACCERR in FSTAT register

wb 0x102 0x00    // clear the WRALL bit in FTSTMOD

wb 0x105 0x02

ww 0xFF0E 0xFFFE // write security byte to "Unsecured" state

wb 0x106 0x20    // write MEMORY PROGRAM command in FCMD register

wb 0x105 0x80    // clear CBEIF in FSTAT register to execute the command

wait 20          // wait for command to complete

reset

undef CLKDIV     // undefine variable

Best regards,

Ladislav

2,112 Views
PadelisGR
Contributor III

According to the following picture :

5XuZVMt.png

First line has the backdoor key and a reserved word,

second line has a reserved word,

third line has all the bits which are set in the FPROT1 register,

fourth line has all the bits which are set in the FPROT0 register and a reserved byte

and fifth line has the bits which are set in the FSEC register.

According to that data there is no backdoor key and the Flash is secured.

This is straight from the dump that i did with a tool that bypasses the security options of the 9S12.

I am trying to do the same with usbdm. How does that tool bypasses the security and reads the data from the flash? This is where the RAM Bootloader came to my mind.

0 Kudos

2,112 Views
lama
NXP TechSupport
NXP TechSupport

Hi,

I hope you understand I will not continue with thinking how to hack the MCU.

Also to Edward:

First of all, there's absolutely no 100% secure application, micro, device, etc. If there's enough demand to "hack" something, it will be done. Just ask Microsoft and the XBOX, Apple and the iPhone or the DVD industry. Saying that our parts are 100% secure could be a lie. So, the answer on the question is really not important because it is HW oriented and also related to security. Simple, if you want to read the transistors you have to know where they are, do some manual invasion which in result can lead to incorrect reading security bytes. I am really not able to imagine how you want to find on the silicon between millions of transistors the right one and how you want to measure its status. We don't claim that our parts are 100% secure. Official announcement is: No security feature is absolutely secure. However, Freescale’s strategy is to make reading or copying the FLASH and/or EEPROM difficult for unauthorized users. Our micros implement a very strong security method by allowing designers to disable the BDM, use Backdoor access and prevent read/writes to internal memory. So, in this way, we are at the same level or better than our competitors. However, if someone finds a way to break the micro by stressing it or using it outside the spec, then there is not a lot we can do.

Hacker (term) - Wikipedia, the free encyclopedia

Best regards,

Ladislav

0 Kudos

2,112 Views
kef2
Senior Contributor IV

Ladislav,

sure there's no 100% secure device. But IMO there's no excuse for the fact that out of the shelf tool and few wires make S12 unlocked in seconds. Is it hard for unauthorized users? Absolutely not. Looks like chip doesn't even have to be removed from PCB! I could understand that ~10 years of the old S12D history could be enough to hack it. But S12X, S12XE also seem having the same security hole? I wonder if latest S12P/S12G are listed too. Not a lot can be done? I don't agree with this. It shouldn't be hard to get this hacking tool and find how it breaks chip security and add protection for this.

You said BDM disableable. How? I see no NV bit that could do this.

padelis,

"little hole" could be left intentionally to support fancy programmer makers or for some goverment services... :-)

0 Kudos

2,112 Views
PadelisGR
Contributor III

To lama:

sure no problem with that. It is just nice to know how someone thought to bypass this security, and if there is an issue with the security of any device out there. That makes you guys come out with more secure products.

To edward:

It is not just freescale, it is every company that produces secure chips. All have a "little hole" that someone might discover and get in. You just need to know that this "little hole" is not there intentionally or forgotten. It is there because no one saw it or never thought that it would be there. You shouldnt blame the companies for that, they do their best and as soon as they discover the issues they try to correct them.

So i consider this as closed as there is no reason to discuss it further and harm our hearts.

As a last comment i can say that i like thinking "out of the box" and sleeping at the unsafe side. It just makes my life more adventurous.

Thank you for all the replies.

0 Kudos

2,112 Views
kef2
Senior Contributor IV

I wonder how do you interpret 5th line and what is NV6_FSEC? There's no NV6 bit in FSEC. Bits 6 and 7 are KEYEN bits, no NV6 (unused, reserved nonvolatile bit 6) in FSEC.

Even if some fancy programmer shows some data, it doesn't mean this fancy programmer is reading meaningful data and not garbage. Are you sure this tool is really able to unsecure and read secured MCU, allowing to dublicate code? Could you mention this tool and www address?

0 Kudos

2,112 Views
PadelisGR
Contributor III

The picture that i showed you is from IDApro. I have completely disassembled the contents of the flash module.

The mcu that i am working on is a t64 type and there only one KEYEN bit.QsM1sIv.png

So my NV6_FSEC is how i named that bit in the IDApro structure. Actually it is the NV6 bit as you see above.

For urls on programmers that do bypass the security on these MCUs is following:

http://www.xprog-m.com/product.php?id_product=50

http://www.scorpio-lk.com/eng/orange5_main_eng.html

and at the bottom there is a "general recommendation":
http://www.eldb.eu/index.php?route=information/information&information_id=15

These tools are sold as vehicle tools many years now and they are worth the money. There are more tools that do the same thing like "UPA programmer".

The data that i have would be garbage if i reprogrammed the unit with those data and it wouldnt work. You could say that "how do you know that the data are erased?" and the discussion would go on for ever.

What is strange is that as an Electrical Engineer and programmer i cant understand how these tools bypass the security. This is why i started this discussion here. More brains work better than one. :smileyhappy:

reference datasheet is : http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12T64AF16V1.pdf

0 Kudos

2,112 Views
kef2
Senior Contributor IV

OK. It seems like Freescale chip security works only for some naive people that are so kind to pay money for chips for naive people. Isn't it, Freescale???? Not only old S12, but S12X, S12XE are listed as supported by thieves hardware... and no Freescale published list of chips with security holes, no ANs of how to avoid security unlock! Cool and nice.

Looking at "general recommendation", breach time limit lets me think that they are using some out of specs condition. Perhaps high voltage is applied to BKGD and or /RESET pin, you could check with your scope. Oscillator wire could be used to supply some special clock, check with your scope.

0 Kudos