这篇著述只讲Android端签名检测，安卓发展到当前，因为国内环境莫得谷歌市集，是以许多官方保举的Api没法使用 ，是以国内的签名检测形势亦然“千奇百怪” 。发展于今每种步调皆有一些绕过粗略抵御妙技，这些步调很难说就一定准 ，可是咱们能作念的便是取尽可能的提高袭击者的资本，晋升Apk的签名检测能力，凝视灰黑产进行袭击 。基础的什么Java赢得签名信息这种基础有贪图柏木ゆう最新番号，这里暂时跳过 ，不在过多论说 。这篇著述主要分为Java和Native两部分 ，永诀从不同的视角取检测签名，包括如何抵御等 ， 其中包含一些大厂和企业壳的中枢检测签名念念路 。
Java层检测签名： 1、IPC契约赢得签名信息 ：领先讲这块之前需要先简便讲一下IPC契约的完结 。
安卓基础架构便是CS架构。每个App皆是客户端，劳动端只消一个 ，客户端和劳动端是不同的程度 。
这样作念的，客户端一朝发生崩溃不影响劳动端 ，劳动端也可以把柄不同的uid完结不同的鉴权操作 。当咱们赢得一些apk信息的期间皆是客户端发送IPC契约 。
劳动端袭取以后进行解决，行使binder进行通信，然后把数据写到客户端里面，客户端拿到 。这块瞎想许多技巧点 ，比如动态代理，IPC契约 ，Binder通信等
上头提及来可能很难解 ，领先咱们去Hook PackageInfo的构造步调 ，把柄栈回溯望望如果想要分娩一个PackageInfo到底需要哪些经过 。
然后讲一下，为什么保举使用IPC契约去赢得签名。由点到面中间可能会存在哪些问题 。公共在测试的期间最佳在谷歌原生的系统上测试，如果是国产厂商可能会添加我方的一些按捺器 。测试版块Android 11 。从上往下看 ，一步一步讲一下 每一步到底作念什么的
追忆：客户端IPC契约经过图简述：
发起东说念主App调用赢得PackageInfo-> PackageManager收到申请，判断是否存在cache，如果不存在 ->劳动端代理东说念主 ->
发起Binder契约->劳动端袭取 ，解决结束写入->客户端袭取。
这块咱们发现，许多逻辑皆是没用的，皆是客户端去为了各式便捷封装了许多步调，可是最终方向皆是为了发送IPC契约和劳动端通信 ，
可是其中，中间每一层级皆可能导致咱们的步调被Hook导致咱们拿到的数据是不安全的 ，比如袭击者是平直hook PackageManager 粗略平直hook PackageManager代理东说念主，然后修改对应的数据内容。导致咱们的数据不安全 ，被替换 。
是以得出论断：
咱们可以平直模拟IPC契约平直和劳动端通信，因为客户端这些皆是不安全的 ，平直通信绕过这些复杂的解决逻辑，可是流毒便是需要兼容不同的android版块 ， 不然可能会导致明白失败。
完结代码如下：
西西人提肉肉 反念念： 这种形势一定是安全的么？不是的，如果这块有个细节便是 咱们骨子上照旧需要通过binder驱动进行通信 ，和PackageInfo.CREATOR明白 。
如果袭击者 平直hook了binder驱动 ，粗略hook明白步调照旧可以绕过 。比如binder亦然会有一些进口，照旧可能被Hook劫捏 。
binder的进口android.os.BinderProxy->transact步调 。粗略平直hook签名明白的步调，因为在getPackageInfo亦然需要去明白签名信息的，可以平直hook签名信息明白这块逻辑 。
android.content.pm.PackageParser->generatePackageInfo 系统明白签名步调 PackageInfo.CREATOR PackageInfo Parcel 明白签名步调皆是可以的 。 还可以连续增强么？可以把柄安卓源码去自完结binder驱动妥协析过程 ，然后连土产货的binder也不信任，平直和劳动端通信亦然可以的 。
Java层还有相比好的签名检测妙技么？当前保举的只消这样一种，大部分皆是SO层作念的检测，Java层还可以作念一些代理东说念主的动态代理，包括一些代理东说念主的classloader，粗略
PackageInfo.CREATOR的classloader之类的去作念抵御 。还有一个tee检测也很可以 ，用于检测各式文凭，亦然容易被hook，这块未几说了 ，重心放在So层 。
So层的基础svc按捺就可以bypass掉许多小白 。
Native层检测签名： 1、基础SVC读取签名：这块什么是svc就未几说了，说了许多遍了 。感兴味可以看 https://bbs.kanxue.com/thread-277402.htm
我之前再看雪发的著述 。
这种形势主若是平直在步调里面内敛svc的形势去openat怒放已装配的apk ，然后去明白文凭文献 。
如果svc层不作念解决 ，很难绕过检测 。明白apk签名过程如下 ，代码来自Magisk ，调用 checkSign 对复返的字符串进行判断即可 。
2、文献权限：当咱们怒放fd的期间，文献很有可能会被IO重定向，重定向到一个新的文献，可是这个文献不行能是系统的，因为没权限。
是以当咱们得到这个fd的期间可以，再次通过fstat去赢得一经怒放的这个fd 是不是一个系统文献，系统文献的gid和uid皆是1000 。
阐述咱们怒放的fd是系统文献 。因为/data/app/包名/base.apk是一个系统文献 。
抵御的话可以平直svc fstat 退出阶段，对复返着力进行bypass即可 。
3、Readlinkat反查旅途：当咱们怒放fd的期间，文献很有可能会被IO重定向，重定向到一个新的文献，咱们把柄fd通过readlinkat 反查fd旅途，判断和传入的旅途是否很是，
如果很是则合计正确 。亦然在SVC Readlinkat推出阶段对查询的buff进行二次覆盖 。
4、Readlinkat复返值截断：这个念念路主若是把柄 Readlinkat的复返复返值进行检测，在创建数组的期间 数组大小接纳Readlinkat复返值的大小 。
Readlinkat复返值 复返值复返的是一个查询旅途着力的长度，如果袭击者只改了Readlinkat的参数，改了旅途，可是复返值健忘修改，这样他的复返值就会被阶段，也便是大小不匹配，也可以检测出来 旅途和传入的原始旅途是否很是 。
5、Inode:inode是linux的文献粗略目次的唯一标记符，每个文献皆是惟一无二的 ，如果文献被关闭，再次怒放一个新的文献可能会被占用，不外一些系统apk 不会被删除和关闭 。
在maps里面 每个item肖似如下 ：
7041e02000-7041e4e000 r--p 00000000 fc:01 25131 /apex/com.android.conscrypt/lib64/libc++.so
这里面的倒数25131 第二项便是inode，咱们当得到一个fd的期间可以赢得文献的fd 信息 ，然后再去maps里面赢得一经怒放的文献fd信息 。
判断怒放文献的inode和内存里面的inode是否很是 。
抵御的话可以平直svc fstat 退出阶段，对复返着力进行bypass即可 。
6、对一经怒放的fd进行签名赢得:这个步调过于激进，很少部分东说念主知说念 ，许多手机在刚开动的期间会自动怒放 /data/app/包名/base.apk
比如 咱们可以平直遍历一经怒放的fd ，然后对这个readlinkat反查旅途 ， 如果是base.apk的fd平直对fd进行签名明白 。相配于对一经怒放的文献进行签名明白 。
因为这个apk是系统开动阶段就被怒放了 ，是以不会走IO重定向的逻辑 ，相对安全 。
经过测试，有的手机App在开机开动阶段不会怒放 ，只符合Apk再开动阶段怒放了base.apk ，平直对一经怒放的fd明白即可 。可以潜逃IO重定向 。
抵御的话 也很简便3种有贪图
如果有东说念主通过一经怒放的文献去遍历fd ， 在readlinkat 着力解决 ，如果是base.apk平直袒护掉 。
平直解决getdents64和getdents ，在遍历阶段平直找不到对应的fd即可
平直close，可是有的版块在close会报 fdsan很是，需要通过 android_fdsan_set_error_level 拓荒禁用
追忆：上述这些有贪图基本覆盖大大皆妙技 ，Hunter的中枢检测念念路亦然上头这几种 。签名Native部分代码如下 。
有莫得一种形势可以轻大肆松绕过上头一说念的检测呢？粗浅有东说念主问我，签名检测太难，不知说念应该怎么绕过 ，有莫得一种可以快速绕过一说念检测的有贪图呢？况且我可以轻视修改apk信息不被发现 。
其实很简便，在root手机上平直使用中枢破解粗略小米的三方lsp插件 Cemiuiler ， 页面如下 。
平直禁用系统的签名考据，平直装配，也便是在阻拦了原始签名的情况下 ，未签名，平直装配 。**因为你莫得修改apk原始的签名信息，他读取到的照旧原始的签名信息，签名文献不会有任何变化 。**你二次签名骨子的方向皆是为了通过系统的签名检测 。
[竞赛]2024 KCTF 大赛征题放胆日历08月10日！柏木ゆう最新番号