从“去除签名验证”说起-天涯论坛

4lqedz 发表于 2024-10-4 11:05:39

从“去除签名验证”说起

数天前坊间传闻有人破解了太极，最后发掘它其实是运用 MT 管理器的“去除签名验证”这功能绕过了太极的签名检测，而后把界面做了必定的调节；并无对太极的内核做出什么实质性的破解。既然如此，今天我就跟大众聊聊，这个“去除签名验证”到底是怎么回事；而后给大众有些思路，怎样去防范自己的应用被某些不怀好意的人莫名其妙地给篡改了。
首要咱们需要晓得的是，Android 应用程序的安装包 APK 文件都必须有自己的签名，无签名的 APK 是没法直接安装到系统的。这个签名实质上是“数字签名”，它是现代秘码学非对叫作加密的重要应用，是当今互联网安全的基石。

这儿不打算仔细说明数字签名等技术性的内容，简单理解，你能够认为研发者经过公开的规则按照 APK 文件的内容给 APK 文件打上一个烙印，由非对叫作加密保准这种形状的烙印仅有研发者自己能打出来；Android 系统在安装应用的时候会经过这种公开的规则计算烙印的形状，而后检测 APK 文件和它的烙印是不是对应，不对应就安装失败。一旦有人对 APK 文件的内容有涂改，那样这个烙印就会出现变化，引起系统在安装的时候发掘烙印形状不对而拒绝安装。
那样倘若非要修改 APK 的内容并且能成功安装到系统，咱们能够有若干种办法：

修改 APK 之后，咱们打一个跟原来研发者一模同样的烙印。这种方式除非研发者自己把他打烙印的方式告诉你，否则基本不可能。这是由于非对叫作加密本身保准的，亦许有人觉得很神奇；打个比方，我告诉你一个数 10000323402614653，你能用简单的办法告诉我这是哪两个大于1的数字相乘得到的吗？对我来讲便是一个简单的乘法，几秒钟搞定；对不晓得这两个数的人来讲，找出这两个数可能要花几天乃至基本不可能。
咱们把这个烙印抹除掉，按照那个公开的规则打上一个自己的烙印；这般修改 APK的时候安装到系统，系统会发掘咱们新打上去的这个烙印是符合规则的，准许咱们安装。
破坏掉系统的验证机制，让系统不要验证这个烙印对不对，不管三七二十一都给我装上去（这便是Xposed 插件：核心破解的原理）。
亦许有人看到这儿就会发掘，这个系统的验证机制貌似无什么用啊？它只能保准 APK 文件必须有合法的签名，并无办法保准 APK 文件不被篡改！你看，别人要修改你的APK，只需要把你的名字抹掉，而后签上他自己的名字就能够了。怎么办呢？

咱们必须在应用程序的内部自己计算 APK文件的签名

，而后跟咱们自己的签名信息做验证。一旦 APK 文件被修改，那样计算出来的签名不一致，咱们就会发现 APK 被篡改，此时候采取其他的处理办法。

Android 系统的这一整套签名机制，包括了从研发工具链（打包过程），Android系统本身（安装时签名验证）以及运行时（动态获取程序签名）因此呢，在“自己计算APK文件的签名”这儿，系统供给了公开的接口，再也不需要咱们自己去计算。这个公开的接口便是 PackageManager 的  getPackageInfo 等一系列办法。咱们只需要在应用程序内部经过此接口获取签名而后验证签名就能发掘应用程序是不是被篡改了。
倘若全部事情有这么简单，那这个世界就没那样好玩儿了。道高一尺，魔高一丈。

假设，倘若别人修改了你的 APK 文件内容之后：
直接删去你做签名验证的部分代码，而后重新签名。
修改 getPackageInfo 的返回值，让他返回他自己的签名。
这般，你的签名验证就形同虚设了。因此呢，针对上面第1个破解之法，咱们最好：
不要在 Java 代码中验证签名，最好在 native 验证；并且为了防止别人直接删除 native 函数调用，必须在 app 功能的核心规律的重点链路之中做验证；这般 native 函数调用删除之后，app 压根没法工作。
针对第二条，咱们有非常多种应对方法：
不运用系统供给的 getPackageInfo 接口，改用自己写代码解析和验证签名。
检测 getPackageInfo 调用是不是被篡改，倘若状况不对亦视为被篡改。
日前非常多所说的“一键去除签名验证”便是经过动态代理修改getPackageInfo 的返回值。说来亦巧，大约在三年前，我在自己的个人博客上仔细介绍了这种方式的实现原理，其中部分代码如下图：
<img src="https://mmbiz.qpic.cn/mmbiz_jpg/tNRVgEFx1ibVNZiaibRPiaWTvahAGZk36VQuyGrhEOdQDrnjLfdDkoia2ibS3up27KpY1Nu810txAnppViblrQAjOZ9Fg/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1" style="width: 50%; margin-bottom: 20px;">
当我打开所说的“破解版太极”的时候，我发掘有部分代码反常熟练，仔细查阅一番之后发掘应该是运用 MT管理器的“去除签名验证”，其中部分代码应该源自这儿：
<img src="https://mmbiz.qpic.cn/mmbiz_jpg/tNRVgEFx1ibVNZiaibRPiaWTvahAGZk36VQuiceRUDNARpqAsN4hm8yRQsPK76iczicWkJCISo28WWicicRhlMJvdFtPOmw/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1" style="width: 50%; margin-bottom: 20px;">
看到这儿的时候我觉得有点搞笑，拿着俺的代码去破解俺的应用。
好了扯远了，动态代理 Package service 的方式能够修改 getPackageInfo 的返回值，从而诈骗过应用程序内部的签名验证。针对这种破解办法，有一种很简单的方法，那便是检测 package service 是不是被动态代理。一旦咱们发掘 package service 被代理，咱们就能够认为有人在搞事情。
咱们上面还说到，除了经过 getPackageInfo 获取签名信息之外，咱们还能够经过自己计算签名来验证签名。实质上，有非常多 app 亦是经过这种方式验证签名的，有无破解之法呢？答案是肯定的，由于只要计算签名，就必须读取 APK 文件，咱们能够拦截 APK 文件读取的过程，让他返回原来正确的 apk 文件就能绕过这个过程。MT管理器的“去除签名验证”加强版应该便是这种方法的详细实现。那样，怎样反掉这种“拦截文件读取过程”的实现呢？方法自然是有的，由于通常的方式是拦截 libc 中的 io 函数调用，只要咱们采取更底层的方式读取文件，就能拿到未被篡改过的数据；或直接检测关键函数是不是被hook就能够。
总结一下，为了避免应用被容易破解，咱们应该这么做：
 必须在App内部自己读取签名而后验证，并且保准这部分规律存在于 app 核心功能的重点链路中；最好把这部分规律运用 native 改写避免被一锅端。
验证 app 内部 package / activity 等关键 service 是不是被篡改。
直接读取apk文件手动解析签名，而后做签名对比。
验证系统 io 关键函数是不是被 inline hook。
今天说了这么多相关“破解”的东西，实质上我是很反感把这种技术到处乱用的。尤其是把这种“一键破除签名”做成傻瓜式的功能供给给用户运用的行径，我真是不敢恭维。非常多研发者不会亦压根无时间去对自己的应用做完善的签名验证，这种傻瓜式工具的显现直接引起了破解成本的大大降低，非常多基本没入门的小白研发者就能拿着这种所说的工具去明目张胆地破解各样应用。不仅损害了原作者的利益，还让破解者背负潜在的法律危害。
另一，我得给大众普及一下法律知识。破解应用并传播给他人运用是属于违反刑法的行径：第五条　以营利为目的，实施刑法第二百一十七条所列侵犯著作权行径之一，违法所得数额在三万元以上的，属于“违法所得数额很强”；拥有下列情形之一的，属于“有其他严重情节”，应当以侵犯著作权罪判处三年以下有期徒刑或拘役，并处或单处罚金：　　（一）违法经营数额在五万元以上的；　　（二）未经著作权人许可，复制发行其文字作品、音乐、电影、电视、录像作品、计算机软件及其他作品，复制品数量合计在一千张（份）以上的；　　（三）其他严重情节的情形。以营利为目的，实施刑法第二百一十七条所列侵犯著作权行径之一，违法所得数额在十五万元以上的，属于“违法所得数额巨大”；拥有下列情形之一的，属于“有其他尤其严重情节”，应当以侵犯著作权罪判处三年以上七年以下有期徒刑，并处罚金：　　（一）违法经营数额在二十五万元以上的；　　（二）未经著作权人许可，复制发行其文字作品、音乐、电影、电视、录像作品、计算机软件及其他作品，复制品数量合计在五千张（份）以上的；（三）其他尤其严重情节的情形。
刑法跟民法区别，那可不是闹着玩儿的。重视到无，就算不是以盈利为目的，复制1000份以上就算严重情节了，做了个破解版别兴冲冲地去分享，一不小心你就得进去了。
好了今天就到这儿了，大众晚安！

4lqedz 发表于 2024-10-14 15:30:39

谷歌外链发布 http://www.fok120.com/

页: [1]

天涯论坛's Archiver

从“去除签名验证”说起