深度解析 Google Play 机审（马甲包策略）

假设你是Google Play（以下简称GP） 审核团队的一名研发，让你去设计GP的机审系统，你会怎么做？

作为一位从事Android逆向分析的专业人士，我想分享一下我对GP机审的理解。

一旦提交aab，你的aab将被送至GP审核系统的后台进行审核队列排队。首先，系统会提取概要信息（如manifest信息和签名信息），然后根据这些特征将其置于等待状态。这个状态会持续N天，目的是让该ab包与在提交日之后N天内提交的其他包进行一次概要信息对比。

经过概要信息对比后，我们进入了正式机审阶段。正式机审可以分为两个主要类别：静态分析和动态分析。接下来我们将详细介绍这两种方法。

静态分析：

经过概要信息对比，你的aab文件经过静态分析。静态分析会解析文件、资源、代码、字符串、ELF和dex节区信息，并通过一系列操作得到一个关键信息特征表，我们将其命名为“StaticInfo”。

动态分析：

经过静态分析后，将进入动态分析阶段。通常，动态分析会使用沙箱来完成。在这个阶段，您需要将您的aab文件放入沙箱中进行模拟执行，并记录下您的网络行为、Java API调用行为以及SO API调用行为等信息。接着，我们会对日志进行筛选，并通过一系列操作提取特征，得到一个关键信息表。我们将这个表命名为“Exeinfo”。

在获得“StaticInfo”和“Exeinfo”之后，将它们输入后台数据库进行检索，并通过比较相似度来判断是否可以通过审查。这一判断是基于一个设定的阈值。

如果你的aab能走到这里 ，恭喜你！机审已经通过了，接下来等待上架；不过 GP还有一个人工回审机制，大概一个月以内会有一次更深度的审核，猜测为人工 + AI 进行审核。

AI回审：

你的包在GP跑着跑着，突然被下架了，不要慌张，很有可能是因为AI回审时给你通过了。AI自动化分析和之前的动静态分析有些相似，但AI回审更加深入。首先从aab处提取：java层调用链流图、so层调用链流图、so导出函数模拟调用执行、启动页截图、执行后定时截图运行时目录文件检索、运行时activity堆栈检索以及关键API调用堆栈检索等信息，并将其整合成一个名为“AI Info”的数据。这些信息仍然会进入后台数据库进行检索和判断是否可以过审。

如果能达到这个阶段，基本上你的AAB就可以在GP上稳定运行了。以上完全是基于对Android安全和游戏开发经验的理解，对GP审核过程的一些猜测。如果有说错的地方，请轻喷并指教。

下面附图一张

标签： 信息 静态 概要 动态