!peb 简介 !peb显示进程环境块(PEB)中信息的格式化视图. 使用形式 !peb [PEB-Address] 参数 PEB-Address要检查其PEB的进程的十六进制地址.(这不是从进程的内核进程块派生的PEB地址.)如果在用户模式中省略PEB地址,则使用当前进程的PEB.如果在内核模式下忽略它,则显示与当前进程上下文相对应的PEB. 支持环境 Windows 2000 Kdextx86.dll Ntsdexts.dll Windows XP 及更高版本 Exts.dll 备注 PEB

        无论是分析程序崩溃原因,还是解决程序hang问题,我们最常查看的就是程序调用堆栈.学会windbg调用堆栈命令,以及理解堆栈中的各个参数的意义就显得至关重要. 上图就是一个典型的Windbg堆栈,如果不理解ChildEBP.RetAddr.Args to Child等参数意义,以及它们之间的来龙去脉,调试工作将很难进行下去. 1. 函数参数         函数的参数传递有二种方式:堆栈方式.寄存器方式.如果是堆栈方式传递的,就需要定义参数在堆栈中的传递顺序,并约定函数被调用之后

这里以WPF作为探测用的例子,简单一些,看看Title的值是什么样子.(之所以写这个,因为不是简单的一个!do就能看到东西的,中间要绕两下,这也涉及到了DependencyObject的实现机制及数据的存储机制) 首先用VS新建一个WPF工程,在XAML中我们修改一下Title属性和Background属性,运行,得到界面如下(我故意缩小了窗口宽度以及高度) 那么,Title的完整字符串是什么呢?窗体的背景色是什么呢? 与常规的managed debugging一样,首先attach到该进程上,

一.获取ShadowSSDT 好吧,我们已经在R3获取SSDT的原始地址及SDT.SST.KiServiceTbale的关系里面提到:所有的SST都保存在系统服务描述表(SDT)中.系统中一共有两个SDT,一个是ServiceDescriptorTable,另一个是ServiceDescriptorTableShadow.ServiceDescriptor中只有指向KiServiceTable的SST,而ServiceDescriptorTableShadow则包含了所有的两个SST.SSDT是

有如下Class.若想查看静态变量内容.因为静态变量和类绑定,仅需要查看类即可. namespace ConsoleApplication13 { class Program { public static string public_string = "pubstr_static"; public static string private_string = "pristr_static"; ... } } 1.查找类. !Name2EE ConsoleAppli

SSDT HOOK 的原理其实非常简单,我们先实际看看KeServiceDescriptorTable是什么样的.         lkd> dd KeServiceDescriptorTable     8055ab80  804e3d20 00000000 0000011c 804d9f48     8055ab90  00000000 00000000 00000000 00000000     8055aba0  00000000 00000000 00000000 00000000  

windbg + .dmp + .pdb + 源代码,可以看到是哪个代码崩溃的 设置符号文件所在路径 File->Symbol File Path... 在输入框中填入.pdb文件所在的文件夹路径 设置源代码路径 File->Source File Path... 在输入框中填入源代码所在的文件夹路径 然后,打开.dmp文件,随后在列出一堆信息的后面,点击!Analysis-V超链接, 分析出具体出bug的代码未知

https://www.cnblogs.com/startpoint/p/4194052.html https://www.cnblogs.com/lyl6796910/p/7613664.html https://www.cnblogs.com/dubing/p/3878591.html https://blogs.msdn.microsoft.com/alejacma/2009/08/13/managed-debugging-with-windbg-managed-heap-part-1/

打开菜单: File->Symbol File Path... 输入: C:/MyCodesSymbols; SRV*C:/MyLocalSymbols*http://msdl.microsoft.com/download/symbols 随便绑定一个进程,然后输入 dt _eprocess

CVE-2015-0057 POC构造 & 利用分析 主要内容: 构造POC 利用思路 0x00 初探 从这篇文章可以获知: 1.问题出在 win32k!xxxEnableWndSBArrows 函数,其在触发 user-mode callback 后,执行完相应操作后从用户层返回到内核层,对接下来操作的对象未能验证其是否已经释放(更改),而继续对其进行操作,导致UAF.触发user-mode callback的调用流程为: 2.所涉及的敏感对象为 tagSBINFO,可以通过CreateWin

0x01 前言 ASLR 是一种针对缓冲区溢出的安全保护技术,通过对堆.栈.共享库映射等线性区布局的随机化,通过增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的的一种技术 目前 ASLR 技术据我所知对3种情况进行了保护,分别是映像基址随机化.堆栈基址随机化和 PEB / TEB 随机化(有论文为参考).下面来亲自测试一下,看看地址到底会不会变 实验环境:Windows 10 ,编译器:C-Free 0x02 映像基址随机化 当可执行文件或动态链接库文件被映射

调试SQLSERVER (三)使用Windbg调试SQLSERVER的一些命令 调试SQLSERVER (一)生成dump文件的方法调试SQLSERVER (二)使用Windbg调试SQLSERVER的环境设置 windbg命令分为标准命令.元命令.扩展命令 标准命令提供最基本的调试功能,不区分大小写.如:bp g dt dv k等 元命令提供标准命令没有提供的功能,也内建在调试引擎中,以.开头.如.sympath .reload等 扩展命令用于扩展某一方面的调试功能,实现在动态加载的扩展模块中

一.windbg查看内存命令: 当我们在调试器中分析问题时, 经常需要查看不同内存块的内容以分析产生的原因, 并且在随后验证所做出的假设是否正确. 由于各个对象的状态都是保存在内存中的, 因此内存的内容也就相当于对象的状态. d命令最常见的格式就是根据指定的类型信息来显示存储在某地址中的数据. 调试器并不会去猜测这个地址上存储的是什么数据, 因为在大多数情况下猜测都是错误的. 所以需要用户显式地制定按照何种格式来解析数据. 命令格式如下: 语法:d [type][address range] /

一.首先准备好一个程序,运行起来,用windbg进行附加调试,由于每个windows下的程序都会加载kernel32.dll,因此,找基址的过程是一样的:  二.查看PEB地址: 法一.r $peb 法二.通过TEB获取,r $teb 获取到teb地址后,对_TEB结构体解析dt _TEB 3ca000 法三.通过fs寄存器获取,我们知道fs:[0]就是TEB结构体的首地址,但是,在windbg里dd fs:[0]时,地址却做了隐藏: 那该怎么办呢,其实,这就要看下TEB的结构了 在TEB结构的

0x01  结构探究 先在win7 x86下通过windbg来探究通过peb来得到进程模块的步骤: 命令!process 0 0 exeplorer.exe 先获取到explorer.exe的EPROCESS的地址,如图我们可以看到EPROCESS的地址为:0x87782d40 ,PEB的地址为:0x7ffdf000 使用 .process /p /r 87ede940 命令切换到explorer.exe进程后才能够访问它的peb用户地址空间: 切换到explorer.exe后,使用命令dt _

PEB地址的取得在NT内核系统中fs寄存器指向TEB结构,TEB+0x30处指向PEB结构,PEB+0x0c处指向PEB_LDR_DATA结构,PEB_LDR_DATA+0x1c处存放一些指向动态链接库信息的链表地址,win7下第一个指向ntdl.dll,第三个就是kernel32.dll的. typedef struct _TEB{ NT_TIB Tib; /* 00h */ PVOID EnvironmentPointer; /* 1Ch */ CLIENT_ID Cid; /* 20h *

转:http://www.cnblogs.com/dsky/archive/2013/05/15/3079363.html 简评: 代码中采用malloc/free进行堆申请,实际调用的仍然是Heapalloc->RtlCreateHeap.. !heap -a//能够查看当前所有的堆: !heap -a heapaddr//查看到堆的所有信息:堆大小/segment信息(包含哪些heapentry,多大,状态)/heapentry信息/freelist heap就是包含若干segment,se

完整工程:http://files.cnblogs.com/files/Gotogoo/%E8%BF%9B%E7%A8%8B%E7%AE%A1%E7%90%86%E5%99%A8%28x86%26%26x64%29.zip PEB(Process Environment Block,进程环境块)存放进程信息,每个进程都有自己的PEB信息.位于用户地址空间. PEB地址可以通过函数PsGetProcessPeb(EPROCESS)来获得,也可以通过EPROCESS基地址加偏移0x1b0(x86)来

转载收藏于:http://www.cnblogs.com/kekec/archive/2012/12/02/2798020.html  #调试命令窗口 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #使用gflags.exe工具(在windbg所在目录下),让某个进程启动时,拉取windbg进行调试 如下截图:当名称为captcomm.exe的进程启动时,拉起windbg调试 也可通过脚本命令来实现: // 运行c

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram