为什么刚安装的App很清爽,几天后广告满天飞?

你是否也遇到过这种现象？很多人以为是自己"运气不好，装到个坏的"。

最近，360移动安全在对某类应用的一次安全检测中，从应用代码里看到了这本"剧本"是怎么被一行一行写出来的。 

今天，我们把这本剧本翻译成“人话”，讲给你听。

这一幕要说的事：它把"什么时候开始打扰你"，当成一个常数写进了代码。

先看一段被拆解出来的代码：

//

System.currentTimeMillis() - appInstallTime > 259200000

看不懂？我翻译一下。这段代码在计算你装这个App多久了。

259200000 毫秒，换算过来正好是 3 天。

也就是说，代码里有一个"3天倒计时"。你装上App的前3天，它刻意表现得很克制——广告少弹，甚至不弹。等你以为"这个App真干净、真好用"时，3天一到，开关被打开。

这还只是最基础的一层。

我们把这套"时间门槛"拆开数了一遍，发现它其实是一个四级体系：

这四道门槛不是每个人都会挨个碰上，不同来源、不同广告位对应的是其中不同的那一道。代码里我们能数出来的，至少有 2、3、7、15 天四道。所以"到底第几天开始"这个问题，答案本身就取决于你是怎么把它装上的。

说白了，它不是"第几天开始弹广告"，而是"每隔几天，解锁一批新的打扰方式"。

第一幕解决的是"什么时候开始"，第二幕解决的是"对谁开始"。

这里还有一段更值得琢磨的逻辑：同一个App，会先看你是怎么装上的，再决定用什么节奏打扰你。

一部分用户：推广用户

   → 前2天完全安静

   → 另有一层15天的"静默期"控制

另一部分用户：自己搜到、自己下载的

   → 直接放行

看懂了吗？推广带来的那部分用户，前期被特别小心地对待。 因为这些人是有获客成本的，太早打扰，人就被吓跑了，钱等于白花——所以先让你用爽，让你留下好评，让你把它留在手机里。等时间到了，再慢慢开始变现。

而另外那部分用户，没有获客成本，广告就可以来得更直接一些。

同一个App，你从哪里来，决定了它用哪一套节奏对你。

这一幕要说的事：前三幕解决"什么时候""对谁"，这一幕解决"能不能被你真的关掉"。这也是代码里比较"技术流"的一段。

App启动 → 触发保护服务

  → 启动3个辅助进程

  → 通过系统底层文件锁 + app_process 挂载

  → 当主进程被杀 → 3个分身互相"发现兄弟没了"

  → 通过 Binder 调用，把主进程重新拉起来

翻译成人话：这个App在手机里留了3个"分身"，它们之间互相盯着。你把主程序划掉？只要分身还在，它就有机会重新复活。

这就是为什么有些App你"明明关了"，过一会儿又能感觉到它在后台跑、通知栏又冒出来、甚至偶尔弹个广告。它不是"卡了"，而是被设计成"杀不死"。

更微妙的是：它不是偷偷干，而是劝你亲手把手机的保护关掉。

我们分析发现了一个权限引导页面，作用很直白：一步一步教用户去系统设置里，把"允许后台运行""后台弹出界面""锁定后台运行"这几个开关打开。带来的结果，值得每个用户记住：

如果一个App反复劝你去系统设置里给它"开绿灯"，你至少应该问一句：它拿这些权限到底要干什么？

这一幕要说的事：前三幕的代码都在你手机里，第四幕的开关不在你手机上。

前面三幕讲的是"本地代码里写了什么"。但真正让这套剧本"活"起来的，是远程控制。

这个App的广告开关、广告频率、素材内容、甚至保活策略，都不是写死在安装包里的，而是通过一个加密通道从云端实时拉取。

也就是说：

• 你手机上的App，只是一个"壳"

• 真正决定"什么时候弹广告、弹什么广告、弹多少个"的，是远端服务器上的一个开关

• 这些开关甚至可以针对每一台设备、每一个用户，单独设置

这带来一个很现实的问题：当开发者想"收网"时，不需要你更新App，云端改个参数就行。

如果说前面四幕是"广撒网"，那这一幕就是开始"认人"。

分析还发现了一段更隐蔽的代码逻辑：这个App能够检测用户在广告页面里是否发起了支付——比如你点开广告、跳转到支付页面，它都能识别到。

检测到之后会发生什么？

• 它会把"这个用户在广告里付款了"这件事上报到服务器

• 上报内容包括：广告标题、描述、链接、点击时间等上下文信息

• 这套能力由云端开关控制，可以针对不同用户单独开启或关闭

• 分析还注意到：对几家头部电商域名的支付跳转，它是放行；对不在这份名单里的其他电商支付跳转，它会拦截并另外上报一条记录。

这里，必须把边界说清楚，这一点很重要：

从分析看，感知粒度只是"发生了支付这件事"。订单号只用来做"是/否"判断，订单金额、买了什么商品，都没有被提取和存储。

这意味着什么？把"这个人转化了"记一笔，再去向广告主结算。虽然，目前只确认了"具备这个能力"，没有证据表明它被大规模滥用。

前面几幕讲的是"这一个版本会做什么"，这一页讲的是"它还能变成什么"。

分析发现其更底层的能力：热修复/插件化框架。

翻译成人话：App 理论上可以不走商店的更新流程，直接从服务器下载新的代码包，然后加载进来运行。

这意味着什么？今天你在应用商店下载的版本，和一个月后它在云端"悄悄"更新成的版本，可能完全是两个东西。

这里你可能想问：这是不是就这一款App的问题？

不是。

这套手法组合——延迟激活、来源差异化、进程保活、云控广告、支付归因、动态加载——在行业里每一个都有各自成熟的"名字"：

单看每一项，它都能找到一个"正当用途"；可一旦把它们按顺序接起来，可能就是一个"高风险条件链"，背后的设计意图就值得思考。

当然，"能力"和"行为"是两件事。

看到这里，你可能会想：那我是不是要开始怀疑手机里的每一个App了？倒也不必焦虑。

真正需要警惕的，是有下面这几个特征的App：

我们拆这套剧本，不是为了让用户对所有App产生恐慌，而是想让大家明白一件事：

一款App好不好，不能只看它"能不能用"，还要看它在你看不见的地方，"正在做什么"。

把代码里的"小聪明"翻译成人人看得懂的话，就是我们把它写出来的原因。

下次你再装一个新App，不妨多给它3天、7天、15天的时间。如果它始终对你"表里如一"，那它值得留在你的手机里。如果它开始"变脸"……你就知道那套剧本，是怎么写的了。

360移动安全团队，专注移动安全与反诈，将不定期拆解真实案例和“剧本”，欢迎关注。

THE END

你有没有遇到过类似的现象？评论区聊聊~

温馨提示：请只聊你遇到的套路和体验，不用点名具体应用，避免给彼此带来不必要的麻烦~