文章总结： 本文揭露了支付宝应用通过多种技术手段进行高精度室内定位和持续位置追踪的行为。作者通过分析代码，发现其构建了包含WiFiRTT、WiFi指纹、iBeacon、GPS等在内的9层定位监控体系，能够实现1-2米的高精度定位，甚至可以追踪用户在不同房间的活动。文章指出，这些远超支付功能所需的定位数据被持续收集并上传，引发了对个人隐私保护的担忧，并质疑其是否违反了最小必要原则。
综合评分： 90
文章分类： 移动安全,应用安全,数据安全,威胁情报,恶意软件
支付宝，你的WiFi正在测距——代码铁证：9层定位体系，你在哪个房间它都知道
原创
风宁
风宁
AI-security-innora
2026年3月21日 09:21
新加坡
⚠️ 预警：前8篇文章已被全部删除
北京格韵律师事务所（代理蚂蚁集团）在6天内完成了全部8篇的投诉删除，援引《中华人民共和国网络安全法》。
本文永久地址（删不掉）：https://innora.ai/zfb/wifi-rtt-tracking.html
GitHub证据仓库：https://github.com/sgInnora/alipay-securityguard-analysis
我想跟那些骂我的人说句心里话。你不看代码、不看文章、不懂技术，拿着几百块就帮支付宝洗地——但你想过没有，你爸妈在家里走的每一步，你老婆孩子的每个动作，都可能被头顶那面“魔镜”精确到厘米，实时上传？我人在海外，支付宝账户已经被冻结了，我也删了APP，以后绝不会再用。15个CVE漏洞、国际论文、7个国际监管机构立案，这些东西我造不出来，也没必要造。不为我自己，为了你的家人，请你理性一点，带点脑子，去看看代码和文章里写的到底是什么。这件事，应该让更多人知道。至少，让你的家人知道，再决定要不要卸载支付宝。
EVIDENCE SUMMARY
165项铁证WiFi定位 60+iBeacon 2套蓝牙 160PatchProxy 146,173DexAOP 1,83415个CVE多国监管立案
引言：律师函之后，我们掘到了更硬的雷
8篇文章，全部删除。北京格韵律师事务所（代理蚂蚁集团）在6天内投诉了我所有关于支付宝安全研究的文章。
这是本系列第2篇技术科普文章。上一篇揭露了1095个APP监控黑名单，这一次，我要揭露的比上次更恐怖。
这一次，证据比上次更硬、更细、更离谱——米级高精度室内定位，全WiFi协议栈劫持，146173个热替换点，连你走进男厕还是女厕都能算出来。支付宝，你们到底在定位什么？定位钞票，还是定位膀胱？
灵魂拷问一：当Apple的”App跟踪透明度”让用户选择，Google的《位置信息记录》可一键清空时，支付宝的”科技向善”，是把9层定位监控焊死在用户的手机里？
01 科普：WiFi RTT——把WiFi当声纳玩
WiFi RTT（Round-Trip-Time）是IEEE 802.11mc标准里的”光速声纳”：
- 手机发一个”Hello”帧到AP，AP回一个”ACK”；
- 手机用纳秒级时间戳测往返耗时，乘以光速再除以2，得到直线距离；
- 三个AP就能三角定位，室内1–2米精度，GPS在室内直接抓瞎，WiFi指纹法只能做到3–5米。
本来这技术是留给仓库机器人、AGV小车的，让它们别撞货架。结果支付宝把它塞进了支付APP。
灵魂拷问：一个用来扫码付钱的工具，需要知道你在收银台左侧1米还是右侧2米？
答：代码显示，推送注册时PushLBSHelper会将所有WiFi AP的BSSID和信号强度绑定userId上报（pushInit.lbsInfo = b，RegisterTask.java:97）。至于这些数据被用于什么目的，支付宝隐私政策未明确说明。
灵魂拷问二：为什么一家金融科技公司，对室内米级精确定位的渴望，超过了所有地图和导航APP的总和？
02 代码证据：每一行都在说”我就是追踪你”
以下片段全部来自证据仓库，文件名+行号原汁原味，欢迎复现。
① RTT测距入口被劫持
InterferePointInitHelper.java:1129 (GitHub: evidence/wifi_rtt/InterferePointInitHelper_wifi_lines.txt)
hashMap.put(DexAOPPoints.INVOKE_android_net_wifi_rtt_WifiRttManager_startRanging_proxy, new DefaultInterferePointProperty( …, // 权限三件套：ACCESS_FINE_LOCATION + ACCESS_WIFI_STATE + CHANGE_WIFI_STATE “位置获取|WiFi控制”, // 中文注释，官方自曝 PointCategory.ACCESS));
翻译：只要App里任何代码想调 WifiRttManager.startRanging()，就会被支付宝的DexAOP框架截胡，先过它的”代理闸机”，再决定给不给真系统。
② 代理方法实现
DexAOPEntry2.java:3056-3068 (GitHub: evidence/wifi_rtt/DexAOPEntry2_wifi_rtt_method.java)
public static final void android_net_wifi_rtt_WifiRttManager_startRanging_proxy(…) { … DexAOPCenter.processInvoke(…); // 先记录，再放行 }
翻译：调用被透明代理，用户毫无感知，系统回调原封不动，但支付宝已经抄了一份RangingResult——里面包含每个AP的MAC、距离、时戳。
③ 推送注册=WiFi大扫除
PushLBSHelper.java (GitHub: evidence/wifi_rtt/PushLBSHelper.java)
for (ScanResult sr : wifiManager.getScanResults()) { PushLBSWifiInfo info = new PushLBSWifiInfo(); info.BSSID = sr.BSSID; // MAC地址 info.level = sr.level; // 信号强度 list.add(info); // → 随push注册包一起上传，绑定userId }
翻译：你刚装好支付宝，第一次打开甚至还没登录，它就把周围所有WiFi AP的MAC+信号扫了个遍，连你楼下沙县小吃的路由器都不放过，绑定userId直接上传。
④ 登录三连，WiFi MAC必上报
SafeZoneInfo结构 (GitHub: evidence/wifi_rtt/SafeZoneInfo.java)
MiniShellLoginHelper.java:343FaceGuideHandler.java:180CdpRequestManager.java:336
统一姿势：
xxxRequestPB.wifiMac = NetWorkInfo.getInstance(…).getBssid();
翻译：无论扫码登录、刷脸登录、营销弹窗，每一次登录都带BSSID。服务器端轻松把WiFi MAC ↔ 账号 ↔ 手机硬件ID三联画挂墙上。
⑤ 网络请求默认带BSSID
anet/channel/statist/RequestStatistic.java:268
this.bssid = NetworkStatusHelper.getWifiBSSID(); // 每次HTTP请求都塞header
翻译：你后面每点一次”查看账单”，BSSID被嵌入请求统计字段，随网络请求一起上报。服务器实时掌握你连接的WiFi接入点位置。
灵魂拷问三：如果连一次普通的HTTP请求都要夹带地理位置”私货”，支付宝到底在怕什么？怕用户失踪，还是怕广告投放不够”精准”？
03 监控矩阵扩容：WiFi全家桶与iBeacon双保险
除了核心的WiFi RTT，证据显示支付宝构建了无死角的感知网络：
WiFi Aware (邻居感知) – 4个拦截点
这项技术允许设备在不连接互联网、甚至关闭GPS的情况下，直接发现并通信。支付宝劫持了相关API，用于探测周围同样安装了支付宝的手机。即便你在飞行模式，只要WiFi开着，它就能知道”附近有谁”。
WiFi P2P (直连) – 28个拦截点
常用于连接打印机或投影仪。支付宝的28个拦截点确保了任何P2P扫描、组网请求都会被捕获并上报。你连过的每一台打印机，都成了支付宝定位你的信标。
iBeacon – 两套完整实现
一套基于系统API，一套是自研的轮询服务。这意味着无论是在商场、机场还是博物馆，只要部署了iBeacon信标，支付宝就能以1-3米精度绘制你的移动轨迹。两套实现互为备份，确保”一个挂了，另一个立刻顶上”。
灵魂拷问四：当一项支付工具，对WiFi P2P、蓝牙信标、邻居感知的兴趣远超支付本身时，它究竟是个钱包，还是个全天候、全频谱的移动间谍终端？
04 完整监控矩阵：9层地狱，层层叠buff
| 层级 | 技术 | 拦截点 | 精度 | 备注 |
| — | — | — | — | — |
| L1 | WiFi RTT | 1 | 1–2 m | 需要Android 9+，硬件支持 |
| L2 | WiFi指纹 | 27+ | 3–5 m | 扫光所有BSSID+RSS |
| L3 | WiFi Aware | 4 | Peer-to-peer | GPS关闭时仍可工作 ，发现附近手机 |
| L4 | WiFi P2P | 28 | Peer-to-peer | 连打印机都不放过 |
| L5 | iBeacon | 2套实现 | 1–3 m | 商场里布100个Beacon就能画轨迹 |
| L6 | 室内定位(IndoorLocationService) | 全方法PatchProxy | 融合精度 | 可远程热补丁 |
| L7 | 地理围栏(Geofence) | — | 30–50 m | 进出事件实时推 |
| L8 | GPS | 46 | 5–10 m | 室外补盲 |
| L9 | 基站+蓝牙 | 169+160 | 50–100 m | 后台持续扫描 |
SafeZoneInfo结构（见证据第7节）把L1–L9全部加密落盘：fineLocation/wifiInfo/cellInfo/crossLocation 各带独立key，服务器想解就解，想扔机器学习就扔。
PatchProxy热替换 146173个挂载点，包括上述所有定位方法。今天发版说”只扫WiFi”，明天热补丁就能静默打开RTT，用户端版本号都不变，应用商店审核形同虚设。
灵魂拷问五：146173个热替换点，9层定位监控——这是为了”提供更好服务”，还是为了构建一个连国家级情报机构都叹为观止的、针对亿万公民的实时态势感知系统？
05 法律分析：最小必要？最大嘲讽！
《个人信息保护法》第6条——最小必要原则：
“处理个人信息应当限于实现处理目的的最小范围，不得过度收集。”
支付场景目的：完成收付款。
以1-2米精度为例，支付宝理论上可获取：
- 你在男厕隔间1还是女厕隔间2；
- 你左手边3米有瑞幸，右手边2.8米有星巴克；
- 你手机周围一共34个AP，其中5个5G，信号最强-41 dBm；
- 你上一次出现在500米外是16:42:33，误差±1.2米。
法律对照：支付需要知道你在哪个商场即可，精确到隔间纯属业务溢出。
嘲讽翻译：”支付宝，你到底是支付工具，还是室内版天网？下次要不要把蹲坑时长也做成信用分？按时冲水+5芝麻分？”
对比Apple：明确区分”精确位置”与”大致位置”，权限可控可追溯。
对比Google：提供位置历史记录仪表盘，可一键暂停或删除。
对比蚂蚁”科技向善”：9层监控，热补丁静默开启，善在何处？善在让你无处可藏吗？
回应可能的质疑
Q: “WiFi RTT精度是1-2米，不是厘米级，标题夸大了吧？”
WiFi RTT单项精度确实是1-2米。但重点是：支付宝不是只用RTT一项技术。代码中注册了9层定位体系：RTT + iBeacon（1-3米）+ WiFi指纹 + 蓝牙（160个拦截点）+ 基站（169个拦截点）。学术研究表明，多传感器融合（如卡尔曼滤波）可将定位精度提升至亚米级（0.3-1米）。更关键的是：问题不在于当前精度是1米还是10厘米，而在于一个支付APP为什么要注册WifiRttManager.startRanging()的拦截——这个API的设计目的就是高精度室内测距。
Q: “支付宝可以辩称这是用于LBS服务/防欺诈/优惠券推送”
法律问题不在于能否辩称，而在于是否告知用户。支付宝隐私政策未将WiFi RTT作为独立的数据处理活动披露。即便用于防欺诈，也必须遵循最小必要原则：防欺诈是事件驱动的（交易发生时），而非在每一个HTTP请求中持续携带BSSID（RequestStatistic.java:268）。449个位置API拦截，远超任何合理的防欺诈需求。
Q: “WiFi RTT需要兼容AP，不是所有地方都能用”
正确。但这不是重点。重点是：代码中已注册了这个能力，且通过146,173个PatchProxy热替换点可随时远程启用。这是一个“休眠监控能力”——今天可能未激活，明天通过热补丁就能全面开启，用户端版本号不变，应用商店无法审核。而且：即使不用RTT，仅凭WiFi指纹扫描（PushLBSHelper扫描所有BSSID + 每次登录上报MAC + 每个请求携带BSSID），已经足够实现3-5米精度的持续位置追踪。
Q: “这些功能可能是第三方SDK带来的，不是支付宝主动开发的”
DexAOP框架和PatchProxy都是蚂蚁集团自研的核心基础设施，不是第三方SDK。WiFi RTT拦截注册在InterferePointInitHelper.java中，属于com.alipay.fusion.interferepoint包——这是支付宝内部代码，不是外部依赖。
结语
本文所有证据已公开可查：
-
GitHub证据仓库
：https://github.com/sgInnora/alipay-securityguard-analysis
-
本文WiFi RTT证据目录
：https://github.com/sgInnora/alipay-securityguard-analysis/tree/main/evidence/wifi_rtt
-
IACR密码学论文
：https://eprint.iacr.org/2026/526（已收录）
-
本文永久地址
：https://innora.ai/zfb/wifi-rtt-tracking.html
-
15个CVE已提交MITRE
（Ticket #2005801, #2010319, 第3批待确认）
本文核心发现已同步提交以下监管机构：
- CNPD 卢森堡（GDPR数据保护）
- CSSF 卢森堡（金融监管，案件号 CSSFWB-2026-XXX）
- PDPC 新加坡（个人数据保护，案件号 006XXXXX）
- HKMA 香港（金融管理局，案件号 CE20260313XXXXXX）
- CIRCL 卢森堡（网络安全应急，案件号 #478XXXX）
- AMCM 澳门（金融管理局，案件号 DSB2603XX-X）
- MITRE（CVE漏洞数据库）
8篇文章被删，但代码里写着的东西，删不掉。
The Nora Chronicles Vol.22 | Innora.ai Lab | Penang, Malaysia | 2026-03-21
本文所有技术主张均附有可独立验证的证据来源。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：AI-security-innora 风宁
风宁《支付宝，你的WiFi正在测距——代码铁证：9层定位体系，你在哪个房间它都知道》