场景 应急响应中从进程发现被注入了EXE文件,通过processhacker的Memory模块dump出来注入的文件.PE修复后在IDA里反汇编查看这个恶意代码的功能是什么. 解决 LordPE 虚拟内存对齐修复 [Section Table] 每个区段的 VirtualAddress与RawOffset对齐 VirtualSize与RawSize对齐 [Basic PE Header Information] 修复exe加载基地址和dump的内存地址 相关示例 LoadPE载入dump后的程序

想要查看一些被增强过的类的字节码,或者一些AOP框架的生成类,就需要dump出运行时的Java进程里的字节码. 从运行的java进程里dump出运行中的类的class文件的方法: 用agent attatch 到进程,然后利用Instrumentation和ClassFileTransformer就可以获取到类的字节码了. 用sd-jdi.jar里的工具.sd-jdi.jar里自带的的sun.jvm.hotspot.tools.jcore.ClassDump就可以把类的class内容dump到文

2014-03-04 Created By BaoXinjian

转发自https://blog.csdn.net/MCC_MCC_MCC/article/details/80623156 1.Windows/Linux环境下查看Java进程ID方法 使用Java自带的工具VisualVM工具实现,在CMD或者是Linux终端下执行“jvisualvm”命令即可以进入VisualVM控制台,双击左侧的进程即可以查看到详细的信息. 2.生成DUMP文件 CMD执行“jmap -dump:format=b,file=F:/heamdump.out 16540”命令

关闭了一个安装缓慢的apt-get install终端窗口,安装另一个软件,提示打不开var下的一个锁(没加sudo也是这个错误但会提示是非root用户权限不够导致,但这里不是这个问题),说是另一个进程在占用(安装上一个软件的apt-get install),ps aux|grep apt-get强杀,导致: dpkg: error processing package snapd 参考: https://blog.51cto.com/jingkonglanxing/2070725 https:

一两个月前为产品写了一个独立的exe,由于产品使用的捕获dump是一个现成的进程外exe,如果以资源的方式集成它容易出现安全警告,由于时间关系没有寻求新的解决方法,还是遵循旧方案,不捕获dump. 最近业余看了会儿breakpad client,想到一个解决方案——其实也蛮简单的,最后exe大概会增加200多KB.下边从头分析. 有这样一种需求,希望一个进程启动之后,有另一个进程来“守护”它,当它发生crash时,能生成dump,然后把它重启:还有一个要求,“守护”进程跟工作进程必须是在同一个物

首先我是attach到进程的方式,附加到进程把. vs里边有个远程调试就是通过连接到远程机附加到进程操作的.在 有公网IP情况下挺好用,但涉及到nat穿越之类的,因为用户的不方便设置,这种调试方式也有局限性. 6. lmf 列出当前进程中加载的所有dll文件和对应的路径 奇怪没找到我程序里边加载的dll  乖乖滴.难道attach 进程把dll关了吗? 用空用dump 试试. 11!runaway 可以显示每一个线程的cpu消耗 这个命令挺好,直接找到哪个线程占得时间久 ,如果一直占着,那这个线

1. Dump文件的用途 Dump文件, 主要用于诊断一个进程的运行状态,尤其是碰到崩溃(Crash)或者挂起(hang)不响应时,需要分析它的工作状态.  除了平时常见的attach到这个进程, 分析Dump文件就成了一个重要的手段了. 相信一些做软件维护和支持的工程师在这方面深有体会, 比如某天某时,客户说, 呀, 糟糕, 服务器进程挂掉了, 怎么回事? 然后,看看了日志文件,也没有什么可用的信息.  技术支持告诉他, 按某步骤生成一个dump文件来看看...... 2. 如何生成Dump文

core dump,翻译过来讲,就是核心转储.大致上就是指,如果由于应用错误,如浮点异常.指令异常等,操作系统将会转入内核的异常处理,向对应的进程发送特定的信号(SIGNAL),如果进程中没有对这些信号进行处理,就会转入默认的处理,core dump就是其中的一种.如果进程core dump,系统将会终止该进程,同时系统会产生core文件,以供调试使用.这个core文件其实就是内存的映像,即进程执行的时候内存的内容,也就是所谓的core dump.平常大家说某某进程core dump了,其实主要

问题描述: 项目反馈应用负载的其中一台服务器业务操作的响应非常慢,登录该服务器发现W3WP进程CPU持续超过90%,哪怕在业务低峰期也是如此?远程查看后发现该应用服务器承载的请求确实很低,why??? 原因分析: 抓取w3wp进程的dump发现,正在运行的线程都没有我们系统的堆栈代码.并且长时间运行的工作线程的栈顶基本都是Oracle.DataAccess.Client.OracleTuningAgent.DoScan() ---->Oracle.DataAccess.Client.Oracle

问题描述:       某二次开发的项目反馈,不定期出现应用服务器无响应的情况,登录服务器发现任务管理器中有大量的w3wp僵尸进程. 分析过程: 针对同一进程每隔15秒抓取dump,连续抓取3个,对比发现线程信息没有变化,并且每个线程的CPU时间和堆栈都没有变化,奇怪??? 以其中一个僵尸进程的dump日志为例,总计61个工作线程,其中正在运行的为15个,但我们仅能查看其中3个线程的信息. 0:000> .load d:\dumps\sos.dll 0:000> !tp CPU utiliza

调试SQLSERVER (一)生成dump文件的方法 调试SQLSERVER (二)使用Windbg调试SQLSERVER的环境设置调试SQLSERVER (三)使用Windbg调试SQLSERVER的一些命令 我们知道调试程序主要有两种方法 一种是:live debugging (附加进程 使进程hang住) 生产环境最好不要live debugging 一种是:post-mortem debugging or reading dump files (生成dump文件然后进行分析) 现在介绍一

#重要说明 (1) windbg命令分为标准命令,元命令和扩展命令. 标准命令提供最基本的调试功能,不区分大小写.如:bp  g  dt  dv  k等 元命令提供标准命令没有提供的功能,也内建在调试引擎中,以.开头.如.sympath  .reload等 扩展命令用于扩展某一方面的调试功能,实现在动态加载的扩展模块中,以!开头.如!analyze等 (2) 进入调试状态时,直接回车可重复执行上一条命令:按上下方向键可以浏览和选择以前输入过的命令 (3) 神奇的Tab键,进行命令补全:ESC清除

IBM AIX Java 1. topas 命令定位 CPU 使用高的进程,比如下面 PID 614852 Name            PID  CPU% java         614852  23.9 java         450806  20.5 2. 使用命令 ps -mp <PID> -o THREAD 定位 CPU 使用高的线程 TID 比如下显示线程 (TID)11219165 消耗了 22% CPU.  把 11219165 换成 16 进制得到 AB30DD ps

breakpad是Google开源的一套跨平台工具,用于dump的处理.很全的一套东西,我这里只简单涉及breakpad客户端,不涉及纯文本符号生成,不涉及dump解析. 一.使用 最简单的是使用进程内dump捕获,使用者只需要跟ExceptionHandler打交道,在自己的程序里定义一个ExceptionHandler对象,ExceptionHandler会挂上异常处理.CRT参数错误处理.purecall错误处理,当发生crash时,breakpad会写好dump,然后回调通知使用者.进程

原文:https://github.com/oldratlee/useful-shells useful-shells 把平时有用的手动操作做成脚本,这样可以便捷的使用. show-busy-java-threads.sh 在排查Java的CPU性能问题时,找出Java进程中消耗CPU多(top us值过高)的线程,查看它的线程栈,从而找出有性能问题的方法调用. $ ./show-busy-java-threads.sh The stack of busy(57.0%) thread(23355

Dump Checking Debug相关的一些小技巧 摘要: 1. 如何Debug一个进程的子进程? 答: 使用WinDBG attach到父进程, 然后输入命令".childdbg 1"(无引号). 这样子进程在刚刚被加载的时候, WinDBG就Attach上去了. 这两个进程的debug session都在一个WinDBG的窗口里, 如果想要切换当前进程, 可以使用命令"|"来查看所有的进程, 使用"|0s"来切换到ID为0的进程, 以此类

进行数据替换无非就是三步, 杀掉redis进程 ------------> 复制 dump.db文件 ------------------>启动redis   pkill redis-server mv dump.rdb /www/var/lib/redis /opt/redis/bin/redis-server /opt/redis/redis.conf

The version of SOS does not match the version of CLR you are debugging 和 PDB symbol for clr.dll not loaded  解决WinDbg调试Dump文件不同环境mscordacwks.dll版本问题 程序发生了崩溃,我抓了一个mini Dump,Mini dump 有一个优点就是非常的小.比full dump 要小很多. 0:020> .loadby sos clr //首先加载sos 0:020>

前言 在分析一个 jar 包时发现他把关键类采用了运行时使用 classloader 的方式加载了.懒得分析算法了,可以使用 jdk 自带的工具 dump 出需要的class. 正文 从运行的java进程里dump出运行中的类的class文件的方法,所知道的有两种 用agent attatch 到进程,然后利用 Instrumentation和 ClassFileTransformer就可以获取 到类的字节码了. 使用 sd-jdi.jar里的工具 本文介绍的就是使用 sd-jdi.jar 来d