大家好，今天我给大家带来的议题是《面向业务守护的移动安全对抗实践》。先介绍一下我本人，我来自千镜安全实验室，主要是负责针对vivo内部业务的守护和防御的工作。

我的议题从两个方面开始讲，第一个方面是游戏平台的广告安全对抗，第二个方面是移动应用的广告安全对抗和治理的问题。我们先从第一个议题开始。

首先什么是游戏平台？本次议题所指的游戏平台，它主要是指的是小游戏，并非我们普通的游戏应用APP，在当前流量至上的时代，小游戏是厂商与开发者都非常投入的一种新形态。

它有以下的三个特点，第一个无需下载即点即玩，它集成于厂商的操作系统，并且基于快应用的框架，它是以前端技术栈进行开发，包体为rpk文件，解压以后可以看到里面的代码都是JSON与js文件等。主要是通过手机厂商的一个游戏平台进行开发。

小游戏它会有较少内购，那么需要一个核心的盈利逻辑——广告为主，游戏联盟分发的游戏应用触达到用户以后，通过对广告的一个曝光和点击，最终产生广告收益，然后开发者再从广告联盟进行一个收益的获取。

但是有些开发者会想要有更多的广告曝光或者广告推送，例如图上这些问题，其实都是对用户体验的破坏，用户体验不好，游戏平台的整体用户量会下降，同时损害厂商的口碑，这是一种恶性循环。作为手机厂商，肯定是需要对游戏的一整个生态进行管控的。

厂商希望提升小游戏的质量，然后通过引导更多的用户来玩小游戏，通过这样的方式塑造一个良好的生态，而不是当前这样一个不良生态，所以目标就是要把这样的恶性循环改良到良性循环。可以给大家看一些典型的广告违规行为的案例，比如说最左边的第一个案例，我们可以看到在游戏过程中他玩着然后突然弹出一个广告。

第二个案例的查看详情按钮，会误导用户，当我们点击查看详情的时候，用户以为是跳过广告但是它还是跳转到了广告。

第三个案例再看用户关闭banner广告以后，过一会又弹出来了，其实很影响用户的一个游戏体验。

最后的案例是在结算页，诱导用户进行惯性点击，诱导用户在疯狂的点发射按钮的时候突然变成广告按钮了，然后用户就点击广告了。

针对于广告的案例的话平台通过对用户的反馈，和后台数据异常的小游戏，可以进行案例分析从云控和静态代码两个方面进行入手。

第一个案例，在人工审查的过程中，它是不推送广告的，但在用户手里面他就会疯狂推广告。然后在分析的过程中我们去抓它流量，动态流量里面发现配置了众多参数，其中有广告的开关，有广告的延时，插屏广告的概率和延时时间，有原生广告的概率，最后还有审查绕过等等云控参数，设置云控云端下发过审模式，通过这样的方式，来进行一个上架的检测对抗。

那么针对这样的方式的，是不是可以考虑对它的动态云控文件下发进行一个匹配检测？

下一个案例，这个案例的话其实也是一个很经典的，在静态代码里面可以看到它有个关键参数offcity 里面有北京东莞、广州、深圳。

右图的云控里面也有，area里面也是北京、东莞、上海、南京这些其实都是厂商的所在地。

开发者通过IP拿小游戏当前的城市定位信息，厂商所在城市不弹广告，这样的话就能规避平台的审查，那么针对于这种方式，怎么样来进行对抗？使用虚拟IP，或者虚拟的定位，来触发广告。

针对案例的分析，我们就可以提取出大量的特征，通过静态和动态两个方面入手。

1、静态扫描，通过扫描数据异常的一个游戏列表，然后爬取下载这些小游戏，然后解压和遍历js，根据我们提取的规则库，进行正则匹配，输出违规的静态检测结果。针对规则进行规则库的扩充和静态特征的优化。

2、动态检测，通过获取到小游戏的违规列表，进行拉起，然后对它的流量进行抓取和过滤，最终定位到它的动态云控参数的下发，结合上述的动态过审和城市屏蔽问题进行匹配。同时需要扩大流量特征库，然后优化云控的参数特征。

最后输出违规的列表，交给业务进行冻结或者下架处理。

从行业侧来说，小游戏的动态广告触发受到很多的干扰，但是它静态的代码，因为本身不允许热更新和动态代码下发，更应当侧重于源码与数据传输层的一个违规检测，从源码与数据传输层，从静态和动态这两个方面入手，通过典型的案例分析，总结出特征，自动化输出高风险列表，最后赋能到游戏平台的违规行为判定。

有了游戏平台的检测环节，这个环节要从哪开始落地？

可以通过两个方面，第一个巡检，第二个上架。巡检是针对存量，上架是针对增量。针对存量小游戏应用，通过工具的巡检进行检测，同时人工也有巡检，人工巡检和工具巡检的结果进行匹配验证以后，生成一个可信规则列表，可信规则列表对小游戏上架进行检测，审查结果最终作为一个上架依据。

这两块侧重点不同，巡检要通过广度优先，扩大检出覆盖面，发现更多的违规广告行为。上架检测致力于精度优先，因为在上架过程中是没有人工审查直接作为判定依据，更好的提升上架的效率。

在平台侧进行管控了以后，对抗趋势就会演变成在开发者方面会加剧代码的云控，代码混淆难度上升，他们会考虑通过更多的方式，更多的手段去绕过审查；平台也会对容易被利用的广告进行优化，通过更精准的规则，进行更严格的管控。

第一部分的小游戏的广告的对抗就告一段落。

接下来介绍移动应用的广告安全对抗，厂商从21年底开始，就有消费者不断对移动端后台自动弹广告的行为而进行了大量的反馈。

一个主要体现形式，消费者在正常使用手机的过程中，比如正在刷微博，或者正在看小说，或者就停在桌面不动，这个时候突然弹出个广告弹窗，消费者也不知道是谁弹的。

这种广告影响的人群主要是以老年人。他们很多时候并不清楚他们手机到底有了什么问题，以为中了病毒，或者以为手机坏了。其实主要的罪魁祸首就是流氓应用的体外弹窗。国家也在315晚会曝光这些工具类APP诱导下载和体外广告的问题。9月30号国家也通过文件，规范当前互联网的弹窗推送。

手机厂商应该怎样去进行治理？首先需要了解它的生态。

首先流氓广告开发者会注册一堆空壳公司、利用那些公司的名称，进行马甲应用投放；流氓广告cp会通过应用商店上架，三分平台和头部媒体的买量进行投放，触达到用户侧。并且他们自身也会推送同公司，同品类的应用到用户这里。

这就常常出现有的老年用户偶然下载了某个这种应用，在应用推送的广告中又点击下载了其他同类应用，以此循环，最后就下载了一屏幕的广告应用。流氓广告cp不仅仅满足于投放应用后应用内广告的正常收入，因为用户平时也不会总是去打开它们，在不被打开的情况下，还能实现广告推送曝光增长？那就是通过各种方式去进行应用外的弹窗广告，这样即使用户不打开这些应用，他们也能获取到广告的曝光收入。总之是使用短留策略，获得用户后通过野蛮广告变现实现商业收益闭环

同时他们为了躲避广告的厂商的审查，他们也会使用大量的方式来进行一个逃逸。可以看到他们的马甲应用变化的特别快，然后他们也同时上了很多的对抗策策略，比如说加密混淆纯净版等等。

他们的利益重点在于应用外弹窗，分析其中的关键因素。第一、应用要在应用外推广告、肯定需要各种各样的方式将自身保活在后台。第二、应用保活后，会通过利用系统漏洞或滥用机制等方式，以解锁、清理垃圾、wifi优化、充电等弹窗，造成用户体验下降。具体的弹窗案例如右图。

接下来我们来讲第一个重点就是保活的分析，这里列出来了很多那种常用的保活，比如一像素保活、壁纸保活、后台无音量保活、前台服务保活，以及一些比较常见的拉活机制，包括service系统拉机制、账户同步拉活， jobScheduler拉活，还有双进程守护，workmanager保护等。

在流氓广告应用使用上述手段并不能有效保活后，有开发者另辟蹊径，根据双进程守护的原理加以改进，使用两个进程互相锁住了对方的文件，其中一方的进程死亡会解除自己持有的锁，另一方会立即感知到，这时立刻拉起对方，详细步骤如图。

具体表现形式为：应用常驻进程多，杀掉其中一个，所有进程都会重启，无论是点击停止服务、am force-stop、桌面上划、强制停止都能保活下来。

接下来我们看缺陷利用和防御绕过，在成功保活了以后，下一个容易被攻击的对象自然就是一个手机的系统防御的策略。

首先安卓本身对于后台自动拉起是做了一定的限制的，但是限制并不完备，存在很多问题：

1、伪造包名启动Android 11 以下，在调用方 Activity 中覆写 getBasePackageName 方法，返回系统白名单包名，则可以通过伪造包名拉起activity；也可以使用Hook Application 中的baseContext将包名伪造从而进行拉起。

2、moveTaskToFront启动：movetask：这种方式不算是直接从后台启动 Activity，而是换了一个思路，在后台启动目标 Activity 之前先将应用切换到前台，然后再启动目标 Activity，如果有必要的话，还可以通过 Activity.moveTaskToBack 方法将之前切换到前台的 Activity 重新移入后台(需要声明android.permission.REORDER_TASKS 权限)。启动目标 Activity 之前先判断一下应用是否在后台，判断方法可以借助 ActivityManager.getRunningAppProcesses 方法或者 Application.ActivityLifecycleCallbacks 来监听前后台。

3、全屏通知启动：cp针对滥用谷歌全屏通知能拉起activity的机制进行后台弹窗。具体方式为构造一个调起外弹页的intent，并传入PendingIntent，构造通知，并通过setFullScreenIntent传入PendingIntent ，通过这样的方式来拉起activity，需要权限 android.permission.USE_FULL_SCREEN_INTENT。

4、伪造输入法拉起：第一步找到系统默认输入法，模拟拉起的广告页面同样声明输入法设置的intent-filter；第二步，将输入法的intent包装成PendingIntent,在通过intent.setData(Uri.parse(getPackageName() +"://start"));的方式将原始的intent替换掉；第三步，发送PendingIntent，因为PendingIntent对象是从输入法获取的，此时恶意app实际上是以输入法的权限和身份发送了这个intent，就可以把FloatActivity拉起来了。问题的原因是PendingIntent中的intent被替换成了拉起广告Activity的intent。

利用缺陷进行体外广告弹窗的行为，肯定是厂商需要重点治理的。

在重点治理的话，其中有一个重要的部分就是动态的对抗，还是老问题在消费者手里弹广告，在厂商手里面不弹广告，通过案例分析可以发现里面有很多对抗方式：

1、云端的风控，最开始的城市屏蔽，所以我们之前讲小游戏的时候也讲到了，然后包渠道，包渠道就是说应用商店上架的东西就比较收敛，然后第三方投放的应用就特别狂放，就推得特别多，然后新手保护大家其实都知道1~7天之类的，还有展示间隔。

2、本地的风控，针对于本地风控的话就检测本地环境，包括sim卡、WiFi代理、 VPN、USB，还有root和开发者选项，这些东西其实最终只是鉴定说你这个人是不是真实的用户，还是说你是个测试机。

3、权限获取，同样的权限的获取也是说要建立一个真实的用户。

针对于这些对抗策略，我们可以这样做：手机本地的风控，可以使用定制代码隐藏root这些特征，城市IP的话可以用代理，然或者框架直接写死，而新手保护的话很简单，就调手机的时间，最后还有一个通杀的方式就是我把你风控逻辑直接给你整个hook，这样进行通杀。

针对上述的行为，就要首先从分析人员的分析对抗能力提升做起，主要分为3个方面，第一块是信息的收集、第二块是分析思路的提升、第三块是对抗工具的建设，详见图。

然后分析思路的话，这几点其实都是比较老生常谈的。第一个立项追踪，通过弹出界面的回溯调用，最后复盘整个拉起逻辑。还有正向逻辑的话，其实就是说通过云控参数的输入，然后进行一个拉起逻辑的调用。然后第三个的话就是lsp的源码审核，我们通过代码审计挖掘本身的漏洞，然后防范于未然。第四个的话针对定制机的一个检测策略进行一个提取，这样也是为了动态浮现。

上图有提到第三方的分析工具，但是厂商肯定需要针对不同的对抗场景，进行工具建设。

在人工分析完这些应用以后，如何将人工分析的结果赋能到用户体验的保障和商店环境净化，自然就是自动化检测能力的建设。自动化能力的建设的核心，业务方将可疑的应用通过任务队列批量上传，再通过分信息集群反编译成Java代码，然后再通过分析人员将分析中提取到的恶意广告代码，包括敏感字符串加固，混淆特征SDK、指纹识别、对抗特征签名证书等等这一系列的东西，进行静态匹配，最后输出检测结果，由业务部门进行处理。

最后总结一下对抗的一个思路，就是从攻击者的视角出发。1、研究新的绕过技术和应对方式；2、验证防御策略的完备性；3、复原攻击场景和挖掘安全缺陷的利用。

总体分为7个步骤：

1、缺陷的利用和防御绕过；2、流氓应用保活分析；3、应用脱壳解密技术对抗；（这三步主要是为了安全缺陷的发现与防御的强化。）

4、应用弹广告的复现；5、检测特征的提取；6、已知缺陷利用商店的排查；（这主要是为了商店环境的净化以及检测工具的赋能。）

7、后台拉广告技术手段的技术手段分析。通过这样的方式，从取证分析的视角握手用户产品。

最后我想给大家聊一下未来的一个广告的对抗趋势，可以看到它有这样的生态机制。

那么针对于应用广告应用市场上架，从增量角度，会伪造更多马甲公司，这就需要行业内部做到更充分的审核与监测。针对于已上架的存量，他们可能有的就直接避风头了，云端关闭广告，隔一段时间再出开启，行业内就要对检测能力进行一个升级，来净化应用市场。

而针对于流氓广告应用从广告平台三方平台的一个买量卖量，他们会对高转化效率的特定机型进行投放，这样就需要厂商有更高效的安全产安全感知安全检测和能力的迭代，然后他们肯定也会通过投入更多的资源来进行缺陷的利用和防御绕过，使得攻防对抗升级。这就需要行业内的安全团队，对于内部模块的一个安全防护进行升级，然后在系统侧前置发现一些安全问题，防范于未然。

最后由于应用商店的预算下降肯定会投更多预算到三方平台，针对这种情况需要更好的产品机制来引导用户进行更好的识别，才能维护用户环境。

总体来说，伴随着厂商治理力度的加大，对抗趋势是将从事后的对抗转移到事前的对抗，这是一个长期的对抗路程，需要行业内的安全团队提升系统防御，加强风险识别、建设对抗工具，赋能检测能力以及产品机制，从而保障用户体验。