Android-APK:为何你的应用老是被破解,该如何有效地做签名校验

private boolean checkApplication(){
Application nowApplication = getApplication();
String trueApplicationName = “MyApp”;
String nowApplicationName = nowApplication.getClass().getSimpleName();
return trueApplicationName.equals(nowApplicationName);
}

  • 先定义我们自己的 Application ——「MyApp」
  • 然后通过 getApplication() 获取到 Application 实例
  • 然后通过 getClass() 获取到类信息
  • 然后通过 getSimpleName() 获取到类名
  • 与正确的值比对然后返回

可以看到可以检测出被二次打包

在 attachBaseContext 之前检测

只要我们检测的够早,他就追不上我们。不,他会 hook 到我们的几率就越小

A: 要有多早?
B: emm,就在 Application 的构造方法里检测吧
A: 那,,,没 context 呀
B: 那就自己造一个 context!
A: 你放屁!
B: 走你

通过学习 Application 的创建流程可知,Context 是通过 LoadedApk 调用 createAppContext 方法实现的

// LoadedApk.java
package android.app;
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);

函数原型为

// ContextImpl.java
package android.app;

@UnsupportedAppUsage
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo) {
return createAppContext(mainThread, packageInfo, null);
}

第一个参数好说,因为这是个单例类,调用 currentActivityThread 即可获取 ActivityThread 对象

// ActivityThread.java
package android.app;

@UnsupportedAppUsage
private static volatile ActivityThread sCurrentActivityThread;

@UnsupportedAppUsage
public static ActivityThread currentActivityThread() {
return sCurrentActivityThread;
}

但是需要注意的是有 「@UnsupportedAppUsage」修饰,需要反射调用。在学习 Application 的创建流程的时候可知(其实是我不会上网找的流程),另一个 LoadedApk 对象是通过 getPackageInfoNoCheck 方法创建的。

// ActivityThread.java
package android.app;

@Override
@UnsupportedAppUsage
public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
CompatibilityInfo compatInfo) {
return getPackageInfo(ai, compatInfo, null, false, true, false);
}

这个值保存在 ActivityThread 实例的 mBoundApplication.info 变量里。

// ActivityThread.java
package android.app;

@UnsupportedAppUsage
AppBindData mBoundApplication;

@UnsupportedAppUsage
private void handleBindApplication(AppBindData data) {
// 省略无关代码
mBoundApplication = data;
// 省略无关代码
data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
// 省略无关代码
}

mBoundApplication 虽然不是静态变量,但是因为我们之前已经获取到了 ActivityThread 实例,所以不耽误我们反射获取。现在我们调用 ContextImpl.createAppContext 的条件已经满足了,反射调用即可。

ContextUtils 最终实现代码如下:

public class ContextUtils {

/**
* 手动构建 Context
*/
@SuppressLint({“DiscouragedPrivateApi”,“PrivateApi”})
public static Context getContext() throws ClassNotFoundException,
NoSuchMethodException,
InvocationTargetException,
IllegalAccessException,
NoSuchFieldException,
NullPointerException{

// 反射获取 ActivityThread 的 currentActivityThread 获取 mainThread
Class activityThreadClass = Class.forName(“android.app.ActivityThread”);
Method currentActivityThreadMethod =
activityThreadClass.getDeclaredMethod(“currentActivityThread”);
currentActivityThreadMethod.setAccessible(true);
Object mainThreadObj = currentActivityThreadMethod.invoke(null);

// 反射获取 mainThread 实例中的 mBoundApplication 字段
Field mBoundApplicationField = activityThreadClass.getDeclaredField(“mBoundApplication”);
mBoundApplicationField.setAccessible(true);
Object mBoundApplicationObj = mBoundApplicationField.get(mainThreadObj);

// 获取 mBoundApplication 的 packageInfo 变量
if (mBoundApplicationObj == null) throw new NullPointerException(“mBoundApplicationObj 反射值空”);
Class mBoundApplicationClass = mBoundApplicationObj.getClass();
Field infoField = mBoundApplicationClass.getDeclaredField(“info”);
infoField.setAccessible(true);
Object packageInfoObj = infoField.get(mBoundApplicationObj);

// 反射调用 ContextImpl.createAppContext(ActivityThread mainThread, LoadedApk packageInfo)
if (mainThreadObj == null) throw new NullPointerException(“mainThreadObj 反射值空”);
if (packageInfoObj == null) throw new NullPointerException(“packageInfoObj 反射值空”);
Method createAppContextMethod = Class.forName(“android.app.ContextImpl”).getDeclaredMethod(
“createAppContext”, 
mainThreadObj.getClass(), 
packageInfoObj.getClass());
createAppContextMethod.setAccessible(true);
return (Context) createAppContextMethod.invoke(null, mainThreadObj, packageInfoObj);

}
}

后面的事就好办多了,就是在 Application 的构造函数里用我们手动构造的 context 去获取签名(这个时候还没有 context)

public class MyApp extends Application {

private static boolean sEarlyCheckSignResult = false;
public static boolean getEarlyCheckSignResult(){ return sEarlyCheckSignResult;}

public MyApp() {
// 在构造函数里提早检测
sEarlyCheckSignResult = earlyCheckSign();
}

boolean earlyCheckSign(){
// 手动构造 context
Context context = ContextUtils.getContext();
// 省略用新 context 校验签名的过程(正常的检测一样)
return 检测结果;
}
}

效果也很棒:

检查 IPackageManager 动态代理

动态代理的原理是系统动态的为我们创建了一个代理类,所以检测 IPackageManager 的类名即可发现端倪:

/**
* 检测 PM 代理
*/
@SuppressLint(“PrivateApi”)
private boolean checkPMProxy(){
String truePMName = “android.content.pm.IPackageManager S t u b Stub StubProxy”;
String nowPMName = “”;
try {
// 被代理的对象是 PackageManager.mPM
PackageManager packageManager = getPackageManager();
Field mPMField = packageManager.getClass().getDeclaredField(“mPM”);
mPMField.setAccessible(true);
Object mPM = mPMField.get(packageManager);
// 取得类名
nowPMName = mPM.getClass().getName();
} catch (Exception e) {
e.printStackTrace();
}
// 类名改变说明被代理了
return truePMName.equals(nowPMName);
}

相当简单,因为 IPackageManager 的实例存在于 PackageManager 实例的 mPM 字段里,所以我们反射他获取即可拿到。拿到后可以判断类名,正常的类名是 「android.content.pm.IPackageManager S t u b Stub StubProxy」。因为是远端对象的缘故,会有 S t u b Stub StubProxy 后缀。如果他被动态被代理了,应该是类似「$Proxy0」这种类名,效果图如下:

使用别的API去获取   /不知道到你有没有发现,他 hook 的 API 其实是过时的,也就是我们用新的 API 的话,有可能一些老牌的自动化工具无法处理到,我们试一试:

/**
* 使用较新的 API 检测
*/
@SuppressLint(“PackageManagerGetSignatures”)
private boolean useNewAPICheck(){
String trueSignMD5 = “d0add9987c7c84aeb7198c3ff26ca152”;
String nowSignMD5 = “”;

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级安卓工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
img
img
img
img

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Android)
img

总结

学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!

最后如何才能让我们在面试中对答如流呢?

答案当然是平时在工作或者学习中多提升自身实力的啦,那如何才能正确的学习,有方向的学习呢?有没有免费资料可以借鉴?为此我整理了一份Android学习资料路线:

这里是一部分我工作以来以及参与过的大大小小的面试收集总结出来的一套BAT大厂面试资料专题包,在这里免费分享给大家,主要还是希望大家在如今大环境不好的情况下面试能够顺利一点,希望可以帮助到大家。需要的小伙伴们可以点击我的GitHub获取免费领取方式

好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划,可以去我的主页加一下技术群。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

最后,祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作!

[外链图片转存中…(img-0rWhsJUq-1710505017146)]

好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划,可以去我的主页加一下技术群。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

最后,祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作!

这些只是整理出来的部分面试题,后续会持续更新,希望通过这些高级面试题能够降低面试Android岗位的门槛,让更多的Android工程师理解Android系统,掌握Android系统。喜欢的话麻烦点击一个喜欢再关注一下~

  • 19
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
universal-apk-builder是一个用于构建通用APK(Android应用程序包)的工具。它的作用是将一个应用程序的源代码和资源文件转换成可以在不同Android设备上运行的通用APK文件。 通常在开发Android应用程序时,需要为不同的设备和系统版本适配不同的APK文件。这意味着开发人员需要为每个设备和系统版本构建多个APK文件,增加了工作量和开发难度。 universal-apk-builder解决了这个问题。它可以根据输入的源代码和资源文件,自动进行适配和优化,生成一个通用的APK文件。这个通用APK文件可以在大多数Android设备和系统版本上运行,不再需要为每个设备和系统版本构建单独的APK文件。 使用universal-apk-builder的好处是显而易见的。首先,它大大减少了开发人员的工作量和开发周期,因为只需要构建一个通用的APK文件即可。其次,通用APK文件的运行效果和性能可以得到更好的保证,因为它经过了适配和优化处理。 然而,与任何工具一样,universal-apk-builder也有一些限制。它可能无法完全适配所有的Android设备和系统版本。在某些特殊情况下,仍然需要构建特定设备和系统版本的APK文件。此外,由于通用APK文件需要兼容多种设备和系统版本,可能会对应用程序的大小和性能产生一些影响。 总体而言,universal-apk-builder是一个实用的工具,可以帮助开发人员简化APK构建过程,提高开发效率。但开发人员仍需根据具体情况和需求来选择是否使用该工具,以及是否进行特定设备和系统版本的适配。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值