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

最新推荐文章于 2024-05-16 20:42:16 发布

2401_84121685

最新推荐文章于 2024-05-16 20:42:16 发布

阅读量1k

点赞数 10

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84121685/article/details/137491939

版权

程序员专栏收录该内容

197 篇文章 0 订阅

订阅专栏

}

/* access modifiers changed from: protected */
public void attachBaseContext(Context context) {
hook(context);
super.attachBaseContext(context);
}

public Object invoke(Object obj, Method method, Object[] objArr) throws Throwable {
if (“getPackageInfo”.equals(method.getName())) {
String str = objArr[0];
if ((objArr[1].intValue() & 64) != 0 && this.appPkgName.equals(str)) {
PackageInfo packageInfo = (PackageInfo) method.invoke(this.base, objArr);
packageInfo.signatures = new Signature[this.sign.length];
for (int i = 0; i < packageInfo.signatures.length; i++) {
packageInfo.signatures[i] = new Signature(this.sign[i]);
}
return packageInfo;
}
}
return method.invoke(this.base, objArr);
}
}

有点长，但是也不是很费解。

他继承自 Application，重写了 attachBaseContext 来调用 hook(context) ，在里面做了 IPackageManager 的动态代理，实现在调用 getPackageInfo 方法的时候，修改 signatures[] 为在破解之前计算好的数值。这就是为什么我们的检测手段无效了。

所谓的知己知彼，百战不殆，我们先来分析下他做了什么：

替换掉原来的 Application
在 attachBaseContext 里初始化 hook
动态代理 IPackageManager
hook 替换掉 signatures 的值

所以应对方案也就水到渠成：

检查 Application
在调用 attachBaseContext 之前检测签名
检查 IPackageManager 有没有被动态代理
使用别的 API 去获取

检查 Application

他替换掉了 Application 为他自己的，那么变化的太多了，Application 的类名 / 方法数 / 字段数 / AndroidManifast 中 Application 节点的 name，都会变。我们这里以检查 Application 的类名为例：

/**

校验 application
*/
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 $St u b$ Proxy”;
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 $St u b$ Proxy」。因为是远端对象的缘故，会有 $St u b$ Proxy 后缀。如果他被动态被代理了，应该是类似「$Proxy0」这种类名，效果图如下：

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

/**
* 使用较新的 API 检测
*/
@SuppressLint(“PackageManagerGetSignatures”)
private boolean useNewAPICheck(){
String trueSignMD5 = “d0add9987c7c84aeb7198c3ff26ca152”;
String nowSignMD5 = “”;
Signature[] signs = null;
try {
// 得到签名 MD5
if (VERSION.SDK_INT >= 28) {
PackageInfo packageInfo = getPackageManager().getPackageInfo(
getPackageName(),
PackageManager.GET_SIGNING_CERTIFICATES);
signs = packageInfo.signingInfo.getApkContentsSigners();
} else {
PackageInfo packageInfo = getPackageManager().getPackageInfo(
getPackageName(),
PackageManager.GET_SIGNATURES);
signs = packageInfo.signatures;
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。