1、背景
最近新开发了一款工具类型的软件
移动工具箱，然而某天下午忽然群里来了一个不速之客说我的软件被破解了。虽然，该软件无需付费并且没有广告（很良心
😃
），也进行了安全加固，但是还是很轻易得被别人破解了。现象是，启动页换成了别人的页面，需要用户点击页面上的按钮分享几次破解者的信息才能进入应用。并且，每次打开应用都是如此。
看到这我的心情还是非常复杂的。一开始觉得自己做个应用都赚不到钱，还要被这些人利用。本是同根生，相煎何太急呀。然而，转念一想，这里有些东西还是可以学习一下，于是我去他们的链接下载了软件，本着学习的精神进行了一波分析并制定了几个方案来加强应用安全。
2、分析
2.1 检查破解应用签名
决定要进行分析之后，我首先想到的就是去检查下应用的签名，这里使用 keytool 即可，指令如下:
keytool -printcert -jarfile 你的apk地址
获取的结果如下，
很显然，应用的签名已经发生了变化，应用被别人二次打包了。实际上，我的应用是在 360 上面进行了软件加固（免费版），但是还是如此轻松地被别人完成了二次打包。
2.2 签名校验
如果仅仅是签名发生了变化，那么解决方式倒也简单。在应用内部增加一个签名校验就可以了。不过签名校验也有需要注意的地方。其一，签名校验可以放在 Java
层来完成，也可以放在 native 层通过 C++
来完成。其二，在应用内部进行整个数字签名的校验还是部分校验。这是因为如果写入完整的数字签名很容易被别人发现，即便写入到 so
中，写入完整字符串比部分更容易被别人找到。
在 Java 中，你可以按照下面这种方式获取应用的数字签名。我已经把相关的方法写成了工具类，你可以在 Github 上面获取
[AppUtils](https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2FShouheng88%2FAndroid-
utils%2Fblob%2Fmaster%2Futils%2Fsrc%2Fmain%2Fjava%2Fme%2Fshouheng%2Futils%2Fapp%2FAppUtils.java
“https://github.com/Shouheng88/Android-
utils/blob/master/utils/src/main/java/me/shouheng/utils/app/AppUtils.java”)：
public static String getAppSignatureMD5(final String packageName) {
return getAppSignatureHash(packageName, "MD5");
}
private static String getAppSignatureHash(final String packageName, final String algorithm) {
if (StringUtils.isSpace(packageName)) return "";
Signature[] signature = getAppSignature(packageName);
if (signature == null || signature.length <= 0) return "";
return StringUtils.bytes2HexString(EncryptUtils.hashTemplate(signature[0].toByteArray(), algorithm))
.replaceAll("(?<=[0-9A-F]{2})[0-9A-F]{2}", ":$0");
}
如果是使用 C++ 进行签名校验可以使用下面的方法，
jbyteArray getSignatureByteArray(JNIEnv *env, jobject context, jstring algorithm) {
jclass context_clazz = env->GetObjectClass(context);
// context.getPackageManager()
jmethodID methodID_getPackageManager = env->GetMethodID(context_clazz,
"getPackageManager", "()Landroid/content/pm/PackageManager;");
jobject packageManager = env->CallObjectMethod(context, methodID_getPackageManager);
jclass packageManager_clazz = env->GetObjectClass(packageManager);
jmethodID methodID_getPackageInfo = env->GetMethodID(packageManager_clazz,
"getPackageInfo", "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;");
jmethodID methodID_getPackageName = env->GetMethodID(context_clazz,
"getPackageName", "()Ljava/lang/String;");
// context.getPackageName()
jobject application_package_obj = env->CallObjectMethod(context, methodID_getPackageName);
jstring application_package = static_cast<jstring>(application_package_obj);
const char* package_name = env->GetStringUTFChars(application_package, JNI_FALSE);
__android_log_print(ANDROID_LOG_DEBUG, "DiDiDaDa", "Package Name : %s", package_name);
// packageManager->getPackageInfo(packageName, GET_SIGNATURES);
jobject packageInfo = env->CallObjectMethod(packageManager, methodID_getPackageInfo, application_package_obj, /*GET_SIGNATURES*/ 64);
jclass packageinfo_clazz = env->GetObjectClass(packageInfo);
jfieldID fieldID_signatures = env->GetFieldID(packageinfo_clazz, "signatures", "[Landroid/content/pm/Signature;");
jobjectArray signature_arr = (jobjectArray)env->GetObjectField(packageInfo, fieldID_signatures);
// packageInfo.signatures[0]
jobject signature = env->GetObjectArrayElement(signature_arr, 0);
// signature.toByteArray()
jclass signature_clazz = env->GetObjectClass(signature);
jmethodID signature_toByteArray = env->GetMethodID(signature_clazz,"toByteArray", "()[B");
jbyteArray sig_bytes = (jbyteArray) env->CallObjectMethod(signature, signature_toByteArray);
// MessageDigest.getInstance("SHA1")
jclass message_digest_clazz = env->FindClass("java/security/MessageDigest");
jmethodID message_digest_getInstance = env->GetStaticMethodID(message_digest_clazz,
"getInstance","(Ljava/lang/String;)Ljava/security/MessageDigest;");
const char* algorithm_bytes = env->GetStringUTFChars(algorithm, JNI_FALSE);
jstring algorithm_name = env->NewStringUTF(algorithm_bytes);
jobject message_object = env->CallStaticObjectMethod(message_digest_clazz, message_digest_getInstance, algorithm_name);
jthrowable exception = env->ExceptionOccurred();
env->ExceptionClear();
if (exception) return NULL;
// sha1.update()
jmethodID message_digest_update = env->GetMethodID(message_digest_clazz,"update","([B)V");
env->CallVoidMethod(message_object, message_digest_update, sig_bytes);
// sha1.digest()
jmethodID digest = env->GetMethodID(message_digest_clazz, "digest", "()[B");
jbyteArray sha1_bytes = (jbyteArray) env->CallObjectMethod(message_object, digest);
return sha1_bytes;
}
这里使用的是 CMake 进行编译，使用 Android Studio 进行开发。上面的逻辑很简单，就是把之前的 java 层获取签名的方法照搬到了
native 方法里。而且，借助于 Android Studio
进行开发，可以帮助我们减轻很多工作量，比如方法的映射关系就不需要你一个一个得进行对比，可以通过提示直接完成转换。当然，上面只是使用 java
的类完成了获取签名的字节数组的逻辑，进一步转换成为 hash 字符串还要进行其他操作。这里就不把代码贴出来了。
因为除了进行这些签名校验我还加了其他的安全措施，所以这部分代码不便开源。不过，我已经把一些基础功能的代码和环境配置打包成了压缩文件，你可以到我公众号里回复【安卓签名校验】获取完整的代码。
拿到了签名之后当然是进行签名校验了，基本的字符串比较即可。当然，你可以进行部分匹配，这样增加了破解的难度。
2.3 签名校验就安全了？
增加了上述的签名校验只不过是第一步，也是比较常规的安全操作。但是这样操作未必就能防止其他用户破解。进一步进行反编译，我又发现一些新的东西。破解包的目录结构挺有意思的，
相比于没有破解的包，在 lib 下面多了两个文件，这里的 libarm.so 的内容尚不清楚，这里的 libhook.apk 是一个 apk
文件，并且签名跟我的原始的包的签名一致，但是 apk 内容并不是我的完整包。所以，我猜测这里的 Apk
文件有其他用途，并且仅仅使用签名校验并不安全。因为别人可以读取你的应用的签名，然后通过某种方式进行伪造，让获取签名的方法返回的结果不是安装包真实的签名而是你的真实包的签名。这里的
apk 很有可能就是用来获取签名的。
于是，我进一步对应用进行资源反编译，这里使用 apktool 来完成，这里如下：
apktool d 破解应用.apk
于是我发现启动应用是被篡改掉了的，这里的启动应用已经被修改为 arm.SignerPro，并且这里的启动类已经被修改为
SplashActivity：
然后，我们将 Apk 解压之后对 dex 文件进行反编译。这里使用的是 d2j-dex2jar 来完成。命令如下，
d2j-dex2jar classes.dex
然后，我们根据反编译的结果，查看启动 Application，
这里的 Application 继承了 InvocationHandler. InvocationHandler 相比大家都不陌生，Retrofit
就是通过在 InvocationHandler 实现的代理来解析请求参数，并根据注解和入参来完成 OkHttp 请求的。我们找到该接口的实现方法
invoke(). 从上图中很明显得可以看出，我们的 getPackageInfo() 方法有很大可能被别人 hook
了。这个方法就是上面说的用来获取应用签名的方法，这里会对 getPackageInfo() 方法进行处理，并返回 signs
作为签名的获取结果而不是应用真实的签名结果。
当然，上面都是猜着，因为他们也只破解了第一个版本的包，第二个版本的包我加了新的安全措施，并且悄悄地增加了几个隐藏的页面用来在应用内获取签名和其他的信息来验证我的想法。
不管怎么说，仅仅加上签名校验很可能是 不安全 的！
2.4 其他安全措施
其实即便他们 hook 了获取签名的 getPackageInfo() 方法我们仍然有许多措施来应对。他们这里的 hook 有几个地方可以入手，
-
首先，我们并没看到 signs 的赋值操作，我猜测是通过 native 方法来完成的赋值，他们如果每次都尝试返回 signs 的话并没有屡次对 signs 进行重新赋值。而从 PackageManager 中多次读取到的 Signature 对象应该是不同的。所以，如果我们多次读取签名的时候返回的同一对象，是不是可以认为该方法被别人 hook 了呢？
-
另外，这里 hook 了
getPackageInfo()方法。只是我们无法判断他们 hook 的范围，我们可以尝试自定义一个getPackageInfo()方法，然后自定义返回的对象类型，如果返回的不是我们指定的类型，就可以得出结论，我们的getPackageInfo()方法被别人 hook 了。比如，public class Fake {
public void getPackageInfo() { }
public FakePackageInfo getPackageInfo(@NonNull String packageName, int flags) throws PackageManager.NameNotFoundException {
return new FakePackageInfo();
}public FakePackageInfo getPackageInfo(@NonNull VersionedPackage versionedPackage, int flags) throws PackageManager.NameNotFoundException {
return new FakePackageInfo();
}public static class FakePackageInfo { }
}
当然，如果他们只 hook 了 PackageManager 的方法，这个就不适用了。
-
除了签名校验，我们还可以检查其他项。比如检查 Application 是否是我们的启动 Application，可以使用如下代码获取应用的 Application 并进行比较，
public static String getApplicationName(final String pkgName) {
if (StringUtils.isSpace(pkgName)) return null;
try {
PackageManager pm = UtilsApp.getApp().getPackageManager();
ApplicationInfo ai = pm.getApplicationInfo(pkgName, 0);
return ai == null ? null : ai.className;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
return null;
}
} -
此外，我们还可以对应用的启动 Activity 进行校验。因为他们对我们的应用的启动 Activity 进行了修改，于是我们启动 Activity 进行了修改，所以这也可以作为一个应对措施：
public static String getAppLauncher(final String pkgName) {
if (StringUtils.isSpace(pkgName)) return null;
try {
PackageManager pm = UtilsApp.getApp().getPackageManager();
PackageInfo pi = pm.getPackageInfo(pkgName, 0);
if (pi == null) return null;
Intent resolveIntent = new Intent(Intent.ACTION_MAIN, null);
resolveIntent.addCategory(Intent.CATEGORY_LAUNCHER);
resolveIntent.setPackage(pi.packageName);
List resolveInfoList = pm.queryIntentActivities(resolveIntent, 0);
ResolveInfo resolveInfo = resolveInfoList.iterator().next();
if (resolveInfo != null) {
return resolveInfo.activityInfo.name;
}
return null;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
return null;
}
} -
上面提到的也只是一部分方法，当然还有其他的可以操作的方法。我们也可以在对类似的破解事件进行多分析来总结，尝试从多个维度做好安全防护。
3、总结
上面是我在应对破解方面的一些简单的总结，除了进行常规的加固之外，还进行了其他的维度的校验。当然，我其实对逆向和破解的了解并不是那么深入，这里权当抛砖引玉了。
随着信息技术的快速发展和互联网的普及，IT行业 成为一个非常热门的领域，也是目前就业前景非常广阔的领域之一。
IT行业是一个非常庞大和多样化的行业，包括软件开发、网络安全、数据分析、云计算等等领域。因此，就业前景也是非常广泛和多样化的，不同的领域和职位都具有不同的就业前景和发展机会。
在软件开发领域，由于软件已经成为现代社会不可或缺的一部分，因此对软件开发人才的需求也越来越大。特别是在移动应用、大数据、人工智能等领域，软件开发人才的需求更是迅速增长。因此，软件开发人才的就业前景非常广阔，尤其是那些熟练掌握多种编程语言和技术的人才。
有幸看到一篇这样一组数据。
根据这些我不得总结，it行业确实人才紧缺，
行业发展空间大，岗位非常多
网络安全行业产业以来，随即新增加了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产品经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁情报分析工程师、灾难恢复专业人员、实战攻防专业人员…
职业增值潜力大
网络安全专业具有很强的技术特性，尤其是掌握工作中的核心网络架构、安全技术，在职业发展上具有不可替代的竞争优势。
随着个人能力的不断提升，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受大家欢迎的主要原因。
从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到重视，升职加薪则是水到渠成之事。
学习资料分享
当然， 只给予计划不给予学习资料的行为无异于耍流氓 ，### 如果你对网络安全入门感兴趣，那么你点击这里
👉CSDN大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享
如果你对网络安全感兴趣，学习资源免费分享，保证100%免费！！！（嘿客入门教程）
👉网安（嘿客）全套学习视频👈
我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。
👉网安（嘿客红蓝对抗）所有方向的学习路线****👈
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
学习资料工具包
压箱底的好资料，全面地介绍网络安全的基础理论，包括逆向、八层网络防御、汇编语言、白帽子web安全、密码学、网络安全协议等，将基础理论和主流工具的应用实践紧密结合，有利于读者理解各种主流工具背后的实现机制。
面试题资料
独家渠道收集京东、360、天融信等公司测试题！进大厂指日可待！
👉 ** 嘿客必备开发工具 👈**
工欲善其事必先利其器。学习 嘿 客常用的开发软件都在这里了，给大家节省了很多时间。
这份完整版的网络安全（ 嘿 客）全套学习资料已经上传至CSDN官方，朋友们如果需要点击下方链接
也可扫描下方微信二v码获取网络工程师全套资料 【保证100%免费】
如果你对网络安全入门感兴趣，那么你点击这里
👉CSDN大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享
网络安全工程师(白帽子)企业级学习路线
第一阶段：安全基础（入门）
第二阶段：Web渗透（初级网安工程师）
第三阶段：进阶部分（中级网络安全工程师）
如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！
学习资源分享
3157
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
