文章总结： 文章介绍了一种使用时间侧信道攻击检测KernelSU的方法，通过比较faccessat和fchownat系统调用的执行时间差异来判断是否存在hook。在正常情况下faccessat更快，但当KernelSU存在hook时会导致faccessat变慢，形成可检测的时间差异。作者分析了检测代码的七个阶段，并在不同Android版本上进行了测试，指出对抗这种检测可能需要魔改hook函数或处理检测函数。
综合评分： 88
文章分类： 漏洞分析,逆向分析,移动安全,安全工具
KernelSU检测之“时间侧信道攻击”
九天666
看雪学苑
2025年11月6日 18:05
上海
偶然间拿到一个海外Bank的样本,打开后出现崩溃的现象，但是我的手机只刷了KernelSU，并且还魔改过的，以前一直都是过五关斩六将，但是这个app为什么会崩溃呢，难道说是检测到我的环境装了KernelSU？
带着这个疑问对这个样本进行了一系列惨无人道的摧残，发现确实检测了KernelSU,并且不是普通的检测方式，而是鲜少听闻的”侧信道攻击“检测。
在开始之前说下什么是“侧信道攻击”。
Part.01
什么是“侧信道攻击”
#
核心概念：不正面强攻，而是“旁敲侧击”
#
想象一下，你想知道一个保险箱的密码，但你并不去尝试破解它的机械结构或电子锁。
◆传统攻击（正面攻击）：你试图用听诊器听密码锁的声音，或者用炸药强行炸开。
◆侧信道攻击（旁敲侧击）：你不直接碰锁，而是去：
-
测量
：转动密码盘时，保险箱发出的微弱声音或振动。
-
观察
：主人输入密码时，他手指的运动轨迹和按键上的指纹磨损。
-
计时
：记录主人从开始输入到打开箱门所花费的总时间。
-
分析功耗
：如果这是一个电子锁，你测量它在尝试不同密码时的微小电量消耗差异。
通过分析这些间接信息，你很有可能推断出正确的密码。这种通过收集和分析系统在运行过程中产生的物理间接信息，而不是直接攻击算法或代码本身，来获取秘密信息的攻击方式，就叫做侧信道攻击。
常见侧信道攻击类型一览表
| 攻击类型 | 攻击原理 | 典型例子 | 关键特点 |
| — | — | — | — |
| 计时攻击 | 测量操作执行时间，通过时间差异推断数据。例如，字符串比较时，早期返回错误会导致更短的执行时间。 | 1. 分析网站登录验证，猜测用户名和密码。 2. 通过测量RSA解密操作的时间来推测私钥。 | 纯软件攻击，无需物理接触。依赖代码逻辑不是“恒定时间”的。 |
| 功耗分析攻击 | 测量设备运行时芯片的功耗波动。处理不同数据（0或1）时功耗有微小差异，分析这些“功耗轨迹”可还原密钥。 | 1. 攻击智能卡、加密狗。 2. 攻击POS机，窃取信用卡PIN码。 | 需要物理接近和精密仪器（如示波器）。分为简单功耗分析（SPA）和差分功耗分析（DPA）。 |
| 电磁分析攻击 | 测量设备运行时散发的电磁辐射。与功耗分析类似，电磁辐射也携带着与当前操作和数据相关的信息。 | 1. 通过探测手机CPU的电磁辐射，还原其正在运行的加密算法和密钥。 2. 攻击接触式/非接触式智能卡。 | 是一种“非侵入式”攻击，可以在一定距离外进行。信息量可能比功耗更丰富。 |
| 声音攻击 | 录制设备运行时的声音，分析其机械部件的声学特征，来还原处理的信息。 | 1. 通过点阵打印机的声音还原打印内容。 2. 通过键盘敲击声识别输入的按键。 3. 通过硬盘寻道声推测读取的数据。 | 利用的是机械振动产生的声音，对麦克风灵敏度要求高。 |
| 缓存攻击 | 利用CPU缓存的访问时间差异（缓存命中快，未命中慢）。通过监控自身程序的访问速度，来探测受害者进程的缓存使用情况，从而泄露信息。 | 1.Spectre（幽灵）和Meltdown（熔断）漏洞就是利用缓存侧信道跨进程窃取内核内存数据。 2. 在云环境中，攻击同一物理主机的其他虚拟机。 | 是现代CPU微架构中最重要的侧信道之一，威胁云安全。 |
| 光学攻击 | 使用高分辨率相机等设备，捕捉设备运行时泄露的光学信息。 | | |
#
#
Part.02
分析
#
样本so用了AppGuard加固,且应用自身的so被加密了,节约时间就直接步入正题。
检测方式用的是“时间侧信道攻击”。
检测代码
这是ksu的检测代码，接下来对其进行拆解
__int64 __fastcall ksu_check(void *a1){
__int64 v1; // x0
__int64 *v2; // x22
__int64 v3; // x19
__int64 v4; // x0
void **v5; // x21
__int64 v6; // x20
__int64 v7; // x0
__int64 i; // x20
__int64 v9; // x19
__int64 v10; // x0
__int64 j; // x20
__int64 v12; // x19
__int64 (__fastcall *v13)(constvoid *, constvoid *); // x19
__int64 v14; // x20
void *v15; // x0
int32x2_t v16; // d0
int64x2_t v17; // q1
uint64x2_t *v18; // x8
int64x2_t *v19; // x9
int32x2_t v20; // d2
uint64x2_t v21; // q3
uint64x2_t v22; // q4
int32x2_t v23; // d0
unsigned __int32 v24; // s0
LODWORD(off_132FC0) = sub_67AF8(a1);
if ( off_132FC0 >= 2 )
{
sub_67E1C();
if ( off_132FD8 )
sub_67F8C();
}
v1 = sub_539B0(80000LL);
v2 = d1_ptr;
v3 = v1;
*d1_ptr = v1;
v4 = sub_539B0(80000LL);
v5 = d2_ptr[0];
v6 = v4;
*d2_ptr[0] = v4;
sub_54EB0(v3, 0LL, 80000LL);
v7 = sub_54EB0(v6, 0LL, 80000LL);
for ( i = 0LL; i != 80000; i += 8LL )
{
v9 = sub_67AD8(v7);
v10 = sub_54E70(48LL, 0xFFFFFFFFLL, 0LL, 0xFFFFFFFFLL, 0LL);
v7 = sub_67AD8(v10);
*(*v2 + i) = v7 - v9;
}
for ( j = 0LL; j != 80000; j += 8LL )
{
v12 = sub_67AD8(v7);
v7 = sub_67AD8(linux_eabi_syscall(__NR_fchownat, -1, 0LL, 0, 0, -1));
*(*v5 + j) = v7 - v12;
}
v13 = compare;
v14 = 10000LL;
sub_557B0(*v2, 10000LL, 8LL, compare);
sub_557B0(*v5, 10000LL, 8LL, v13);
v15 = *v2;
v16.n64_u64[0] = 0LL;
v17 = vdupq_n_s64(1uLL);
v18 = (*v2 + 16);
v19 = (*v5 + 16);
v20.n64_u64[0] = 0LL;
do
{
v21 = v18[-1];
v22 = *v18;
v18 += 2;
v14 -= 4LL;
v16.n64_u64[0] = vsub_s32(v16, vmovn_s64(vcgtq_u64(v21, vaddq_s64(v19[-1], v17)))).n64_u64[0];
v20.n64_u64[0] = vsub_s32(v20, vmovn_s64(vcgtq_u64(v22, vaddq_s64(*v19, v17)))).n64_u64[0];
v19 += 2;
}
while ( v14 );
v23.n64_u64[0] = vadd_s32(v20, v16).n64_u64[0];
v24 = vadd_s32(v23, vdup_lane_s32(v23, 1)).n64_u32[0];
if ( v24 > 0x1B58 )
{
sub_681AC(v24);
v15 = *v2;
}
operator delete(v15);
operator delete(*v5);
return 0LL;
}
拆解分析
阶段1：环境初始化
LODWORD(off_132FC0) = sub_67AF8(a1); // 获取 CPU 核心数
if ( off_132FC0 >= 2 )
{
sub_67E1C(); // 分析 CPU 性能
if ( off_132FD8 )
sub_67F8C();// 绑定到高性能核心
}
作用：
◆获取核心数，评估性能并识别大核
◆绑定到高性能核心以稳定测量
阶段2：内存分配
v1 = sub_539B0(80000LL);//sub_539B0-->malloc
v2 = d1_ptr;
v3 = v1;
*d1_ptr = v1;
v4 = sub_539B0(80000LL);
v5 = d2_ptr[0];
v6 = v4;
*d2_ptr[0] = v4;
sub_54EB0(v3, 0LL, 80000LL);//sub_54EB0-->memset
v7 = sub_54EB0(v6, 0LL, 80000LL);
作用：为时间数据分配并清零内存
阶段3：收集时间
这里会收集两个函数的执行耗时
for ( i = 0LL; i != 80000; i += 8LL )
{
v9 = sub_67AD8(v7);//开始时间
v10 = sub_54E70(48LL, 0xFFFFFFFFLL, 0LL, 0xFFFFFFFFLL, 0LL);//sub_54E70-->syscall
v7 = sub_67AD8(v10);//结束时间
*(*v2 + i) = v7 - v9;
}
for ( j = 0LL; j != 80000; j += 8LL )
{
v12 = sub_67AD8(v7);//开始时间
v7 = sub_67AD8(linux_eabi_syscall(__NR_fchownat, -1, 0LL, 0, 0, -1));
*(*v5 + j) = v7 - v12;//结束时间
}
unsigned __int64 sub_67AD8()//提供纳秒级计数器值{
unsigned __int64 result; // x0
__isb(0xFu);// 指令同步屏障
result = _ReadStatusReg(CNTVCT_EL0);// 读取虚拟计数器
__isb(0xFu);// 指令同步屏障
return result;
}
分别收集__NR_faccessat和__NR_fchownat的执行时间
阶段4：排序数组
v13 = compare;
v14 = 10000LL;
sub_557B0(*v2, 10000LL, 8LL, compare); //sub_557B0-->qsort
sub_557B0(*v5, 10000LL, 8LL, v13);
作用：稳定比较，减小极值影响
阶段5：NEON 向量化比较
do
{
v21 = v18[-1];
v22 = *v18;
v18 += 2;
v14 -= 4LL;
v16.n64_u64[0] = vsub_s32(v16, vmovn_s64(vcgtq_u64(v21, vaddq_s64(v19[-1], v17)))).n64_u64[0];
v20.n64_u64[0] = vsub_s32(v20, vmovn_s64(vcgtq_u64(v22, vaddq_s64(*v19, v17)))).n64_u64[0];
v19 += 2;
}
while ( v14 );
v23.n64_u64[0] = vadd_s32(v20, v16).n64_u64[0];
v24 = vadd_s32(v23, vdup_lane_s32(v23, 1)).n64_u32[0];
作用：并行比较并累加异常计数
这段代码理解起来可能比较吃力,换个如下实现方式就非常清晰了
uint32_t anomaly = 0;
for (int i = 0; i < NUM_SAMPLES; i++) {
if (baseline[i] > syscall_array[i] + 1) {
anomaly++;
}
}
就是单纯的比较NR_faccessat数组和NR_fchownat数组里的元素大小，当出现NR_faccessat>NR_fchownat的情况是就记录为一次异常,往后依次自增。
用NEON的目的是为了提升代码执行性能。
阶段6：判断与处理
if ( v24 > 0x1B58 )// 阈值 0x1B58 = 7000
{
sub_681AC(v24); // 检测到 KernelSU，触发处理
v15 = *v2;
}
作用:超过阈值时判定存在 hook，并触发回调
阶段7：清理资源
operator delete(v14);
operator delete(*v5);
return 0;
KernelSU源码针对分析
针对这块的检测我们可以简单看看KernelSU的hook
实现方式
为何选择faccessat检测
◆选择 faccessat 因其在 KSU hook 列表中，且满足“简单、快速、失败无副作用”的要求
◆其他 hook 调用要么更复杂，要么有副作用，不适合用作可靠的基线或被测调用
一般来说faccessat的执行速度是要比fchownat快的，如果faccessat出现大量慢于fchownat的情况，那么说明环境有异常。
实践
Android 15
Android 10
小结
// 正常路径
syscall -> kernel -> 快速返回
时间：50-100 纳秒
// 有任何拦截后
syscall -> kernel -> hook层 -> 返回
时间：200-500 纳秒
Part.03
总结
“侧信道攻击”防护确实非常有效，感觉针对这种防护的方式只有进一步去魔改对应的hook函数了,要么就针对处理检测函数。
#
看雪ID：九天666
https://bbs.kanxue.com/user-home-947335.htm
*本文为看雪论坛优秀文章，由 九天666 原创，转载请注明来自看雪社区
往期推荐
静态程序分析之数据流分析(Foundations + LiveVar Analysis Code)续
基于Minifilter实现目录保护软件，自定义保护目录，用户可选择是否允许文件行为
球分享
球点赞
球在看
点击阅读原文查看更多
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：看雪学苑 九天666《KernelSU检测之“时间侧信道攻击”》