-
-
[原创]再战堆栈损坏:Critical error detected c0000374
-
发表于: 2024-10-31 10:04
-
继分析堆栈损坏:Critical error detected c0000374再分析一案例。为什么对0xc0000374那么情有独钟呢？理由有:
- 崩溃点不在引起错误的代码位置
- 崩溃点随机。如果涉及线程，崩溃点更加随机
- 崩溃出的调用堆栈对调试工作基本没有太大用处
正文开始，程序运行崩溃，在输出窗口出现信息:
赤果果的发现了异常代码:0xc0000374,并且弹出窗口:
弹出的RDEmboss.dll是友商的模块，所以是否可以扔锅了呢？(奸笑)
鉴于之前有374的分析经验，所以个人还是先挑战一下。对于崩溃时读取内存位置跟踪一下：
咦，发现该地址之后的内存确实是无法访问的，但是，它临近的内存是有数据的，观其数据的形象，应该是图片数据的像素值。所以，怀疑这个内存可能是访问图片数据类似的数据，但是这里的内存可能又被释放或者没有申请过，总之，这里的内存不管之前是否有效，但是现在是无效了。于是接下来，观察了一下崩溃现场的变量数据，发现一个可疑的地址:
这个地址和崩溃地址是比较接近的，并且该地址对象是图片相关对象。于是，凭经验假设该地址其实是在遍历pShape->pDIBData的内存越界造成的崩溃。于是根据图片的宽高估算了一下，地址范围
发现确实是越界了。于是，顺着pDIBData查看生成该数据的相关代码，很快，发现了可疑代码：
原本这里应该是图片每行的像素个数，但是错用了cv::Mat的rows。最后，改成cv::Mat的cols，问题果然解决了。
总结:
- 观察崩溃时访问内存附近的数据，是否能猜测出数据的对象
- 虽然崩溃指向明确的模块，但是有可能是输入参数出现了错误
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
最后于 2024-10-31 10:16
被_THINCT编辑
，原因：
|
|
|---|---|
