最近遇到一个变量（内存）被异常串改的问题，问题很具有代表性，解决问题的思路也很常规，这里把解决问题的思考过程、尝试的解决办法以及最终的问题原因记录下来，希望对入门的朋友有所帮助。

Note: 由于问题解决后，尝试再次复现问题时复现不了了，所以这里的问题是我人为制造的，但是现象还是一模一样的。

1.1 开发环境

芯片：Infineon TC377

Autosar工具链：Vector Davinci/Developer

调试器：Lauterbach

1.2问题的对外表现

板子上电后不再往外发报文了，用来调试的指示灯也不再闪烁，感觉程序跑死了。

1.3 仿真器上的表现

查看程序最后停在哪里了（或者在哪里陷入死循环了）

程序果然跑入了死循环。

查看进入死循环的函数调用栈

Nm模块在初始化的时候检测到了Error，向Det模块报错，报错ErrorID = 41。

查看ErrorID=41具体是啥Error类型

ErrorID==41表示模块已经初始化了，有重复初始化的Error。

这就很尴尬了，难道是Nm_Init被调用了两次？--尝试在Nm_Init开始处设置了一个断点，结果是Nm_Init只进入了一次，但是第一次进入Nm_Init就报ErrorID=0x29的Error了。到这里就很奇怪了……

查看源代码，看什么条件下会设置0x29的ErrorID。

Nm_IsInitialized( PARTITION_IDX )这个条件其实就是判断Nm_Initialized这个全局变量有没有被置为1.

把Nm_Initialized这个变量加入到Lauterbach的watch窗口，再次在Nm_Init的开始处设置断点。

刚进入Nm_Init时，Nm_Initialized这个全局变量已经被置为1了。

全局搜索Nm_Initialized这个全局变量，看哪里会设置这个全局变量。

Nm_Init函数的最后会设置Nm_Initialized这个全局变量为1，也是整个代码唯一会设置Nm_Initialized变量为1的地方，所以在进入Nm_Init函数前Nm_Initialized就已经被设置为1了，这是不正常的，也就是说Nm_Initialized这个全局变量被异常篡改了。

2.1 怀疑Nm_Initialized没有被初始化

Nm_Initialized变量没有初始值，位于.bss段，如果在main函数之前没有对.bss段作初始化（设置为0）的话，Nm_Initialized变量就可能是随机值。

在main函数之前已经完成了BSS段的清零初始化操作，也就是说Nm_Initialized变量的值是确定的为0。

通过EcM_Init入口处断点调试，也确定Nm_Initialized的值为0，是正常的。

随后通过逐步断点调试，在Start_OS之前Nm_Initialized的值一直为0，是正常的。

小结：BSS段在main函数之前已经完成了初始化，Nm_Initialized是在Start_OS之后被异常篡改的。

2.2 尝试将Nm_Initialized从Bss段移到Data段

Nm_Initialized本来是未初始化的全局变量，位于.BSS段，我们给Nm_Initialized变量加上初始化值，这样Nm_Initialized就会被移动到.Data段。

再次编译仿真调试，结果问题消失了！

小结：Nm_Initialized位于.BSS段被异常修改了。

查看.Map文件，Nm_Initialized变量位于.BSS段，如果在操作Nm_Initialized之前的数据数据时发生越界非法操作，就可能异常修改Nm_Initialized的值。

2.4 设置读写断点

为了验证Nm_Initialized在哪里被异常修改了，我对Nm_Initialized所在地址处设置了一个读写断点。

通过lauterbach设置Wrtie属性断点。

果然产生断点停止，NvM模块异常修改了Nm_Initialized变量。NvM模块NvM_InternalCopyData函数从srcPtr=0x70024C18往destPtr=0x70024ABC拷贝160字节数据的时候发生数据踩踏。

查看.Map文件

问题水落石出，NvM模块从srcPtr=0x70024C18(NvM_InternalBuffer_au8)往destPtr=0x70024ABC(Dem_Cfg_AdminData)拷贝160字节数据的时候异常串改了Nm_Initialized变量。

也说明了为什么我们把Nm_Initialized变量移动到.Data段后就不会被异常修改了（可能改了其他的变量…没有出现问题而已）。

是NVM模块导致了Nm_Initialized变量被异常修改，那肯定是NVM模块配置异常了。最终检查出来的问题是因为，NVM模块给Dem_StatusEntry配置的NVMBlock为272字节，但是Dem模块的DTC根本没有配置这么多（不需要272字节的NVMBlock来存储每个DTCStatus），导致了在初始化阶段，NVM往Dem写初始化数据的时候发生了异常访问。

Note: 实际问题是NvM_InternalBuffer_au8往Dem_Cfg_StatusData拷贝的时候发生了数据篡改，这里是问题场景是我自己制造的，变成了NvM_InternalBuffer_au8往Dem_Cfg_AdminData数据拷贝发生异常，但是异常现象是一样的。

1）首先要能分析出异常现象是因为数据被异常篡改导致的

2）能使用调试器设置读写断点是本次问题分析的关键

3）找到异常篡改的地方后能理解NVM和Dem之间的关系才能找到哪里配置错误导致的异常

4）AUTOSAR的模块是买的，但是也要熟悉他们的代码，遇到问题的时候还是要看代码调试。

码上报名

WISS 2023 第四届世界物联网安全及数据安全治理峰会火热报名中，3月9-10日，上海

码上报名

AutoSec 2023 第七届中国汽车网络安全周暨第四届汽车数据安全展火热报名中

更多文章

智能网联汽车信息安全综述

软件如何「吞噬」汽车？

汽车信息安全 TARA 分析方法实例简介

汽车FOTA信息安全规范及方法研究

联合国WP.29车辆网络安全法规正式发布

滴滴下架，我却看到数据安全的曙光

从特斯拉被约谈到车辆远程升级（OTA）技术的合规

如何通过CAN破解汽

会员权益: (点击可进入)谈思实验室VIP会员

END

微信入群

谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术，为汽车行业提供最优质的学习交流服务，并依托强大的产业及专家资源，致力于打造汽车产业一流高效的商务平台。

每年谈思实验室举办数十场线上线下品牌活动，拥有数十个智能汽车创新技术的精品专题社群，覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家，已经服务上万名智能汽车行业上下游产业链从业者。专属社群有：信息安全、功能安全、自动驾驶、TARA、渗透测试、SOTIF、WP.29、以太网、物联网安全等，现专题社群仍然开放，入满即止。

扫描二维码添加微信，根据提示，可以进入有意向的专题交流群，享受最新资讯及与业内专家互动机会。

谈思实验室，为汽车科技赋能，推动产业创新发展！