qianmu's blog

Frida总体来自吾爱破解-正己的Frida篇教程 原理Frida 是一款开源的动态插桩工具，可以插入一些代码到原生App的内存空间去动态地监视和修改其行为，支持Windows、Mac、Linux、Android或者iOS，从安卓层面来讲，可以实现Java层和Native层Hook操作。 frida注入的原理就是找到目标进程,使用ptrace跟踪目标进程获取mmap，dlopen，dlsym等函数库的偏移获取mmap在目标进程申请一段内存空间将在目标进程中找到存放frida-agent-32/64.so的空间启动执行各种操作由agent去实现 插桩技术frida使用的是动态二进制插桩技术（DBI），首先来了解一下插桩技术： 插桩技术是指将额外的代码注入程序中以收集运行时的信息，可分为两种：(1)源代码插桩[Source Code Instrumentation(SCI)]：顾名思义，在程序源代码的基础上增加（注入）额外的代码，从而达到预期目的或者功能； 源代码插桩实例 (2)二进制插桩（Binary Instrumentation）：额外代码注入到二进制可执行文件中，通 ...

使用Windows API在Ring3对系统进行操作Cmd使用管道通信 客户端 LoadLibrary(“Cmd.dll”); GetProcAddress 获取下述各种函数地址 SetPipeCommunication开启管道通信 启动cmd.exe，SetPipeData发送服务端的数据 启动线程，GetPipeData获取管道内的数据（cmd返回的），向服务端发送 析构时UnsetPipeCommunication释放管道 服务端接受到客户端返回的东西然后展示 用户输入要在客户端cmd运行的东西，发送出去（IOCP） 登录客户端 capGetDriverDescription获取打印机、摄像头等外部设备信息 RegOpenKey打开注册表键句柄，RegQueryValueEx传入句柄和要查的键string获取值 上述方法查到进程信息，在HARDWARE\DESCRIPTION\System\CentralProcessor\0，ProcessorNameString 发送到服务端 服务端拿到信息设置进数据结构里面 服务管理客户端 LoadLibrary(“Service.dl ...

arm和thumb为什么逆向的时候计算thumb地址是so 基址 + 函数在 so 中的偏移 + 1？ 【ARM】Thumb2指令集中函数的地址不对齐？_thumb 地址-CSDN博客 ARM指令集： 编代码全部是 32bits 的，每条指令能承载更多的信息，因此使用最少的指令完成功能， 所以在相同频率下运行速度也是最快的， 但也因为每条指令是32bits 的而占用了最多的程序空间。 Thumb指令集： 编代码全部是 16bits 的，每条指令所能承载的信息少，因此它需要使用更多的指令才能完成功能， 因此运行速度慢， 但它也占用了最少的程序空间 Thumb-2指令集： 在前面两者之间取了一个平衡， 兼有二者的优势， 当一个 操作可以使用一条 32bits指令完成时就使用 32bits 的指令， 加快运行速度， 而当一次操作只需要一条16bits 指令完成时就使用16bits 的指令，节约存储空间。 实验程序： 12345678910111213141516void test(void (*p)(USART_TypeDef*,u8)){ ...} int mai ...

获取Ntdll常用服务信息和Ntos服务信息Ntdll公式 写好枚举等结构 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081enum{ ZW_CREATE_THREAD = 0, ZW_CREATE_THREAD_EX, ZW_SUSPEND_THREAD, ZW_SUSPEND_PROCESS, ZW_PROTECT_VIRTUAL_MEMORY, ZW_SHUTDOWN_SYSTEM, ZW_TERMINATE_THREAD, ZW_SET_CONTEXT_THREAD, ZW_TERMINATE_JOB_OBJECT, ZW_SYSTEM_DEBUG_CONTROL, ZW_CREATE_USER_PROCESS, ZW_DEBUG_ACTIVE ...

APC注入APC机制线程是不能被杀死 挂起和恢复的，线程在执行的时候自己占据着CPU，别人怎么可能控制他呢？举个极端的例子，如果不调用API，屏蔽中断，并保证代码不出现异常，线程将永久占据CPU。所以说线程如果想结束，一定是自己执行代码把自己杀死，不存在别人把线程结束的情况。 那如果想改变一个线程的行为该怎么办？可以给他提供一个函数，让他自己去调用，这个函数就是APC，即异步过程调用 对于内核APC，APC函数的插入和执行并不是同一个线程，具体点说：在A线程中向B线程插入一个APC，插入的动作是在A线程中完成的，但什么时候执行则由B线程决定。所以叫异步过程调用。 线程切换时，在SwapContext函数即将执行完成的时候，会判断当前是否有要执行的内核APC，接着将判断的结果存到eax，然后返回，接着找到上一层函数KiSwapContext函数，这个函数也没有对APC进行处理，而是继续返回，到父函数，会判断KiSwapContext的返回值，也就是判断当前是否有要处理的内核APC，如果有，则调用KiDeliverApc进行处理。 系统调用中断或者异常(_KiServiceExit)，会 ...

使用内核内存wdm给出的使用内存池方法 申请内存 123456789PVOID AllocateBuffer(ULONG ViewSize){ PVOID VirtualAddress = ExAllocatePool(NonPagedPool, ViewSize); if (VirtualAddress != NULL) { RtlZeroMemory(VirtualAddress, ViewSize); } return VirtualAddress;} 释放内存 1234VOID FreeBuffer(PVOID VirtualAddress){ ExFreePool(VirtualAddress);} new 和delete 关键字在驱动里面是不可以使用，通过重载的方式即可在内核中使用，并通过c++编译器来编译。使用面向对象时，DriverEntry系列函数需要extern “C” 内部重载 1234567891011121314151617181920212223 ...

使用Lookaside内存频繁申请和回收内存，会导致在内存上产生大量的内存“空洞”，从 而导致最终无法申请内存。DDK为程序员提供了Lookaside结构来解决这个问题。 频繁地申请内存，会导致一个问题，就是在内存中产生“空洞”。图 5-11显示了这种情况，在内存中先后申请三块内存。最开始可用的内 存是连续的。当某个时刻内存块2被回收以后，如果系统想分配一块略 微大于原先内存块2的内存，这时候原先的内存2就不能被申请成功。 因此，频繁地申请、回收内存会导致在内存上产生大量的内存“空洞”。 如果系统中存在大量的内存“空洞”，即使内存中有大量的可用内 存，也会导致申请内存失败。在操作系统空闲的时候，系统会整理内 存中的“空洞”，将内存中的“空洞”进行合并。 如果驱动程序需要频繁地从内存中申请、回收固定大小的内存，DDK提 供了一种机制来解决这个问题，这就是使用Lookaside对象。 可以将Lookaside对象想象成一个内存容器。在初始的时候，它先向 Windows申请了一块比较大的内存。以后程序员每次申请内存的时候， 不是直接向Windows申请内存，而是向Lookaside对象申请 ...

内核拦截DLL123456789FAST_MUTEX __AntiLoadDllLock;PANTI_LOAD_DLL __AntiLoadDll = NULL;VOIDInitializeAntiLoadDll(){ ExInitializeFastMutex(&__AntiLoadDllLock); BootReadFile();} 处理文件信息首先获取当前工作目录，然后将其与文件名 XXXX.ini 拼接起来，得到文件的路径。接着，使用 Windows API 函数 ZwCreateFile 打开文件，使用 ZwQueryInformationFile 获取文件长度，使用 ExAllocatePool 分配内存缓冲区，再使用 ZwReadFile 读取文件内容。最后，它调用 ParseAntiLoadFile 解析文件内容 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859 ...

突破safeSeh设计SafeSEH保护机制的目的，以为了防止那种攻击者通过覆盖堆栈上的异常处理函数句柄，从而控制程序执行流程的攻击。自Windwos XP SP2之后，微软就已经引入了SafeSEH技术。不过由于SafeSEH需要编译器在编译PE文件时进行特殊支持才能发挥作用，而xp sp2下的系统文件基本都是不支持SafeSEH的编译器编译的，因此在xpsp2下，SafeSEH还没有发挥作用（VS2003及更高版本的编译器中已经开始支持）。从Vista开始，由于系统PE文件基本都是由支持SafeSEH的编译器编译的，因此从Vista开始，SafeSEH开始发挥他强大的作用，对于以前那种简单的通过覆盖异常处理句柄的漏洞利用技术，也就基本失效了。 SafeSEH的基本原理很简单，即在调用异常处理函数之前，对要调用的异常处理函数进行一系列的有效性校验，如果发现异常处理函数不可靠（被覆盖了，被篡改了），立即终止异常处理函数的调用 对于目前的大部分windows操作系统，其系统模块都受SafeSEH保护，可以选用未开启SafeSEH保护的模块来利用，比如漏洞软件本身自带的dll文件，这个可以 ...

突破GS针对缓冲区溢出覆盖函数返回地址这一特征，微软在编译程序时候使用了一个很酷的安全编译选项—GS。/GS 编译选项会在函数的开头和结尾添加代码来阻止对典型的栈溢出漏洞（字符串缓冲区）的利用。当应用程序启动时，程序的 cookie（4 字节（dword），无符号整型）被计算出来（伪随机数）并保存在 加载模块的.data 节中,在函数的开头这个 cookie 被拷贝到栈中，位于 EBP 和返回地址的正前方（位于返回地址和局部变量的中间）。 [局部变量 ] [cookie] [保存的EBP] [保存的返回地址] [参数] 在函数的结尾处，程序会把这个 cookie 和保存在.data 节中的 cookie 进行比较。 如果不相等，就说明进程栈被破坏，进程必须被终止。 为了演示覆盖虚表指针这种技术，将使用下面的代码: 123456789101112131415161718192021222324252627282930313233343536373839404142434445#include "stdafx.h"#include "w ...