解剖“牛皮癣”：深度逆向分析某恶意安卓应用的“赖皮”操作

W4nk3r

（由于本人手机无法root，一切操作几乎纯大力出奇迹，主要分享思路）
最近，由于贪便宜，从拼夕夕上下单了一款电子产品，根据商家提供的二维码，下载相应的遥控程序OK，下载成功以后，接下来我的体验堪称噩梦:应用启动以后，屏幕上密密麻麻弹出各种全屏广告-电商促销、游戏下载、贷款、相亲软件。。。。主打一个应有仅有。关闭一个，立即弹出另一个。咋关也关不掉。
那么，深入探究一波
首先，用jadx-gui工具进行反编译。从Mainfest入手，查看Androidfest.xml一般来说这个文件，你可以从它身上粗略知道
1.app有几个“外来组件”
2.它们属于哪些sdk以及
3.某个功能由哪个组件（这里是Activity）负责实现

OK，在application中看到了
android:name=”com.shix.shixpc.CrashApplication"

我们先根据app的运行逻辑（启动顺序)做一个假设：
由于App的启动顺序是Application->第一个Activity，那么，系统在加载进程时，会直接new这个类，并调用onCreate()那这样的话 任何“全局只需要初始化一次的东西(崩溃日志、统计、广告sdk、远程配置)之类的东西都很适合放在这里。
那么为了验证猜想，果断访问，果不其然，在文件中找到了相应库的调用，而且还有更劲爆的appid和appkey直接显示了


下面是crashapplication被扣掉细节，保留框架后的代码

这段代码上来就验证了我的猜想。
首先上来就是访问一个外部配置文件（在https:后面的一个txt），一般来说，十有八九就是了。
Handler延迟一秒，带一个APP_idOpenAd()的条件判断：这个就算看不懂代码，直接翻译英文OpenAd也是跟广告相关的
也看到了广告真正的入口 intiCYAd()，里面的内容被我清除了，当时写了某甲、某手、某点通、某度等sdk的init()
而且在主页面代码的逻辑中，也看到跟crashapplication相同的外部库的调用


接下来开始拆解病灶这里着重分析一下某甲的这条链

高层入口:某处发起“加载奖励视频广告请求”（伪代码）

实际调用入口都封装在相应的sdk里面，但最终都会落到某甲的广告核心加载类里面


统一入口：核心加载类（伪代码）
这个类找的时候用的是搜索关键词，搜索“广告”，看到了“广告请求开关已关闭”以及“联系管理员” 字样访问发现里面一堆j(....)重载，对应不同的广告sdk

这里你能学到以下通用套路
sdk自己也有一个广告请求总开关(p.g.j())和App里的APP_isOpenAd()是两层开关真正做事的是Runnable task，会调用组件管理器，执行广告投放的任务所有的入口最后都归一到一个调度j(task,adTypeId)，负责线程池和打点

组件层:奖励视频组件（伪代码）
在run（）里：

这一层完成了几件事:根据广告位、网络状况，像服务器发起了HTTP请求。请求返回后，解析成内部的az/AdTemplate之类的对象把结果通过回调aeVer抛给上层（“有一个TTRewardVideoAd实例可以显示”）

展示层：TTRewardVideoActivity/TTRewardVideoLandscapeActivity

真正播放视频的就是这两个Activity,以及一个基类TTBaseVideoActivity当上层调用TTRewardVideoAd.show(Activity)时：构造intent，目标是RewardVideoActivity或LandscapeActivity（根据横竖屏显示）

Activity启动后，从Intent/Bundle中恢复广告素材、播放配置、进入TTBaseVideoActivity的播放设置
奖励视频链路加载入口代码

检测入口代码

Mainfest末尾以及一堆
xxxxRewardVideoAd的使用整体结构位”LoadManager
->组件
->xxxRewardVideoActivity/xxxRewardLandScapeVideoActivity.”





App侧的广告循环/频次在该app中，广告循环是通过一套计数器+远程配置控制频率

1. 全局总开关+分位开关总开关:isOpenAd各页面开关:adSplash、adMe、adAdd、adCloudVideo、adVideo App要在某个未知加载广告，一般会检查:


APP_adVideo()内部就是


抽象一下读isOpenAd(总开关)读adVideo(奖励视频开关)两个都>0才允许播放其他方法如APP_adSplash()/APP_adMe()/APP_adList()全是如此

计数器
文件末尾是一组很典型的“次数统计”接口：


开屏次数：  APP_SaveSplashCount() ：每次开屏 +1，超过 10000 重新从 1 开始。
APP_GetSplashCount() ：读取当前值。
其它页面”次数：
  
APP_SaveOtherCount() / APP_GetOtherCount()列表广告相关计数：  APP_GetListCount() ：读取并自增


AdListCount  APP_GetAdDataListCount() ：


读取并自增 AdCloudDataListCount 使用示例，比如“其它功能”页： FragmentOther.onCreateView 播放本地录像时也会记录次数：
ShowLocalVideoActivity.onCreate 后半段
这些计数在你看到的 Java 里， 大多只是记录，没有直接“每 N 次弹一次广告”的 if 。


这有两个常见用途：

做埋点：广告 SDK 或自有后台可以看到用户第几次打开某页面。
留“远程策略”的余地： 服务端可以根据计数 + 用户行为下发更复杂的配置（例如某个字段含义是“从第几次开始才开启某广告”），终端只负责计数和读取。

SDK 侧的“循环播放”控制
在某甲奖励视频的内部实现里，还有一层“再看一次”的控制，典型关键词是： TTRewardVideoAd.RewardAdPlayAgainController
内部类RewardAdplayAgainController相关逻辑

媒体平台的桥接代码代码里也有


播放结束后，根据配置信息判断是否允许“再看一次拿额外奖励”如果允许，就在同一条广告链里再次触发一次播放（可能不再重新从服务器请求，而是复用缓存）所以奖励视频的“循环”可以有两层： App 自己控制：比如用户每看 5 次某个功能，就弹一次奖励视频（通过计数器实现）SDK 内部控制：一条广告播放完，SDK 提供“再看一次”逻辑

整体调用链示意（以奖励视频为例）
把上面信息串起来，可以脑中画出这样一条“抽象链”：
进程启动：     Android → CrashApplication.onCreate()
远程配置阶段： CrashApplication.networkTaskApp→ getJSONObjectApp(url) →HTTP GET 远程 JSON → CommonAppUtil.SaveAppJspn(json) → SharedPreferences 写入： isOpenAd 、 adVideo 、 adSpType 、 adIP 、 adPort 等
广告初始化触发：CrashApplication.initSDK() → Handler 延时 1 秒发消息   Handler.handleMessage：   调 CommonAppUtil.APP_isOpenAd() 读总开关   如果 > 0 ：调用 intiCYAd() （理论上的广告 SDK init 入口）业务触发奖励视频：某个 Activity/Fragment 中（例如列表、云视频、某个按钮）： APP_adVideo() = 总开关 + 奖励视频开关
SDK 加载链：      
高层：调用 TTAdNative（或 Mediation 的 LoadManager），最终进入：   TTAdNativeImpl.gq.j(xtVar, aeVar) （奖励视频入口）   

内部检查 SDK 总开关 → 构造 Runnable → 调度到线程池   组件管理器 reward.j.up.j().j(xtVar, callback) 向服务器发请求   

解析结果 → 回调给业务层（或 Mediation 层）

展示链： 业务层拿到 TTRewardVideoAd 实例 → 调 show(activity)   内部通过 Intent 启动：TTRewardVideoActivity 或 TTRewardVideoLandscapeActivity   TTBaseVideoActivity 里执行播放、点击、奖励发放等逻辑   如允许再看一次，则内部再触发一轮播放（SDK 内部循环）


循环 / 频次控制： 每次进入相关页面，业务代码调用：     APP_SaveSplashCount() / APP_SaveOtherCount() / APP_GetListCount() 等

显示广告前，根据计数和远程配置字段决定是否触发 SDK 加载




害怕排版出问题，让deepseek帮我把调用链画生成了一份流程图

(tips：打码区域均为相应的广告sdk，由于数量众多可能存在漏掉的情况，望师傅们海涵)
(本文仅用于技术研究与交流，提高公众安全意识，请勿用于非法用途。
仅分析设计与逻辑层面的问题，不再补充任何实操修改、代码或教程类内容

retsyo

感谢如此相信的解剖帖子

IcePlume

这些流氓软件真的恶心，疯狂钻空子

sailor22

retsyo 发表于 2026-1-17 21:48
感谢如此相信的解剖帖子

好多人打剖腹产打成刨，吓人

666888tzq

分析详细，学习了，感谢分享。

femten

虽然看不懂，不影响给楼主点赞！感谢分享！

能发个成品版本就最好了

ltao007

楼主好厉害，感谢分享！

dreamtrue1985

我也碰到一个，海银之家

liuhai7435

可以把原包发出来吗

liu0356

感谢分享

kexiu

真是厉害啊

立竿见影

监控类的小鹰看看，和视频类的大师兄影视就是各种恶心人的广告，快应用，电商促销、游戏下载、贷款、相亲软件。。。。主打一个应有仅有。关闭一个，立即弹出另一个咋关也关不掉。和楼主的经历完全相同，因为没技术，选择了跳过广告的软件屏蔽，作用有一些，但是没有完全根治。真无奈！