Android多开检测的另一个思路

栏目: IOS · Android · 发布时间: 5年前

内容简介:之前写了篇检测多开的文章后,经过几个月的时间,基本上都已经被各多开软件绕过了。最近无意中发现了一些新特征,在特定环境下可以用来检测多开环境,特此来分享一下。某次在多开环境下运行demo,发现动态库加载失败了,错误信息如下:这个错误没什么好多说的,很明显,动态库是64位的而App运行在32位下,因此加载失败了。其实之前也看到过类似的现象,本应在64位下运行的App到多开环境下就变为32位环境了,只是之前并没有去深究,这次遇到后仔细想了一下,在某些情况下可以用来检测多开环境。

之前写了篇检测多开的文章后,经过几个月的时间,基本上都已经被各多开软件绕过了。最近无意中发现了一些新特征,在特定环境下可以用来检测多开环境,特此来分享一下。

起因

某次在多开环境下运行demo,发现动态库加载失败了,错误信息如下:

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app/【手动打码】/lib/arm64/【手动打码】.so" is 64-bit instead of 32-bit
 at java.lang.Runtime.loadLibrary0(Runtime.java:1016)
 at java.lang.System.loadLibrary(System.java:1660)
 ... 省略

这个错误没什么好多说的,很明显,动态库是64位的而App运行在32位下,因此加载失败了。其实之前也看到过类似的现象,本应在64位下运行的App到多开环境下就变为32位环境了,只是之前并没有去深究,这次遇到后仔细想了一下,在某些情况下可以用来检测多开环境。

解释

对于64位的手机,会启动2个zygote, zygotezygote64

root  670 1 4359784  27292 poll_schedule_timeout 7f7b47058c S zygote64
root  671 1 1696576  11120 poll_schedule_timeout eb823684   S zygote

以64位运行的App将由 zygote64 fork而来,而以32位运行的App将由 zygote fork出来。可以从下面的代码看出来, ZygoteProcess.java 中, startViaZygote 方法会通过 openZygoteSocketIfNeeded 方法选择合适的zygote。

private Process.ProcessStartResult startViaZygote(final String processClass,
                                                  final String niceName,
                                                  final int uid, final int gid,
                                                  final int[] gids,
                                                  int debugFlags, int mountExternal,
                                                  int targetSdkVersion,
                                                  String seInfo,
                                                  String abi,
                                                  String instructionSet,
                                                  String appDataDir,
                                                  String invokeWith,
                                                  String[] extraArgs)
        throws ZygoteStartFailedEx {
    // 省略...
    synchronized (mLock) {
        return zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), argsForZygote);
    }
}

@GuardedBy("mLock")
private ZygoteState openZygoteSocketIfNeeded(String abi) throws ZygoteStartFailedEx {
    Preconditions.checkState(Thread.holdsLock(mLock), "ZygoteProcess lock not held");

    if (primaryZygoteState == null || primaryZygoteState.isClosed()) {
        try {
            primaryZygoteState = ZygoteState.connect(mSocket);
        } catch (IOException ioe) {
            throw new ZygoteStartFailedEx("Error connecting to primary zygote", ioe);
        }
    }

    if (primaryZygoteState.matches(abi)) {
        return primaryZygoteState;
    }

    // The primary zygote didn't match. Try the secondary.
    if (secondaryZygoteState == null || secondaryZygoteState.isClosed()) {
        try {
            secondaryZygoteState = ZygoteState.connect(mSecondarySocket);
        } catch (IOException ioe) {
            throw new ZygoteStartFailedEx("Error connecting to secondary zygote", ioe);
        }
    }

    if (secondaryZygoteState.matches(abi)) {
        return secondaryZygoteState;
    }

    throw new ZygoteStartFailedEx("Unsupported zygote ABI: " + abi);
}

那么如何确定App是以64位还是以32位运行呢?这就取决于动态库,如果只有32位的动态库(armeabi、armeabi-v7a),那么就会以32位运行,如果有64位的动态库(arm64-v8a),那么就以64位运行,不存在动态库则默认以64位运行。

如何证明?我们写3个demo来实际看一下。

  • demo1: 包名 top.darkness463.whichzygote ,不加动态库。
  • demo2: 包名 top.darkness463.zygote32 ,加一个 armeabi 动态库。
  • demo3: 包名 top.darkness463.zygote64 ,加 armeabiarm64-v8a 动态库。
root     670    1   4359784  27692 poll_schedule_timeout 7f7b47058c S zygote64
root     671    1   1696576  11416 poll_schedule_timeout eb823684   S zygote
u0_a177  9878   670 4456080  63412 SyS_epoll_wait        7f7b47046c S top.darkness463.whichzygote
u0_a180  13690  671 1791700  58664 SyS_epoll_wait        eb8234ac   S top.darkness463.zygote32
u0_a179  13871  670 4456524  64716 SyS_epoll_wait        7f7b47046c S top.darkness463.zygote64

可以看到,demo1和demo3的父进程是 zygote64 ,而demo2的父进程是 zygote

那么为何在多开环境下会出现动态库加载失败的情况呢?原因就在于我那个demo有 arm64-v8a 的动态库,在安装时,系统会把该64位动态库拷到 /data/app/【包名】/lib/arm64/ 下,然后那款多开软件只有32位的动态库,因此是以32位运行的,此时去 /data/app/【包名】/lib/arm64/ 路径下加载64位的动态库必然导致失败。

打开思路的话,这也可以是一种检测多开环境的方式。

局限性

其实与其说这是检测多开的方法,倒不如说这是多开软件的bug。看了几款排名靠前的多开软件,都只有32位的动态库,但它们完全可以加上64位动态库来避免这个问题。

另外,为了减小apk的体积,绝大多数App只会添加 armeabi 平台,而不会添加 arm64-v8a 平台的动态库,所以这种检测方法在很多App上本身就是不成立的。

补遗

之前那篇文章提到过一个通过 /proc/self/maps 来检测多开的方式,当时提到这个方法的缺点是需要收集所有多开App的包名,但真正搞事的人很可能不会拿市面上的多开软件来作恶,他们可能利用开源的多开软件改成乱七八糟的包名,之前我甚至见过命名成 com.tencent.qqlite 来进行伪装的。之后我又做了一些工作,也和大家分享一下。

思路还是从 /proc/self/maps 中的动态库出发。在这里直接给出结论了不再详细讨论了。

  • /proc/self/maps 中出现包含 /vbox/data//shadow/data//virtual/data/ 的动态库,则运行在多开环境下。主要是因为很多多开软件都是基于开源或者抄来抄去的,所有目录名无外乎这么几种,但不排除会有多开软件修改掉名字的情况。
  • /proc/self/maps 加载的动态库路径我们可以解析到包名,如果自己的App并不会加载其他App的动态库(第三方登录可能会把其他App的动态库加载进去)的话,出现非自己包名的动态库可能疑似运行在多开环境下。服务端可以建立一套自动解析包名 + 添加到黑名单的流程。

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

数据挖掘技术

数据挖掘技术

[美]MichaelJ.A.B / 别荣芳、尹静、邓六爱 / 机械工业 / 2006-7 / 49.00元

本书是数据挖掘领域的经典著作,数年来畅销不衰。全书从技术和应用两个方面,全面、系统地介绍了数据挖掘的商业环境、数据挖掘技术及其在商业环境中的应用。自从1997年本书第1版出版以来,数据挖掘界发生了巨大的变化,其中的大部分核心算法仍然保持不变,但是算法嵌入的软件、应用算法的数据库以及用于解决的商业问题都有所演进。第2版展示如何利用基本的数据挖掘方法和技术,解决常见的商业问题。 本书涵盖核心的数......一起来看看 《数据挖掘技术》 这本书的介绍吧!

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

MD5 加密
MD5 加密

MD5 加密工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具