欲知己之所防，先知彼之所攻——论Hook 技术的攻防对抗

APP常见风险主要分为:客户端安全、数据安全、通信安全、业务安全。

一、客户端安全:

1、签名校验:大部分的Android APP没有对正盗版进行校验，重新签名后的APP在手机中安装后可以正常运行,

这使APP面临被他人反编译、恶意篡改、二次打包的风险。

2、未检测安全环境:

1）ROOT环境: APP在ROOT环境下运行可以随意访问任意应用储存的任何数据，造成数据泄露、数据非法篡改等风险。

2）模拟器环境:攻击者通过自己修改定制特定的模拟器来达到监控应用关键函数、获取应用敏感数据，破解应用的目的。

3）Hook环境: Xposed/Substrate是 常见的hook框架,黑客可使用hook手段对apk进行脱壳、内存截取/修改等操作。

4）代理环境: APP应用运行在代理环境下，通信过程能被中间人截获,造成用户请求伪造、重放攻击、敏感信息泄露等威胁。

3、配置安全: allowbackup备份风险、 Debug属性安全、 组件安全

4、代码安全:反编译风险、-次打包风险、so文件风险、动态调试风险、进程注入安全

二、数据安全

1、不安全的数据存储:

SharePreferences数据明文存储、SQLite数据明文存储

2、Logcat日志: .

移动应用在运行的过程中，通过adb或者monitor查看实时打印日志，如果日志的输出没有做好等级控制，则存在用户名、密码等敏感信息泄露的风险。

3、密钥存储安全:

APP开发者将密钥信息硬编码在代码中，造成密钥泄露。

三、通信安全

1、不安全的通信:

移动APP与服务器进行交互时，使用不安全的HTTP协议,对数据进行明文传输，攻击者将有机会对当前网络环境中其他合法用户的通信内容进行甚至算改，进而影响数据的安全性。

2、未对通信双方身份进行鉴别(不安全的身份验证) :

移动APP与服务器进行交互时，互相不验证证书,手机设置代理，使用Burpsuite等抓包工 具可以捕获APP所有请求,造成中间人攻击、通信数据被泄露的风险。

3、未加密或加密不足: .

如果使用弱加密算法对数据进行加密处理，存在被破解，造成数据泄露的风险。

四、业务安全

1、身份鉴别安全

任意用户登录风险、用户名注册状态泄露、弱密码风险、账户登录限制、登录密码爆破风险、账号注销安全

2、验证码机制安全

验证码爆破风险(短信轰炸)、验证码泄露风险、验证码无限发送风险、万能验证码、修改返回包绕过验证码找回密码

3、支付机制安全

支付密码爆破风险、交易篡改风险、支付数据包重放风险

Hook在 React 和 Vue 中使用

游戏辅助软件开发，过保护一直以来都是关键的一步骤，今天我们来再谈SSDT HOOK驱动保护原理（主要分为以下四部分）：初识内核进程相关结构；内核函数PsGetCurrentProcess；进程保护原理；实例测试。具体代码等可以和小编聊聊（私信:游戏辅助），最近也收集了一些资料。

看一个实例（代码已经写好了）

将 mini_ddk.sys 和 test_exe.exe 复制到 虚拟机，载入驱动

以一个记事本进程为例

启动 WinDBG

ZC: WinDBG 中 打印了很多信息...

∵ 被hook了之后，系统的速度变慢了，可以看到 虚拟机中的CPU已经被占满了

ZC: 看这个显现，貌似有点死循环的意思啊...不像变慢啊...【575】WinDBG中也看到信息一直在打印出来，个人判断，肯定是写的代码有问题，貌似是 无休止的调用某函数的缘故。

我们把调试去掉（ZC: WinDBG里面打了 命令"g"，貌似这个操作与"去掉调试"没有关系吧...它说的"把调试去掉"应该是指把test_exe.exe关掉/mini_ddk.sys卸载掉？）

ZC: 貌似虚拟机重启过了

此时，再用 CE 来附加 记事本进程，CE报错"打开进程错误"，它已经被保护起来了

并非说 记事本进程 就绝对的 能够得到很好的保护了，如 OD里面有一些过保护的插件，它就可以过这个保护

打开 OD1.1(郁金香OD2010.exe)，此时(OD-->文件-->附加)找不到 记事本的进程

OD-->插件-->StrongOD-->Options-->"*KernelMode"勾上 -->关闭OD

再次打开 OD 【990】此时(OD-->文件-->附加) 能看到 记事本进程，也能正常的附加

OD-->反汇编窗口-->右击-->StrongOD-->Detach --> 关闭OD

只是一个简单的演示

CE5.4 里面 也有一个 内核模式: CE-->设置-->其他 --> 隐藏模式(内核模式)，但是这个是 调试模式，不知道这个有没有用。∵ 虚拟机里面测试非常的不方便，就不再做再多的演示了，有兴趣自己测试

看一下原理

对 函数NtOpenProcess 做了一个 SSDT的 HOOK，它不是一个内联的(ZC: 讲的是"内联的"吗?)

一般来说比较强的保护的话，它都是一个内联的更深层次的保护，今天我们就不说内联HOOK了，说SSDT的HOOK

内核里面的 NtOpenProcess 如下：

“

NTSTATUS NtOpenProcess(

__out PHANDLE ProcessHandle, // 【1360】这个是用来回传参数的

__in ACCESS_MASK DesiredAccess, // 【1410】访问权限的掩码

__in POBJECT_ATTRIBUTES ObjectAttributes,

__in_opt PCLIENT_ID ClientId

);

”

MSDN里面查看看 OpenProcess，返回值 对应 函数NtOpenProcess的参数ProcessHandle

HANDLE OpenProcess(

DWORD dwDesiredAccess, // 【1485】对应函数NtOpenProcess的参数DesiredAccess

BOOL bInheritHandle, // 【1680】对应函数NtOpenProcess的参数ObjectAttributes

DWORD dwProcessId

);

OpenProcess的参数dwProcessId 对应的不是 函数NtOpenProcess的参数ClientId

包含这样一个结构 dt _CLIENT_ID 这个结构，在OD里面也能看到，在WInDBG里面能够看到（ZC: 到底 OD里能不能看到？）

vs2003里面看到 ntddk.h中 有该结构的定义

“

typedef struct _CLIENT_ID

{

HANDLE UniqueProcess;//进程PID

HANDLE UniqueThread; //线程PID

} CLIENT_ID;

”

根据传入的值，这个值(CLIENT_ID.UniqueProcess)如果是我们要打开的进程，做一个简单的过滤，就直接返回 函数NtOpenProcess的参数ProcessHandle 的值 为空。我们对 OpenProcess 进行SSDT的HOOK 进入我们自己的函数，自己构建一个假的函数 MyNtOpenProcess()

“

MyNtOpenProcess()

{

if 要打开进程是我们要保护的

{

ProcessHandle=NULL

}

else

{

ProcessHandle = NtOpenProcess()//HANDLE hProcess

}

}

”

这样就起到一个简单的保护作用

MSDN查看 WriteProcessMemory

也就是说 我们的战场就是在 OpenProcess这里

看一下这个结构 "dt _eprocess"

打开虚拟机，启动 WinDBG

∵ 进程相关的结构，在程序(vs2003)里面是看不到的，∵该结构是一个未公开的一个结构

VS2003中 _EPROCESS 【2565】此时 提示“未定义符号"_EPROCESS"”

ZC: 根据 应用层的结构-->得到内核未公开的结构名-->在WinDBG中用"dt"命令 一点一点往下挖

WinDBG 命令"dt _eprocess"

_EPROCESS.DebugPort 比较重要，常用来 反调试

_EPROCESS.ImageFileName 进程名。也可以通过过滤进程名来保护进程

WinDBG 命令"dt _CLIENT_ID"

看一下 大致的代码

小编搜集了一些资料，有兴趣的可以私信：游戏辅助，了解些下