English | 中文html
NXP-MCUBootUtility是一个专为NXP MCU安全加密启动而设计的工具,其特性与NXP MCU里BootROM功能相对应,目前主要支持i.MXRT系列MCU芯片,与NXP官方的标准安全加密配套工具集(OpenSSL, CST, sdphost, blhost, elftosb, BD, MfgTool2)相比,NXP-MCUBootUtility是一个真正的一站式工具,一个工具包含NXP官方全部加密配套工具的功能,而且是全图形用户界面操做。借助于NXP-MCUBootUtility,你能够轻松上手NXP MCU安全加密启动。
NXP-MCUBootUtility主要功能以下:python
- 支持i.MXRT全系列MCU,包含i.MXRT101五、i.MXRT102一、i.MXRT1051/105二、i.MXRT1061/106二、i.MXRT1064 SIP
- 支持UART和USB-HID两种串行下载方式(COM端口/USB设备自动识别)
- 支持五种经常使用格式(elf/axf/srec/hex/bin)源image文件输入并检查其连接地址的合法性
- 源image文件既能够是裸源image文件,也能够是含启动文件头的bootable image文件
- 支持将裸源image文件自动转换成i.MXRT能启动的Bootable image
- 支持将裸源image文件自动转换成MfgTool和RT-Flash工具能下载的.sb格式文件
- 支持下载Bootable image进主动启动设备 - FlexSPI NOR、SEMC NAND接口Flash
- 支持下载Bootable image进备份启动设备 - LPSPI接口NOR/EEPROM Flash
- 支持DCD配置功能,可用于加载image进SDRAM执行
- 支持用于开发阶段的非安全加密启动(未签名加密)
- 支持基于HAB实现的安全加密启动(单签名,签名和加密),证书自动备份
- 支持基于BEE实现的安全加密启动(惟一SNVS key,用户自定义key)
- 支持MCU芯片内部eFuse的回读和烧写操做(即专用eFuse烧写器)
- 支持外部启动设备的任意读写擦操做(即通用Flash编程器)
- 支持从外部启动设备回读Bootable image,并对其组成部分(NFCB/DBBT/FDCB/EKIB/EPRDB/IVT/Boot Data/DCD/Image/CSF/DEK KeyBlob)进行标注
NXP-MCUBootUtility彻底基于Python语言开发,而且源代码所有开源,其具体开发环境为Python 2.7.15 (32bit)、wxPython 4.0.三、pySerial 3.四、pywinusb 0.4.二、bincopy 15.0.0、PyAudio 0.2.十一、PyInstaller 3.3.1(或更高)。git
NXP-MCUBootUtility在发布时借助PyInstaller将全部的Python依赖所有打包进一个可执行文件(\NXP-MCUBootUtility\bin\NXP-MCUBootUtility.exe),所以若是不是对NXP-MCUBootUtility的二次开发,你不须要安装任何Python软件及相关库。github
Note1: 使用NXP-MCUBootUtility以前必须先从NXP官网下载 HAB Code Signing Tool工具,并将其解压放在\NXP-MCUBootUtility\tools\cst\目录下,而且须要修改代码使能AES功能从新生成\NXP-MCUBootUtility\tools\cst\mingw32\bin\cst.exe,不然HAB签名以及加密相关功能没法使用。具体步骤能够参考这篇博客 《开启NXP-MCUBootUtility工具的HAB加密功能 - cst.exe》。web
Note2: 使用NXP-MCUBootUtility以前必须编译\NXP-MCUBootUtility\tools\image_enc\code下面的源文件生成image_enc.exe,并将其放置在\NXP-MCUBootUtility\tools\image_enc\win,不然BEE加密相关功能没法使用。具体步骤能够参考这篇博客 《开启NXP-MCUBootUtility工具的BEE加密功能 - image_enc.exe》算法
Note3: 源代码包里的NXP-MCUBootUtility.exe是在Windows 10 x64环境下打包的,也仅在该环境下测试过,若是因系统缘由没法直接使用,你须要先安装 Python2.7.15 x86版本 (安装完成后确认\Python27\, \Python27\Scripts\目录被添加到系统环境变量Path里),而后在\NXP-MCUBootUtility\env\目录下点击do_setup_by_pip.bat安装开发NXP-MCUBootUtility所依赖的Python库,最后点击do_pack_by_pyinstaller.bat从新生成NXP-MCUBootUtility.exe可执行文件。编程
Note4: 必须使用Python2 x86版本去打包NXP-MCUBootUtility,由于NXP-MCUBootUtility使用了pywinusb库,该库在Python2 x64版本下没法用PyInstaller打包,pywinusb做者没有计划修复该问题。缓存
NXP-MCUBootUtility是一个是纯绿色免安装的工具,下载了源代码包以后,直接双击\NXP-MCUBootUtility\bin\NXP-MCUBootUtility.exe便可使用。使用NXP-MCUBootUtility没有任何软件依赖,不须要额外安装任何软件。
在NXP-MCUBootUtility.exe图形界面显示以前,会首先弹出一个控制台窗口,该控制台会伴随着NXP-MCUBootUtility.exe图形界面一块儿工做,不少图形界面的操做都会在控制台窗口看到对应的底层命令执行,保留控制台主要是为了便于定位NXP-MCUBootUtility.exe的问题,目前NXP-MCUBootUtility尚处于早期阶段,等后期软件成熟会考虑移除控制台。安全
NXP-MCUBootUtility软件目录组织以下:app
\NXP-MCUBootUtility \apps --放置NXP官方评估板示例image文件 \bin --放置NXP-MCUBootUtility可执行文件及用户配置文件 \doc --放置NXP官方安全启动相关的参考文档 \env --放置用于安装NXP-MCUBootUtility开发环境以及打包脚本 \gen --放置NXP-MCUBootUtility使用过程当中生成的临时文件 \bd_file --根据配置动态生成的BD文件 \bee_crypto --BEE加密过程当中生成的文件 \bootable_image --生成的bootable image文件 \dcd_file --生成的DCD数据文件 \hab_cert --HAB签名过程当中生成的文件 \hab_crypto --HAB加密过程当中生成的文件 \log_file --保存软件操做记录日志 \sb_image --生成的.sb格式文件 \user_file --软件运行过程当中缓存的临时文件 \gui --放置开发NXP-MCUBootUtility UI构建工程文件 \img --放置NXP-MCUBootUtility使用过程当中需加载的图片 \src --放置开发NXP-MCUBootUtility的全部Python源代码文件 \tools --放置NXP-MCUBootUtility使用过程当中需调用的外部程序 \blhost --与Flashloader通讯的上位机命令行工具 \cst --HAB加密的配套命令行工具 \elftosb --生成bootable image的命令行工具 \ide_utils --各IDE提供的image格式转换工具 \image_enc --BEE加密的配套命令行工具 \imgutil --生成DCD数据的命令行工具 \openssl --生成证书和秘钥的标准工具 \sdphost --与ROM通讯的上位机命令行工具
下图为NXP-MCUBootUtility工具的主界面,界面主要由六部分组成,各部分功能以下:
- 【Menu Bar】:功能菜单栏,提供软件通用设置。
- 【Target Setup】:目标设备设置栏,提供MCU Device和Boot Device配置选项。
- 【Port Setup】:串行接口设置栏,选择用于链接MCU Device的接口。
- 【Device Status】:目标设备状态信息栏,当链接上目标设备以后,用于显示目标设备的状态。
- 【Secure Boot Action】:安全加密启动主界面,提供对目标设备作安全加密启动的全部操做。
- 【Log Info】:操做日志栏,记录软件操做日志。
在使用NXP-MCUBootUtility工具前主要有两个准备工做:1、准备好i.MXRT硬件板以及串行下载链接线(USB/UART);2、准备好用于下载进Flash的源image文件。
关于串行下载线链接,须要查看i.MXRT参考手册System Boot章节,确保链接的UART/USB引脚是BootROM指定的。
关于源image文件准备,NXP-MCUBootUtility工具可以识别五种常见格式(elf/axf/srec/hex/bin)的image,源image既能够包含i.MXRT加载启动头(IVT, BootData等),也能够不包含这些i.MXRT加载启动头。若是源image中不包含这些启动头,NXP-MCUBootUtility会自动添加文件头。
以NXP官方SDK为例进一步讲解源image文件的生成,注册并登陆NXP官网,来到 MCUXpresso SDK Builder 页面,选择合适的MCU芯片以及IDE(以RT1060芯片,IAR IDE为例)并点击Download SDK后即可获得SDK_2.4.0_EVK-MIMXRT1060.zip。
使用IAR打开SDK包里的\boards\evkmimxrt1060\demo_apps\led_blinky\iar\led_blinky.eww示例应用:
led_blinky应用其实包含了三个工程(ram/flexspi_nor/sdram),分别对应三个不一样的linker文件(.icf),其中ram工程生成的image便是所谓的Non-XIP image,flexspi_nor工程生成的image便是所谓的XIP image。
默认状况下,ram工程和flexspi_nor工程生成的image文件是没法直接为NXP-MCUBootUtility所用的,须要作一些小小的改变。
ram工程须要修改linker文件以下:(推荐从0x3000开始连接中断向量表,中断向量表前面预留一段内存用于放置i.MXRT加载启动所需的文件头)。
define symbol m_interrupts_start = 0x00003000; // 0x00000000 define symbol m_interrupts_end = 0x000033FF; // 0x000003FF define symbol m_text_start = 0x00003400; // 0x00000400 define symbol m_text_end = 0x0001FFFF; define symbol m_data_start = 0x20000000; define symbol m_data_end = 0x2001FFFF; define symbol m_data2_start = 0x20200000; define symbol m_data2_end = 0x202BFFFF;
flexspi_nor工程须要修改工程配置选项里的Defined symbols以下:(将XIP_BOOT_HEADER_ENABLE设为0,即不须要生成包含i.MXRT加载启动文件头的image; 若是保持XIP_BOOT_HEADER_ENABLE为1不变,那么生成的可执行image文件会包含i.MXRT加载启动文件头)。
若是只是为了快速验证NXP-MCUBootUtility工具,在NXP-MCUBootUtility\apps文件夹下默认存放了全系列恩智浦官方i.MXRT评估板的led_blinky应用的image文件。
在使用NXP-MCUBootUtility时首先须要配置目标设备,目标设备包括MCU Device和Boot Device。以NXP官方开发板EVK-MIMXRT1060为例,该开发板主芯片为i.MXRT1062DVL6A,因此【MCU Device】应设为i.MXRT106x。且以最经常使用的FlexSPI NOR启动为例,【Boot Device】设为FLEXSPI NOR,开发板上对应的外部存储芯片为IS25WP064AJBLE,其是一颗经常使用的四线QSPI NOR Flash,咱们须要在软件里进一步配置该Boot Device,单击【Boot Device Configuration】按钮可弹出以下新的配置页面:
在弹出的名为FlexSPI NOR Device Configuration页面里能够看到不少描述Multi-IO SPI NOR Flash特性的选项,好比Device Type、Query Pads等,这些选项都须要被正确地设置,以与开发板上的外部存储芯片相匹配。
除此之外,页面上还有一个名为【Use Typical Device Model】的选项,NXP-MCUBootUtility软件预先定义了一些经常使用的Multi-IO SPI NOR Flash型号模型,若是开发板上的外部存储芯片刚好在软件预约义的型号列表里,那么你能够直接在【Use Typical Device Model】选择对应型号,而没必要在Nor Option里逐一配置。
EVK-MIMXRT1060开发板上的IS25WP064AJBLE芯片属于ISSI - IS25LP064A大类,所以咱们只须要在【Use Typical Device Model】选择ISSI - IS25LP064A并点击【Ok】即完成了目标设备的设置。
设置好目标设备以后,下一步即是链接目标设备,以USB-HID接口链接为例,给EVK-MIMXRT1060板子供电,并用USB Cable将PC与J9口链接起来,若是一切正常,应该能够在设备管理器找到vid,pid为0x1fc9,0x0135的HID-compliant vendor-defined device设备被枚举。若是没有发现该HID设备,请仔细检查板子SW7拨码开关是否将Boot Mode设为2'b01即Serial Downloader模式。
确认HID设备存在以后,在【Port Setup】选中USB-HID,而后直接点击【Connect to ROM】按钮,此时软件便会自动完成目标设备链接全过程(使用sdphost链接ROM,获取一些MCU内部寄存器信息,使用sdphost加载Flashloader并跳转过去,使用blhost链接Flashloader,获取一些eFuse信息,使用blhost去配置boot device并获取boot device meomry信息),这个过程须要大概5s的时间,若是目标设备链接正常,你能够看到指示灯变蓝,而且【Connect to ROM】按钮标签变为【Reset Device】。若是目标设备链接失败,指示灯会变红,而且【Connect to ROM】按钮标签变为【Reconnect】。
目标设备链接成功后能够在目标设备状态信息栏看到一些有用的设备状态信息,好比MCU芯片的UUID值、HAB状态、与启动相关的重要Fuse值,Boot Device的Page/Sector/Block大小等。
确保菜单栏Tools/Generate .sb file选项勾选的是"No",目标设备链接成功后即可以开始最核心的安全加密启动操做,在作安全加密启动以前先来介绍安全加密启动主界面分布:
- 【Image Generation Sequence】:image生成窗口,用于对源image进行加密安全处理,生成可放在Boot Device中的bootable image
- 【Image Loading Sequence】:image下载窗口,用于将生成的bootable image下载进Boot Device中,而且在MCU中烧录相应的Fuse值(各类Key,HAB设置等)
- 【eFuse Operation Utility】:eFuse回读与烧录窗口,用户可烧录自定义值进Fuse Region。
- 【Boot Device Memory】:image回读与标注显示窗口,用于从Boot Device回读已下载的Bootable image数据,并对数据组成各部分进行标注
- 【Secure Boot Type】:安全加密模式选择,选择想要安全模式(不使能安全,HAB单签名,HAB签名加密,BEE加密)。
- 【All-In-One Action】:一键操做,image生成窗口和image下载窗口里激活的操做自动按序执行
第一种模式是最简单的模式,即不启动任何安全措施,通常用于产品开发调试阶段。
【Secure Boot Type】选择“DEV Unsigned Image Boot”,而后点击【Browse】按钮选择一个原始image文件(使用IDE生成的裸image文件便可,不须要包含任何i.MXRT启动所需的额外文件头),点击【All-In-One Action】按钮便可完成bootable image生成与下载全部操做。
Note: 软件若是设置为Auto-detect image format选项,则根据文件后缀名自动识别源文件格式。可是对于MCUXpresso或者GCC生成的axf文件,须要主动设置为".out(axf) from MCUXpresso/GCC ARM"。
上图中Step4和Step5并非必需操做,仅是用于确认【All-In-One Action】按钮操做是否成功,尤为是Step5操做,能够对应image下载窗口里显示的Bootable image构成图作一遍检查。
一切操做无误,板子上SW7拨码开关将Boot Mode设为2'b10即Internal Boot模式,其他保持全0,从新上电即可以看到unsigned image正常执行了。
第二种模式是初级的安全模式,即仅对image进行签名认证,通常用于对产品安全性要求较高的场合。签名认证主要是对image合法性进行校验,检测image是否被异常破坏或篡改,若是检测发现image不合法,那么MCU便不会启动执行该image。
【Secure Boot Type】选择“HAB Signed Image Boot”,而后输入serial(必须是8位数字)以及key_pass(任意长度字符)后点击【Advanced Cert Settings】按钮配置全部签名认证的参数(熟悉 NXP官方HAB Code Signing Tool工具 使用的朋友应该对这些设置很熟悉),再点击【Browse】按钮选择一个原始image文件,最后点击【All-In-One Action】按钮便可完成bootable image生成与下载全部操做。
上图中Step5主要确认两点:1、HAB状态是不是Closed的(Fuse 0x460[31:0]的bit1为1'b1);2、SRKH是否被正确烧录(Fuse 0x580 - 0x5f0,一共256bit,即sha-256算法),SRKH是最终bootable image里CSF数据里的Public RSA Key的Hash值,用于校验Public RSA Key是否合法。
一切操做无误,板子上SW7拨码开关将Boot Mode设为2'b10即Internal Boot模式,其他保持全0,从新上电即可以看到HAB signed image正常执行了。
由于此时MCU芯片HAB状态已是Closed,而且SRKH已经被烧录没法更改,因此未经签名认证的image没法正常运行,在软件目录\NXP-MCUBootUtility\tools\cst\crts文件夹下存放着Private RSA Key文件,请妥善保存好,一旦遗失,那么新的image将没法被正确签名从而致使HAB认证失败没法被启动执行。
第三种模式是中级的安全模式,即对image进行签名认证以及HAB级加密,通常用于对产品安全性要求很高的场合。签名认证主要是对image合法性进行校验,而加密则能够保护image在外部Boot Device中不被非法盗用,由于在外部Boot Device中存放的是image的密文数据,即便被非法获取也没法轻易破解,而且加密是和MCU芯片绑定的,由于HAB加密过程当中使用了MCU内部SNVS模块里的惟一Master Secret Key。
【Secure Boot Type】选择“HAB Encrypted Image Boot”,而后配置全部签名认证的参数(若是本地已有证书,能够不用配置,软件会尝试复用),再点击【Browse】按钮选择一个原始image文件,最后点击【All-In-One Action】按钮便可完成bootable image生成与下载全部操做。
上图中Step6操做以后能够看到下载进Boot Device里的image部分确实是密文,实际上HAB加密仅支持加密image区域,其余区域(好比FDCB、IVT、Boot Data等)均没有加密。
一切操做无误,板子上SW7拨码开关将Boot Mode设为2'b10即Internal Boot模式,其他保持全0,从新上电即可以看到HAB signed encrypted image正常执行了。
你可能会好奇,既然image是通过HAB加密的,那么密码在哪里?怎么设置的?其实image加密操做彻底被HAB配套工具封装好了,HAB加密使用的AES-128算法,其对应的128bits的AES-128 Key不是由用户自定义的,而是HAB加密工具自动随机生成的,而且每一次加密操做生成的AES-128 Key都是不同的,即便你没有更换输入的原始image。AES-128 Key保存在\NXP-MCUBootUtility\gen\hab_crypto\hab_dek.bin文件里。
从上图中image下载窗口里显示的Bootable image构成图里能够看出,相比HAB单签名的方式,HAB签名加密方式最终使用的Bootable image的最后多了一个DEK KeyBlob组成部分,这个DEK KeyBlob是经过MCU芯片内部SNVS模块里的Master Secret Key对hab_dek.bin里的key数据进行动态加密生成的,由于Master Secret Key是芯片惟一的,所以DEK KeyBlob也是芯片惟一的,这是保护image不被非法盗用的关键。
关于HAB加密为什么不支持XIP Image,其实简单分析一下启动原理便清楚,Image在Boot Device里存储的是密文,这部分密文必需要通过HAB解密成明文才能够被CPU执行,所以必需要指定不一样的存储空间去存放Image明文,Non-XIP image自然指定了明文应存放在芯片内部SRAM或者外挂SDRAM中,而XIP Image是在Boot Device中直接执行的,通常明文地址与密文地址是相同的,所以HAB加密不支持XIP Image。
第四种模式是高级的安全模式,即用惟一SNVS Key对image进行单引擎BEE级加密,通常用于对产品安全性要求极高的场合。BEE加密与HAB加密的主要区别是执行解密操做的主体不一样,主要有以下三点区别:
- HAB加密是由BootROM里的HAB将加密后的image所有解密成明文另存后再执行(静态解密),而BEE加密是由MCU芯片内部的BEE模块对加密的image进行解密后再执行(若是是XIP image,则是原地边解密边执行(动态解密);若是是Non-XIP Image,则解密执行流程与HAB加密相似)。
- HAB加密仅支持Non-XIP Image(不限Boot Device),而BEE加密仅支持在FlexSPI NOR中启动的Image(不限XIP/Non-XIP)。
- HAB加密区域不可指定(默认所有用户Image区域),而BEE加密的区域可由用户指定。
【Secure Boot Type】选择“BEE Encrypted Image Boot”,而后配置全部签名认证的参数(若是本地已有证书,能够不用配置,软件会尝试复用),再点击【Browse】按钮选择一个原始image文件(必须是XIP在FlexSPI NOR中的image),【Key Storage Region】选择“Fixed Otpmk(SNVS) Key”后点击【Advanced Key Settings】按钮配置全部BEE加密的参数,最后点击【All-In-One Action】按钮便可完成bootable image生成与下载全部操做。
上图中Step6操做主要确认一点:BEE_KEY0_SEL是否设置的是From OTPMK[255:128](Fuse 0x460[31:0]的bit13,12为2'b10)。Step7操做以后能够看到下载进Boot Deivce里的Bootable image从IVT开始全是密文,本示例仅启用一块加密区域,具体对哪些区域进行加密是在【Advanced Key Settings】里指定的,最大支持指定3块加密区域。
有必要对以下使用Fixed Otpmk(SNVS) Key加密的BEE参数设置页面再作一下介绍,主要是设置Region Count以及指定Region范围,默认为0即自动对整个image区域进行加密。
一切操做无误,板子上SW7拨码开关将Boot Mode设为2'b10即Internal Boot模式,而且将BT_CFG[1]设为1'b1(使能Encrypted XIP),其他保持全0,从新上电即可以看到BEE encrypted image正常执行了。
BEE加密相比HAB加密是要更安全的,由于HAB加密毕竟仅能静态解密,当HAB解密完成以后在SRAM/SDRAM中存储的是所有的image明文,若是此刻黑客去非法访问SRAM/SDRAM是有可能获取所有image明文的(不过也不用担忧,i.MXRT能够设置JTAG访问权限);而BEE加密能够是动态解密,CPU执行到什么地方才会去解密什么地方,任什么时候候都不存在完整的image明文,黑客永远没法获取所有的image明文。
第五种模式是顶级的安全模式,即用用户自定义Key对image进行双引擎BEE级加密,跟第四种模式(单引擎)原理相似,通常用于对产品安全性要求最高的场合。单引擎BEE加密与双引擎BEE加密具体区别以下:
- 惟一SNVS Key单引擎BEE加密默认使用SNVS Key,芯片出厂已预先烧录,没法更改;用户自定义Key双引擎BEE加密使用的Key是由用户本身设的,须要手动烧录在Fuse SW_GP2和GP4区域。
- 惟一SNVS Key单引擎BEE加密只启用了BEE引擎0;用户自定义Key双引擎BEE加密能够同时启用BEE引擎0和引擎1。但须要注意的是不管启动几个BEE引擎,最大加密区域总数均是3个。
- 惟一SNVS Key单引擎BEE加密必需要配合HAB签名一块儿使用,由于只有在HAB Closed的状态下才能获取SNVS Key;用户自定义Key双引擎BEE加密不必定要使用HAB签名。
【Secure Boot Type】选择“BEE Encrypted Image Boot”,【Enable Certificate For BEE Encryption】选择是否要使能HAB签名,而后点击【Browse】按钮选择一个原始image文件(必须是XIP在FlexSPI NOR中的image),【Key Storage Region】选择“Flexible User Keys”后点击【Advanced Key Settings】按钮配置全部BEE加密的参数,最后点击【All-In-One Action】按钮便可完成bootable image生成与下载全部操做。
上图中Step6操做主要确认两点:1、BEE_KEY0_SEL是否设置正确(Fuse 0x460[31:0]的bit13,12)和BEE_KEY1_SEL是否设置正确(Fuse 0x460[31:0]的bit15,14);2、用户Key是否被正确烧录(SW_GP2: Fuse 0x690 - 0x6c0,GP4: Fuse 0x8c0 - 0x8f0)或锁住。
有必要对以下使用Flexible User Keys加密的BEE参数设置页面再作一下介绍,首先是选择要激活的BEE引擎,能够单独激活BEE引擎0,也能够单独激活BEE引擎1,固然更能够同时激活BEE引擎0和1,本示例同时激活BEE引擎0和1。指定了BEE引擎后须要进一步为该引擎配置加密所使用的Key的存储空间以及须要用户手动输入Key(128bits)。最后还须要设置加密保护的区域,本示例共使能加密2个区域,分别为0x60001000 - 0x60001fff(由BEE引擎0保护),0x60003000 - 0x60003fff(由BEE引擎1保护)。
为了确认image是否按指定区域加密,你能够打开\NXP-MCUBootUtility\gen\bootable_image\文件夹下面生成的未加密bootable image文件与image回读窗口里的内容进行比对。
一切操做无误,板子上SW7拨码开关将Boot Mode设为2'b10即Internal Boot模式,而且将BT_CFG[1]设为1'b1(使能Encrypted XIP),其他保持全0,从新上电即可以看到BEE encrypted image正常执行了。
双引擎BEE加密是将用户自定义的Key烧录进了Fuse SW_GP2/GP4区域里,但该区域的Fuse内容是能够回读的,若是黑客拿到Key,仍是有可能破解存在外部Boot Device里的image密文,有没有对Fuse SW_GP2/GP4区域进行保护的方法?固然有,你能够对指定的Fuse区域进行加锁,可设置Fuse区域访问权限(读保护,写保护,覆盖保护),具体后面有单独章节详细介绍。NXP-MCUBootUtility工具为了安全考虑,直接将SW_GP2/GP4区域锁了起来。
双引擎BEE加密相比单引擎BEE加密,从破解角度来讲难度加倍,毕竟能够启用两组不一样的Key来共同保护image不被非法获取。
在菜单栏Tools/Generate .sb file选项里勾选"Yes",此时点击【All-In-One Action】按钮便会在\NXP-MCUBootUtility\gen\sb_image\目录下生成.sb格式的文件,该文件可用于MfgTool或者RT-Flash工具中。注意此时【All-In-One Action】按钮并不会在MCU上真正地执行3.3节里的各类操做,而只是将全部命令操做记录在\NXP-MCUBootUtility\gen\bd_file\imx_application_sb_gen.bd里,最终用于生成.sb格式文件。
Note1: .sb格式文件生成有一个限制,即每次生成新.sb文件均须要从新链接,点击【Reset device】按钮后回到初始链接状态,而后点击【Connect to ROM】按钮。
Note2: 当.sb文件中包含必要的efuse操做时,会一次性生成3个.sb格式文件,其中application_device.sb包含所有的操做(flash+efuse操做),application_device_flash.sb仅包含flash操做,application_device_efuse.sb仅包含efuse操做,这样作的目的是为了方便工厂量产。
Note3: 对于NOR Flash(FlexSPI NOR、LPSPI NOR)型的启动设备生成.sb文件而言,既可链接板子在线操做(推荐),也能够不用链接板子离线操做。
Note4: eFuse Operation Utility窗口里的【Scan】、【Burn】按钮可用于生成仅含自定义efuse操做的.sb文件,须要先点【Scan】按钮,而后填入想烧写的efuse值,最后再点【Burn】按钮即可在\NXP-MCUBootUtility\gen\sb_image\下生成burn_efuse.sb文件。
NXP-MCUBootUtility软件打开默认工做在Entry Mode下,可经过功能菜单栏Tools->Option选择进入Master Mode,在Master模式下开放了一些高级功能,适用于对NXP MCU芯片以及Boot ROM很是熟悉的用户。
进入Master模式下,能够不勾选One Step选项,这样能够单步去链接目标设备,单步链接的主要意义在于,能够在不配置Boot Device的状况下仅链接到Flashloader去实现eFuse操做。
进入Master模式下,能够看到eFuse所有区域都开放了,你能够任意烧写指定的eFuse区域。eFuse操做是按bit一次性的(相似熔丝烧断),只能将0烧写成1,烧录成1以后便没法更改,因此eFuse的操做须要特别谨慎。
在上一章节安全加密启动过程当中,咱们会烧录SRKH(0x580 - 0x5f0)、SW_GP2(0x690 - 0x6c0)、GP4(0x8c0 - 0x8f0),这些区域一经烧录便不得更改,甚至咱们但愿这些区域不只不能被更改,也要不能被回读。
从上图可知eFuse 0x400便是各Fuse功能区域的Locker,咱们能够经过烧录eFuse 0x400来锁住SW_GP2, GP4区域。那么如何烧录呢?其实很是简单,直接在各eFuse框内填写想要烧录的值,点击【Burn】按钮便可。
进入Master模式下,能够点击【Read】、【Erase】、【Write】按钮实现已配置Flash的任意读擦写操做,这样能够将NXP-MCUBootUtility工具当作通用Flash编程器。