Google上架之包网平台RAJA.GAME

今天介绍的是包网平台RAJA.GAME的1个APP，这个包网平台和之前介绍的DD.Game和ATM相比，主要有以下不同：

1.集成的游戏厂商偏国际化，而不是东南亚化，而且游戏偏少

2.主打了ludo玩法，给了它一个核心入口

3.缺少代理裂变机制

1. 基本情况

Google Play链接：https://play.google.com/store/apps/details?id=com.dfkjhakd.czxva

上架时间：2026年1月15日 下载次数：100k+

2.B面截图

3.技术方案

APP 简介

  • 技术框架：当前主包本体明确是 Unity IL2CPP 游戏壳，核心资源位于 resources/assets/bin/Data；同时动态日志已坐实运行时还会装入另一套 Cocos/JSB 游戏类。
  • 自定义 so：已发现 libgamelog.so，并由 com.unity3d.player.UnityPlayerActivity 在 onCreate() 中显式执行 System.loadLibrary("gamelog")。
  • B 面 APK：目录中的 b.apk 是你通过 hook 得到的 B 面 APK 文件，体积 11.79 MiB；其内容结构与 hooklog.txt 中装入的 com.game.maingame.SSMainGame、org.cocos2dx.javascript.AppActivity 等类高度对应。
  • 自定义 so 文件分析：libgamelog.so 体积 2.75 MiB，字符串侧可见 JNI_OnLoad、socket、connect、SSL、https:// 等线索，说明它具备 native 联网与 JNI 初始化能力；但未直接暴露明文 b.apk 路径或清晰的 Java 导出方法名。
  • 事件上报 SDK：已明确发现 Adjust；LevelApp.onCreate() 中调用 Adjust.onCreate(new AdjustConfig(this, "wk14qt363qbk", ...))，同时 Manifest 里声明了 AdjustReferrerReceiver。
  • APK 体积经验：主包 18.65 MiB 落在 15-30 MiB 区间，经验上 WebView 与子 APK 两种方案都可能；但本样本已有你提供的 b.apk 与 hooklog 双重证据，当前应优先判定为“子 APK / 子游戏 B 面”方案，而不是远程 WebView 页。

大文件分析

文件大小判断
resources/assets/bin/Data/data.unity3d14.64 MiBUnity 主包的标准资源载体，结合 global-metadata.dat 与 UnityPlayerActivity 判断，它更像壳包自身的正常 Unity 资源。
b.apk11.79 MiB这是已被 hook 取出的 B 面 APK，且其 zip 条目中可见 libcocos2djs.so、assets/main/index.jsc、assets/src/cocos2d-jsb.jsc、assets/jsb-adapter/jsb-engine.js；当前不是“可疑”，而是已坐实的 B 面载体。
resources/assets/bin/Data/Managed/Metadata/global-metadata.dat5.42 MiBUnity IL2CPP 元数据文件，属于主包框架正常文件，不是 B 面载体的首要怀疑对象。
libgamelog.so2.75 MiB业务自定义 so，启动时显式加载，且结合动态 in-memory dex 装载现象，应作为主包 A/B 判定、资源选择或壳层调度的重点对象。
Fortune Quest 777.apk18.65 MiB原始壳 APK 本体；其大小本身不能决定 B 面形态，但与目录内可见的 b.apk 形成“壳包 + 子 APK”双层结构。

AndroidManifest.xml 分析

  • 包名：com.dfkjhakd.czxva；应用名来自 @string/app_name，解析值为 Fortune Quest 777。
  • Application：com.unity3d.player.LevelApp，说明主包主体是 Unity 壳应用；onCreate() 中同时初始化 Adjust。
  • Launcher Activity：com.unity3d.player.MainActivity；它本身很薄，只做一次 startActivity(new Intent(this, UnityPlayerActivity.class)) 跳转。
  • 真正容器页：com.unity3d.player.UnityPlayerActivity；其 onCreate() 中会先加载 libgamelog.so，再构建 UnityPlayer。
  • 许可壳：Manifest 中存在 com.pairip.licensecheck.LicenseActivity 与 LicenseContentProvider，说明样本同时带有 PairIP 许可校验层。
  • 归因与广告：Manifest 声明 com.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE、com.google.android.gms.permission.AD_ID 和 AdjustReferrerReceiver，说明主包具备商店安装来源与广告标识链路。
  • Activity 结构：Manifest 中存在大量混淆命名 Activity，但当前请求的核心目标不是这些 UI 页面本身，而是壳包如何切向 B 面；目前最关键的还是 MainActivity -> UnityPlayerActivity -> gamelog/native 这条链。

Manifest 关键 meta-data

  • unity.splash-enable = true
  • unity.launch-fullscreen = true
  • unity.render-outside-safearea = true
  • unity.auto-report-fully-drawn = true
  • com.android.stamp.source = https://play.google.com/store
  • com.android.stamp.type = STAMP_TYPE_DISTRIBUTION_APK
  • com.android.vending.splits = @xml/splits0

Manifest 关键网络策略

  • Application 使用 @xml/network_security_config，对应文件里设置了 <base-config cleartextTrafficPermitted="true">。
  • 这说明应用允许明文流量。当前样本没有直接坐实远程 WebView B 面 URL，但这仍是潜在的远程配置/联网能力放宽线索。

结论

  • A/B 判断迹象：存在明确迹象。启动期同时出现 PairIP、Adjust Install Referrer、Locale/TimeZone/SIM/VPN 采集、native so 加载和 in-memory dex 装载，说明主包确实在做壳层环境判定与运行时模块选择。
  • A/B 跳转迹象：存在明确跳转 B 面迹象，且这次不是单纯怀疑。你提供的 b.apk 已被动态日志中的 SSMainGame / org.cocos2dx.javascript.AppActivity 类加载行为强力补证。
  • B 面形态：当前更像“独立 Cocos/JSB 子 APK / 子游戏”，而不是当前主包 Java 可见层直接通过 WebView.loadUrl(...) 打开的远程 H5 页面。

调用链

  • 启动入口：MainActivity.onCreate() 只做一次跳转，直接进入 UnityPlayerActivity。
  • Application 初始化：LevelApp.onCreate() 先设置全局实例，再初始化 Adjust，说明安装来源与归因链在应用冷启动时就已挂上。
  • native 入口：UnityPlayerActivity.onCreate() 中先执行 System.loadLibrary("gamelog")，然后继续 UnityPlayer 初始化；因此 libgamelog.so 介入时机非常早。
  • 动态模块装入：hooklog.txt 明确记录多次 InMemoryDexClassLoader.loadClass，先装入主包相关类、Adjust/InstallReferrer 辅助类，随后再装入 com.game.maingame.SSMainGame、org.cocos2dx.javascript.AppActivity、org.cocos2dx.lib.Cocos2dxHelper 等 B 面类。
  • B 面承载：b.apk 内部条目明确包含 libcocos2djs.so、assets/main/index.jsc 与 jsb-engine.js，与动态装入的 Cocos 类完全同向，因此可以把 B 面承载物具体写成“Cocos JSB 子 APK”。
  • 缺口：当前静态源码层没有直接看到“从主包把 b.apk 落地、解出或启动”的明文 Java 代码，这条链更可能隐藏在 libgamelog.so、运行时 dex 或 Unity/native 层回调里。

安装来源参数传递链

  • 静态源码层：主包中已集成完整 com.adjust.sdk 与 com.android.installreferrer.api；LevelApp.onCreate() 初始化 Adjust，Manifest 里注册了 AdjustReferrerReceiver。
  • 动态补证：hooklog.txt 中明确出现 com.android.installreferrer.api.ReferrerDetails、getInstallReferrer、InstallReferrerClient.Builder、startConnection 等调用。
  • 返回值：hook 日志显示 ReferrerDetails.getInstallReferrer() 的原始值被拦截后改写为带 gclid、gbraid、gad_source 的自定义值，因此它能证明“接口被访问、字段会进入链路”，但不能拿来当真实商店归因内容。
  • 环境联动：同一条动态链还伴随 TimeZone.getID()、Locale.toString()、getSimOperator()、getNetworkOperator() 和 VPN 检查，说明主包不是只取 referrer，而是把多类环境输入一起收集。
  • native 入参：当前静态源码不可见这些字段最终如何传给 libgamelog.so 或 in-memory dex，但结合它们都出现在启动早期，可以合理判断这部分属于 A/B 判定的前置输入链。

A/B 风控接口命中情况

接口类别是否命中静态 / 动态证据说明
Root / 调试工具检测当前未确认当前可见源码未命中 Build.TAGS、su、Magisk、Frida、Xposed 等业务侧检测；hooklog.txt 也未直接打印这类关键词。不能因为壳层较重就默认写成“已命中”。若存在这类检查，更可能隐藏在 native 或运行时 dex 中，当前证据不足。
VPS / 虚拟化环境检测当前未确认静态源码只看到 Unity/Adjust 通用读取 Build.MANUFACTURER、Build.MODEL、Build.FINGERPRINT，但未见明确 qemu / virtual / /proc/cpuinfo 业务判断链。当前最多只能说“存在设备构建信息读取”，不足以直接落成“虚拟化检测已命中”。
USB / ADB / 锁屏状态检测当前未确认静态源码未见 ADB_ENABLED、sys.usb.state、USB_STATE、KeyguardManager.isDeviceSecure() 等业务侧调用；动态日志也未直接命中。当前没有证据表明样本显式把 USB / ADB / 锁屏状态纳入风控。
时区 / 语言 / 手机卡信息检测已命中动态日志明确命中 Locale.toString()、Configuration.getLocales()、TimeZone.getID()、getSimOperator()、getSimOperatorName()、getNetworkOperator()、getNetworkOperatorName()。这是当前样本最明确的一类风控输入采集证据，而且与 Install Referrer、VPN 检查同时出现，说明其更像 A/B 判定前置环境信息，而不是单独的普通统计。

推送旁路

  • 当前未发现主包内显式 FirebaseMessagingService 或“通知点击直达 WebView / B 面 Activity”的清晰旁路。
  • 现有证据更偏向“冷启动后由壳层 + native/in-memory dex 决定模块选择”，而不是走推送直达。

本地页与远程页

  • 主包本体未坐实明确 WebView 容器页；当前静态主链是 Unity 壳，而不是 Java 层直接 WebView.loadUrl(url)。
  • hooklog.txt 里确实出现过 loadUrl、shouldOverrideUrlLoading 字样，但没有打印出实际 URL，也没有在源码中找到与之对应的主业务 WebView 容器，因此不能据此写死“B 面是远程 H5”。
  • 当前更可信的结论是：B 面不是本地 H5，而是独立的 Cocos/JSB 子游戏 APK；其核心资源位于 b.apk 内的 assets/main/index.jsc、assets/src/cocos2d-jsb.jsc、libcocos2djs.so。

读取已保存配置

  • 当前可见源码里能看到不少本地 SQLite/配置操作，但大多位于混淆 Activity 中，且字段名严重混淆，暂时不能坐实它们保存的是 B 面 URL、模式位或 B 面 APK 路径。
  • LevelLogs 里可见一个简单 SQLite 表 zafsdkbhdonxyesobc，但这更像干扰项或壳层噪音，不足以认定为 B 面配置缓存。
  • 因此目前只能保守写成“存在本地配置/数据库操作痕迹，但尚未静态坐实其保存的是 B 面配置”。

hook log分析

  • 已直接观察到的动态事实：启动期命中了 InstallReferrer、Locale、TimeZone、SIM/运营商、VPN 等接口调用。
  • 已直接观察到的动态事实：InMemoryDexClassLoader 先装入主包类和 Adjust 辅助类，随后明确装入 com.game.maingame.SSMainGame、org.cocos2dx.javascript.AppActivity、org.cocos2dx.lib.Cocos2dxHelper、Cocos2dxHttpURLConnection、AdjustUtil 等 B 面类。
  • 这条日志链与目录中的 b.apk 内容完全同向，因此它已经补足了“静态源码不可见的 B 面加载事实”。
  • 日志没有直接打出 b.apk 的落地路径或显式 startActivity 目标类，因此“如何把 APK 注入到运行时”的最后一步仍未完全坐实。

JS bridge 信息

  • 当前主包源码未发现像典型 WebView 壳那样的 addJavascriptInterface(...) 桥接接口。
  • B 面是 Cocos/JSB 子 APK，更多体现为游戏引擎脚本桥与 native/JSB 层交互，而不是传统 Android WebView JS bridge。
  • 事件上报能力方面，B 面动态日志中已出现 org/cocos2dx/javascript/AdjustUtil，说明子 APK 层也可能继续复用 Adjust 能力。

自定义 so 文件分析

与 B 面关系：结合启动时机、动态 dex 装载和 B 面 APK 已坐实这几个条件，libgamelog.so 很可能承担了 A/B 判定、环境采集、模块装载或桥接调度中的至少一部分职责。

文件：libgamelog.so，大小 2.75 MiB；由 UnityPlayerActivity 在启动期显式加载。

JNI 形态：字符串侧可见 JNI_OnLoad，但当前未从简单字符串提取中看到清晰 RegisterNatives 或 Java_com_* 业务导出名；这类特征更像混淆或桥接式 JNI 初始化。

联网迹象：可见 socket、connect、SSL、https:// 等字符串，说明该 so 具备 native 层联网能力。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注