桌面端反编译注入

这里是偏小众的发行渠道编译注入方式, 而且主要针对还是桌面平台, 这部分仅作为参考(毕竟太小众了), 目前上架桌面端常见就是以下平台

  • Windows: 目前比较广的桌面平台, 微软平台基本上目前市场占用率最高, 大部分情况对接该平台即可
  • Unix: 这部分比较多的就是 Apple 设备平台, 读取程序目录文件存在权限限制(需要注意这类情况)
  • Linux: Linux 更多应用在服务端上, 但是桌面端也有部分受众在使用

这些平台不可避免会出现大量 碎片化 问题, 也就是采用编程语言/编译器/系统权限/跨平台技术等都没有统一规划

所以对于桌面端不推荐采用任意编程语言类库处理, 而是将需要编译注入渠道信息处理成二进制下的签名加密文件

这里推荐的签名 JSON 格式如下

lines
1
2
3
4
5
6
7
8
9
10
{
// 签名文件自我的哈希数据
"hash": "",
// 应用唯一标识
"app_ident": "",
// 渠道信息
"channel_ident": "",
// 子级渠道信息
"sub_channel_ident": "",
}

这部分 JSON 数据需要采用特定 openssl 做对称加密, 加密的 KEY 为渠道后台分发的 app_key

大部分桌面技术都是对称加密解密的功能, 只需要验证 *.exe 所在目录下有没有 signature.bin 文件, 之后按照以下流程处理

  1. 应用启动之后验证应用根目录下是否有 signature.bin 文件

  2. 如果不存在按照应用类型做 崩溃退出 或者 跳过验证, 部分应用其实不需要强认证渠道信息, 所以可以直接跳过网络请求

  3. 用编程语言常规二进制文件读取功能, 加载 signature.bin 二进制数据

  4. 这里的 APP_KEY 可以编译在桌面端开发技术的配置文件之中, 注意需要做好混淆加密处理

  5. 桌面端获取 APP_KEY 按照 openssl 签名规则解密 signature.bin, 解密数据异常就当作崩溃退出处理

  6. 如果解密成功之后, 需要验证内部的 hash 字段是否和 signature.binmd5 文件哈希是否一致, 不一致也是崩溃退出

  7. 当以上解密流程都通过的时候, 就可以按照上面解密的 app_ident/channel_ident/sub_channel_ident 做 HTTP 接口推送数据

  8. 一般推送桌面端推送事件就和移动端也差不多, 所以参考下移动端推送方式即可

而提交后台分包其实就比较简单, 要求研发商提交 zip 压缩包(压缩包内部以程序启动二进制文件根目录)

这部分可能后续做不同平台而二次打包, 将应用程序直接构建成 insteller(安装器), 方便用于点击一键安装

后台需要用 Python 编写打包脚本, ZIP 解压之后按照不同平台来注入渠道信息并且用不同平台安装包程序合并成执行文件

这种方式偏小众私域的桌面端应用渠道分包处理, 官方都内置归因方案

  • Steam: 官方提供游戏绑定独立命令行启动参数, 支持类型启动附带渠道参数, 如下所示

    • steam://rungameid/123456 -app_ident=s34x123x -channel=steam_channel -sub=agent_001
    • 内部可以通过 SteamSDK 加载到外部启动参数, 所以不需要放置二进制读写
    • GetLaunchCommandLine 文档: https://partner.steamgames.com/doc/API/iSteamApps?l=schineseSteamworks
  • Microsoft Store: 微软本身支持携带 cid 渠道标识方便归因, 如下所示

    • Web: https://apps.microsoft.com/detail/{微软应用标识}?cid=s34x123x
    • 协议: ms-windows-store://pdp/?PRODUCTID={微软应用标识}&cid=s34x123x
    • 内部可以通过 UWP/Windows App SDK 接口加载获取, 该 cid 标识写入之后无法篡改删除
    • string cid = await Windows.ApplicationModel.Store.CurrentApp.GetAppPurchaseCampaignIdAsync();
    • https://learn.microsoft.com/zh-cn/windows/apps/publish/create-a-custom-app-promotion-campaign
  • Mac App Store: Apple 基于隐私合规设计两套官方渠道归因: AdServices APIApp Store 营销链接归因

实际上桌面应用的分包和归因更加依赖于所在平台应用商店上架提供 API 接口归因, 一般为了安全性都不会直接采用读取启动二进制的加密内容

部分私域应用才会用二进制读取验证方法, 其他情况都是直接走官方平台应用, 毕竟这样合规性更高