本文告诉大家如何用 WinDbg 调试 UWP 应用,使用 WinDbg 调试是在没有其他手段的时候才进行的调试,因为调试难度特别大。我最近因为发现有 Edge 和其他 UWP 程序打不开的问题,然而我没有 Edge 和其他 UWP 的源代码,于是我只能通过 WinDbg 去调试 UWP 程序
前面一篇写过《Windbg调试----Windbg入门》,可能不少新手会问,我在本地用Visual Studio去做调试就行了,为什么还需要那么抽象的Windbg去进行调试呢?
Windbg相信windows开发的人都知道,有些人用的溜儿溜儿的,有个crash,直接拿这个工具一分析,就定位出来了。非常好用。以前有个同事,做sdk开发的,会各种命令。来北京后,还去过微软面试(不过当时是做外包,挣得也不少),问的问题就包括会不会用windbg定位问题。当时就会几个简单的命令,最后还是没面上(不堪回首)。 使用windbg调试windows下的程序,只要有符号文件,问题定位分分钟的事。下面主要讲一下使用windbg调试chromium。有些是从官网上对翻过来的,如果大家看不明白
介绍 1. 什么是Windbg WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。 WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。 Dump文件是进程的内存镜像, 可以把程序的执行状态通过调试器保存到dump文件中 2. Windbg可以解决以下问题 ◆ 内存高 ◆ CPU高 ◆ 程序异常 ◆ 程序Hang死 3. 使用windbg进行调试
以前总想知道IDA是否能够实现内核调试,后来找了一段时间没什么结果就暂时放弃了。今天在国外的一个博客上偶然看到了用IDA实现内核调试的方法。
今天在测试的时候发现IDA 5.5可以启动windbg调试器,而IDA 6.0却无法启动windbg调试器。大体看了一下可能是由于搜索路径造成的,重新将windbg安装到program files下之后问题就结局了。
最近在进一步学习support技能的时候,了解到分析Dump的重要性,经过学习,做一些笔记。
我们知道,当今主流的x86/x64 Intel处理器默认都使用了保护模式,不同于8086时代的实模式机制,保护模式和分页机制实现了内核层与用户层隔离,进程间执行环境隔离。
0x00 引子 最近开始要在部门内进行 WinDbg 漏洞分析方面的专题showcase,打算将每次分享的内容整理成文章,希望能写一个系列。另外,鉴于笔者还在学习中,不对的地方还望各位多多指正:D 0x01 概述 本文将作为此系列的开篇,首先会提及Windows进程的知识,而后就进入正式的漏洞分析,此次选的是一个IE漏洞(CVE-2012-1876)。需要说明一点,随着微软在自身安全上的不断改进,漏洞利用的难度也越来越大,出于学习目的这里主要关注比较经典的漏洞,虽然有些可能比较老了,但还是很有借鉴意义的。
Windbg是微软开发的免费源码级调试工具。Windbg可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。
在早期版本的IDA中可以直接通过进程选项来设置Windbg的路径,但是在6.0之后这个菜单没了。
WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。
暂定各种错误码对照 //断点相关 bp + 地址 设置断点 bl 显示已经设定的断点 bu + 地址 设置断点,但是这种类型断点再下一次启动时被记录 bc 清除断点 对于断点范围,可以用*匹配,-表示一个范围,表达多个可用,号隔开 程序入口伪寄存器 WinDbg里有个伪寄存器叫$exentry,里面记录了程序的入口点。所以我们只要在命令输入栏里输入 bp $exentry (bp就是用来下断点的命令,详细用法可以参考WinDbg的帮助文档) //调试符号 ld ke
俗话说:万事开头难! 自从来到新公司遇到性能问题后,需要想办法解决这个问题,但是一直没有合适的性能分析工具,然后找到StevenChennet 大神帮忙,他用WinDbg工具远程帮我分析了一个 dump文件,但是只看到键盘 “啪啪啪”,得到了结果,却不是很清楚WinDbg神奇具体如何使用的。结果,第二天,性能问题又来了,总不能每次劳烦大神驾到,所以不得不自己开始学习WinDbg,这里记录一个入门过程。 1,首先,下载并安装WinDbg程序 从下面的地址打开: https://msdn.microsoft.c
Iris是一款WinDbg扩展,它可以针对常见的Windows进程缓解进行安全检测,并给研究人员提供详细的检测数据。
有小伙伴告诉我一台设备全触摸失效了,但实际上是资源管理器未响应。通过本文可以了解到调试的思路和用到的工具
在这篇文章中,我想谈一谈通过基于Windows内核的exploit来提升权限。之所以没有使用像HackSys Extreme Vulnerable Windows Driver这样的东西,是因为想做点不同的事情。恰逢Google Project Zero近期公布了漏洞,由于mjurczyk把漏洞进行了记录,所以感觉便于理解。该漏洞还被Microsoft标记为“Wont-Fix”,意思就是32位的Windows 10 Creator版本仍然存在漏洞。 漏洞概览 根据披露出的消息,我们可以了解到这个漏洞影响了3
本文来告诉大家如何一步步搭建一个 DUMP 分析平台,核心是用来分析桌面端的应用软件,如 WPF 软件的 DUMP 文件。在开始之前需要说明的是,如果桌面端软件使用纯 WPF 实现,中途没有调用不安全的 C++ 库,那么 DUMP 平台几乎无用,原因是 WPF 是 .NET 应用,而 .NET 是安全的,除非是系统环境问题,否则依靠捕获异常所拿到的信息就完全超过了 DUMP 能获取的信息。因此本文的核心功能是提供给调用了不安全的 C++ 等语言编写的库的桌面端软件 DUMP 分析平台
Windows 下记录有两个记录进程信息和线程信息的结构 TEB/PEB 这两个结构很复杂,我们只关注PEB的BeingDebugged的标志 检测很简单,微软提供了一个API,叫IsDebuggerPresent 照着文档用就行 下面是一个简单的测试:
配置环境变量 _NT_SYMBOL_PATH,(;)路径分割符 .;SRV*http://msdl.microsoft.com/download/symbolsD:\Program Files\symbol
生成dump文件有三种方式:任务管理器生成,windbg抓取,源码中添加dump转储代码。需要根据实际情况选择。
终端产品一般部署在客户的环境中,那么奇奇怪怪的问题也就容易出现了。比如Windows产品进程为什么忽然停止了?这个时候稍微有些经验的程序员会做出以下判断:
在博客堂的不是我舍不得 - High CPU in GC(都是+=惹的祸,为啥不用StringBuilder呢?)、 不是我舍不得 - .NET里面的Out Of Memory 看到很多人在问如何分析dump,所以就写下了这篇短文,抛砖引玉。 一、安装 DebuggingToolsforWindows: 从以下 Microsoft 网站下载 DebuggingToolsforWindows: http://www.microsoft.com/whdc/devtools/debugging/installx8
那么,这种驱动模型带来什么变化呢? 首先基于COM思想,引入接口机制,可以把相关联的函数分门别类进行组织,使得驱动代码清晰明了;其次,运行在RING3的驱动,大幅度降低了驱动程序在稳 定性和安全性上面的风险,UMDF驱动崩溃不会导致bugcheck(蓝屏),并且UMDF驱动的宿主进程是在受限的用户身份下运行的,不是受信任的系统内核模块。可以在UMDF里面使用Win32 API。 运行于RING3的UMDF对于程序员开说至少带来两个额外好处:
对于64位的可执行程序已经搞了好长一段时间了,但是却一直没有写点什么东西。前面的两篇文章仅仅是单纯的翻译,个人认为不管是32位还是64位的程序脱壳只要能到达程序的OEP就可以了。现在支持64位加壳的程序貌似也不多,这里以mpress压缩的64位系统下的64位notepad为例进行简单的演示。在《IDA + Bochs 调试器插件进行PE+ 格式DLL脱壳 》一问中提到了可以使用bochs调试器进行DLL文件脱壳。但是却没有办法进行64位EXE文件调试,启动调试之后由于代码完全识别错误,因为会出现异常导致无法调试。要想调试64位可执行程序目前只有通过远程调试的方式,使用Windbg插件同样是无法进行调试的。但是用windbg调试时将会提示如图1所示的信息:
在调试软件时,工具非常重要。获取正确的工具,然后再调试时提取正确的信息。根据获取的正确的错误信息,可以找到问题的根源所在。找到问题根源所在,你就能够解决该错误了。
PPLcontrol是一款功能强大的受保护进程安全控制工具,在该工具的帮助下,广大研究人员可以快速枚举出目标操作系统中受保护的进程,并获取指定进程的保护级别,或给目标进程设置任意保护级别。
若要安装最新版 dotnet-sos NuGet 包,请使用 dotnet tool install 命令:
未捕捉异常无法生成dump文件,导出中二次崩溃,程序主动调用abort终止进程都会导致dump文件未生成。
需要使用WinDbg工具来分析windows系统产生的dump文件,此工具属于Windows SDK的一个组件,在微软官方网站可以下载(链接)。
Lupo是一款功能强大的恶意软件IoC提取工具,可以帮助广大研究人员在恶意软件分析自动化的任务场景下实现恶意代码分析和调试。
本文将和大家介绍一个简单且实际用途不大的使用 windbg 配合脚本的方式,进行自动化的大批量对 dotnet 系应用的 dump 进行自动化分析调试处理,可以自动根据调试需求输出 dump 文件的一些信息
学习地图 书籍推荐 C++ Primer Windows核心编程 TCP/IP详解 卷1:协议 设计模式GoF版 编码规范 C++编码规范 C++语言 C++宏 C++11 用正则表达式查找提取
该篇文章主要分享了作者在使用.NET进行应用程序调试方面的一些经验和技巧,包括异常处理、调试工具、代码调试、性能优化、内存泄漏检测、远程调试、日志记录、死锁、线程调试、Visual Studio调试、F5负载均衡和服务器端应用程序等方面的内容。作者还介绍了如何使用Visual Studio调试.NET应用程序,并提供了详细的步骤和截图。此外,作者还介绍了一些常用的.NET调试工具,如Fiddler、Wireshark、Process Monitor等,以及如何使用这些工具进行网络调试、进程监控、文件读写等方面的操作。最后,作者还分享了一些调试.NET应用程序的经验和技巧,包括如何识别和解决死锁、内存泄漏、性能问题等。
随着应用程序的复杂度不断上升,要想将好的设计思想稳定的落实到线上,我们需要具备解决问题的能力。需要具备对运行时的错误进行定位且快速的解决它的能力。本篇文章我将分享一下我对.NET应用程序调试方面的学习和使用总结。
本文介绍了异常处理在Windows平台下的实现方式,包括栈溢出、段寄存器以及结构化异常处理。作者通过分析异常处理机制的原理和过程,以及C++中的try-catch语句在Windows平台下的实现,让读者对异常处理有更深入的理解,掌握异常处理的方法和技术。
功能:ProcessHacker 是一款不错的进程分析工具,可查看所有进程信息,包括进程加载的 dll、进程打开的文件、进程读写的注册表……,也可以将特定进程的内存空间 Dump 到本地,此外还可以查看网络连接。
int 3则是产生一个断点,请注意,一定要配合WinDbg进行调试,也就是双机调试,否则这条代码则会蓝屏.
在不少电影电视剧中,主角的身边都有这么一位电脑高手:他们分分钟可以黑进反派的网络,攻破安全防线,破解口令密码,拿到重要文件。他们的电脑屏幕上都是一些看不懂的图形和数字,你能看懂的就只有那个进度条,伴随着紧张的BGM,慢慢的向100%靠近······
前天晚上,在一个页面上拖了一个ObjectDataSource,配置数据源时发现选择业务对象的列表没有列出当前项目的实体类,甚至连NewLife.CommonEntity中的实体类也没有列出来。按以往管理,重新编译、删除引用、更新DLL……所有操作都试了一遍,还是不行。这就奇了怪了,虽然这几年来一直碰到这个问题,尽管不知道原因,但是从来没试过解决不了的。觉得也许是我安装了vs2010sp1的原因。 第二天早上到了办公室,让没有安装vs2010sp1的同事试一下,同样的问题…… 于是打算反编译
在Windows上做开发的程序猿们都知道,x86架构处理器有一条特殊的指令——int 3,也就是机器码0xCC,用于调试所用,当程序执行到int 3的时候会中断到调试器,如果程序不处于调试状态则会弹出一个错误信息,之后程序就结束。使用VC开发程序时,在Debug版本的程序中,编译器会向函数栈帧中填充大量的0xCC,用于调试使用。因此,经常我们的程序发生缓冲区溢出时,会看到大量的“烫烫烫…”,这是因为“烫”的编码正是两个0xCC。
在前一节中介绍了通过远线程不带参数的方式提前注入进程,现在介绍种远线程携带参数的方法。(转载请指明出处)
Net 高级调试的相关文章,我自从学习了之后,以前很多模糊的地方现在很清楚了,原来自己的功力还是不够,所以有很多不明白,通过学习 Net 高级调试,眼前豁然开朗,茅塞顿开。
无论是在编写Windows程序还是Linux程序,都可能存在句柄泄露的问题。在Linux中一般来说一个进程的fd使用是有上限的,可以使用ulimit命令进行上限查看,当出现fd泄露的时候,可能会出现socket创建失败,文件打不开等问题。Windows类似,本文主要阐述了对Windows中的句柄泄露的追踪方法。
FalconEye是一款功能强大的Windows终端安全检测工具,可以帮助广大研究人员实时检测Windows进程注入行为。FalconEye也是一个内核模式驱动工具,旨在实现实时的进程注入行为。由于FalconEye需要以内核模式运行,它可以提供一个强大可靠的安全防御机制来抵御那些尝试绕过各种用户模式钩子的进程注入技术。
Windbg是Microsoft公司免费调试器调试集合中的GUI的调试器,支持Source和Assembly两种模式的调试。Windbg不仅可以调试应用程序,还可以进行Kernel Debug。结合Microsoft的Symbol Server,可以获取系统符号文件,便于应用程序和内核的调试。Windbg支持的平台包括X86、IA64、AMD64。
KeServiceDescriptorTableShadow是ShadowSSDT表 KeServiceDescriptorTable是SSDT表.
本文介绍使用Windbg去验证《DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子》中的结论,调试对象是文中刚开始那个例子。(转载请指明出于breaksoftware的csdn博客)
32位系统逐渐淘汰,转到64位编程相当重要. 但苦于64位驱动编程网上的资料比较杂乱
领取专属 10元无门槛券
手把手带您无忧上云