不完美逆向320块的apihook教程
好把,他的是教程,俺这不是,只是写着玩的简单的逆向烂文。希望各位客官不要拍砖。
要说起来逆向这个程序的原因呢,其实也很简单,前段时间在天空下载软件,无意中发现了一个软件。自称是API拦截技术教程,还开价320元。apihook的技术在windows核心技术里讲了很多,居然还有人卖这么贵,我就对他来了点兴趣。程序的简介是这样的。
对于程序员来讲,API拦截技术是一种重要的基础技术。这项技能为编写某些工具软件提供了可能,并可以大大提高我们对第三方应用程序的控制能力。不过,目前 API 拦截的技术资料往往局限于原理方面的论述,对于如何具体地编译一个 API 拦截程序却守口如瓶。毕竟,对于程序员来讲,当初学习这项技能花费了不少心血,如果让他们无偿地奉献出来,恐怕不太现实;另外的一个因素就是竞争,多一个人学会这项技能,就多一份竞争。我在掌握这项技能的时候,就走了不少弯路,如果当初有一份详细的资料,这些不必要的弯路是完全可以避免。而这正是我编写这份技术资料的目的。
本程序是一个示例程序,用以演示如何拦截 API 调用。开始拦截 CreateProcess之后,当用户通过资源管理器运行程序时,就会弹出一个对话框提示用户运行了什么程序。停止拦截之后,用户运行程序时则不会弹出对话框。
随本程序附带的教程是未注册版本,如果您需要详细的资料,请通过网上商城进行注册。注册费用为 320 元人民币。最终价格请以网上商城的价格为准。
这就引起了我的好奇,难道这个软件用了什么牛x的新技术?居然这么值钱!那得看看,于是就把该软件下载下来研究了研究。谁知道,他所用的技术不但一点创新都没有,还有着很大的局限性。于是就有了这篇文章,还希望高手不要见笑。
这个程序的原版大家自己找,名字就叫做API拦截教程。启动该程序后,按下拦截createprocess的按钮后,运行任何程序都会弹出运行程序的路径。稍微了解apihook的都了解,通常ring3下hookapi的办法有三种,一是修改程序的iat表,使api调用跳向自己的函数而不是转向api入口。二是修改api入口的机器码。三是用创建远线程CreateRemoteThread的办法来完成。那么这个教程究竟用了什么先进手法呢?
先运行一次,按下按钮后,果然explorer弹出了程序的路径。此时,你如果使用icesword类的可以查看程序模块的程序查看explorer的模块,你就会发现explorer里面多了个InterceptDll.dll的模块,当我们卸载了这个dll后,这个拦截的效果就没有了。看来这个程序的核心不是那个启动的程序,而是这个dll。现在让我们看看这个InterceptDll.dll到底做了什么。
先使用VC++的工具DUMPBIN将DLL中的导出函数表导出到一定义(.DEF)文件
DUMPBIN InterceptDll.dll /EXPROTS /OUT:InterceptDll.def
ordinal hint RVA name
1 0 00001230 InstallHook
2 1 00001270 UninstallHook
只有两个导出函数,看名字就知道,一个是安装钩子,一个卸载钩子。我们调用看看 ,结果连参数都不用,只要调用InstallHook就可以把InterceptDll.dll插入explorer,用UninstallHook就可以卸载钩子。看来我们不用分析他的exe文件了,因为有用的东西就在这个dll里。那么如何分析这个dll这么工作的呢?直接用ida看静态代码,可以看见dll里有vivirtualalloc,setwindowshookexa等钩子函数。但是,里面乜嘢CreateRemoteThread这个函数,那么基本可以排除了第三种方法了。修改iat或者字节数的可能性比较大一些。那么具体究竟是用了什么手段,又是怎么实现的呢?光静态看源代码看出来,我可没那种本事。如果说要实时调试explorer又非常的麻烦,那么怎么办呢?其实办法很简单啦,只要自己修改一个exe文件名让他跟explorer同名就可以了。这家伙可不管你是真李逵还是假李鬼,统统都插!我先写了个很简单的exe程序,只有一个按钮直接掉用createprocess启动notepad的小程序,然后改名为explorer。运行后让程序拦截,果然再用icesword看模块,那个InterceptDll.dll偷偷的钻进了我写的这个程序。
好,现在动手钻进InterceptDll.dll的内部,看看他到底干了什么!我用的是olldbg,其实windbg也可以,我用od习惯了。先附加到我自己写的这个小explorer程序,然后在createprocess下断点,按下启动notepad的按钮,断下以后,一步一步跟踪。当进入到原先createprocess的领空的时候,入口变了
7C802332 >- E9 B9ED7F93 jmp 100010F0
7C802337 6A 00 push 0
变成了跳向100010F0,运行了这个跳转,就进入了dll的程序代码段。具体汇编代码如下。
100010F1 8BEC mov ebp, esp
100010F3 6A FF push -1
100010F5 68 50710010 push 10007150
100010FA 68 7C220010 push 1000227C
100010FF 64:A1 00000000 mov eax, dword ptr fs:[0]
10001105 50 push eax
10001106 64:8925 0000000>mov dword ptr fs:[0], esp
1000110D 83EC 0C sub esp, 0C
10001110 53 push ebx
10001111 56 push esi
10001112 57 push edi
10001113 33C0 xor eax, eax
10001115 8945 E4 mov dword ptr [ebp-1C], eax
10001118 8945 FC mov dword ptr [ebp-4], eax
1000111B 50 push eax
1000111C 68 44710010 push 10007144 ; ASCII "鎎*b"
10001121 8B75 0C mov esi, dword ptr [ebp+C]
10001124 56 push esi
10001125 50 push eax
10001126 FF15 FC700010 call dword ptr [100070FC] ; USER32.MessageBoxW
1000112C 8B45 2C mov eax, dword ptr [ebp+2C]
1000112F 50 push eax
10001130 8B4D 28 mov ecx, dword ptr [ebp+28]
10001133 51 push ecx
10001134 8B55 24 mov edx, dword ptr [ebp+24]
10001137 52 push edx
10001138 8B45 20 mov eax, dword ptr [ebp+20]
1000113B 50 push eax
1000113C 8B4D 1C mov ecx, dword ptr [ebp+1C]
1000113F 51 push ecx
10001140 8B55 18 mov edx, dword ptr [ebp+18]
10001143 52 push edx
10001144 8B45 14 mov eax, dword ptr [ebp+14]
10001147 50 push eax
10001148 8B4D 10 mov ecx, dword ptr [ebp+10]
1000114B 51 push ecx
1000114C 56 push esi
1000114D 8B55 08 mov edx, dword ptr [ebp+8]
10001150 52 push edx
10001151 E8 7AFFFFFF call 100010D0
当运行到 call 100010D0 时开始跳回原领空
call 100010D0里面的实际代码是这样的。
100010D0 8BFF mov edi, edi
100010D2 55 push ebp
100010D3 8BEC mov ebp, esp
100010D5 - E9 5D12806C jmp kernel32.7C802337
而 kernel32.7C802337处
100010D0 8BFF mov edi, edi
100010D2 55 push ebp
100010D3 8BEC mov ebp, esp
正是原本createprocess代码接下来的一段
到这里,这个dll的hook功能就真相大白了,他完全没有使用什么新技术来完成hook。照样是修改api函数的头5个字节,然后跳转到自己的函数,之后再构造一个类似的头,最后跳回原来的api领空继续运行。这个完全就是windows核心编程里的代码的照抄,就这抄一下就要人320元,是在有点太黑了吧!
更为重要的是,apihook中这样的hook有很大的缺陷,为什么这么说呢?我们可以看见他是将入口修改为 jmp 100010F0
7C802332 >- E9 B9ED7F93 jmp 100010F0
我们知道一般的api函数头部是不会出现这样的远距离的jmp的,所以只要检测api的函数头一个字节是否e9就可以很轻松的检测出api是否被hook住了。还有一个问题就是,如果我们的目的并不停止于,只是在api函数处理之前修改某些入口函数或者做些处理,而是整个重新处理而不回到系统的api处理处,这个流程也不符合我们的要求。
不过没有关系,既然现在我们已经知道了这个dll工作的大至流程,我们也可以自己写一个拦截createprocess的dll了,而我们把这个程序改进一下,使他成为一个全局的钩子,而且我们可以选择程序的开启,在程序开启以前弹出一个msgbox,上面有是和否的按钮,你按下是程序就不能启动,而按下否程序就照常启动,而弹出的按钮里不但有这个程序的路径,还有启动这个程序的路径。怎么样,比他的还要高级一些吧。
我想说一句,大家不要总说Detours,因为表面上Detours可以很容易的钩住api,但是他的自由度太低了。最重要的是,他无法完成ssdt hook,还是提高自己的水平最重要。
我改出了两个版本一个是asm的一个是vc的,但是奇怪的是asm代码没有问题,而vc的代码却出了问题,我希望高手能帮我解决以下两个问题,
相关推荐
JEP30-PX100A PartModel Product Guidelines for Electronic-Device Substrates and Assemblies – XML Requ
JEP30-PX100A PartModel Product Guidelines for Electronic-Device Substrates and Assemblies – XML Requirements
基于Matlab的自动睡眠粒状结构检测算法,从脑电信号中进行。.zip
1.版本:matlab2014a/2019b/2024b 2.附赠案例数据可直接运行。 3.代码特点:参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象:计算机,电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
JEP375 2.5D_3D Silicon thinned wafers with Through Silicon Vias (TSV’s) and Backside Redistribution
JEP375 2.5D_3D Silicon thinned wafers with Through Silicon Vias (TSV’s) and Backside Redistribution Layer (RDL).pdf
考虑供电可靠性与算力柔性的数据中心园区源‑储‑荷一体化规划研究(Matlab代码实现)
考虑供电可靠性与算力柔性的数据中心园区源‑储‑荷一体化规划研究(Matlab代码实现)内容概要:本文围绕“考虑供电可靠性与算力柔性的数据中心园区源-储-荷一体化规划”展开研究,提出了一种综合能源系统优化规划方法。该方法充分考虑数据中心对供电可靠性的高要求以及算力负载的灵活性特征,将电力供应、储能配置与计算负荷进行协同优化。通过建立数学模型,整合光伏发电、储能系统与数据中心负荷调度,利用Matlab代码实现优化求解,旨在提升能源利用效率、降低运营成本并增强系统韧性。研究涵盖了对新能源出力不确定性、负荷波动以及储能动态行为的建模与仿真分析,最终验证了所提一体化规划方案在提高供电可靠性和实现算力资源柔性调度方面的有效性。; 适合人群:具备一定电气工程、能源系统或计算机科学背景,从事数据中心、智能电网、综合能源系统等相关领域研究的研究生、科研人员及工程技术人员。; 使用场景及目标:① 为数据中心园区的绿色低碳与高可靠运行提供规划设计方案;② 实现可再生能源的高效消纳与储能系统的优化配置;③ 探索算力作为柔性负荷参与电力系统互动的潜力,支撑新型电力系统建设。; 阅读建议:此资源以Matlab代码为核心,辅以理论模型,建议读者在理解基本原理的基础上,动手运行和调试所提供的代码,通过修改参数和场景设置来深入掌握一体化规划的优化逻辑与关键技术细节。
歌曲爆款传播预测数据集10000首曲目Spotify音频特征机器学习
本数据集为合成音乐数据,包含2010至2025年间10000首曲目的Spotify风格音频特征与明确的爆款(viral)目标标签。现有音乐数据集常缺少可用建模目标或存在授权限制,本数据集提供了干净、字段完整、可直接用于监督学习的基准语料。字段涵盖节奏、能量、可舞性、声学度、效价等音频属性,以及曲目元数据与年份信息,目标列viral基于传播表现定义,可直接用于二分类建模。适合开展爆款歌曲预测、音频特征与传播关系分析、年代音乐风格演变可视化、特征重要性排序等分析任务,也可作为分类、回归与特征工程教学的演示数据。数据结构清晰、无缺失值,适合数据科学课程、音乐媒体分析与推荐算法原型验证使用。


