如何在包含反调试器措施的进程中调试崩溃 [英] How to debug a crash in a process containing anti-debugger measures

查看:113
本文介绍了如何在包含反调试器措施的进程中调试崩溃的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的应用程序崩溃了,无法调试,因为我们的合作伙伴之一认为适合使用真正的可怕'CodeMeter'来加密其DLL. CodeMeter许可可防止所有尝试调试包含CodeMeter加密DLL的应用的尝试,甚至可能导致从未处理的异常过滤器调用的MiniDumpWriteDump失败(此技术在未加载此DLL的情况下有效).仅当将加密的DLL加载到进程中时,才会发生崩溃.

I've got a crash in our app which I can't debug as one of our partners has seen fit to use truly horrible 'CodeMeter' to encrypt their DLL. CodeMeter licensing prevents all attempts to debug an app containing a CodeMeter encrypted DLL and even seems to cause MiniDumpWriteDump called from an unhandled exception filter to fail (this technique works without this DLL loaded). The crash only happens when the encrypted DLL is loaded into the process.

我很生气,试图调试它并确定是否崩溃的是加密的DLL,如果是的话,我如何向我们的合作伙伴提供足够的诊断信息来解决这个问题.

I'm going mad trying to debug this and establish whether it's the encrypted DLL that's crashing, and if so how I can provide adequate diagnostic information to our partner to solve this.

有什么建议-也许我可以从未处理的异常过滤器中调用一些手动堆栈和模块遍历代码?

Any suggestions - perhaps some manual stack and module walking code I could call from my unhandled exception filter?

CodeMeter的构建设置是否可以使我们的合作伙伴生成仍然经过加密和许可但不会如此积极地破坏调试的构建?

Does CodeMeter have build settings that will allow our partner to produce a build that is still encrypted and licensed but doesn't sabotage debugging so aggressively?

为了清楚起见,如果有任何疑问,我不是在尝试破解许可,只是诊断此崩溃.

Just to be clear in case there's any doubt, I'm not trying to hack the licensing, just diagnose this crash.

推荐答案

我使用了一些堆栈漫游代码效果很好,可以通过将传递给异常过滤器的CONTEXT记录传入SEH或未处理的异常过滤器中进行调用.

I've used some stack walking code that works well that can be called from an SEH or unhandled exception filter by passing in the CONTEXT record passed to the exception filter.

可以使用日志,用于解释堆栈地址与哪些DLL相关.

The addresses in the stack and the potential addresses in the first few exception parameters can be interpreted using SymFromAddr in DbgHelp including the module handle. Add to that a log of the module file names and module handles for interpreting which DLLs the stack addresses relate to.

此特定崩溃是Visual C ++异常.通过使用SymFromAddr查找其中一个异常参数的地址来揭示异常的类型.

This particular crash was a Visual C++ exception. The type of the exception is revealed by looking up the address of one of the exception parameters using SymFromAddr.

Raymond Chen的博客上有一些代码,用于查找类型来自异常参数的Visual C ++异常,但由于某种原因(可能是我自己的错误),我无法使它正常工作.

Raymond Chen's blog has some code for finding the type of a Visual C++ exception from the exception parameters but I couldn't get this to work for me for some reason (probably my own error).

这篇关于如何在包含反调试器措施的进程中调试崩溃的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆