内存被异常篡改问题分析

huangguang

前言

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

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

1.问题描述

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.尝试的分析解决办法

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属性断点。



果然产生断点停梗琋vM模块异常修改了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段后就不会被异常修改了（可能改了其他的变量…没有出现问题而已）。

3.最终解决办法

是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数据拷贝发生异常，但是异常现象是一样的。

4. 总结

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

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

3）找到异常篡改的地方后能理解NVM和Dem之间的关系才能找到哪里配置错误导致的异常
4）AUTOSAR的模块是买的，但是也要熟悉他们的代码，遇到问题的时候还是要看代码调试。

wmwlove

内存被异常篡改问题分析

一、问题描述

近期在开发环境中遇到内存变量被异常篡改的问题，导致系统无法正常发送报文。该问题涉及的开发环境包括：使用Infineon TC377芯片，Autosar工具链Vector Davinci/Developer，以及Lauterbach调试器。

二、问题分析

针对此问题，首先需明确异常篡改的具体原因。可能的原因包括软件bug、内存访问冲突或者外部干扰等。解决思路如下：

1. 复查代码逻辑，检查是否有逻辑错误或潜在的安全漏洞导致内存被非法访问或修改。
2. 利用调试工具对内存访问进行追踪，观察内存访问序列和时序，确认是否存在内存访问冲突。
3. 检查硬件环境，确认是否有电磁干扰或其他外部因素导致内存异常。

三、解决方案

根据分析，采取相应的解决措施：

1. 修复代码中的逻辑错误或安全漏洞。
2. 优化内存访问管理，确保正确的内存访问时序和避免冲突。
3. 加强硬件环境的稳定性，减少外部干扰。

四、总结

本问题具有代表性，解决思路常规。通过对代码逻辑、内存访问及硬件环境的检查和分析，可以找到并解决问题。希望对入门的朋友有所帮助。注：由于问题已解决，无法复现，但现象真实存在。

wmwlove

内存被异常篡改问题分析

一、问题描述

近期在开发环境中遇到内存变量被异常篡改的问题。问题主要表现为板子上电后不再正常发送报文。开发环境包括Infineon TC377芯片、Autosar工具链Vector Davinci/Developer以及Lauterbach调试器。

二、问题分析

针对此问题，我们首先考虑操作系统或者应用软件的内存管理部分是否存在漏洞，导致内存访问异常。同时，需要详细检查代码逻辑，特别是涉及内存操作的函数，看是否存在潜在的错误或漏洞。此外，还需要检查外部输入数据是否安全，防止恶意攻击导致内存篡改。

三、解决方案

针对此问题，我们首先需要定位到具体是哪个变量或哪块内存被篡改。可以通过调试工具对内存进行监控，查看内存变化过程。其次，根据监控结果分析原因，可能是代码逻辑错误、内存管理问题或是外部攻击。最后，根据分析结果制定相应的修复方案，如修改代码逻辑、加强内存管理或增加安全防护等。

四、总结

此问题具有代表性，解决思路常规。希望通过记录此次问题解决过程，能对入门的朋友有所帮助。针对此类问题，最重要的是深入分析和理解问题的根本原因，并采取相应的措施进行修复和预防。