在远程内核调试中部分丢失了 DLL [英] The DLL is partly missed in remote kernel debugging

查看:58
本文介绍了在远程内核调试中部分丢失了 DLL的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用 IDA + WinDBG 插件进行一些远程内核调试,我想在 DLL 内的某个函数中设置断点,这是我在 IDA 中反汇编它时发现的.我切换到加载目标 DLL 的进程,但不幸的是我发现内存中的 DLL 部分丢失,包括我的函数.

I'm doing some remote kernel debugging with IDA + WinDBG plugin and I want to set a breakpoint in some function inside the DLL, which I found while disassembling it in IDA. I switched to the process, which loads the target DLL, but unfortunately I found out that the DLL in memory is partly missed including my function.

证明示例如下.在这里,IDA 识别出函数 sub_180001FC8,但在 WinDBG 中,此反汇编在地址 0x7fff3d131fff 处中断.

Examples for proof are below. Here IDA recognized the function sub_180001FC8, but in WinDBG this disassembly breaks off on address 0x7fff3d131fff.

截图 1 - DLL 在实时内核调试中加载到内存中

Screenshot 1 - DLL loaded into memory in live kernel debugging

截图 2 - 在 IDA 中静态"打开相同的 DLL

Screenshot 2 - same DLL opened in IDA "statically"

出了什么问题以及如何恢复丢失的零件?

What's wrong and how to recover missed parts?

推荐答案

我终于找到了答案.反汇编以?? 中断的区域被调出内存区域.
恢复"我使用命令的页面:

Finally I found the answer. The region where disassembly breaks off with ?? is paged out memory region.
To "restore" the page I used the command:

.pagein /f /p <process_address> <page_start_address>

对于我的情况:

.pagein /f /p 0xffffbc4a4405efc0 0x7fff3d132000

此命令从辅助存储加载内存页面,它们在反汇编中可见.

This command loads memory pages from secondary storage and they become visible in disassembly.

参考文献:
https://en.wikipedia.org/wiki/Memory_paging
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-pagein--page-in-memory-

这篇关于在远程内核调试中部分丢失了 DLL的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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