本文档围绕广告情报类 SaaS 产品，从产品需求分析、用户痛点、目标客户群体，到技术栈全景，进行系统性梳理。适用于具备完整 Android 逆向技术栈、计划切入该赛道的技术从业者参考。
广告情报平台本质上是一种数据服务产品，核心价值是让企业”看见”竞争对手在投什么广告、用什么素材、在哪个平台投、投了多久、投放量级大概是多少——然后用这些数据指导自己的广告投放决策。
这件事本身的市场需求非常大。广告投放是绝大多数互联网产品获客的主要手段，一个中型游戏公司每年的买量预算可能是几千万到几个亿，但如何分配这笔钱、选什么素材方向、押哪个平台——大部分决策都在靠”感觉”或者低效的内部测试。能给这个决策过程提供数据依据的产品，市场愿意为它付钱。
这类产品通常覆盖以下几个方向，每个方向对应不同的客户群体：
游戏广告情报：核心功能是竞品买量素材监控——能看到某款游戏正在投放的广告创意、投放媒体、投放持续时长（持续时间长通常意味着该素材跑量效果好）、买量趋势变化。目标用户是手游厂商的市场和买量团队。
出海广告情报：覆盖海外主流广告平台（北美、东南亚、中东等不同市场），帮助做全球发行的游戏公司了解海外竞品的投放策略。海外市场信息不对称程度远高于国内，这类数据的价值也更高。
泛行业广告情报：把覆盖面从游戏扩展到短剧、电商、金融、教育等行业，采集全媒体全行业的广告数据。
电商选品情报：专门面向电商从业者，覆盖竞品投放的商品数据、爆品趋势、实时销量推算等。
素材库与创意参考：把采集到的素材结构化处理后，按行业、风格、卖点类型分类，供广告主直接参考和借鉴。
所有广告情报产品在解决同一个根本问题：
广告营销领域的信息严重不对称。 你不知道竞争对手在投什么、花多少钱、效果怎样；你不知道哪些素材在市场上已经跑通了；你不知道某个市场现在什么品类最火。这种不透明让每个广告主都要花大量时间和预算自己”试错”。
数据情报产品的价值，是把这些原本不透明的信息变成可查询、可分析的数据，让客户用”看情报”代替”交学费”。
他们是谁： 游戏公司的市场部、买量团队，从独立开发者到大型手游厂商均有覆盖。核心工作是在国内主流流量平台花钱做付费推广，把游戏推给目标玩家，核心 KPI 是广告投入产出比（ROI）和新增用户成本。
业务场景： 日常工作是在多个广告平台（信息流、短视频、激励视频等）同时跑广告，测试不同素材的效果，把跑量好的素材加大预算，把跑量差的停掉。每天和广告创意、出价策略、平台算法打交道。
核心痛点：
素材是买量的命脉，但创意枯竭极快。一套素材跑几天就进入疲劳期，需要持续不断地产出新创意，但”下一个爆量素材该往哪个方向做”是个高度不确定的问题，从零摸索成本很高，测一批方向可能烧掉几十万。
竞品动向完全不透明。竞争对手突然大幅增加买量，是新版本上线了？还是发现了某个高效的素材方向？完全不知道，只能靠猜，等自己察觉到的时候往往已经落后一截。
预算分配缺乏依据。往哪个平台投、各平台预算怎么分、哪个受众人群最值得打——这些决策没有竞品数据参照的话，基本靠历史经验加运气。
广告情报产品解决这些问题的方式： 让买量团队直接看竞品投了什么素材、这个素材连续投放了多久（持续时间长代表效果好，平台不会给烧钱没效果的素材持续跑量）。用”看竞品已验证的方向”代替”从零测试”，大幅压缩试错成本和时间。
他们是谁： 做海外市场的游戏发行团队，目标市场是北美、欧洲、日韩、东南亚、中东等。在海外主流广告平台投放广告，驱动游戏在海外应用商店的下载增长。
核心痛点：
海外市场信息严重不对称。不同国家的用户口味、素材风格偏好、有效媒体渠道完全不同，国内的经验无法直接照搬。做北美市场和做东南亚市场，连用户审美都是两套逻辑。
不知道哪些竞品在海外已经跑通了。同类产品有人在某个市场大量买量，说明这个产品在当地已经找到了商业模型，这个信号非常有价值——意味着这个市场有用户、有付费能力，值得进去打。但这个信息对于不在当地的人来说几乎拿不到。
多语言素材制作成本高。要覆盖多个市场，就要做英语、阿拉伯语、泰语等多语种版本的素材，翻译和本地化的成本不低，而且本地化质量直接影响效果。
他们是谁： 短视频内容平台的流量运营方，以及做短剧内容的制作和发行团队，通过信息流广告把内容推给潜在付费用户，核心指标是付费转化率和投资回报比。
核心痛点：
竞争烈度极高，投流效率决定生死。这个赛道已经是红海，稍微落后竞争对手的投流效率，用户成本的差距会直接反映在利润率上。
爆款素材规律难以总结。一条引流素材突然跑量，很难判断是哪个因素起了作用——是封面、标题、前3秒的钩子、还是剧情的节奏？不知道原因就很难复现，下一条还是要靠猜。
素材数量需求极大而创意资源有限。投流的逻辑是靠数量跑概率，一天需要产出大量素材，但有效的创意方向不好找，大部分素材投出去转化率很差。
他们是谁： 在主流电商和社交电商平台经营多个店铺的品牌商和经销商，通过付费广告驱动商品销售。
核心痛点：
选品靠感觉，押错货损失惨重。备了一批货，结果这个品类已经过了爆发期，库存积压是电商卖家最头疼的问题之一。
不知道竞品在投什么广告。对手的爆品用的是什么素材风格、主打什么卖点、在哪个时段集中投放，这些信息完全不透明。
广告创意方向缺乏依据。打”性价比”还是打”品质感”？强调功能还是强调场景？每次方向测试都要烧一笔测试预算，而且结果不一定有代表性。
| 用户群体 | 核心业务 | 最大痛点 | 情报产品解决的本质问题 |
|---|---|---|---|
| 手游买量团队 | 国内付费推广 | 素材方向没依据、竞品动向不透明 | 把竞品已验证的投放经验变成自己的参考 |
| 游戏出海团队 | 海外市场拓展 | 陌生市场信息不对称 | 降低进入新市场的信息成本 |
| 短视频投流团队 | 内容付费转化 | 爆款逻辑难总结、素材需求量大 | 提供已跑量素材的方向参考 |
| 跨境电商广告主 | 选品 + 卖货 | 选品靠猜、广告方向无参考 | 用竞品数据替代自己盲目试错 |
结合以上分析，切入这个赛道的潜在客户分为两类。
A 类：数据平台与工具研发方（B 端，客单价高）
做广告情报数据的公司，其核心数据管道依赖 Android 逆向和协议还原技术。他们内部有持续的逆向人才需求，且这类人才极度稀缺——能逆向平台 App 拿到数据接口、又能持续跟进平台版本更新应对风控升级的人，市场上并不多。这类客户对应的合作形式通常是长期外包或技术顾问，单价高、合作周期长。
另外有自建数据采集需求的游戏公司市场部，以及做竞品监控工具的创业团队，他们不想买现成 SaaS 但有能力自己搭，需要有人帮他们打通最难的技术部分。
B 类：广告情报产品的终端使用者（C/SMB 端，量大）
手游买量团队、游戏出海团队：他们使用广告情报产品的过程中，会遇到数据采集脚本失效、账号封禁、平台限制等技术问题，是有真实付费意愿的技术咨询客户。
短剧投流团队：需要了解平台检测机制，规避投流账号的封禁，账号存活率对他们来说直接影响收益。
跨境电商商家：多账号运营、账号关联风险、自动化工具被平台识别，这些技术卡点他们普遍存在，但很少有人能给出技术层面的解释和解法。
广告情报产品背后的核心技术是 Android 逆向与协议还原，这不是辅助手段，是整个产品数据管道的起点。没有逆向能力，采集管道断了，产品就空了。
广告平台（短视频平台、信息流平台、海外主流广告平台）的投放数据从来不对外开放 API。这类广告情报产品拿到这些数据的唯一方式，是逆向平台的 App，还原其内部通信协议和接口签名算法，然后用程序模拟合法请求自动化采集。
完整的采集流程大概是这样的：
目标平台 App
↓ 脱壳（针对商业加固方案）
↓ IDA Pro / Hopper 静态分析（还原函数逻辑）
↓ Frida / lldb 动态 trace（追踪运行时调用链）
↓ 还原加密/签名算法（sign、token、timestamp 生成逻辑）
↓ 协议抓包（Charles / Burp Suite / mitmproxy）
↓ 构造合法 API 请求
↓ 大规模自动化爬取
↓ 结构化存储与处理
这条链路上的每一步都是技术难点，尤其是签名算法还原和风控对抗这两块。
C / C++ 是 Native 层分析和工具开发的核心语言。广告平台 App 的关键风控逻辑、签名算法、防爬机制几乎全在 .so 里，不懂 C 就看不懂。自己写 Hook 工具、unidbg 调用封装也需要 C/C++。
Java / Kotlin 是 DEX 层分析的必须能力。App 的业务逻辑、请求构造、账号体系在这里，反编译代码的可读性依赖对 Java/Kotlin 语法的熟悉程度。
Smali 需要能读，做 patch 改包的时候绕不过去。不需要手写，但看不懂就没法做针对性修改。
ARM 汇编 是进阶必备。函数被 OLLVM 混淆后，IDA 反编译出的伪代码可读性极差，能直接读汇编决定了你能不能继续往下分析。
Python 是自动化采集脚本、数据清洗处理、签名算法验证的主力语言，几乎每个项目都要用，要足够顺手。
JavaScript 在 Frida 脚本编写和部分 App 的 JS 层签名分析（WebView 内嵌 JS 引擎）时会用到。
IDA Pro 是 Native 层分析的核心工具，分析 .so 文件、还原函数逻辑、定位签名算法和风控检测的入口函数。遇到 OLLVM 控制流平坦化混淆，需要配合反混淆插件（如 D810）辅助恢复控制流，单靠肉眼看汇编基本不可行。
Hopper 在 macOS 环境下是 IDA 的轻量替代，部分场景下更快出结果，两者互补使用。
JADX 是 DEX 反编译的日常工具，把 .dex 转成可读 Java 代码，日常用得最多。遇到复杂混淆或 Kotlin 代码，JEB 的处理能力更强，尤其在交叉引用分析和调用链追踪方面。
Ghidra 是开源替代方案，脚本扩展性好，可以写自动化分析脚本批量处理 .so 文件，在需要规模化分析多个 App 版本时效率比 IDA 手动操作高。
Apktool 用于资源文件提取和 smali 层面的改包。dex2jar 做格式转换，配合 Java 反编译器使用。
Frida 是动态分析体系的核心，没有之一。广告平台 App 的签名算法追踪、加密逻辑拦截、风控参数采集，基本都靠 Frida 完成。
具体用法：Hook Java 层的请求构造方法，拦截完整请求参数；追踪 Native 层的加密函数，在入参和出参处打断点记录数据；用 Frida Stalker 做指令级 trace，追踪复杂算法的完整执行路径。
Frida 本身也是被检测的对象，平台 App 会扫 /proc/self/maps 找 gadget、检测 frida-server 的默认端口、检测特征字符串。绕过这些检测有对应的方法，具体用哪种要看实现。
lldb 在 iOS 端（部分广告平台有 iOS 版本需要分析）和 macOS 开发环境调试中会用到，是 GDB 的替代工具。
Xposed / LSPosed 用于开发系统级 Hook 模块，适合需要持久生效、在 App 启动最早期介入的场景。对于批量采集任务，Xposed 模块比每次 attach Frida 更稳定。
unidbg / Unicorn 是这个赛道的关键工具之一。广告数据的规模化采集需要高并发，不可能维护一大堆真机，unidbg 可以在不需要真实设备的情况下直接执行 .so 里的签名函数，在服务器上跑并发采集，是工程化落地的核心路径。
Charles / Fiddler 是 HTTPS 抓包的日常工具，分析 App 的接口请求结构、参数字段、返回数据格式。这是分析签名算法的第一步——先看清楚请求长什么样，再去逆向签名的生成逻辑。
Burp Suite 在需要对请求做精细改包和重放测试时更合适，验证还原后的签名算法是否正确通常要靠它。
Wireshark / tcpdump 处理底层全流量。部分广告平台使用非标准 HTTP 协议（私有二进制帧格式、Protobuf over TCP），HTTPS 代理看不到，只能在底层流量里找规律逐字节分析。
mitmproxy 的优势是可编程，用 Python 写插件实时处理拦截到的请求，适合自动化的签名参数提取和格式化。
SSL Pinning 绕过是标配能力。广告平台 App 几乎都有证书绑定，不绕过就没法用代理抓包。常用方案：Frida 脚本 hook TrustManager / X509TrustManager；Xposed 模块全局处理；直接 patch DEX 里的证书校验逻辑。
Protobuf 解析在这个赛道里出现频率很高。大量平台的内部接口使用 Protobuf 序列化，抓到的是二进制数据，需要逆向还原 .proto 文件定义才能正确解析字段含义。gRPC 接口在这个基础上再加 HTTP/2 帧解析。
这是整个技术链路里最核心、最耗时、也最有价值的部分。
广告平台的每个 API 请求都带有防爬签名参数（各平台叫法不同，常见的有 x-sign、_signature、x-argus、ms_token 等）。这些签名是由客户端在 Native 层计算生成的，服务端收到请求后会验证签名合法性，不合法直接拒绝，所以不还原签名算法就构造不出有效请求。
还原流程：
定位签名函数：通过抓包找到签名参数的字段名，然后在 DEX 和 .so 里搜索相关字符串，找到生成签名的入口函数。
动态 trace：用 Frida Stalker 或手动 hook 的方式，记录从签名函数入参到出参的完整调用链，搞清楚算法的输入是什么（时间戳、设备信息、请求体 hash 等）。
静态分析：在 IDA 里静态分析签名函数的完整逻辑，还原算法的具体实现——是标准的 HMAC-SHA256？还是自定义的 CRC 变体？还是混淆后的私有算法？
Python 复现：用 Python 实现还原后的算法，和 App 的实际输出对比验证，确保结果一致。
工程化：用 unidbg 直接调用 .so 里的签名函数，或者把 Python 复现版本封装成服务，供采集脚本调用。
签名算法会随着 App 版本更新而变化，尤其是平台检测到自己的算法被破解之后会主动更新。所以需要建立持续跟进机制，快速定位每次版本更新后算法的变化点。
平台除了签名验证，还有风控系统检测异常采集行为，需要逆向平台集成的风控 SDK，分析它采集了哪些设备和环境特征，然后针对性地构造”正常”的环境。
风控 SDK 采集的主要维度：
设备硬件特征：IMEI、序列号、MAC 地址、蓝牙地址，以及 Android 10 以后的 OAID；屏幕分辨率与 DPI 的组合；CPU 型号和核心数；
系统环境特征：Android 版本、系统语言与时区、Build fingerprint（厂商/型号/版本号的组合）、已安装应用列表；
运行环境检测：Root 检测（检测 su 路径、Superuser.apk、/proc/self/status 里的 TracerPid）；虚拟环境检测（扫 /proc/self/maps 里的 VirtualApp 路径、检测模拟器特征 build prop）；调试检测（Frida gadget、调试器附加）；
传感器数据：加速度计、陀螺仪的时间序列数据，用来判断设备是否在真实物理环境里运行；
行为特征：点击间隔分布、滑动轨迹的线性程度、操作序列是否符合真实用户路径。
对抗策略：
逆向风控 SDK 之后，对所有被采集的字段做 Hook 拦截，在采集发生之前替换为构造好的”正常”值，而不是在采集完成后去修改已上报的数据。时机很重要，太晚了绕过没用。
传感器数据是最难处理的维度，因为虚拟环境里这些传感器要么没有，要么返回静态值，和真实设备有明显差异。需要在 Framework 层做模拟，返回带有正常物理噪声分布的时间序列数据。
这块是整个技术栈里门槛最高的部分，对应的是”虚拟环境 App 兼容修复”和”设备指纹体系完整伪造”这类高单价需求。
Framework 层修改是核心能力。在 android.hardware、android.os、android.telephony 等系统包里做修改，让上层 App 通过任何方式读取设备信息，拿到的都是你控制的数据。这比 Java 层 Hook 稳定得多——Java 层 Hook 需要针对每个 App 单独处理，还可能被检测到；Framework 层修改对所有 App 全局生效，不需要额外维护。
AOSP 编译与定制：能从源码构建可运行的系统镜像，理解各模块的依赖关系，知道修改哪里会影响哪些系统行为。这是做 ROM 定制的基础能力，没有这个就只能做浅层的 Hook，深层的系统行为改不了。
ART 虚拟机内部机制：理解解释执行和 AOT 编译的区别，知道 dex 在运行时的内存结构——这是做运行时脱壳、内存 dump、自动化脱壳工具的必备知识。很多商业加固方案的核心保护逻辑在 ART 层展开，不懂 ART 就看不穿。
Binder / IPC 机制：Android 的进程间通信几乎全走 Binder，理解 Binder transaction 结构和 ServiceManager 注册机制，才能做系统服务级别的拦截，也才能理解某些 App 为什么能”穿透”普通沙箱读到真实设备信息。
SELinux 策略：ROM 定制必须处理 SELinux，否则新增的系统服务或被修改的系统文件会被 SELinux 直接拦截导致无法运行。编写自定义策略规则是绕不开的基础工作。
采集到的原始数据是非结构化的，还需要一套数据处理能力，这部分虽然不是逆向核心，但是决定交付质量的关键：
素材去重：广告平台里同一素材会被多个广告主反复使用，需要做大规模图片/视频去重。感知哈希（pHash/dHash）处理图片，视频需要关键帧提取后做哈希比对，或者用特征向量（embedding）做相似度计算。
Protobuf 结构还原后的数据解析：把还原的 proto 定义应用到批量数据解析上，需要健壮的容错处理，因为字段定义可能随版本变化。
版本变更快速定位：平台 App 版本更新后，用工具对比新旧版本的 DEX diff 和 .so diff，找到有改动的函数，缩小重新分析的范围，这是维护长期采集项目的效率关键。
壁垒高低
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
极高 │ 签名算法逆向还原（平台最核心的反采集机制）
│ 风控 SDK 逆向与完整对抗体系
高 │ unidbg 工程化（规模化采集的关键路径）
│ ROM / Framework 层定制
│ 长期版本跟进能力（持续维护采集管道）
中 │ 协议抓包与 Protobuf 解析
│ 设备指纹 Hook 与环境伪造
低 │ 爬虫框架搭建（有了协议之后的工程实现）
│ 数据存储与展示层
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
签名算法还原和风控对抗是这类产品最核心的护城河。没有这个能力，数据采集管道断掉，整个产品就没有数据了。这也是为什么这个方向的招聘薪资普遍高于普通 Android 开发，且要求经验年限长——不是这个工作量有多大，而是会的人确实不多。
| 需求类型 | 核心依赖能力 | 难度 |
|---|---|---|
| 单个平台 App 签名算法还原（一次性交付） | Frida + IDA + 抓包 + Python 复现 | ★★★ |
| 签名算法长期维护（App 更新后持续跟进） | 同上 + 快速定位变化点的经验 | ★★★★ |
| 完整采集方案搭建（协议 + 脚本 + 去重） | 全链路能力 + 工程化经验 | ★★★★ |
| unidbg 化签名服务（规模化并发采集） | unidbg + 算法工程化封装 | ★★★★ |
| 风控 SDK 逆向分析报告 | 风控 SDK 全维度分析 | ★★★ |
| 虚拟环境 App 兼容修复 | ROM 定制 + Framework 修改 + 指纹伪造 | ★★★★★ |
| 出海平台 App 协议逆向 | 同签名还原 + 海外风控差异经验 | ★★★★ |
| 自建广告情报系统技术顾问 | 全链路能力 + 架构设计经验 | ★★★★★ |
先摸清对方在检测什么，再动手
拿到一个新项目，第一步不是上来就改参数，而是用 Frida 把 App 访问的所有设备信息 API 全部 hook 住，日志化记录它到底读了哪些字段、读了多少次、读取的时机是什么。这一步做完，你知道对方在看什么，后面的每一步改动都有明确理由。
跳过这步直接猜的代价是：改了半天，不知道哪个改动起了效果，下次遇到类似项目还是从零开始。
Native 层是真正的战场
很多人的注意力停在 Java 层——改 Java API 的返回值、hook Java 层的设备信息读取方法。这些确实能骗过部分检测，但核心的风控评分逻辑几乎全在 .so 里，从 Java 层看不到它在干什么。
遇到 Java 层已经处理了但问题还在，往 Native 层走就对了。定位方法：从已知的 Java 层 JNI 调用顺着往下追，或者在 .so 里搜 device、fingerprint、risk、score 等字符串找入口。
版本更新是持续的，方案的生命周期是有限的
签名算法被还原之后，平台一旦察觉到数据异常，或者到了固定的安全审计周期，就会更新算法。这既是麻烦，也是长期维护价值的来源——客户一旦依赖你的方案，更新后的修复就是持续的收入。
建立快速定位变化点的工作流很重要：版本更新后先做 DEX 和 .so 的 diff，找到有改动的函数，缩小分析范围，而不是从头再分析一遍。有时候改动很小，半天能搞定；有时候是大规模重构，要另说。
设备池的一致性比单台设备的伪造更重要
批量采集场景里，不只是单台设备的指纹要真实，设备池里多台设备之间的特征分布也要符合真实世界的规律。如果一批采集账号的分辨率全是同一个值、Android 版本全相同、安装的应用列表高度相似——这种”太整齐”的分布本身就是异常信号，风控的机器学习模型很容易识别。
做这类项目的时候，要分析目标平台真实用户的设备分布（可以从公开的移动统计数据里拿参考），然后让伪造的设备特征分布和真实用户的设备分布接近，而不是给所有账号配一套一模一样的参数。
能力边界要清楚
有些技术上完全能做的需求，实际接了会有法律或平台风险。有些需求技术上根本做不到——比如有 TEE 绑定的金融级加密，在没有硬件漏洞的情况下纯软件层面无法绕过。
接项目前把可行性评估清楚，不确定的情况下宁可拒接，也不要花大量时间最后交付不了，对双方都是损失。
文档基于需求分析与技术实践整理，供技术变现路径规划参考。