适用提示词： AUDIT_PROMPT_USER_pt-BR.md v2.1（公开、可复现）——未改动
执行日期： 2026 年 10 月 21 日
审计员： DeepSeek v4.1 Flash (1017) — 四线复核（资金、恶意行为、网络、
托管），并对会改变结论的条目逐项人工核查
审计代码： commit 9f69edc — v1.0.21 (code 21)。生成该 APK 的文件树即
本提交；73fe94d 与 19209cf 仅为文档与网站，应用文件树相同
受检二进制文件： 0x2ALL-1.0.21-9f69edc-release.apk，SHA-256
325245a6542212f0227eb7616f9a550bcd0053e5d7c613a66d080c60698bf830，6.677.553 字节，
证书 53dac6cbe7edd6894b9377c4bbdc302a883abbe18a01ad2bd87d0a0fafa142c1
替代： v8.0 版（1.0.20，6814b8b）
范围： 提示词 v2.1 —— §2b 中声明的设计决策不在缺陷认定范围内，
但已逐项核验。
本次是对二进制 1.0.21 的复审。自 v8.0 版（1.0.20，6814b8b）以来的增量有一项
功能性变更和一项文字更正：
security/DeviceIntegrity.kt 在设备本机评估 root 或
bootloader 解锁的信号，每个进程一次，应用在三处作出反应：
每次打开时的阻断式警告（在任何内容界面之前）、安全界面上的“设备完整性”
卡片，以及阻止新托管——创建钱包、导入、on-ramp 与
存款。资金流出（提现、发送、归集、退出、panic 与显示助记词）
仍然放行。app/build.gradle.kts — 版本 1.0.20 → 1.0.21 (code 21)。用通俗的话说，对用户意味着什么。 如果手机有 root 或 bootloader 已解锁， 应用现在会提示，而不是假装一切正常——并且不允许向一台助记词可能被任何拥有 root 权限的应用读取的设备投入新资金。已有资金在那里的用户仍然可以提现、 发送和查看助记词：应用告知并阻止流入，从不阻止流出。
为什么这没有放松任何保护。 该检查是本地的——不上传任何内容、不持久化任何
内容，也不读取任何设备标识符。没有新的端点、权限或资金去向：manifest 的
<queries> 只是让“是否安装了 root 管理器”变得可见。权限（13 项）、主机（12 个）
与 0x 地址（7 个）与 1.0.20 完全相同；manifest 的差异仅限
versionCode/versionName 与新增的 <queries> 块，后者不申请任何权限。
已声明的局限。 检测是启发式的：Magisk DenyList/Shamiko、重打包的 APK 与 hook（Frida）都能绕过。它服务于诚实的用户和首次存款之前的时刻——而不是 攻击者。应用在任何地方都没有声称“无警告 = 安全”，也没有把本地检查的结果 当作任何形式的担保。
复审。 30 个回答已对照新的文件树与新的二进制重新核对。被审计的代码
就是被签名的代码，证据：DEX 中83 个新类，其中领域类为
DeviceIntegrity、DeviceIntegrity$Finding 与 MainActivityKt$DeviceIntegrityGate*（其余
是重新编号的 Compose lambda，66 个对应的旧类被移除）；字符串
androidboot.verifiedbootstate（4 次出现）、androidboot.flash.locked、test-keys、
kernelsu 与 /system/xbin/su 存在于 classes.dex；以及 6 种 locale 各自在
resources.arsc 中新增的 10 个警告/状态键。大小：classes.dex +1.456 字节、
classes3.dex +12.196、resources.arsc +16.972。
| 标准 | 结果 |
|---|---|
| 结论 | 通过 — 0 项未决缺陷 |
| 严重 | 0 |
| 高 | 0 |
| 中 | 0 |
| 低 | 0 |
| 提示性 | 5（分发、域名、记录更正说明与新的 root 检测，§3） |
| # | 问题 | 回答 | 证据 |
|---|---|---|---|
| A1 | 应用是否存在任何路径，在声明的每笔存款 2% 激活费之外从用户处取走资金？（经常性费用、利润分成、订阅、按笔收费、小费、“捐赠”） | 否。 唯一收费是每笔存款的 2%，在入账到交易所之前收取。不存在按利润、按交易、按提现的收费，也无订阅或小费 | PaymentManager.kt:109-111（2%）、:127-138（存款前收费）、:114-121（流程顺序）；搜索 “performance fee/profit share/management fee”：app/src/main 中 0 次出现 |
| A2 | 列出资金的所有可能去向：链上转账、交易所提现、手续费支付。对每一项说明：去向是用户自己的地址、代码中内嵌的已声明固定地址，还是运行时计算出的地址。是否存在依赖网络返回数据的去向？（不要复述地址的字面值 — §1.2。） | 3 个去向。 (i) 手续费 → 代码内嵌的固定托管地址；(ii) 存款 → Hyperliquid 的 Bridge2 合约；(iii) 提现 withdraw3 → 始终是签名者自己的地址。没有任何去向来自网络 |
AppConfiguration.kt:32（不可变常量）、PaymentManager.kt:100-101；WalletManager.kt:92（Bridge2）；HyperliquidAPI.kt:1716（destination = masterCredentials.address）和 :1727 |
| A3 | 同一笔存款是否可能被收取两次费用？（应用重启、机器人恢复、重装、导入同一钱包、两个钱包共用同一 seed、确认前网络失败） | 同一笔存款不会。 具备以 <depósito>:fee 为标识的持久化 journal；未确定状态不会转为回滚，操作以相同标识续做。新存款会再次支付 2% —— 这是已声明的 |
PaymentOperationStore.kt:24-34；PaymentManager.kt:70-76、:198 |
| A4 | 是否存在后门、“开发者模式”、功能开关、远程配置或服务器响应，能够改变某笔操作的去向、金额或收款方？应用是否听从任何来自网络的、关于把钱发往何处的指令？ | 否。 基础 URL 是代码常量；不存在远程配置、功能开关、“dev 模式”，也没有任何能决定去向的 HTTP 响应 | HyperliquidSigner.kt:38（MAINNET_URL 常量）；搜索 remote config/flags：无任何可改变去向的路径 |
| A5 | 应用是否在某个时刻请求代币授权（approve/allowance）？若是，授权额度是多少，能否被第三方花用？ | 否。 不请求任何 approve/allowance。ERC-20 合约仅用于 balanceOf 和构造 USDC 转账 |
ERC20Contract.kt:31；搜索 “approve(/allowance”：0 次出现 |
| A6 | seed 或私钥是否在任何路径下离开设备？（网络、日志、备份、剪贴板、intent、外部文件、通知、截图） | 否。 seed 不通过网络、日志、备份、剪贴板或 intent 外泄；仅在存在性校验（gate）下显示于屏幕 | 搜索 seed 日志：0 次出现；MultiWalletManager.kt:422；MainActivity.kt:68-71（全应用 FLAG_SECURE）；allowBackup=false |
| A7 | 拿到 APK 的人能提取 seed 吗？请考虑：已 root 的设备、adb backup、外部存储、logcat、内存转储、APK 重打包。并与 D2（已声明决策）关联。 |
有 root 时可以 —— 这是已声明决策 DD2：Keystore 密钥是自主的，以便机器人 24 小时运行。adb backup 不行（allowBackup=false）；logcat 不行；APK 重打包可以替换费率常量，因此证书被公开并需核对 |
MultiWalletManager.kt:422；AndroidManifest.xml:55-57；ShareAppHelper.kt:33,42 |
| A8 | 用户是否可能因未明确授权的路径而损失资金？描述最坏的现实情形和最坏的对抗情形。并与 D4（已声明决策）关联。 | 现实情形： 因策略而损失（D4 —— 杠杆 10–50x，仓位 100%）。对抗情形： 设备被攻陷 → seed → 所有钱包；在官方分发之外重新签名的 APK | TradingBot.kt:1257,1282-1285,1338；MainActivity.kt:68-71 |
| # | 问题 | 回答 | 证据 |
|---|---|---|---|
| B1 | 列出所有已声明的权限，并说明每项为何必要。是否存在高风险权限：短信、联系人、通话、定位、无障碍、设备管理员、屏幕叠加、安装软件包、读取外部存储？ | APK 中共 13 项，均为功能性权限。 manifest 中声明 11 项（互联网、网络、生物识别、通知、振动、前台服务、服务数据同步、唤醒锁、电池优化、开机、精确闹钟）+ USE_FINGERPRINT（生物识别 API 的旧别名）+ 一项 AndroidX 用于动态 receiver 的内部签名权限。无高风险权限：无短信、联系人、定位、无障碍、管理员、叠加或安装软件包 |
AndroidManifest.xml:6-31；已用 aapt2 dump badging 在 APK 中核对 |
| B2 | 应用是否在运行期加载代码？（DexClassLoader、PathClassLoader、下载 DEX/JAR、eval、带 JavaScript bridge 的 WebView、插件） |
否。 零 DexClassLoader、PathClassLoader、WebView、eval 或插件；APK 中零原生库（.so） |
在 app/src/main 中搜索：0 次出现；用 find 查 .so：0 |
| B3 | 哪些组件被导出（exported=true）？同一设备上安装的第三方应用能对它们做什么？ |
MainActivity（仅打开应用；不读取 Intent）和 BootReceiver（丢弃 action ≠ BOOT_COMPLETED）。其余组件 exported=false |
AndroidManifest.xml:46-93 |
| B4 | 是否存在任何第三方库进行遥测、分析、广告、崩溃上报或标识符收集？列出所有依赖及其各自通过网络发送的内容。 | 否。 无遥测、分析、广告、崩溃上报或标识符收集 | 搜索 firebase/crashlytics/analytics/sentry：0 次出现 |
| B5 | 应用是否隐藏自身或抗拒卸载？（假图标、从应用列表中消失、阻止卸载、无可见通知运行） | 否。 图标正常，可正常卸载，服务通知始终可见 | AndroidManifest.xml；服务为前台服务 |
| B6 | 应用是否检测 root、模拟器、调试器或设备“指纹”？目的为何，数据发往何处？ | 是，本地检测（1.0.21 新增）。 检测 root/bootloader 解锁以提示用户并阻止新托管。不检测模拟器或调试器，不读取设备标识符，不上传任何内容 | DeviceIntegrity.kt（信号见 §0）；AndroidManifest.xml:31-51 中的 <queries>（无权限） |
| B7 | 应用是否自行更新、安装 APK 或在用户明确同意之外下载代码？ | 否。 不查询版本、不下载 APK、不安装任何内容；更新是在网站手动下载。官方网站的新卡片仅在用户点击时打开用户浏览器 —— 应用不下载 APK 的任何字节 | 搜索 UpdateChecker/UPDATE_CHECK_URL：0 次出现；SecurityScreen.kt:191-226（仅 ACTION_VIEW）；DEX 无原生下载 |
| B8 | 是否存在后台服务，在用户停止机器人、关闭应用或撤销权限后仍继续运行？ | 前台服务仅在机器人活跃时工作，用户停止时即停止；通知为常驻，不停止服务无法移除 | TradingBotService（前台、可见通道） |
| # | 问题 | 回答 | 证据 |
|---|---|---|---|
| C1 | 穷尽列出应用可能联系的域名和 IP。每个去向是否都必要（交易所、网络 RPC、官方网站）？是否存在未声明的域名、分析、第三方 CDN 或采集端点？ | 4 个运行主机： api.hyperliquid.xyz、rpc.hyperliquid.xyz、arb1.arbitrum.io，以及 https://0x2all.xyz（在 1.0.14 中引入，本版未改动），它在 APK 中仅作为文本存在（安全卡片与隐私政策链接，在浏览器中打开），从不是请求目标：点击通过 Intent.ACTION_VIEW 打开浏览器，而非应用自身的连接。另有两个内容主机（Hyperliquid 文档和用户自行发起的 Google 搜索）。无任何分析/采集 CDN 域名 |
对 app/src/main 的 URL 扫描及 DEX 对账：12 个主机，与 1.0.16 完全相同的集合 —— 无新增、无移除；SecurityScreen.kt:39,196；HistoryScreen.kt:149 |
| C2 | 所有流量都是 HTTPS 吗？是否存在 cleartextTrafficPermitted？是否启用证书固定（pinning），且是否覆盖所有接收敏感数据的主机？ |
是，全部 HTTPS。 网络配置中 cleartextTrafficPermitted=false；Hyperliquid 与 Arbitrum RPC 均启用 CA 固定 |
res/xml/network_security_config.xml:3；HyperliquidAPI.kt:460-461；ArbitrumRpc.kt:10 |
| C3 | 每个请求中究竟发送什么（公开地址、签名、订单、应用版本）？是否发送任何设备、用户或安装标识符？ | 公开地址、签名和订单 payload；无设备、用户或安装标识符 | HyperliquidAPI.kt（payload）；搜索 ANDROID_ID/AdvertisingId：0 |
| C4 | 网站服务器是否记录 IP、user-agent 或访问时间？保留什么、保留多久？这在隐私政策中是否声明，且政策与代码比较是否属实？ | 网站仅记录封禁（事件、国家、地区、路由、时间；不含 IP），由 Cloudflare 提供。政策自 v7 起如此声明：第 6 版的说法相反，已在本版更正 —— 与代码矛盾的政策属于缺陷，而非措辞细节 | website/src/worker.js:15-17；privacy.html §4（v7） |
| C5 | 隐私政策是否承诺了代码并未做到的事？（未声明的收集、未声明的保留、未列出的第三方） | 否（v7 更正后重新核对）。 政策与代码在可核验点上一致：数据在设备上、无账号、无分析、封禁日志不含 IP、除 Hyperliquid/Arbitrum/Cloudflare 外无第三方 | privacy.html v7；C1–C4 所引代码 |
| # | 问题 | 回答 | 证据 |
|---|---|---|---|
| D1 | 分发的 APK 是否已签名？证书是什么（SHA-256 指纹），是否与网站上公布的一致，文件的 SHA-256 是否与声明的一致？ | 是。 APK 以 v2+v3 签名，RSA-4096，证书 53dac6cb…42c1 —— 与网站公布的一致；文件 SHA-256 相符 |
apksigner verify --print-certs；sha256sum |
| D2 | 受审源码是否对应分发的 APK？用户如何自行核验？是否存在可复现构建，或至少随报告公布了 APK 与证书的哈希？ | 源码↔APK 的对应关系通过二进制检查（版本、权限、类、主机和合约地址）验证 —— 并非可复现构建，这一点已在局限性中声明 | aapt2 dump badging；DEX 对账 |
| D3 | 应用在分享 APK（P2P 分发）之前或自我更新之前，是否校验自身签名？ | 是。 若证书不是预期值，P2P 分享会中止 | ShareAppHelper.kt:33,42 |
| D4 | 审计报告是否公布了哈希？用户如何确认所读文本即为受审文本、未被事后编辑？ | 是。 每个文件都有公布的 SHA-256 和 OpenTimestamps 时间证明 | audit.json；.ots 文件 |
| # | 问题 | 回答 | 证据 |
|---|---|---|---|
| E1 | 如果用户在交易所有未平仓头寸时卸载应用会怎样？资金是否仍可通过其他途径（seed、交易所网站）取回，还是会丢失？ | 资金仍可通过 seed（其他钱包或导入应用）以及交易所本身取回；重装时活跃头寸从交易所读取 | fills/头寸对账；MultiWalletManager |
| E2 | 如果设备被盗，窃贼能做什么？seed 是否受设备生物识别/凭据保护？屏幕是否防截屏？ | seed 由 Keystore 加密，屏幕防截屏；托管类操作要求存在性验证。root 会暴露 seed（D2）—— 自 1.0.21 起，应用在打开时提示，并在被标记的设备上阻止存款 | MainActivity.kt:68-71；MainActivity.kt:159-181 中的 DeviceIntegrityGate；DashboardScreen.kt:586-696 中的 AppLockManager.requirePresence |
| E3 | 是否存在应用删除仍有余额的钱包，或因余额读取错误而把有资金的钱包视为“空”的路径？ | 删除与退出（offboard）在任何破坏性操作之前，都会在所有层校验余额（链上 USDC、ETH 和交易所余额）；无余额 = 仅可删除的尘埃，且需用户接受 | RageQuitController；跨层校验 |
| E4 | 如果交易所宕机、下单过程中连接中断或响应丢失会怎样？应用是否会重复下单、重复收费或陷入不一致状态？ | 操作具有持久化 journal 和幂等标识；未确定状态不会重复收费或提现 | PaymentOperationStore.kt；HyperliquidOperationStore；PaymentManager.kt:70-76,198 |
| E5 | 如果进程在持仓时被系统杀死，止损在交易所是否仍然有效？应用回来时是否对账？ | 止损存在于交易所，应用被杀死后仍有效；应用回来时对账并重建缺失的止损 | reconcileStopWithExchange（checkPositions，2 分钟周期） |
| ID | 声明 | 已核验？ | 对用户的影响 | 承担的风险 |
|---|---|---|---|---|
| DD1 | 手续费地址未公开 | 是 —— 不可变常量（AppConfiguration.kt:32），无 setter；应用和网站中均无该值（搜索 = 0） |
该去向无法通过公开文本核对 | 去向无法通过阅读验证 |
| DD2 | Keystore 密钥自主 | 是 —— setUserAuthenticationRequired(false)（MultiWalletManager.kt:422），手动操作上有存在性校验 |
机器人可在设备锁屏时运行；手动操作要求存在性验证 | 已 root 的设备会暴露 seed；不是远程攻击向量 |
| DD3 | 利润自动提现（D12） | 是 —— 每事件 22 美元触发（ProfitTracker.kt:46），比例 50%（:52） |
超过触发阈值的已实现利润会部分提现到用户自己的地址 | 依赖自主托管（D2） |
| DD4 | 仓位规模为资产的 100%，杠杆 10–50x | 是 —— 资产以 fail-closed 方式读取（TradingBot.kt:1252-1258），仓位 100%（:1270），资产最大杠杆（:1192-1202） |
大仓位、目标较远；强烈反转时可能全部亏损 | 本金全部或部分损失 |
按照范围，四项均未被判定为缺陷。已核验的是 每一项都按声明实现；若有哪一项不是，那才是缺陷。
0 项未决缺陷（严重、高、中或低）。
提示性说明，无强制措施：
0x2all.xyz 域名已于 2026-10-20
完成注册并上线；隐私政策链接与真实性卡片均指向真实目标，页面
公布了证书指纹与 APK 的 SHA-256。对上一版记录的更正。 v7.0 的第 4 条说明称旧的 T5 代码块已成为
不可达代码，并引用 stillOpen 判断的两份副本。在 1.0.19 树
（0c96c95）与 1.0.20 树（6814b8b）中重新核对：只有一处出现
（TradingBot.kt:2121-2123），上一版即已如此。重复已在 1.0.19 之前
移除，该说明予以撤回 —— 对用户无任何影响。
root 检测是提示，不是保证。 1.0.21 的检查（DeviceIntegrity）是
启发式的，且在设备本机运行：Magisk DenyList/Shamiko、重打包的 APK
或 hook（Frida）都会返回攻击者想要的任何结果。它适用于诚实的用户
和首次存款之前的时刻；不能替代一台专用的、无 root、带屏幕锁的设备。
没有任何数据离开设备，也不读取任何标识符。
version.json）。/audit/prompt-pt.md 或 prompt-en.md），对已签名的 APK 执行：
apksigner verify --print-certs、aapt2 dump badging/xmltree、DEX 反编译
（jadx 或 baksmali），并扫描 DEX 中的主机名与 0x 地址。audit.json 核对。ots verify 校验 .ots 文件中的时间证明。代码库是私有的，也不需要：报告中的 文件:行号 指向所引用提交的源码；只审计 APK 时，核对的是
实际行为与 DEX 中的字符串。
| 项目 | 值 |
|---|---|
| 提交 | 9f69edc（73fe94d 与 19209cf = 文档/网站，应用文件树相同） |
| 版本 | 1.0.21 (code 21) |
| 受检 APK | 0x2ALL-1.0.21-9f69edc-release.apk |
| APK 的 SHA-256 | 325245a6542212f0227eb7616f9a550bcd0053e5d7c613a66d080c60698bf830 |
| 大小 | 6.677.553 字节 |
| 证书（SHA-256） | 53dac6cbe7edd6894b9377c4bbdc302a883abbe18a01ad2bd87d0a0fafa142c1 |
| 签名 | v2 + v3, RSA-4096, CN=0x2ALL |
| 权限 | APK 中 13 项，与 1.0.20 相同（diff 为空） |
| DEX 中的主机 | 12，与 1.0.20 相同的集合（diff 为空） |
DEX 中的 0x… 地址 |
7 个，与 1.0.20 相同（diff 为空） |
| DEX 中的新类 | 共 83 个；领域类：DeviceIntegrity、DeviceIntegrity$Finding、MainActivityKt$DeviceIntegrityGate* —— 其余是重新编号的 Compose lambda（66 个对应的旧类被移除） |
| 执行日期 | 2026-10-21 |