我把流程复盘了一遍，别再搜这些“入口”了——这种“APP安装包”在后台装了第二个壳
最近帮客户排查一例通过第三方“入口”下载的安装包，结果发现表面上的安装器只是“幌子”——在后台又写入并激活了第二个壳（第二个 APK / 动态加载的执行体）。流程复盘后觉得有必要把整个判断逻辑、复现步骤和防护建议整理出来，免得更多人踩雷。下面是我在排查过程中走过的路径和能落地的建议。
一、现象速览（你会看到什么）
- 安装了 A.apk 后，应用图标、名字、行为并不是唯一的程序，系统里突然多出一个或多个不明包名；
- 应用启动后有下载行为，但没有明显安装确认界面；或者有一段安装流程看起来像“系统安装器”自动完成；
- 应用实现了动态加载（DexClassLoader / loadClass）或通过反射执行从 assets/lib 里读出的代码；
- 网络请求指向不透明的 CDN/域名，下载内容为二进制 APK 或加密壳体；
- 日志里能看到 PackageManager 的安装记录，或 Accessibility / SYSTEM 权限相关异常请求。
二、我复盘的关键步骤（从安装到定位） 1) 在安全的沙箱环境做初始验证
- 使用干净 Android 模拟器或隔离手机（不要用主力机）；
- 关闭 Google Play 自动更新、Play Protect，保证测试可复现； 2) 捕获安装和运行时行为
- adb logcat 全程记录（过滤关键字 PackageManager、Installer、Intent.ACTION_VIEW）；
- 在设备上抓包（手机用 mitmproxy 或者在模拟器做 tcpdump）观察下载 URL 和二进制； 3) 检查安装包内部
- apktool / jadx 反编译：搜索 DexClassLoader、loadClass、Reflection、getAssets().open(“xxx.apk”) 或直接嵌入的 .apk 文件名；
- 查看 AndroidManifest：有没有 REQUESTINSTALLPACKAGES、BINDACCESSIBILITYSERVICE、RECEIVEBOOTCOMPLETED 等权限与服务；
- 查看 lib/ 目录有没有 native loader（.so）在运行时解压二进制； 4) 系统层面确认“第二个壳”的写入方式
- adb shell pm list packages -f | grep 可疑包名，adb shell pm path 包名 查看安装路径；
- adb shell dumpsys package 可得安装时间、安装来源（installer），对比日志找出是哪个进程触发的；
- 如果安装过程没有用户交互，说明要么是系统/厂商预装权限，要么是通过 Accessibility 自动化点击完成，或利用 root/privileged 权限； 5) 还原安装过程（回溯）
- 在模拟器上重复安装并逐步关闭网络或权限，以确认哪一步触发第二壳写入（例如先禁止网络，看是否仍写入）；
- 动态 hook（如 Xposed / Frida）观察何时调用 pm.install 或何时写入 /data/app、/sdcard/下的 apk 文件。
三、常见实现手法（你可能会遇到的几个套路）
- 动态下载 + 系统安装器触发：主包下载第二个 apk，再通过 ACTION_VIEW 打开安装界面（通常会弹出安装确认）；有时配合 Accessibility 自动“点击安装”；
- 嵌入二进制并动态加载：把真正逻辑以 dex/apk/so 的形式放在 assets 或 lib 中，运行时解密并用 DexClassLoader 加载，不会被普通安装器直接察觉；
- 利用预装/厂商权限：某些渠道包和预装程序有 INSTALL_PACKAGES 权限，能静默安装；
- “双壳”混淆：第一层壳负责推广/行为伪装，第二层壳是真正的执行体，二者通过加密、反射和资源隐藏互相掩盖。
四、如何高效识别这类安装包（给普通用户与技术用户） 对普通用户（非技术细节）：
- 不要去不明渠道、“入口”站点下载安装包；很多所谓“一键安装入口”把你导流到带壳的安装器；
- 安装时留心是否出现多次“安装”或额外授权请求；不要随意开启无关的 Accessibility 权限；
- 优先使用 Google Play / 官方应用商店，并开启 Play Protect。
对技术用户 / 审计人员：
- 先用 apktool / jadx 搜索“apk”、“install”、“DexClassLoader”、“getAssets”之类关键词；查找 assets 下是否有 .apk/.dex；
- 在受控设备上通过 adb logcat 观察安装期间的 PackageManager/Installer 日志，注意触发 install 的进程 ID；
- 抓包看是否有二进制被下载，分析下载域名和签名不匹配时的风险；
- 使用 adb shell pm path 和 dumpsys package 确认包来源和安装路径；如果安装时间与主包安装时间不同，说明后续写入；
- 如果怀疑 Accessibility 自动化，查看设置里哪些应用被授权了 Accessibility Service。
五、防护建议（用户和开发者不同侧重点） 普通用户：
- 放弃所谓“聚合入口”或“不明提供的安装包集合”；这类入口往往为快速变现而带来风险；
- 关闭“未知来源”/“允许安装未知应用”的全局授权，只在必要时临时允许并仅对可信来源；
- 不给应用 Accessibility 权限、不启用“设备管理器”类权限，除非完全信任并理解用途。
开发者 / 渠道方：
- 如果你是正规开发者，审计所有第三方 SDK 和渠道包，尽量使用官方 SDK 市场版，避免把安装逻辑交给不受信任的第三方；
- 不要在应用中嵌入下载并自动安装其他 apk 的逻辑；动态加载可用但必须做好代码签名和完整性校验；
- 对于渠道发布，保留完整的可追溯签名与发布记录，定期检查自己包在主要渠道的 hash 值；
- 对安全团队：在发布前做静态+动态混合分析，把 assets/lib 里嵌入的二进制列入重点检查项。
六、看到“入口”时的简单核查清单（快速版，1 分钟内）
- 来源：这个入口/网站是谁维护的？有没有企业资质、用户评价？
- 包体：下载前先查看 apk 的 md5/sha256，和官方渠道是否一致；
- 权限：安装前看清权限列表，极端权限（Accessibility、设备管理员、未知来源安装）要格外警惕；
- 运行：安装后用 adb pm list packages -f 检查是否多出包名；用抓包检查是否在后台下载其他二进制。
七、实战教训与经验
- 不要轻信“万能入口”或“聚合安装器”类的便捷承诺，它们的营利逻辑往往是把用户流量变现，可能通过植入第二壳来实现；
- 复盘排查时把“安装行为”看作一个时间线：下载 → 写文件 → 调用安装 → 激活服务。逐步关断某一步能帮你快速定位到底是哪一步出现了问题；
- 最稳妥的做法是用隔离环境做所有可疑包的初期验证，确认无风险后再在主力设备安装。
结语（以及我能做什么） 如果你在渠道审核、渠道合规或移动安全检测上遇到类似问题，我提供的服务包括：
- APK 静态/动态安全审计，定位隐藏壳体与动态加载逻辑；
- 渠道包复盘与签名追踪，帮助还原安装链路与责任方；
- 针对开发者的安全加固建议，避免被恶意渠道或 SDK 利用。
如果需要把具体包交给我做一次快速复盘，或者想要一个能复制我流程的检查脚本，我可以把常用的 adb / apktool /抓包脚本整理成交付品给你。发包名或联系方式我们进一步约时间复盘。不要再盲目搜那些所谓“入口”了——省下的时间和安全成本，值回票价。
