Google Play 机审浅析 （马甲包思路）

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

　　鄙人站在一名Androi逆向分析从业者的角度出发，讲讲自己对GP机审的理解。

　　从提交aab那一刻 你的aab到达了GP审核系统的后台，进行审核队列排队，首先提取概要信息（例如manifest信息 签名信息等），拿到这个特征 进入wait状态，持续N天（目的是为了让这个ab包和提交日后N天内提交的包先进行一次概要信息对比）。

通过了概要信息对比，这时候来到了正式机审，正式机审分两个大类，静态分析和动态分析 下面分开来说。

静态分析：

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

动态分析：

　　静态分析通过以后会进入到动态分析，动态分析一般使用沙箱完成，这时候把你的aab丢到沙箱模拟执行，并记录下来你的网络行为，java api调用行为， so api调用行为， 日志筛选，经过一系列操作 提取特征得到一个关键信息表 我们命名为 “Exeinfo”

得到“StaticInfo”和“Exeinfo”以后进入到后台数据库进行检索匹配相似度 通过一个阈值判断是否可以过审

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

AI回审：

　　你的包在GP跑着跑着，突然被下架了，莫慌，很有可能就是AI回审的时候 给你PASS了; AI自动化分析和前面的动静态分析略有相似之处，不同的地方是AI回审会更深层。首先从aab处提取：java层调用链流图，so层调用链流图，so导出函数模拟调用执行，启动页截图，执行后定时截图运行时目录文件检索，运行时activity堆栈检索，关键API调用堆栈检索，等信息做成一个 “AI Info” 依然还是进入到后台数据库进行检索 判断是否可以过审

如果能走到这，基本上你的AAB 就可以稳定在GP上“待着”了 以上完全是凭借对android 安全的理解以及游戏从业经验对GP过审的一点点猜想， 如有说错，还望轻喷 并指教一二 ;

下面附图一张