iolaSay

我分析了 11 万局王者对局，发现一些有趣的事情

Tue, 28 Jul 2026 14:30:00 GMT

声明：本文只记录个人设备和本人账号上的分析过程，包含 AI 辅助创作，可能会带来一定的不适感，谨慎阅读。

2019 年，我写过《抓取、分析王者荣耀高分段战绩》和《王者荣耀数据分析 1》。那次靠王者营地跑了两个月，拿到 6.5 万局和 34.6 万名玩家。

七年后，我把数据入口换到了游戏客户端。上一篇《从抓包到改字段》里，我在游戏进程中拦截收发消息，把对局结算和玩家档案读成 JSON，再让客户端查询玩家近期战绩。

每次查询最多返回最近 50 局，每局还能带出九名同局玩家。陌生玩家会进入待查队列，查询沿着同局关系继续展开。

截至 2026 年 7 月 29 日，库里共有 600,987 名玩家、118,781 局对局和 1,176,669 条参战记录，其中 6,521 名玩家有档案，共留下 6,553 份档案快照。对局覆盖一千多个大区。

先说几条最值得看的结果。

游戏的真实响应里确实有官方 AI 标记。它们带正常 uid、大区、昵称和段位，外观上足以伪装成真人。
排位中有 1,842 局出现一整队五名伪人，它们的胜率只有 4.45%。有一名玩家在 48 局里遇到 23 次这种对手，拿走 22 胜。
完整五排比五个散人平均早 1 分 32 秒结束。
游戏响应还带有普通界面看不到的 MMR 和 ELO。它们与累计星数的相关系数接近 1，渠道、手机系统和大区之间也能看到清楚的差异。

声明：本文只分析个人设备和个人账号可以查询到的数据，不发布采集代码。查询从高星玩家附近开始，样本无法当作全服统计。

先来个劲爆的。

游戏里确实有伪人

《王者荣耀》玩家很早就在怀疑，排位会安排人机伪装成真人。过去的讨论常靠昵称、头像、英雄选择和走位猜测，很难确认。

这次我从客户端收到的真实响应里读到了 bIsAI。部分参战者的 world 大于 0，有正常 uid、大区、昵称和段位，bIsAI 却带着非零值。本文把这类身份叫作「伪人」；world=0 或对局带 bPkAI 的记录归为简单人机。

当前库里有 17,857 条伪人参战记录，涉及 17,674 个 (uid, world) 身份。除 bIsAI 外，英雄熟练度也能把两组记录清楚分开：17,851 条伪人记录为非零，普通玩家记录全部为 0。

排位、巅峰赛和匹配都有

十人记录完整时，三个主要模式的统计如下：

模式	完整对局	有伪人的对局	出现率	每边一个	一方五个	五人伪人队胜率
排位	74,715	4,693	6.28%	2,830	1,842	4.45%
巅峰赛	33,193	524	1.58%	521	3	0%
匹配	4,815	254	5.28%	180	71	0%

巅峰赛里也有 524 局，出现率 1.58%。其中 521 局是双方各一个伪人，另有 3 局是一方完整五人伪人队，三局全输。

排位里的两种主要安排是双方各一个，以及一方出现完整五人队。细分到每局双方人数，1+1 有 2,830 局，0+5 有 1,535 局，1+5 有 292 局，2+2 有 21 局。

伪人出现率随分段快速下降。按每局真人的平均累计星数每五颗一档，低分档最高达到约 50% 至 71%；王者门口约 13%，110 至 114 累计星为 5.17%，135 至 149 累计星降到约 0.9% 至 1.03%。

五人伪人队胜率只有 4.45%

排位里一方完整五人伪人的 1,842 局，伪人队只赢 82 局，胜率 4.45%，对手一侧胜率 95.55%。其中 1,535 局的对手是纯真人，292 局带一个伪人，11 局带两个，1 局带三个，3 局带四个。

伪人队赢下的 82 局里，71 局对手是纯真人，11 局对手带一个伪人。五个伪人都打不过的纯真人队有 71 支，福利局送到脸上还能输，这次很难怪匹配。

再看真人对手上一条已采集记录。完整五人伪人队的对面共有 7,067 名不同玩家，其中 1,077 人能找到更早的记录，上一条记录的败率为 79.44%。

按开局月份和累计星数每五颗一档寻找普通排位对照后，留下 1,065 名可比玩家：

上一条已采集记录	五人伪人局对手	同月同分段普通排位
败率	79.44%	34.98%
平均评分	7.718	8.494
平均 KDA	3.055	5.383

把窗口拉到十条已采集排位，离目标局越近，输局越集中。最近三条整体胜率为 38.52%，最近十条为 51.56%。

战绩接口最多返回最近 50 局，两条已采集记录之间仍可能夹着遗漏对局。近期输局与五人伪人局经常一起出现。

有人 48 局遇到 23 次五人伪人队

玩家「我是给※」的档案排位胜率为 51.0%。我采到他的 48 局 PVP，对面有完整五人伪人队的共有 23 局，他赢了 22 局；另有 5 局带部分伪人，赢了 4 局；剩余 20 局纯真人对局只赢 11 局。48 局合计 37 胜，胜率 77.1%。

主播磊哥分享过一套利用匹配机制的经验：在游戏里梦游，待在塔下挂机清线，尽量少击杀、少拿高评分和 MVP。他把这叫「避免沾染因果」。相关视频包括《高阶鸡爪流教学，随便沾染因果也不涨评分》和《谁暴露了自己的实力，谁就会变成牢玩家》。

这 23 场带来 22 胜，占他全部 37 个胜场的 59.5%。全库按上一局胜负分层后，五人伪人局与普通排位的低评分、零击杀比例接近；上一条记录告负与五人伪人局同时出现得更频繁。

同一身份键同时以真人和伪人出现

17,674 个带 AI 标记的身份里，198 个也出现过普通玩家记录，87 个只以伪人身份重复出现。

30 个身份留下 32 条「普通昵称、伪人昵称、恢复普通昵称」记录，跨度都在 15 天内；其中 9 个身份的伪人记录还与普通玩家对局发生时间重叠。相同的 (uid, world) 可以使用两个名字，同时参加两场正在进行的对局。

这里甚至能查到一部分伪人开放的历史战绩。这种现象很容易让人怀疑真人账号被拿去填充；目前只能确认身份键复用和 9 组时间重叠，uid 生成机制仍未知。

五人伪人局在同段位下仍然结束得很快

我之前直接拿三类排位的总体分布做比较，这里混入了段位构成的影响：高星局的伪人出现率低，而高星局本来就打得更短。8 月 4 日，我用扩充后的样本重算了一次。每局先取真人的平均累计星数，按五颗星分档；纯真人分桶至少有 20 局才进入对照，再按两类伪人局各自的星数构成给真人样本加权。

排位类型	进入同星对照	本组平均	对照平均	本组中位数	对照中位数	10 分钟内（本组 / 对照）
一方五个伪人	4,761 / 4,807	12:44	15:46	12:05	15:16	14.95% / 4.58%
每边一个伪人	3,391 / 3,422	16:21	16:08	15:51	15:42	2.86% / 3.83%

完整五人队的平均时长仍然短 3:02，95% 区间为短 2:56 至 3:08；中位数短 3:11。校正段位构成后，差距还比总体对照更大。每边一个伪人的平均时长只多 13 秒，中位数多 9 秒，10 分钟内占比还略低于同星真人局。这组的时长分布基本贴着同星真人基线，短局特征集中在完整五人伪人队。

一天内没有固定的伪人时段。按场次数看，完整五人队在 22 点占比最高，为 8.96%；双方各一个在 21 点最高，为 9.75%。按该小时全部排位计算，19 点的两类出现率最高，分别为 3.36% 和 5.72%。

自然日走势里，完整五人队在 7 月 26 日最多，共 270 局；双方各一个在 7 月 25 日最多，共 368 局。出现率峰值都在 7 月 20 日，分别为 4.07% 和 9.65%。

自然日曲线受每日样本分段变化影响，目前看不出固定周期。

单个伪人有一半去打野

双方各一个伪人的记录中，49.43% 出现在打野位；对抗路占 27.42%，游走 13.59%，发育路 7.47%，中路只有 2.08%。同批普通玩家的五路分布都接近两成。

完整五人伪人队的 1,842 支队伍中，1,840 支五路齐全，所有队伍都选择了五个不同英雄。1,842 套阵容里有 1,828 套互不重复。

单个伪人的英雄选择很集中，前十名合计占 43.96%，普通真人只有 19.60%。打野前三是铠、典韦和宫本武藏；对抗路的项羽占 15.01%，普通真人只有 4.10%。

完整五人伪人队用过 99 名英雄，前十合计占 27.46%。对抗路最常见吕布，中路安琪拉，发育路马可波罗，打野铠，游走刘禅。马可波罗在这组发育路里占 16.58%，同分路普通真人只有 4.92%。

说完最抓眼的伪人，再回到这 11 万局本身。

再看这 11 万局

页面里的段位统一换算成累计星数，从青铜开始累加每一小段所需星数，王者门口是 92 星，之后继续加王者星数。

这张分布图主要说明采样范围。查询从高星玩家开始，队列也优先寻找相近星数，所以高星玩家很多。7 月 20 日的样本平均累计星数为 134.09，中位数 129；到 7 月 29 日，均值升到 171.09，中位数 190。后文的段位和英雄数字只描述这批偏高星样本。

先收紧到 70,022 局完整真人排位：双方各有五条记录、十人都是正常大区、整局没有简单人机或伪人，时长至少五分钟。

这些对局平均打 14:56，中位数 14:17。13 分钟档最多，共 8,770 局；不到 10 分钟的占 6.05%，20 分钟以上占 11.00%。

分段越高，对局整体越短

8 月 4 日，我用扩充后的样本补算了一次分段与时长。这里只看完整真人 5v5、时长至少五分钟的对局：排位按每局十人的当局累计星数取平均，每五颗一档；巅峰赛用结算分数和本局增减还原十人的开局前积分，再取平均，每 50 分一档。统计单位是对局，每局只记一次。

排位共有 93,782 局，46 个分桶中有 38 个达到每档 100 局的门槛。45 至 49 累计星的平均时长为 16:34，220 至 224 星为 14:07，稳定分桶的最大差距是 2 分 27 秒。把 38 个稳定分桶做简单线性拟合，每增加五颗星，平均时长约缩短 3.7 秒。曲线中段有一段回升：160 至 164 星为 14:11，195 至 199 星升到 14:54，随后再次下降。

巅峰赛共有 77,781 局，25 个分桶中有 19 个达到门槛。1500 至 1549 分的平均时长为 15:16，2250 至 2299 分为 13:22，相差 1 分 54 秒；线性趋势约为每增加 50 分缩短 5.8 秒。2300 分以上又回到 13:36 至 13:37。两个模式的整体方向一致，局部都能看到反复。当前数据无法区分操作水平、阵容选择、投降和采样路径各自带来的影响。

开局时间集中在晚间。22 点有 9,520 局，21 点有 9,379 局；早上 6 点和 7 点最低，分别为 1,352 和 1,354 局。凌晨 4 至 6 点的样本平均累计星数为 174.9 至 178.9，19 至 22 点落在 136.6 至 138.8。采样范围里，凌晨还在玩的玩家平均星数明显更高。

这 70,022 局里，胜方平均死亡 2.94 次，败方为 4.77 次。基础战斗数据里，胜负最明显的区别就是少死。

下面的英雄榜切回全部已采模式。瑶有 23,739 次出场，百里守约 23,671 次，后羿 23,266 次。只看至少出场 800 次的英雄，胜率前三是盾山 56.63%、雅典娜 56.00% 和沈梦溪 55.97%；末三位是明世隐 45.39%、吕布 46.56% 和露娜 46.65%。

这些英雄胜率只是当前高星采样路径下的快照。它适合观察这批对局，拿去当全服英雄强度表会失真。

越高端的局，瑶的胜率越高

把瑶单独拿出来，排位和巅峰赛的完整真人 5v5 共有 20,464 场，综合胜率 51.85%；排位胜率 52.4%，巅峰赛胜率 47.1%。再按瑶玩家本人当局结算的累计星数每五颗分一档，195 星以前的胜率大多在 50% 附近，195 星以后进入明显的上升段。230 星以上超过 70%，最后一档接近 90%。每档至少有 20 场才进入曲线。

为什么呢好难猜啊🤪……（高分段还在玩瑶的很可能是为了国标请演员的富婆，在 B 站搜索「富婆瑶妹」等关键词了解）

再把 7 月 1 日至 8 月 3 日的完整真人排位按胜负拆开，200 星以上的瑶胜局结束得更快：

瑶玩家累计星数	对局	胜 / 负	胜率	胜局平均时长	败局平均时长	胜局比败局短
200 至 224 星	3,736	2,127 / 1,609	56.93%	13:58	14:41	0:44
225 至 249 星	421	300 / 121	71.26%	13:24	14:59	1:35

高星段同时出现了胜率上升和胜局缩短。到了 225 至 249 星，平均差距已经超过一分半，除了请演员无法解释。

朵莉亚也有同样的演员问题

朵莉亚的曲线也在高星段突然上扬。排位完整真人 5v5 中，175 至 199 星的胜率为 46.51%，200 至 224 星为 49.94%，225 至 249 星升到 65.66%，最后一段共有 265 场。按连续星数拟合，每增加十颗星，胜率约增加 1.48 个百分点，BH 校正后的 q = 0.0196。

六七分钟结束的瑶和朵莉亚胜局

继续筛选 7 月 1 日至 8 月 3 日的完整真人排位，只保留瑶或朵莉亚获胜、时长在 6:00 至 7:59 的对局（六分概念神，资本发力了）：

英雄	6:00 至 6:59	7:00 至 7:59	合计	使用者 ≥175 星	使用者 ≥200 星	十人平均 ≥175 星	十人平均 ≥200 星
瑶	110	113	223	142	70	89	22
朵莉亚	87	75	162	98	36	86	24

两名英雄没有在同一胜方一起出现，因此 385 次英雄胜场对应 385 局。按使用者本人 ≥175 星计算，短胜局占瑶该分段全部胜局的 2.12%，朵莉亚为 1.79%；按十人平均 ≥175 星计算，比例分别为 1.43% 和 1.60%。十人平均达到 200 星后仍有 46 场。

露娜的高分段胜率也在涨

露娜在巅峰赛里的趋势也很明显。这里把分桶放大到每 100 分一档：2000 至 2099 分的胜率为 50.97%，2100 至 2199 分为 49.69%，2200 至 2299 分升到 53.19%，2300 至 2399 分达到 59.88%。最后一档有 334 场。按连续积分拟合，每增加 100 分，胜率约增加 3.44 个百分点，BH 校正后的 q = 0.0454。

这条曲线大概来自玩家熟练度。露娜对操作和进场时机的要求很高，高分段还敢选露娜的一般都是绝活哥了。把对局时长按同样分段拆开后，露娜没有出现瑶和朵莉亚那种高分段异常缩短的区间，2300 至 2399 分的平均时长回到 14:00。

正式服里有人用上了五个未公布英雄

英雄出场榜里还出现了五个官方尚未公布、当前只显示 ID 的英雄：#547、#631、#640、#646 和 #635。它们分别出场 3、7、14、16 和 19 次，合计 59 次，涉及 56 个玩家身份和 50 局对局。

这些记录来自 1xxx 至 4xxx 的正式大区。使用者自身都没有 AI 标记，59 次出场中还有 28 次发生在整局没有 AI 标记的对局里。正式服确实已经有人玩到了这五个英雄，客户端目前还没有显示它们的名字。

先看一些榜单

6,521 名有档案的玩家里，2,626 人玩了九年以上，3,288 人打过一万场，207 人超过三万场。总场次最高的玩家打了 58,959 场。

单局榜单只看排位、时长至少五分钟、目标玩家为真人的记录。

纪录	玩家与英雄	数值	结果
对英雄伤害	明日寻飞鸟ν / 甄姬	795,681	29:36，胜
承伤	卡纳德·白星 / 海诺	618,878	26:53，负
治疗	瞅你咋地8855 / 程咬金	519,015	25:13，负
控制	众生苦我独鲜 / 墨子	197.5 秒	29:14，负
击杀	✿҉͜恋戰᭄ / 鲁班七号	31	25:13，胜
助攻	渣渣o瑶 / 元流之子（辅助）	49	30:25，胜
经济	春眠不橘晓 / 诸葛亮	31,601	35:14，负
死亡	゛小趴菜・ / 兰陵王	18	26:42，负
推塔	杨砚辞、凝冬 / 后羿	9 座	12:58，胜
补兵	落幕$忧伤 / 姜子牙	148	31:39，胜

31 杀那局只打了 25:13。伤害榜第一的甄姬在 29:36 里打出 795,681 英雄伤害；控制榜第一的墨子让对手累计失去操作 197.5 秒。推塔纪录只用了 12:58，经济纪录打到 31,601 仍然输了。

五排、段位、平台和分区

结算记录带有每名玩家排队时的组队人数和组队编号，可以直接识别完整五排、混编队和五个散人。

完整五排每个人头平均带 2.03 个助攻，混编队是 1.88，五个散人是 1.77。五排全队平均击杀 17.14，五个散人是 22.61；平均死亡分别为 17.06 和 22.45。

时长差异更大。

对局构成	对局数	平均时长	中位数	12 分钟内	20 分钟以上
完整五排	12,358	14:14	13:35	29.74%	8.93%
混编	43,331	14:51	14:14	21.92%	10.36%
五个散人	14,333	15:46	15:13	13.40%	14.71%

完整五排的平均时长比五个散人短 1 分 32 秒，中位数短 1 分 38 秒。12 分钟内结束的比例高了一倍多，人头数还少约四分之一。

哪些英雄在五排里变化最大

旧文章曾拿鬼谷子做过一次五排和单排的卡方检验，当时五排样本只有 499 局，结果无法支持「鬼谷子更依赖配合」。

这次只比较完整五排和五个散人，并按开局月份、队伍平均累计星数每五颗一档分层。两组分别有 24,716 和 28,666 支队伍，106 名英雄达到两组各 200 场的门槛，再对全部英雄做 BH 多重检验校正。

校正后有 10 名英雄达到显著水平。公孙离的五排胜率高 22.42 个百分点，戈娅高 20.07 个百分点，沈梦溪高 18.06 个百分点，瑶高 7.67 个百分点。另一端，黄忠低 19.75 个百分点，程咬金低 20.86 个百分点。

鬼谷子的五排复核仍然没有显著差异：五排 138 胜 / 317 场，五个散人 95 胜 / 174 场；分层差异为 -4.49 个百分点，95% 置信区间跨过 0，p = 0.644。当前达到显著水平的 10 名英雄已经列在图中。

累计星数与死亡、KDA

把排位按累计星数每五颗一档后，死亡和 KDA 都有波动。

再把玩家分成三组，并按实际对局时长归一到每 10 分钟：累计星数不高于 108 的玩家死亡 2.76 次，109 至 127 星是 2.42 次，128 星以上是 2.52 次；三组击杀加助攻分别为 7.61、7.44 和 7.42。中间一组死亡最低，最高一组回升到 2.52 次。图里画的是每五颗星一档的每局平均死亡和平均 KDA，两种口径的趋势都有波动。

苹果样本段位更高，微信区对局更久

区服号段可以分成手Q安卓、手Q苹果、微信安卓和微信苹果。档案响应里还有 MMR 和 ELO，这两个数字不会显示在普通玩家界面。

渠道与系统	玩家	平均累计星数	ELO	排位胜率
手Q安卓	2,170	175.9	3,339	55.06%
手Q苹果	745	195.3	3,547	57.08%
微信安卓	2,229	153.1	3,103	54.10%
微信苹果	1,347	176.5	3,350	54.89%

同一渠道里，苹果样本的平均累计星数和 ELO 都更高。手Q苹果比手Q安卓高 19.4 个累计星数和 208 ELO；微信苹果比微信安卓高 23.4 个累计星数和 247 ELO。

对局时长还有另一条稳定趋势：手Q安卓平均 14:21，手Q苹果 14:17，微信安卓 14:53，微信苹果 14:47。同一手机系统下，微信样本都比手Q多打约半分钟。

「微信区玩家年纪更大，所以动作慢」可以当作一个有趣猜想。当前能确认的只有渠道时长差异，档案里没有年龄字段。

MMR、ELO 与累计星数几乎同步

相关性矩阵把玩家档案、实战数据、每场被赞和 MVP 比例放到了一张图里。

累计星数、MMR 和 ELO 的相关系数为 0.991 至 0.997。累计 MVP 与总场次的相关系数达到 0.86，累计指标明显受场次影响。横向比较玩家时，场均被赞和 MVP 率更有参考价值；它们与排位胜率的相关系数分别为 0.47 和 0.40。

隐藏战绩后还能继续找

指定玩家关闭战绩以后，他仍可能出现在同局其他人的公开历史中。继续查询这些同局玩家，还能找到更多相关对局。这个方法在顶尖对局尤其有效，因为高分段玩家会反复遇到。

查询结果也能直接生成开黑关系图。严格口径只连接同一阵营、组队人数大于 1、组队编号相同的玩家。当前图谱有 172,103 个玩家节点和 239,372 条开黑关系。下面这个例子向外展开两层，一屏里有 53 人和 143 条关系，中心玩家直接连着 15 名开黑伙伴。

战绩还保留每局当时的昵称，所以能看到玩家改名。

最后

这 11 万局串起了几件平时很难放在一起看的事：英雄和玩家的极端纪录、五排与散人的节奏差异、不同平台和大区的表现、界面里看不到的 MMR 与 ELO，还有伪人在排位和巅峰赛里的分布。

七年前那篇文章主要依赖王者营地公开的战绩。这一次，客户端响应里的组队结构、隐藏分和 AI 标记也进了同一套分析。样本沿高星玩家向外扩散，结论都限定在这 11 万局里；至少下次再聊五排、区服差异、隐藏分和伪人，手里已经有图和数字可以对照。

王者荣耀消息协议的一些研究

Sun, 26 Jul 2026 15:40:00 GMT

声明：本文只记录个人设备和本人账号上的分析过程，包含 AI 辅助创作，可能会带来一定的不适感，谨慎阅读。

起因很简单。登录页列着一千多个大区，我想确认这些名字来自实时响应还是本地缓存，再改一个看看。区服流量很快就抓到了，后面的工作主要花在进程内改写和协议对象解析上。

设备是一台 root 真机，HyperOS 3 / Android 16 / arm64，装了 KernelSU 和 Zygisk Next。游戏版本是国服 11.4.1.1，SO 构建日期为 2026-06-14。文中的函数地址都是这个版本的 RVA，具体数值记录在项目文档中。

现在能做什么

游戏进程里常驻一个 Zygisk 原生模块，分别拦截收包和发包。消息对象会通过 IL2CPP 反射转成 JSON，发送到主机上的工作台。规则在网页中配置，可以按字段路径改写消息，也可以构造一条本地消息交给客户端处理。

先看两个已经在屏幕上确认的例子。第一个是区服名，只改手Q1区：

第二个是大厅左上角的昵称。游戏内改名入口最多填写 6 个中文字，下面这张图显示了 8 个，后面的内容被控件截断：

规则只有一行，把登录响应 SCID_CMD_GAMELOGINRSP 里的 szName 换掉。实际塞进去的是 26 个中文字、78 字节，而 TDR schema 给这个字段的定长是 64 字节：

I WzryZg: [route] r msgid=1003 szName : System.Byte[] OK -> 新 Byte[78](任意长)

这里修改的是 unpack 完成后的对象，发生在游戏逻辑读取之前。客户端改名界面的 6 字限制没有参与，收包对象也接受了超过 schema 定长的数组。

区服表是明文，改写放到进程内

tcpdump 直接抓到了明文区服流量，区服名和 LogicWorldID 都在响应里。帧结构也很简单：55 00 00 00 后面是一个字节的长度，再跟 UTF-8 名字。

顺着这份明文把整张表解了出来，1075 条，每条是 <平台><编号>区<诗意名> 加上 LogicWorldID 和一组 relay 地址。手Q 601 条、微信 458 条，剩下十来条是抢先服、测试服、提审服这类。诗意名基本取自英雄和皮肤词，落雪白狼、鲜血枭雄、电玩小子、长城防线都在里面。

游戏界面当时最多显示到手Q547区（落雪白狼，LogicWorldID 1557），ilink 响应已经包含手Q600区（戍鼓铭心，1610）。548 到 600 区的名字已经下发，界面只显示开服部分。编号和 ID 大致遵循手QN区对应 1000+N、微信N区对应 3010+N，中间有跳号；547 区对应 1557，1547 已被其他节点占用。

确认响应内容后，还需要找到合适的改写位置。我依次检查了 libc 收发函数、eBPF 和透明中继。

我先用 Frida 挂 recv、read 和 recvfrom。同一次 60 秒启动中，tcpdump 看到了两千多次区服相关字段，libc hook 的计数为零。诊断日志正常，确认这段流量使用了编号 207 的裸 recvfrom 系统调用。

eBPF 可以稳定看到完整流量，我也记录了 ilink flow 的特征。本次使用的探针只做观测，没有继续实现内核侧改写。

透明中继需要实现拆帧、TDR 解析、字段修改和重新组包，还要处理心跳与重传。这个工作量超出了区服名验证的需要。

我改在游戏进程内处理已经解包的对象。后续消息是否加密、走哪种传输协议，都由游戏原有网络层处理。

Frida attach 会触发游戏崩溃

Frida 便于快速验证，但 attach 主进程后游戏会崩溃，注入的 gum 运行时无法继续运行。

我又把 gadget 放进 Zygisk 模块加载。主进程仍会退出，能存活的子进程没有目标协议对象。继续处理 Frida 特征需要覆盖多处检测点，这次没有沿用这条方案。

我改用纯 Zygisk 原生模块随 zygote 进入游戏进程。模块可以常驻，inline hook 需要自行实现。

ShadowHook 无法在代码段附近分配跳板

我先试了 ShadowHook。它使用四字节相对跳转，需要在目标函数 ±128MB 内放置一小段跳板代码。libil2cpp.so 有 217MB，代码段占 155MB；扫描整个代码段只找到一处 12 字节零填充，附近也没有可用映射。

安装时报错 errno=40。源码里使用目标地址减 128MB 作为 mmap hint，这个地址落在库自身映射中，内核返回的地址超出了相对跳转范围。MAP_FIXED 也找不到稳定空闲区间；ASLR 生成的布局每次不同，有一次出现 9MB 间隙，重启后便消失了。

我改用 16 字节绝对跳转：目标函数开头写入 LDR X17,#8; BR X17; .quad proxy，原指令搬到另一块可执行内存，末尾再跳回目标函数加 16 的位置。And64InlineHook 也使用这种做法。被搬走的指令必须位置无关；当前目标函数以 sub sp 或 stp 开头，adrp 都在前 16 字节之外。

区服名相关函数只在登录期调用，可以在 gcloud 载入后、组网前一次性安装 16 字节跳转。

收发函数从启动起就被网络线程高频调用。16 字节写入不具备原子性，安装过程中执行到目标地址会读到新旧混合的指令，崩溃时间也不固定。

高频函数改用断点 hook。安装时原子写入一条 BRK #0（0xD4200000），SIGTRAP 处理函数在信号上下文中把 PC 改到 proxy。frida-gum 的 exceptor 也采用类似方式。安装过程无需暂停线程，每次命中会增加一次异常处理；首指令为 adrp 的函数仍需先完成重定位。

托管内存盲读统一使用 process_vm_readv，非法地址返回 EFAULT；写入前先用 safe_read 检查目标地址。实测读取速度约为 pipe 探测的四十倍。托管指针的顶字节还带有 TBI tag，解析前需要移除；日志中指针顶部的 0xb4 帮助确认了这个问题。

在运行时导出 IL2CPP 符号

在 IL2CPP 层安装 hook，需要先确定函数地址。这个版本的 CodeRegistration 和 MetadataRegistration 都是零，Il2CppDumper 的 auto 和 manual 模式均失败。几年前的游戏版本还能通过明文 metadata 和两个注册地址静态导出符号，这个方法已经无法使用。

IL2CPP 使用 AOT：C# 先转成 C++，再编译为 ARM64 机器码。libil2cpp.so 中没有统一的解释执行入口，每个 C# 方法对应一个原生函数。运行时 metadata 仍保留方法指针，函数逻辑则需要在 IDA 中查看反汇编。

模块可以从运行时 domain 枚举 assembly 和 class，再导出命名空间、父类、方法名、RVA、字段偏移与类型。结果包含 63,034 个类、412,674 个方法，共 69.8MB 文本，执行时间不到一秒。字段偏移来自当前进程中的实际布局。

收包拦截 HandleMsg，发包拦截 pack

拿到符号表后，我按消息覆盖范围选择 hook 点。

区服名最初挂在服务器 URL 构造函数上。每个区服节点调用一次，一次登录触发一千两百多次，名字位于参数节点下层的托管字符串中。这个位置只能处理区服列表。

协议封装层有出站序列化的 CSPkg.pack 和入站反序列化的 unpack。从这里可以拿到 CSPkg 对象：+0x10 是消息头，头里 +0xc 是路由键 dwMsgID，+0x18 是消息体，消息体的 +0x10 是实际消息对象。

大厅阶段还有部分消息不经过 unpack。继续查看调用关系后，收包分发入口确定为 NetworkModule.HandleMsg，参数布局与 CSPkg 一致，msgid 也能对应。最终收包拦截 HandleMsg，发包拦截 pack。登录重试阶段反复出现的 1014、1191 和 1193，分别对应重新登录通知、游戏服重定向通知和错误码通知，也与游戏日志中的方法名一致。

从等长字节替换改成字段路径

最早的实现会在消息体中搜索字节串，再原地替换成等长内容。「王者独尊」和「总裁牛逼」在 UTF-8 与 UTF-16LE 下长度相同，所以区服名验证能够成功。

这种方式无法修改长度，也无法直接确认目标字段。

我用反射 API 把消息对象递归写成 JSON：il2cpp_object_get_class 获取类，il2cpp_class_get_parent 遍历父类，再按 il2cpp_type_get_name 选择读取方式。实例字段需要通过 flags 排除 static；第一版没有过滤，输出里混入了 BASEVERSION 和 CLASS_ID 等类常量。单条记录如下：

{"dir":"r","msgid":1193,"cmd":"SCID_NTF_ERRCODE","type":"SCPKG_NTF_ERRCODE","body":
 {"stResultInfo":{"iResultId":11014,"stArgList":{"iNum":0,"astArgs":{"classId":148,
 "jarrCount":5}},"m_classID":150},"m_classID":3338}}

字段名和嵌套结构导出后，规则可以直接使用 stResultInfo.iResultId 这样的路径。消息写入 JSONL 文件；logcat 会截断长行，消息量大时也会丢行，不适合保存几 KB 的消息。缓冲区写满时会补齐右括号并添加截断标记，保证每行仍可解析。

收包在 unpack 之后修改，对象会直接交给游戏逻辑；发包在 pack 之前修改，TDR 会重新计算长度前缀。对象层可以替换数组指针，收包侧已验证可以扩展长度，发包侧仍受 schema 定长约束。

8,868 个协议类中没有 System.String 字段，文本使用 System.Byte[]，共 1,155 处。文本改写需要用 il2cpp_array_new 创建新数组。

昵称空白来自 8 字节偏移

账号最初所在的区服达到注册上限，登录阶段只能收到 1014、1191 和 1193 三条通知，其中没有文本字段。换到可以进入大厅的区服后，收包消息从 3 种增至 282 种，其中 21 个字段是文本 Byte[]。

挑中的是 SCID_CMD_GAMELOGINRSP（1003）的 szName，TDR schema 里定长 64 字节，原值「饿了狂吃三碗」18 字节，大厅左上角直接显示它。

第一条规则我就写了个 78 字节的名字，故意超过 schema 的 64。logcat 里 新 Byte[78](任意长) 打出来了，切到大厅一看，昵称位置是空的：

我先怀疑 78 字节超过限制，于是换成 15 字节短名字，界面仍然空白。问题出在数组写入方式。

于是在改写之前，先把原数组从对象首地址起的 48 字节打出来：

+0x00  e08cdd496f0000b4                  klass
+0x08  0000000000000000                  monitor
+0x10  4000000000000000                  max_length = 0x40 = 64
+0x18  e9a5bf e4ba86 e78b82 e59083 ...   数据 = 饿了狂吃三碗

标准 Il2CppArray 布局通常为 +0x10 bounds、+0x18 max_length、+0x20 数据。当前 SO 的长度位于 +0x10，数据从 +0x18 开始，整体相差 8 字节。旧代码读取时漏掉开头，写入时在数据前留下 8 个零，游戏将其识别为空串。

把偏移改成数据 +0x18、长度 +0x10，短名字立刻就出来了：

再使用 78 字节规则后，界面显示「任意长度改写验证」，后续内容被控件截断。本次收包对象成功读取并渲染了 78 字节数组，客户端改名界面的输入限制没有参与这条处理路径。

发包时换入 99 字节数组，对象可以正常创建，pack 仍按 schema 中的 N 读取 char szXxx[N]，超出部分不会发送。长度扩展目前只在收包侧验证成功。

协议表使用相邻版本的数据

拿到 msgid 还差一张表，得知道 1193 是什么、body 里都有哪些字段。

相邻小版本的协议项目已经整理了 4,015 条命令 ID 映射，以及按 C# 类还原的 proto 和 TDR 定义。我抽查心跳、登录、匹配、商城和聊天消息，编号、类名与命名空间都能对应当前运行时 dump，便直接用作路由表。RVA 仍按当前版本重新定位。

当前 dump 中筛出了 7,836 个协议消息类，并将字段名、类型和偏移导出为 JSON。相同协议名会同时出现在 CSProtocol.* 和 CSProtocolWrapper.* 中，前者是运行时引用类型，后者是 ValueType 镜像，字段偏移不同。索引最初使用短名，Wrapper 覆盖了运行时类型；改用全名并单独生成运行时索引后，字段偏移恢复正常。

在 curl_easy_perform 读取最终 URL

游戏还有一批 HTTP 请求，我也记录了它们的 URL。第一版按符号拦截 libcrosCurl.so 导出的 cros_curl_easy_setopt，只收到四次调用，option 都是 99（CURLOPT_NOSIGNAL），没有出现 CURLOPT_URL。

静态反汇编显示，导出层会转到库内的非导出变参 setopt，再进入 Curl_vsetopt。跳转表使用标准 curl option 编号，CURLOPT_URL 为 10002。我按地址拦截库内 setopt，触发次数与导出层一致，收到的仍然只有 CURLOPT_NOSIGNAL。

libPluginCrosCurl.so 是一个 18KB 的 GCloud 插件，导出 CurlFuncQueryService::QueryCurlFuncs。调用方通过函数指针表调用 curl，符号 hook 无法拦截设置 URL 的位置。

我在两个库的 curl_easy_perform 入口调用 getinfo(handle, CURLINFO_EFFECTIVE_URL)，再将结果写入 JSONL。这样可以记录 MSDK、FaaS 的完整请求 URL，以及构造服务器地址时使用的 Tdir 字符串，并通过 via 区分来源。

消息工作台和远端规则

规则最初写在设备的 wzry.cfg 中。每次修改都要编辑文件、推送并等待热重载；查看消息结构还要先读取 JSONL。大厅能收到 282 种消息，继续用配置文件操作很慢。

我把消息查看和规则配置放到主机。设备上报收发消息，前端提供实时列表、历史记录和全文搜索，也可以直接创建规则。设备端只保留引导配置。

传输使用局域网常驻 TCP，每帧由四字节大端长度和 JSON 组成。连接开启 TCP_NODELAY；实测 Nagle 会增加约 40ms 决策延迟。收发直接调用 syscall，防止数据再次进入 libc hook 的 scan()。

局域网常驻连接的 300 次往返全部成功：P50 2.5ms、P99 5.0ms、最大 18.1ms。登录峰值达到每秒 264 条消息；全部同步决策时，网络线程单秒累计等待约 700ms。大厅空闲阶段约为每秒 5 条消息，累计等待 13ms。

服务端会下发一份关注集。名单内的 msgid 使用同步决策，名单外直接放行并异步上报。单次超时或连续失败时，设备放行消息并熔断十秒，随后重新探测连接。

服务端使用 Node 22 和内置的 node:sqlite，启用 FTS5。TypeScript 由 Node 直接运行，一个进程提供 TCP 决策、HTTP 控制接口和前端静态文件。前端使用 Vite、React 与 react-router。

界面现在是这样：

左侧消息流支持按方向、msgid 和名称过滤，也可以暂停。右侧显示消息头、运行时类名和 body 的 JSON 树。图中搜索 npc 后找到了 CSID_ADD_NPC_REQ（2015）。点击树中的字段可以创建改写规则，路径和当前值会自动填入。

规则支持三种处置：allow 原样放行、patch 按字段路径修改、drop 在发包侧丢弃。

验证昵称、金币和钻石

昵称规则用于验证远端下发。synctimeout 最初按 30 字节空包的 P99 设为 5ms，真实事件 JSON 约 5KB，设备在收到决策前已经超时。放宽到 50ms 后，日志记录为 决策回话 8323us。JSON 字符串值本身带引号，重复包装后昵称会显示为 "远端下发的名字"，解析时需要去掉外层引号。

货币数据位于登录响应。SCPKG_CMD_GAMELOGINRSP 中有 stCoinList.CoinCnt，类型为 UInt32[]。

完整登录后，stCoinList.CoinCnt[1] = 6222 与界面金币一致，下标 6 的值 190 与钻石一致。COM_COIN_TYPE 只能提供候选，这两个下标来自界面交叉确认。前端会保存人工确认的数组下标含义。

原来的 JSON walker 遇到数值数组只记录长度，赋值也只支持 Byte[]。这里增加了数组元素展开和 name[idx] 路径语法。

规则在页面上填两行就行：

保存，重登，大厅顶上的数字就变了：

点券不在 CoinCnt 里，它有自己的消息 SCPKG_CMD_ACNTCOUPONS（1161/1162），字段是 llCouponsCnt，后来也验过了，同样能改。

这些修改只影响 unpack 后的客户端对象。服务器账户数据没有变化，购买请求仍会按服务器状态校验。

协议按 msgid 分发消息

前端显示往返耗时，需要先配对请求和响应。RegisterMsgHandler(msgid, delegate) 只按 msgid 建立索引，HandleMsg 也根据包头 msgid 找到委托。分发过程中没有通用请求上下文、逐请求回调或关联令牌。

CSPkgHead.dwSvrPkgSeq 是服务器包序号，客户端发包会回显最近收到的值，同一个序号可能连续出现在多条发包中；服务器主动通知的值为 0，属于 ack 语义。四千个消息类里只有 6 个带 dwClientReqID。SCID 有 2,435 个，CSID 有 1,580 个，许多服务器通知没有对应请求。

前端使用命名规则和时间窗口配对，CSID_X_REQ 对应 SCID_X_RSP。1,580 个 CSID 中有 1,280 个能按名称找到响应，耗时列会明确标记为推测值。

HandleMsg 按 msgid 选择处理委托。构造 CSPkg 后交给这个入口，就能复用游戏已有的消息处理函数。

构造 CSPkg 并交给 HandleMsg

CSPkg、CSPkgHead 和 CSPkgBody 会经过真实收包路径，可以在 hook 中缓存对应的 class。dataObject 的协议类需要按名称查找，模块会在 112 个程序集里调用 il2cpp_class_from_name。object_new 分配内存后，还要通过 il2cpp_runtime_object_init 执行 TDR 生成的 .ctor，创建子结构和定长数组。

托管 API 需要在已经 attach domain 的线程上调用。在轮询线程直接调用会导致进程退出。远端命令会先进入队列，下一次 HandleMsg 触发时再由游戏网络线程执行。队列在当前消息分发前清空，以保持到账通知先于 _RSP 的实际顺序。

注入 1162 SCPKG_CMD_ACNTCOUPONS 并将 llCouponsCnt 设为 777777 后，大厅顶栏显示 777777 点券。注入 1823 SCPKG_HEROSKIN_ADD 后，商城中对应皮肤的按钮从「购买」变为「已拥有」。

让客户端显示到账需要三类消息

我记录了一次购买小乔的完整时间线，一条请求对应七条服务端消息：

s 1817 CSID_BUYHERO_REQ                  dwBillNo=... bBuyType=2 dwHeroID=106
r 1010 SCID_ACNT_INFO_UPD                货币扣除
r 1504 CSID_TASKUPD_NTF                  任务进度
r 48601 SCID_COLLECT_VALUE_TOTAL_INFO_NTF
r 4403 SCID_ACHIEVEMENT_DONE_DATA_CHG_NTF
r 1810 SCID_HERO_INFO_UPD          ←     英雄到账，排在 _RSP 前面
r 1818 SCID_BUYHERO_RSP                  iResultId=0 dwHeroID=106 dwCoinCost=5888
r 51457 SCID_BUY_REGRET_INFO_NTF         反悔期信息

1810 SCID_HERO_INFO_UPD 在购买响应 1818 之前到达。另一次皮肤购买因货币不足而失败，服务端只返回 1820，iResultId=13，wCoinType 和 dwCoinCost 都是 0。

只把 _RSP 结果码改为 0 时，客户端没有收到到账通知，也没有显示购买成功弹窗。

注入到账通知后，客户端自动发送穿戴请求，服务端继续返回：

s 8566 CSID_CMD_SKIN_SUIT_REQ         客户端自动发的穿戴请求
r 8569 SCID_CMD_WEAR_SKIN_SUIT_RSP    iResultId=122009
r 8567 SCID_CMD_SKIN_SUIT_RSP         iResultId=0

122009 对应下面的未拥有提示。此时商城按钮已经显示「已拥有」，穿戴请求仍被服务端拒绝：

这次皮肤流程需要三处处理：模块注入 1823 到账通知，规则将 1820 的购买响应改为成功，再将 8569 的穿戴校验结果改为成功。三条都只改变客户端当前会话中的显示和后续处理。

购买请求只提供 dwResID，到账通知使用 dwHeroID 和 bSkinID。换算关系为 dwHeroID = dwResID / 100、bSkinID = dwResID % 100；18801 对应英雄 188 的 1 号皮肤。

英雄拥有列表在登录时下发

注入英雄到账通知后，客户端显示了购买成功弹窗，商城列表仍显示未拥有。

1886 SCID_ACNTHEROINFO_PARTTWO_NTY 在登录时下发英雄拥有列表，结构为 dwHeroNum 加一个 200 槽位数组，我的账号当时 dwHeroNum=12。1810 SCID_HERO_INFO_UPD 只更新已有条目；列表中缺少目标英雄时，商城读取不到对应记录。

处理方式是在 1886 中增加 dwHeroNum，并向空槽位写入英雄号。普通字段改写遇到空元素时停止，构造消息时则按元素类型创建对象。

用模块处理计算和跨消息状态

规则适合把指定字段改成固定值。购买流程还需要根据 dwResID 计算英雄号和皮肤号、记录已经处理的物品，并主动推送新消息。

本地主机服务增加了模块脚本。脚本运行在 node:vm 中，上下文只提供 msg、body、get、push、patch、store、grants 和 log。on 声明触发条件，handle 执行处理。皮肤模块的主体如下：

on = { dir: 's', msgid: 1819 };
handle = function (ctx) {
  const resid = ctx.get('dwResID');
  ctx.push({ msgid: 1823, type: 'SCPKG_HEROSKIN_ADD', patch: [
    { path: 'dwHeroID', value: String(Math.floor(resid / 100)) },
    { path: 'bSkinID',  value: String(resid % 100) },
  ]});
};

ctx.store 保存模块自己的 KV 状态，ctx.grants 按类型记录物品号。前端存储页可以查看和编辑这两类数据，也可以手工添加发放记录。

固定字段改写继续使用规则；涉及计算、状态或消息推送时使用模块。

模块命中次数最初 upsert 到 modules 表。仓库模块命中后会产生一条 code 为空的同名记录，数据库记录优先加载，导致文件模块失效。命中计数随后移到独立表中。

当前范围

目前验证的是客户端消息改写和本地消息注入。金币、点券、英雄与皮肤状态都只改变当前客户端中的对象；切换场景或重新登录后，真实响应会覆盖这些状态，服务器账户数据保持原值。

完整服务端还需要实现持久状态、业务逻辑和校验。文中的 IL2CPP RVA 只适用于 11.4.1.1 与 2026-06-14 构建，游戏更新后需要重新定位。

Codex Control Chrome MCP：把 Chrome 控制能力借给其他 Agent

Fri, 26 Jun 2026 15:20:00 GMT

声明：本文包含 AI 辅助创作。

最近扒了扒 Codex App 控制 Chrome 的办法。它通过 Codex Chrome Extension 接管用户平时使用的 Chrome Profile，登录态、Cookie、打开的标签页和已安装扩展都在。常见的浏览器自动化方案会新开一个干净的 Profile，有些还要求开启 --remote-debugging-port。碰到需要登录的网站，重新收拾环境很麻烦。

这套能力目前主要给 Codex App 使用。我想把通信链路抽出来包成 MCP，交给其他 Agent 工具。

项目地址：

https://github.com/iola1999/codex-control-chrome-mcp

起因

我之前用 Chrome DevTools MCP 时，浏览器环境通常和日常 Chrome Profile 分开。隔离环境适合自动化测试。通用 Agent 经常卡在登录和环境配置上。

典型问题包括：

新 Profile 要重新登录网站；
平时依赖的浏览器扩展需要再装一遍；
当前打开的标签页接不过来；
有些网站会对新设备或新登录态多做一次校验。

Codex Chrome Extension 直接运行在用户日常的 Chrome Profile 里，可以复用真实登录态和扩展。

通信链路

扒完发现，链路走的是 Chrome Extension + Native Messaging。外部 CDP remote debugging port 没有参与。

大致结构如下：

Codex Chrome Extension
  -> chrome.runtime.connectNative("com.openai.codexextension")
  -> native messaging host
  -> chrome.debugger.attach / chrome.debugger.sendCommand
  -> CDP

扩展运行在日常 Chrome Profile 中，通过 Native Messaging host 和本地进程通信，再调用 chrome.debugger 发送 CDP 命令。这样一来，现成的登录态和扩展都能直接用。

做了什么

codex-control-chrome-mcp 在这条链路外包了一层 MCP：

注册 com.openai.codexextension 对应的 Native Messaging host；
保存并代理 Codex 原有的 extension-host，让 Codex App 继续使用同一个入口；
在本地开一个 bridge socket，供 MCP server 发送 JSON-RPC；
MCP server 提供标签页、导航、CDP、截图和事件读取等工具；
仓库内附带一份 skill，约束 Agent 调用工具的顺序。

名字沿用了 Codex 官方 skill 里的 control-chrome，后缀说明它是 MCP server。

怎么用

前置条件是先装好 Codex Chrome Extension：

https://chromewebstore.google.com/detail/hehggadaopoacecdllhhajmbjkdcmajg

随后按仓库 README 安装 native host，再给支持 MCP 的 Agent 工具添加一份 stdio 配置。

如果 Agent 支持 skill，也可以引用仓库里的 skill：

skills/codex-control-chrome-mcp

这份 skill 主要管调用顺序：

先检查 MCP bridge 和扩展连接状态；
复用已有页面时，先列出用户标签页，再 claim 对应 tab；
做 CDP 之前先 attach；
监听 Network/Runtime/Page 事件时，先 enable 对应 domain；
结束前 finalize tabs，明确哪些标签页需要保留。

步骤本身很短。模型自己猜时会搞错顺序、臆造 tab id，偶尔还会漏读事件。单独放一份 skill 能省下不少纠错时间。

现在的状态

目前版本已经能读取、claim、新建和导航标签页，也能发送原始 CDP 命令、读取网络与页面事件、截屏。包发在 npm 上，可以用 npx 启动；仓库里也带着配套 skill。

我还在研究 Codex 自己的 browser-client。眼下先把 tab 和 CDP 这些底层能力做稳，高层封装以后再说。

适用场景

我主要拿它处理已经登录的网站和当前打开的页面。任务要调用浏览器扩展，或者需要通过 CDP 查网络、控制台、性能与 DOM 时，也不用再维护另一套 Profile。

限制也很具体：项目依赖 Codex Chrome Extension 和 Native Messaging host 注册。同一时间，com.openai.codexextension 只有一个 manifest 生效。项目会代理原有的 extension-host，让 Codex App 和 MCP 共用这个入口。

浏览器自动化跑在哪个 Profile 里，很影响实际体验。日常 Agent 接手现成页面时，登录态和扩展都对得上，少了许多重复配置。这个项目把 Codex Chrome Extension 已有的控制链路接到 MCP 上，代码不算多，我自己用着挺省事。

本文仅记录个人设备和个人环境下的技术调研与实现。浏览器 Profile 中可能包含敏感数据，请只在自己拥有并明确授权的场景中使用。

再谈如何愉快地使用钉钉

Thu, 18 Jun 2026 12:00:00 GMT

声明：本文包含 AI 辅助创作。

折腾仅因个人兴趣，记录分享仅为研究学习交流，请勿用于违法用途。

起因

接着如何愉快地使用钉钉那篇往下写。上次写到「如何不让别人看自己的已读状态」时，我只放了几个参考链接。这次把 macOS 客户端上的做法补全。

最近刷屏的《置身钉内》里有段话：

钉钉的基因，从诞生的第一天起，就是永远站在「发信人」立场……为什么卡片里的消息一定要算已读，为什么系统要主动把事推到用户面前，很多答案，都可以回到这个原点。

发消息时，我也喜欢看到「已读」。轮到自己收消息，这两个字有时就像一只盯着人的眼睛。我从客户端这一侧下手，给自己留一点「装没看见」的余地。碰到难回答的问题，至少还能先不说话。

原理

钉钉的已读状态由客户端主动上报。点开会话后，客户端会发送消息状态 RPC，服务器更新状态，再把结果同步给其他设备和消息发送方。

下面只讲运行时注入。通过启动脚本拉起的进程会加载 hook，从 Dock 或 Applications 启动时照常上报已读。

调用链

当前版本点开会话时会发送两类状态请求：

/r/IDLMessageStatus/updateToViewV2
/r/IDLMessageStatus/updateToReadV2

顺序通常是先 View，再 Read。调用链如下：

用户点开会话
  -> 业务层生成消息状态 Request
  -> wukong::lwp::UserAgent::sendRequest
  -> GaeaMac LWP RPC
  -> /r/IDLMessageStatus/updateToViewV2
  -> /r/IDLMessageStatus/updateToReadV2
  -> 服务器更新消息状态

这些请求走钉钉自己的 LWP RPC，最后都会进 GaeaMac。

主程序从 GaeaMac.framework 动态导入下面这个函数：

wukong::lwp::UserAgent::sendRequest(
    std::shared_ptr<wukong::lwp::Request>,
    std::shared_ptr<wukong::lwp::RequestContext>)

用 fishhook 替换主程序的导入指针，就能在请求进入 GaeaMac 前读取 requestLine。遇到 Read/View 状态路径时直接返回，其余 RPC 仍交给原函数发送。

hook 只改当前进程里的动态导入指针，不会碰代码页和安装包内容。进程退出后，这次修改也就没了。

文件结构

先准备这四个文件：

dingtalk-read/
├── fishhook.c
├── fishhook.h
├── noread_hook.mm
└── launch_noread.sh

fishhook.c 和 fishhook.h 取自 facebook/fishhook，项目目录里已经放好了。

Hook 源码

新建 noread_hook.mm：

// noread_hook.mm
// Hook DingTalk's Wukong LWP request layer through its imported symbol.

#include "fishhook.h"

#include <dlfcn.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>

#include <atomic>
#include <memory>
#include <mutex>
#include <string>
#include <utility>

namespace gaea::lwp {
class Request;
}

namespace wukong::lwp {
class UserAgent;
class Request;
class RequestContext;
}

namespace {

constexpr const char *kSendRequestSymbol =
    "_ZN6wukong3lwp9UserAgent11sendRequestENSt3__110shared_ptrINS0_7RequestEEENS3_INS0_14RequestContextEEE";
constexpr const char *kRequestLineSymbol =
    "_ZNK4gaea3lwp7Request11requestLineEv";

constexpr const char *kReadV1 = "/r/IDLMessageStatus/updateToRead";
constexpr const char *kReadV2 = "/r/IDLMessageStatus/updateToReadV2";
constexpr const char *kViewV1 = "/r/IDLMessageStatus/updateToView";
constexpr const char *kViewV2 = "/r/IDLMessageStatus/updateToViewV2";
constexpr const char *kViewByEntrance =
    "/r/IDLMessageStatus/updateToViewByEntranceCid";

using SendRequestFn = void (*)(
    wukong::lwp::UserAgent *,
    std::shared_ptr<wukong::lwp::Request>,
    std::shared_ptr<wukong::lwp::RequestContext>);
using RequestLineFn = const std::string &(*)(const gaea::lwp::Request *);

SendRequestFn gOriginalSendRequest = nullptr;
RequestLineFn gRequestLine = nullptr;
std::mutex gLogMutex;
std::atomic<unsigned long> gSeenCount{0};
std::atomic<unsigned long> gBlockedCount{0};
bool gBlockMode = false;

const char *logPath() {
    const char *path = getenv("NOREAD_LOG");
    return path && path[0] ? path : "/tmp/dingtalk-noread.log";
}

void logLine(const char *format, ...) {
    std::lock_guard<std::mutex> lock(gLogMutex);
    FILE *file = fopen(logPath(), "a");
    if (!file) return;

    va_list args;
    va_start(args, format);
    vfprintf(file, format, args);
    va_end(args);
    fflush(file);
    fclose(file);
}

bool isMessageStatusUpdate(const std::string &requestLine) {
    return requestLine == kReadV1 || requestLine == kReadV2 ||
           requestLine == kViewV1 || requestLine == kViewV2 ||
           requestLine == kViewByEntrance;
}

void hookedSendRequest(
    wukong::lwp::UserAgent *self,
    std::shared_ptr<wukong::lwp::Request> request,
    std::shared_ptr<wukong::lwp::RequestContext> context) {
    const char *requestLineText = "(unavailable)";
    bool shouldBlock = false;

    if (request && gRequestLine) {
        // wukong::lwp::Request derives from gaea::lwp::Request. The base
        // subobject is at offset zero in the current GaeaMac build.
        const auto *gaeaRequest =
            reinterpret_cast<const gaea::lwp::Request *>(request.get());
        const std::string &requestLine = gRequestLine(gaeaRequest);
        requestLineText = requestLine.c_str();
        shouldBlock = isMessageStatusUpdate(requestLine);

        if (requestLine.find("/r/IDLMessageStatus/") != std::string::npos) {
            const unsigned long seen = ++gSeenCount;
            logLine("[NoRead] SEEN #%lu %s\n", seen, requestLineText);
        }
    }

    if (gBlockMode && shouldBlock) {
        const unsigned long blocked = ++gBlockedCount;
        logLine("[NoRead] BLOCKED #%lu %s\n", blocked, requestLineText);
        return;
    }

    if (gOriginalSendRequest) {
        gOriginalSendRequest(self, std::move(request), std::move(context));
    }
}

}  // namespace

__attribute__((constructor)) static void initializeNoReadHook() {
    const char *mode = getenv("NOREAD_MODE");
    gBlockMode = mode && std::string(mode) == "block";

    gRequestLine = reinterpret_cast<RequestLineFn>(
        dlsym(RTLD_DEFAULT, kRequestLineSymbol));

    struct rebinding binding = {
        kSendRequestSymbol,
        reinterpret_cast<void *>(hookedSendRequest),
        reinterpret_cast<void **>(&gOriginalSendRequest),
    };
    const int result = rebind_symbols(&binding, 1);

    logLine(
        "[NoRead] loaded mode=%s rebind=%d original=%p requestLine=%p\n",
        gBlockMode ? "block" : "observe",
        result,
        reinterpret_cast<void *>(gOriginalSendRequest),
        reinterpret_cast<void *>(gRequestLine));
}

这段代码有两个运行模式：

observe：记录消息状态 RPC，再调用原函数发送。
block：记录并丢弃 Read/View 状态 RPC，其余请求照常发送。

启动脚本

新建 launch_noread.sh：

#!/bin/bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"

APP="/Applications/DingTalk.app"
BIN="$APP/Contents/MacOS/DingTalk"
DYLIB="$SCRIPT_DIR/dingtalk_noread.dylib"
SOURCE="$SCRIPT_DIR/noread_hook.mm"
FISHHOOK_C="$SCRIPT_DIR/fishhook.c"
FISHHOOK_H="$SCRIPT_DIR/fishhook.h"
ENTITLEMENTS="$SCRIPT_DIR/.entitlements.plist"
LOG="$SCRIPT_DIR/noread.log"
MODE="${1:-block}"

if [ "$MODE" != "observe" ] && [ "$MODE" != "block" ]; then
    echo "Usage: $0 [observe|block]" >&2
    exit 1
fi

for file in "$BIN" "$SOURCE" "$FISHHOOK_C" "$FISHHOOK_H"; do
    if [ ! -e "$file" ]; then
        echo "Missing: $file" >&2
        exit 1
    fi
done

command -v clang >/dev/null
command -v clang++ >/dev/null
command -v codesign >/dev/null

NEED_BUILD=0
if [ ! -f "$DYLIB" ]; then
    NEED_BUILD=1
elif [ "$SOURCE" -nt "$DYLIB" ] ||
     [ "$FISHHOOK_C" -nt "$DYLIB" ] ||
     [ "$FISHHOOK_H" -nt "$DYLIB" ]; then
    NEED_BUILD=1
fi

if [ "$NEED_BUILD" = "1" ]; then
    BUILD_DIR=$(mktemp -d)
    trap 'rm -rf "$BUILD_DIR"' EXIT

    clang -c -arch arm64 -O2 -Wall -Wextra \
        -o "$BUILD_DIR/fishhook.o" "$FISHHOOK_C"

    clang++ -dynamiclib -arch arm64 -std=c++17 \
        -framework Foundation \
        -O2 -Wall -Wextra -Wno-deprecated-declarations \
        -o "$DYLIB" "$SOURCE" "$BUILD_DIR/fishhook.o"

    rm -rf "$BUILD_DIR"
    trap - EXIT
fi

codesign --force --sign - "$DYLIB" >/dev/null 2>&1

# 钉钉更新后官方签名会恢复 disable-library-validation。启动脚本读取当前
# entitlements，只翻转这一项，然后按 hardened runtime 方式重签 App 主层。
CURRENT_ENTITLEMENTS=$(mktemp)
codesign -d --entitlements :- "$BIN" \
    > "$CURRENT_ENTITLEMENTS" 2>/dev/null || true

LIBRARY_VALIDATION=$(
    grep -oE 'com\.apple\.security\.cs\.disable-library-validation</key><(true|false)/>' \
        "$CURRENT_ENTITLEMENTS" |
    grep -oE '(true|false)/>' |
    tr -d '/' || true
)
rm -f "$CURRENT_ENTITLEMENTS"

if [ "$LIBRARY_VALIDATION" != "true" ]; then
    codesign -d --entitlements :- "$APP" \
        > "$ENTITLEMENTS" 2>/dev/null

    python3 - "$ENTITLEMENTS" <<'PY'
import plistlib
import sys

path = sys.argv[1]
with open(path, 'rb') as source:
    entitlements = plistlib.load(source)

entitlements['com.apple.security.cs.disable-library-validation'] = True

with open(path, 'wb') as target:
    plistlib.dump(entitlements, target)
PY

    codesign --force --sign - --options runtime \
        --entitlements "$ENTITLEMENTS" \
        "$APP"
fi

: > "$LOG"
{
    echo "[launch_noread] starting @ $(date '+%F %T')"
    echo "[launch_noread] app   = $APP"
    echo "[launch_noread] dylib = $DYLIB"
    echo "[launch_noread] mode  = $MODE"
} >> "$LOG"

(
    cd "$APP/Contents/MacOS"
    exec env \
        NOREAD_MODE="$MODE" \
        NOREAD_LOG="$LOG" \
        DYLD_INSERT_LIBRARIES="$DYLIB" \
        "$BIN"
) >> "$LOG" 2>&1 &

PID=$!
echo "[launch_noread] pid=$PID" >> "$LOG"
echo "DingTalk started: pid=$PID, mode=$MODE"
echo "Log: $LOG"

脚本会处理这些事：

根据源码时间自动编译 dingtalk_noread.dylib。
给 dylib 做 ad-hoc 签名。
应用更新后自动恢复注入所需的 entitlement。
通过 DYLD_INSERT_LIBRARIES 启动并写入独立日志。

脚本实际执行的重签命令是：

codesign --force --sign - --options runtime \
    --entitlements .entitlements.plist \
    /Applications/DingTalk.app

它会保留 hardened runtime，内嵌 framework 仍使用官方签名。

使用方式

给脚本添加执行权限：

chmod +x launch_noread.sh

启动拦截模式：

./launch_noread.sh

查看请求但保留原生行为：

./launch_noread.sh observe

实时查看日志：

tail -f noread.log

日志判读

注入成功后，日志开头会出现：

[NoRead] loaded mode=block rebind=0 original=0x11f1fe158 requestLine=0x11f1bb374

再点开一个会话，会看到：

[NoRead] SEEN #1 /r/IDLMessageStatus/updateToViewV2
[NoRead] BLOCKED #1 /r/IDLMessageStatus/updateToViewV2
[NoRead] SEEN #2 /r/IDLMessageStatus/updateToReadV2
[NoRead] BLOCKED #2 /r/IDLMessageStatus/updateToReadV2

其中：

rebind=0 表示 fishhook 注册成功。
original 有地址表示已拿到原始发送函数。
requestLine 有地址表示可以读取 LWP 请求路径。
BLOCKED 表示请求在进入 GaeaMac 之前已经被丢弃。

验证

先记下启动时间，再在客户端点开一个新的未读会话。noread.log 里应该出现 Read/View 的 BLOCKED 记录。

接着从当前进程打开的文件中找到原生 gaea.log：

PID=$(pgrep -f '/Applications/.+\.app/Contents/MacOS/DingTalk' | head -1)
LOG=$(lsof -p "$PID" | awk '/gaea\.log/{print $9}' | tail -1)
echo "$LOG"

再查注入启动后的发送记录：

grep -E 'send request request_line=/r/IDLMessageStatus/updateTo(Read|View)' \
    "$LOG" | tail -20

如果注入日志有 BLOCKED，原生 RPC 日志还停在启动前的最后一条，请求就已经被截在 wukong::lwp::UserAgent::sendRequest 这一层。

也可以拿同账号的另一台设备对照。电脑端点开新的未读会话后，另一台设备应继续显示未读。

普通启动

退出注入进程，再从 Applications 或 Dock 启动钉钉，已读功能就会恢复。

命令行方式：

open /Applications/DingTalk.app

版本更新

客户端更新后仍然运行这个启动脚本。它会重新读取 entitlements、编译 dylib，再启动注入进程。

如果新版本改了 GaeaMac 的 C++ 符号，启动日志里的 original 或 requestLine 会变成空地址。遇到这种情况，用 nm 重新确认两个导出符号：

APP=/Applications/DingTalk.app
BIN="$APP/Contents/MacOS/DingTalk"
GAEA="$APP/Contents/Frameworks/GaeaMac.framework/Versions/A/GaeaMac"

nm -arch arm64 -m "$BIN" 2>/dev/null | c++filt |
    grep 'wukong::lwp::UserAgent::sendRequest'

nm -arch arm64 "$GAEA" 2>/dev/null |
    grep '__ZNK4gaea3lwp7Request11requestLineEv'

使用边界

本文记录的是个人设备、个人账号和官方安装的 macOS 客户端。文中的逆向、调试与 Hook 只应用于自己拥有或明确获准测试的环境，请勿改动他人数据，也不要拿它规避正常的工作协作。

-END-

王者荣耀 GM 调试面板入口验证记录

Sun, 14 Jun 2026 12:55:00 GMT

声明：本文只记录个人设备和本地安装包上的分析结果，初稿由 AI 生成。

结论

2026-06-17 更新：训练营中已能通过 CheatCommandBattleEntry._GMDesignDebugCommand 唤起「策划属性调试」面板。

测试对象是王者荣耀 Android 版 11.3.1.1。目前确认了两条调试入口：

外层 CheatCode 配置面板，通过隐藏触摸暗码触发，还要 patch 设备登记检查。
对局内的「策划属性调试」面板，需要先处理 TP 检测，再调用 _GMDesignDebugCommand。

在选服页 patch libtprt 的线程创建函数后，进入对局没有再产生 crash 或 tombstone。旧截图里的 GM指令、DldGMPanel 和 OpenGM 资源也还在，内容与体验服字节级一致；大厅中的直接入口暂时没找到。

一、外层 CheatCode 面板

触发方式

触发点在启动阶段的开场视频/启动 Dialog 上，通过屏幕四角和中心区域的隐藏触摸暗码触发：

左上 -> 右上 -> 右上 -> 右下 -> 左下 -> 中心

暗码由 Java 层的触摸事件处理器识别。命中后内部开关置为 true，随后进入 Unity 层的 GM/Cheat 显示逻辑。

设备登记拦截

暗码命中后，原始流程会先进入设备登记检查并显示弹窗：

设备未登记
请使用下列ID登记设备
否则未来会无法登录
点击确定复制

弹窗背后是 IL2CPP 侧的异步状态机。它会向服务端发 HTTP 请求，检查当前设备是否在白名单中。

运行时 Patch

设备登记状态机里有一个条件分支。进程启动后、输入暗码前，用 root 权限修改当前进程内存，把这个分支 nop 掉，流程就会走成功侧的清理路径并打开 CheatCode 面板。保留原指令时，流程会显示“设备未登记”弹窗。

运行时 patch 只对当前 PID 生效。应用重启后，要给新 PID 再写一次。

验证日志

暗码命中时，日志会打印 0~4 的区域序列，m_bOpenCheat 和 java IsShowCheatWindow 也会变成 true。patch 前后的 PID 一致，可以确认内存修改与暗码触发发生在同一进程。

CheatCode 面板

该面板偏配置/环境调试，可见项目包括：

TVersion / 废弃 Tdir(mtcls)
清空缓存 / 清空Prefs / 清空Http缓存
离线云控配置 / 显示缓存目录 / 显示出错文件
CachePatchSwitch / QtsLibVerboseLog / 关闭所有SDK
启用网络诊断工具 / 启用网络加速
pandora测试环境 / 强制使用Limited声音
禁用FormPreload / Wwise不hookQts / 启用AudioService

方法暴露

Java 层负责识别触摸暗码并切换显示开关。Unity/IL2CPP 层能找到 IsEnableGM()、OpenCheatForm() 等 Cheat 方法，面板也由这一层真正打开。

二、策划属性调试面板

旧截图里的 GM指令 / GM 命令列表 界面走另一条分支。解析 metadata 后，CheatCommandBattleEntry 类一共能找到 23 个方法，_GMDesignDebugCommand 会打开对局内调试面板。这个方法要在对局或训练营中调用；大厅没有注册回调，拿到返回对象也不会渲染 UI。

对局中使用动态调试工具会触发腾讯 TerSafe 检测，所以调用面板前还得先处理 TP。

唤起方式

一开始我用短时 Frida 调用确认了面板存在，随后两次遇到封号。frida-agent.so 注入后会留在进程里，frida-server 还要监听端口，这些都是 TP 的检测目标。实际链路是 TP 发现异常、进程崩溃、tombstone 上报，最后由服务器标记账号。

后来换成了 9KB 的原生探针。它通过 ptrace 注入游戏进程，在 constructor 中调用 IL2CPP 的 runtime_invoke，面板唤起后立刻退出。全程没有常驻后台进程和监听端口，内存里也不会长期留着 agent。

	Frida 方案	原生探针
注入物	frida-agent.so (~8MB)	自定义 .so (9KB)
后台进程	frida-server 常驻	无
网络端口	27042	无
内存驻留	长期	constructor 执行完即退出
封号风险	高（已确认两次）	仍待验证

面板截图

训练营：

离线单机模式：

面板标题是「策划属性调试」，下面排着大量分类按钮，内容以对局属性和数值调试为主。UI 用独立 Canvas 渲染，遇到非标准分辨率时会缩得很小。Canvas 的 set_scaleFactor 方法已经找到，适配还没做。

方法列表

metadata 中的 CheatCommandBattleEntry 一共有 23 个方法。下面这些已经逐个测过：

方法	argc	大厅	训练营
`_GMDesignDebugCommand`	0	返回对象，无 UI	弹出「策划属性调试」面板
`_GMBluePrintFrameCommand`	5	未测	蓝图调试面板（待测试）
`SendCommand`	7	未测	发送调试命令（待测试）
`StartHighlightAutoToolFunc`	0	异常	返回正常
`IsPVECoop`	0	true	true
`SetKillNotifyText`	1	正常执行	未测
`RemoveAll`	0	void	void
`ResetSkinIds`	0	未测	void

资源痕迹：旧 GM 命令列表

旧截图中包含 GM指令、DldGMPanel、OpenGM 等字符串。对应的资源块 5165_0.db 在当前版本中依然存在，内容与体验服字节级一致。当前版本里还能找到 GM/Cheat 系统、命令注册和命令历史等资源。

我还没在大厅里直接打开这组资源。它可能依赖 UGC/Pandora app exposure 或特定对局上下文，从资源关系看是第三条面板分支。

三、脚本与后续

脚本

分析时写的脚本都放在 tools/runtime/：

脚本	用途
`open_sgame_cheatcode_panel_root.sh`	启动阶段 patch + 暗码触发 CheatCode 面板
`sgame_tp_race_patch.sh`	ptrace 安全 patch libtprt，阻止 TP 检测线程启动
`sgame_frida_cheatbattle_invoke.py`	Frida 短时调用 CheatCommandBattleEntry 方法
`sgame_ptrace_memrw.cpp`	ptrace 安全内存读写（编译为 ARM64 设备二进制）
`sgame_metadata_index.py`	global-metadata.dat 解析，方法/类型/token 索引
`sgame_qtsvfs_gm_blocks.py`	QtsVFS 资源块解析
`sgame_qtsvfs_compare_blocks.py`	正式服/体验服资源块字节级对比

设备侧工具路径：/data/adb/.sgame_diag/。

最近 Vibe Coding 的玩具们

Mon, 18 May 2026 12:00:00 GMT

声明：本文包含 AI 辅助创作。

刚水完一篇 UURC-Web 的逆向记录，回头盘了盘今年的业余项目，我才发现自己几乎没手写过代码。

我的做法很固定：需求和现象由我讲，AI 负责查资料、改代码和跑排查；我盯结果，拿实机验收，跑偏了就让它重来。上班写业务代码也渐渐变成这个状态，业余项目更放飞。现在主要靠嘴干活，像个随时返工的监工。

下面这些，就是最近下班后靠 Vibe 搓出来的玩具。

1. UURC-Web：在公司浏览器里远程控制

UURC-Web 是最近最合我心意的一个。公司电脑不让装远控，我就试着在浏览器里复刻 UU 远程。

这活儿以前能让我掉一地头发：Android APK 要拆，native 层的 libstreamer.so 要看，那套改过的 WebRTC 协议也得逐项对齐。

给 AI 接上 IDA Pro MCP 后，它能直接进 so 库里翻 Protobuf 封包、找加密 Key。真正难查的一次卡死发生在开源以后：画面放着一直正常，接管鼠标几秒后就停。每次 pointermove 都会触发三次左右的整棵组件树重渲染，100ms 一次的控制心跳被主线程拖慢；data channel 碰上背压时，旧代码还会把心跳彻底停掉。

调试事件改用环形缓冲，输入处理从大 controller 里拆开，鼠标移动也合并到每个动画帧只发一次，这才把停推问题压住。Windows 键鼠随后又单独折腾了一轮：桌面端直接收 JSON 和归一化坐标，键盘用 VK 键码；网络稍慢时，远端会把 press 到 release 之间的延迟当成长按，whoami 能打成 whoooooami。现在普通键会在 keydown 时立即发出一组 press + release，修饰键留到 keyup 再释放。

控制页现在会自动连设备，连续重连失败后改走 UU Relay，伙伴远程协助也能处理设备验证码和对端确认。音频和双向剪贴板也接上了。控制通道里的 cursor shape 会跟着输入框、窗口边缘等状态变化，自定义 PNG 光标还保留热点和缩放。我大部分时间都在描述现象、抓日志和检查实机，AI 负责顺着线索改代码。

2. SmallDesktopDisplay：桌上的像素乐园

SmallDesktopDisplay 是个基于 ESP8266（ESP-12E）的桌面迷你显示器。以前玩单片机，总要写 C++、调 SPI 驱动，再盯着那点内存抠像素。

这次我让 AI 按远程渲染架构来做。ESP8266 固件只管选择链路、上传按钮事件，再把收到的 RGB565 矩形帧刷到 TFT 屏幕。UI、页面状态和动画都在 remote-render 服务里跑，由 Node.js、React、Yoga 和 Skia 生成 240x240 的画面。

逻辑都在后端，加功能基本等于写前端。现在首页是时钟加萧山天气，公历旁边会显示农历、节气和节日；主题、字体、亮度可以在屏幕上调，也能从 Web 控制台看预览。之前塞进去的贪吃蛇、吃豆人和打砖块已经撤掉，数字雨背景在实机上也显得太乱，后来整个删了。少画这层背景以后，稳态传输量大约减半，全屏重同步从 28KB 降到了 9KB。

屏幕接上实机后，预览图里好看的颜色到了 ST7789 上会发灰，Noto 天气图标也比文字高出 5～10px。我把实机现象继续丢给 AI，它给设备输出加上饱和度和暗部 gamma 补偿，又用真实字体逐像素量墨迹边界，把图标偏差压到 2px 左右。

传输链路也重做了一遍。设备接上 USB 时，会在开机后的 1.5 秒内探测宿主机，连上就走 921600 波特率的串口推送，没探测到便继续用 WiFi。OrbStack 透不过 USB 串口，我这台 Mac 上的渲染服务也搬成了 launchd 常驻进程。相邻的差分色块会合并，CRC32 换成查表计算，TFT 的 SPI 时钟也从 27MHz 提到了 40MHz。现在时钟跳秒通常只传一个 747B 的矩形；最新一次实机记录里，全屏帧是 8.9KB，总耗时 128ms。

串口第一次跑到真机上时冒出几个很怪的问题。我把日志丢给 AI，它查到健康检查拿旧的 millis() 做减法，时间戳下溢成了约 42 亿，设备每两秒就误发一次探测；从 WiFi 切串口时，WiFi 反初始化又会阻塞，第一帧直接挤爆 4KB 的 RX 缓冲。它随后改成消费完帧再取新时间，先关 WiFi 再回复握手；宿主机收到设备重启的 HELLO 也会立刻回应。

3. x-tui：在终端里摸鱼

x-tui 是个 X（Twitter）终端客户端。官方网页用着太重，我便让 AI 做了一个跑在 Alt-buffer 里的全屏 TUI。

技术栈很缝合：fork 了一份 @anthropic/ink，再用 React 19 和 Bun 跑在终端里。操作方式照着 Vim 来，j/k/gg/G 移动，l/t/b 点赞、转推、收藏，/ 搜索。详情页退回列表时，SWR 缓存会保留内容和焦点位置。

推文配图也能直接显示。iTerm2、Kitty 和 Ghostty 走各自的图片协议，其他终端退回半方块（Halfblock）字符画。我没细抠控制序列和光标跟踪，只提了句“想在终端里像 Vim 一样刷推，还要能发图”，代码就一批批冒出来了。

4. AnchorDesk：强迫症的资料库助手

AnchorDesk 看起来更像个正经产品原型，给个人和小团队整理工作资料用。

它会解析 PDF、Docx、TXT 和 Markdown，切块后放进检索库。回答必须带引用，缺资料时再去网上查公开信息。

BullMQ 任务调度和 Drizzle ORM 的 Schema 升级都是 Vibe 出来的，长报告的大纲生成与分章导出也一样。我的主要贡献，可能是 README 里那句“本项目采用 MIT 协议”。hh

5. Lapse-box：旧手机的最后一点尊严

这个还没开源，专门拿家里吃灰的 Android 旧手机拍延时。

后台做的事还挺多。手机会连续扫描焦点，并测试不同 ISO 下的曝光和底噪；后端自动拉取原图、降噪，再用 FFmpeg 把几千张照片压成带时间戳的 4K 视频。

旧手机固定在窗台上，每天盯着日出日落。我坐在电脑前，让 AI 帮忙修 Bug，等着看自动生成的延时预览。

这几个月，我开始把时间花在拆问题上。API 的小坑交给 AI 处理，我去琢磨贪吃蛇的路径、远控延迟和系统的数据流。它写出的代码照样会犯蠢，有时修一个 Bug 又添两个，所以检查结果和及时叫停依旧少不了。

顺便，这篇博客也是我 Vibe 出来的。摸鱼快乐！

-END-

UURC-Web：如何愉快地从公司电脑连回家

Mon, 18 May 2026 02:00:00 GMT

声明：本文包含 AI 辅助创作。

折腾仅因个人兴趣，记录分享仅为研究学习交流，请勿用于违法用途。

2026-07-19 更新：补上开源后两个月的排查记录，内容来自仓库里的实际提交和测试。

2026-07-26 更新：加上我部署的公共实例地址，以及自部署的说明。

很久没写这种长篇考古记录了。最近又开了个坑：UURC-Web。

公司电脑不让装第三方远控软件，可我偶尔还得连回家里那台 Mac。客户端装不了，那就试试浏览器。

我给 AI 提了个需求：把网易 UU 远程（UURemote）接进网页。接下来几天，我主要在准备环境、描述现象和验收结果。

为什么要折腾这玩意？

UU 远程在 macOS 上延迟低，画质也不错。它没有网页版主控端，我便给 AI 接上 IDA Pro MCP，让它从官方客户端里找线索。

目标很朴素：网页能登录、看屏幕，键盘鼠标也能用。中转服务放到 Cloudflare 的免费额度里，直连控制照常工作。

考古现场

第一阶段：拆解 Android APK

第一步是看官方客户端怎么做。Android 版 com.netease.uuremote 交给 AI 后，它先跑了一次 apktool d。

业务逻辑基本都在 Java/Kotlin 层，走普通的 HTTPS 请求，也就是网易的 nrd API。音视频流、信令（Signaling）和 WebRTC 协商都塞在 native 库 libstreamer.so 里。

硬骨头也在这里。AI 通过 IDA Pro MCP 顺着 native 符号往下翻，找到了 socket.io、SDP、ICE 和 DTLS/SRTP，最后理出三层：业务 API、Socket.io 信令、WebRTC 数据通道。

第二阶段：照着原生客户端的 WebRTC 布局协商

原生客户端会在 native 层创建 5 路 video 收流和 1 路 audio。浏览器端要照着这套 WebRTC 布局协商，费了不少劲。

UU 的信令在 WebRTC 交换外又包了一层 SOAC（Signaling Offer/Answer/Candidate），还会用 Gzip 压缩 SDP。受控端只认官方格式，AI 便照着原生客户端构造 Protobuf 风格的 Envelope 和二进制 payload。

踩过的坑

鼠标一动，画面就停

刚开源时碰到过一个很邪门的问题：只看画面可以一直跑，接管鼠标后几秒就冻住，断开重连才能恢复。WebRTC stats 里显示的是 transport_stalled，RTP 收包已经停了，受控端压根没再推流。

问题出在输入热路径。每次 pointermove 都会触发大约三次整棵组件树重渲染，还要深拷贝完整的会话状态。鼠标以 60～120Hz 移动时，主线程忙着跑 React，100ms 一次的控制心跳和 EchoRequest 回复开始延迟。channel.send 偶尔遇到背压，还会把心跳永久停掉。受控端超时后把主控判成离线，视频也随之停了。

这部分修复由 AI 完成：调试事件放进环形缓冲，data channel 状态只在真正变化时推给 React，输入处理也从大 controller 中拆了出去。我负责反复移动和点击，把仍会卡住或丢落点的情况继续丢回去。后来它又把连续的鼠标移动合并到每个动画帧只发一次；点击发生前先补发当前位置，合并后也不会丢掉最后一个落点。

卡顿诊断也跟着细分了。transport_stalled 表示 RTP 已停，decode_stalled 表示包还在进、解码帧数却没动。后者连续出现两次时会触发自动恢复，控制台同时记录 RTP 增量、ICE candidate pair 和信令状态，下一次再卡就有东西可查了。

Windows 画面正常，键鼠全死

Windows 端最初只能看到画面，鼠标和键盘完全没反应，console 里也没有报错。我把 Windows 受控端和官方 Android 主控端连好，再让 AI 重翻 libinputmanager.so，对照控制通道抓包。它发现桌面端输入直接发送 JSON；Android 和 MuMu 会在外面包一层 send_to_rom protobuf。当时的代码把 Windows 送进了移动端路径，被控端收到后直接丢弃。

鼠标坐标和键码也各有一层转换。Windows 与 macOS 都收 [0, 1] 范围的绝对坐标，代码当时发的是像素；键盘则要把 Android KeyCode 映射成 Windows VK，并带上官方报文里的 interrept: true。把路由、坐标和键码补齐后，Windows 的键鼠终于开始工作。

紧接着又出现了 whoami 打成 whoooooami。网络延迟拉长了 kbd_press 到 kbd_release 的间隔，UU 的 Windows 服务端把中间这段时间当成长按。最终处理是让 Ctrl、Alt、Shift、Meta 保持到 keyup 再释放；普通按键在每次 keydown 时立即发一组 press + release，长按重复交给浏览器自己的 repeat 事件。中文直接用远端输入法，复制粘贴走文本通道。

右键、Alt+Tab 和触控板

输入能走通以后，还有些很碎、用起来又很烦的问题。浏览器右键菜单会吞掉 pointerup，远端便一直以为右键还按着；Alt+Tab、切应用和切标签页也可能让系统吃掉 keyup。现在 stage 失焦、window blur 或页面隐藏时都会调用 releaseAllInputs，把记录中的按键和鼠标按钮全部抬起。

滚轮也绕了一圈。React 的 onWheel 是 passive listener，preventDefault 拦不住页面跟着滚，所以控制区改用了原生的 non-passive listener。桌面端还要把 DOM 的内容滚动方向换成 UU 使用的原生滚轮方向，并统一 pixel、line、page 三种 delta。触控板的横轴噪声会先过滤，最终增益降到 0.5，不会轻轻一划就滚出去半页。

多路视频时，早期代码用 querySelector("video") 取到了第一路隐藏画面，鼠标坐标会按错误分辨率换算。现在只认正在显示的 video，并用同一套几何计算处理 contain 留黑边和 cover 裁切。最近接上的远端光标也复用了这套坐标，光标形状、热点和缩放能和画面对上。

现在的样子

到 7 月，我已经会实际拿 UURC-Web 干活了。短信验证码登录、账号凭证导入导出、设备状态和控制占用都能在网页里处理，Windows、macOS、Android 和 MuMu 也各自走对了输入路径。

部署有两种方式：Docker 直接拉起，或者放到 Cloudflare Worker + Durable Objects，后者刚好能吃到免费额度，细节写在下一节。

在线体验

公共实例：https://uurc.678234.xyz

这个入口适合看界面、走一遍基本流程。UU Remote Web 要处理短信登录、账号凭证和带鉴权的 UU API 请求，日常使用建议自己部署，验证码、账号登录和凭证导入这几步只在自己控制或者完全信任的实例上做。

自部署里比较省事的是 Cloudflare Worker + Durable Object。Worker 负责页面、UU API 转发和信令网关，远控的画面、声音和输入仍然由浏览器通过 WebRTC 协商。自动路径会优先尝试局域网或者 P2P 直连，条件不满足时才走 UU 中转，部署到 Cloudflare 上不会关掉直连能力。

后记

这个项目里最花时间的是把 native 层的调用链、协议字段和网页端实现对起来，libstreamer.so 那几万行伪代码靠我自己读会非常慢。AI 做这部分效率比我高，我负责把现象说清楚、判断它查得有没有跑偏，再拿设备验证。这个分工在这个项目上是成立的。

项目代码已经开源，有类似需求、或者想看看这套远控协议怎么跑，可以直接去仓库翻代码。

使用边界

本文记录的是个人账号和自有设备上的研究过程。文中的逆向、抓包、调试与远控验证只应在自己拥有或明确授权的设备上进行，请勿连接或控制他人设备，也不要用这些方法规避平台或组织的管理要求。

-END-

如何愉快地使用钉钉

Sat, 27 May 2023 11:00:00 GMT

忙太久没冒泡了，水一篇工作相关的吧。

标题有点科幻，不过最近确实解了钉钉上困扰我的两个问题：思考的间隙无意识点开钉钉看一眼，以及因为好奇谁没读我在群里发的消息而点击已读状态翻一翻。

靠掰正习惯、调整心态来解决它们难度有点高，最近找了些技术流的解法效果不错，记录一下万一能帮到谁呢~

如何避免无消息时看钉钉

这个很好解决，以下几种一起用：

不要设置弹出钉钉窗口的快捷键；
将钉钉的小图标收起来，Windows 上托盘区自带了，macOS 上可以用 Hidden Bar 这个软件；
Windows 能直接关掉钉钉窗口让它离开任务栏，而 macOS 上想隐藏 Dock 上的钉钉图标麻烦了些，查了些方案成本都有点高（比如得关 SIP 或者要借助些付费软件），对比下来还是 sudo lsappinfo setinfo -app 钉钉 ApplicationType=UIElement 这样一行命令搞定最为方便，虽然有些副作用（影响不大就不写了），也可以临时 set 回 Foreground 恢复；
[可选] 直接退出钉钉，隔久一点时间再打开看下或者单纯靠手机的通知被找。

如何不去看别人的已读状态

这个就略技术流了，其实前面也水过几篇「调戏」钉钉的文档，例如调戏钉钉 PC 客户端、调戏钉钉 PC 客户端之 Hook CEF 函数调用，针对该问题的解决方案是通过修改前端代码隐藏会话窗口内的「x 人未读」的 DOM 节点，看不到自然也不会想去点击了。

Windows 上需要参考前文找一下 webContents 压缩包密码，而 macOS 上的钉钉干脆直接没压缩 webContents ~~任人摆布~~（飞书：？）。

要修改的文件是 webContents/assets/chatbox-index.[hash].js（跟撤回的一样），文件中搜一下 msg-unread-indicator 可以看到几处 createElement，不用管具体都是啥场景，都将第三个参数改成空字符串即可。

不便拿公司电脑截图，本文就不附图了，效果完美到就跟钉钉没有已读回执这种 👻 东西一样。

如何不让别人看自己的已读状态

这个是突然想起来的，但不在本文范围内，也不是很礼貌就不写了，感兴趣请参考 https://www.freebuf.com/sectool/258385.html 或 https://blog.csdn.net/frozleaf/article/details/111569433。

套话

折腾仅因个人兴趣，记录分享仅为研究学习交流，请勿用于违法用途。

在浏览器端计算 ssimulacra2

Sun, 08 Jan 2023 11:00:00 GMT

受限于数据安全规定，暂不能贴出本文的完整版。当前已经有了 napi 版本的 ssimulacra2 实现，可以用在 Node.js 服务端。

关于图像处理

关于图片处理前后的质量差异，有多种评价指标: PSNR SSIM SSIMULACRA SSIMULACRA2

计算 SSIMULACRA2

C++

原版实现，官方仓库 https://github.com/cloudinary/ssimulacra2

编译困难，可执行环境有限。

Rust

编译简单，支持多种可执行环境 https://github.com/rust-av/ssimulacra2

纯 JS 实现

性能问题、精度

https://github.com/iola1999/ssimulacra2-js

Wasm

两种思路：虚拟文件系统、零拷贝 rgb 数组

实现 Wasm 方案

安装 rust 等等等等

可用库

npm 包 https://github.com/iola1999/calc-s2-rust

demo 演示 https://calc-s2-vitefe.vercel.app/

Web3.0 捞钱入门

Sat, 09 Apr 2022 08:00:00 GMT

先看示例 https://web3-fe.vercel.app/ ，接下来分享如何实现它，看完你也有机会去捞钱。

0x0 基础概念

这部分内容有官方更专业的表述： https://ethereum.org/zh/developers/docs/intro-to-ethereum/

以太坊网络

以太坊是一条区块链，最好的描述是将其描述为一个公共数据库，它由网络中的许多计算机更新和共享。

“区块”指的是数据和状态是按顺序批量或”区块”存储的。如果你向别人发送 ETH，需要将交易数据添加到一个区块中才算成功。

“链”指的是每个区块加密引用其父块。换句话说，区块被链接在一起。在不改变所有后续区块的情况下，区块内数据是无法改变，但改变后续区块需要整个网络的共识。

ETH

以太币 (ETH) 是以太坊上的的原生加密货币。它存在目的是为了允许算力市场的存在。这种市场为参与者提供了一种经济激励，以验证并执行交易请求，为网络提供计算资源。这也是大家对挖矿、加密数字货币的传统印象。

当前，1 ETH 价格约 3200 USD ，大约 20400 CNY。

比 ETH 更小的单位是 wei（致敬密码学的先驱戴伟（Wei Dai）），1 ETH = 10^9 Gwei = 10^18 wei。

交易

在以太坊网络中，有一台规范化计算机（称为以太坊虚拟机，或 EVM），其状态得到以太坊网络中所有人的一致同意。每个参与以太坊网络的人（每个以太坊节点）都会保存一份这台计算机的状态。此外，任何参与者都可以广播请求这台计算机进行任意计算。每当广播这样的请求网络时，网络上的其他参与者就会验证、确认并进行（“执行”）计算。这个命令会导致 EVM 的状态变化，并且在整个网络中传播。

计算请求被称为交易请求；所有交易的记录以及 EVM 的当前状态都存储在区块链中，而区块链又由所有节点存储并达成一致。

以下为一些交易示例：

ETH 转账 https://etherscan.io/tx/0x0aee0c2060a15a172701abbd17bde9c1ca7f11210a90002336aeb5d59d9454fe
发布智能合约代码（目标账户地址是 0） https://etherscan.io/tx/0x8f7858f98c58d61c2648788f06affe505fde3b29cb35bd6256477eb5212a7203
执行智能合约代码

智能合约

应用程序开发者将程序（可重复使用的代码片段）上传到 EVM 存储中，然后用户通过不同的参数请求执行这些代码片段。我们将这些上传至网络并由网络执行的程序称为智能合约（类似后端服务），它不可被篡改。

简单来说，你可以把智能合约想象成一种自动售货机：通过特定参数调用脚本后，如果满足某些特定条件，就会执行一些操作或计算。例如，如果调用者将以太币发送给特定的接收者，通过简单的卖方智能合约就可以创建和分配数字资产所有权。

任何开发者都可以创建智能合约并在网络上公开，并使用区块链作为其数据层，向网络支付费用。然后，任何用户都可以调用智能合约来执行其代码，并再次向网络支付费用。

帐户

存储以太币之处。用户可以初始化帐户，将以太币存入帐户，并将以太币转给其他用户。帐户和帐户余额储存在 EVM 中的一个大表格中，是 EVM 总体状态的一部分。

以太坊有两种帐户类型：

外部持有 — 私钥的所有者控制
合约 — 一种由代码控制，部署在网络上的智能合约。

它们都能接收、持有和发送 ETH，与已部署的智能合约进行交互。

钱包

帐户和钱包不同。账户是用户拥有的以太坊账户的密钥和地址对。钱包是一个界面或者说应用程序，可以与以太坊账户交互。

支持 ETH 的钱包非常多：https://ethereum.org/zh/wallets/find-wallet/

为了与 Web3.0 交互，可以考虑如 Chrome 浏览器插件：MetaMask 这样的钱包。

Gas

以太坊允许开发者创建去中心化应用 (dApp)，它们共享算力池。这个共享池是有限的，因此以太坊需要一种机制来确定谁可以使用它。否则，某个 dApp 可能会意外或恶意地消耗所有网络资源，从而导致其他应用程序无法访问算力池。

ETH 加密货币支持以太坊算力的定价机制。当用户想要完成一笔交易时，他们必须支付以太币，使他们的交易被区块链识别。「交易」要是按照智能合约的规定一步一步执行命令，每执行一个命令都会产生一定的消耗，这个消耗以 Gas 作为单位，不同命令消耗的 Gas 数量也不相同。例如，加减计算的费用是 3 gas，计算 SHA-3 的费用是 30 gas，输出日志的费用是 8 gas / byte，写入存储的费用高达 20000 gas / 32 bytes。总的来说，消耗 CPU 比消耗存储便宜，简单计算比复杂计算便宜，读取比写入便宜。「查询」则不需要。

这些使用成本被称为 gas 费用，gas 费用的多少取决于执行交易所需的算力和全网当时的算力需求。以太坊上的每一笔交易都包含一个值域，指定了要从发送者地址发送到接收者地址的 ETH 转移数量（以 wei ，10^-18 ETH，为单位）。当接收者地址是智能合约时，当智能合约执行其代码时，这些转移的以太币可用于支付 gas 费用。

撰文时以太坊的 Gas Limit (即 Gas 限制) 是 1500 万 Gas，这是单个以太坊区块中可以使用多少 Gas 数量的上限(也即是说，单个以太坊区块中包含的所有交易的 Gas 量加起来不能超过 1500 万)。

Gas 价格以 Gwei 标明，假设 gas 的价格是 20 Gwei（这个比例称为基本费用，最终会被燃烧销毁），当前一次交易基础费用 21000 gas，则需要支付交易费用 21000 * 20 = 420,000 Gwei = 0.00042 ETH（约 1.34 USD，约 8.5 CNY）。

Gas 一般用于描述交易费用，wei 则一般用于 ETH 金额单位。

为了使交易更快地被确认，还可以在每 gas 对应的基本 Gwei 费用之外添加额外的小费（优先费），由矿工获得，大多数钱包会自动设置该值。

还可以为交易设置最高费用，它与实际收费之间的差额将会退还给交易发起者。

Web3

Web2 指的是我们如今众所周知的互联网版本。一个在互联网公司掌控下提供服务来交换个人数据的互联网。就以太坊而言，Web3 指的是在区块链上运行的去中心化应用。任何用户都可以参与以太坊上的这些应用，个人数据却不会被出卖。

Web3 就是一个去中心化的互联网，旨在打造出一个全新的合约系统，并颠覆个人和机构达成协议的方式。可以基于“无须信任的交互系统”在“各方之间实现创新的交互模式”。

一些优点：

网络上的任何人都有使用服务的权限 — — 换言之，不需要许可。

没有人可以屏蔽您或拒绝您访问该服务。

付款是通过本地令牌即 ether (ETH) 构建的。

以太坊是图灵完备的，这意味着你可以有很多程序部署在上面。

局限性：

交易进展较慢

开发、使用学习门槛高，可访问性稍差

成本较高，因此很多成功的 dApp 仅将其代码的一小部分放入区块链

是不是已经会了？有没有迫不及待地想了解如何捞钱，Let’s start！

0x1 编写与部署智能合约

了解测试网络

MetaMask 钱包中切换到 Ropsten 测试网络

【图片待补充】

可以在这里获取测试所需的 ETH 资产 https://faucet.egorfine.com/

测试网浏览器 https://ropsten.etherscan.io/

编写合约

HardHat 是一个 Ethereum 本地开发套件，用于智能合约的开发测试部署。

使用 npx hardhat init初始化项目。

contractssol 是 eth 合约后缀名，VSCode 插件：solidity。

contract关键字声明合约。view关键字是指该函数不更改 EVM 状态，也就不需要消耗 Gas**。**

//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

import "hardhat/console.sol";

contract Counter {
    uint256 count;

    constructor() {
        count = 0;
    }

    function increment() public {
        count += 1;
    }

    function getCount() public view returns (uint256) {
        return count;
    }
}

部署、执行合约

在 hardhat.config.js文件中添加一个 network 条目。这里我们使用 Ropsten 测试网络。

require("@nomiclabs/hardhat-waffle");

// usePlugin("@nomiclabs/hardhat-waffle");
// Go to https://infura.io/ and create a new project
// Replace this with your Infura project ID
const INFURA_PROJECT_ID = "xxxxx";
// Replace this private key with your Ropsten account private key
// To export your private key from Metamask, open Metamask and
// go to Account Details > Export Private Key
// Be aware of NEVER putting real Ether into testing accounts
const ROPSTEN_PRIVATE_KEY = "xxxxx";

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more
/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.8.4",
  networks: {
    ropsten: {
      url: `https://ropsten.infura.io/v3/${INFURA_PROJECT_ID}`,
      accounts: [`0x${ROPSTEN_PRIVATE_KEY}`],
    },
  },
};

infura 是一个网关，代理与以太坊交互。周五（2022.4.22）晚间服务中断了一会儿【图片待补充】

部署、执行合约的写法：

const hre = require("hardhat");
const main = async () => {
  const Counter = await hre.ethers.getContractFactory("Counter");
  const counter = await Counter.deploy();
  await counter.deployed();

  console.log(`deplyed at ${counter.address}`);

  let count;
  count = await counter.getCount();
  console.log(`count(0) is ${count}`);

  await counter.increment();
  count = await counter.getCount();
  console.log(`count(1) is ${count}`);

  const incrementTx = await counter.increment();
  // 等待确认
  await incrementTx.wait();
  count = await counter.getCount();
  console.log(`count(2) is ${count}`);
};

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

使用npx hardhat run --network ropsten scripts/run.js来运行合约。

$ npx hardhat run —network ropsten scripts/run.js Compiled 1 Solidity file successfully deplyed at 0x4a37bDf634b6D56b0A84Ec60939E11F0f16c0B44 count(0) is 0 count(1) is 0 count(2) is 2

可以在 artifacts目录查看合约编译产物。反编译合约：https://ropsten.etherscan.io/bytecode-decompiler?a=0x4a37bdf634b6d56b0a84ec60939e11f0f16c0b44

每次重新部署都会产生新的合约地址，所以合约一经部署后是不能更新的，即使是被发现了 Bug。

不过，也可以实现一种“可升级”的智能合约来实现迭代。

可以看到 count(1) 还是旧的值，说明交易在被矿工确认过之前还不是真正“生效”的。

合约交易执行完成后会返回一个 Transaction 对象，获取 count(2) 之前等待了这个交易确认（耗时可能要许久），获取的才是更新后的值。

如需直接执行指定地址的合约，参考代码如下：

const contractAddress = "0x4a37bDf634b6D56b0A84Ec60939E11F0f16c0B44";
const counter = await hre.ethers.getContractAt("Counter", contractAddress);

let count;

count = await counter.getCount();
console.log(`count(0) is ${count}`);

检查 ETH 支出

在测试网浏览器上查看自己的钱包地址的 ETH 记录：https://ropsten.etherscan.io/address/0x02f71c43977dfe2399a23ba4272493819fbf86b5

【图片待补充】

可以看到合约部署 + 合约调用及其 ETH 花费。

在线编辑器

http://remix.ethereum.org/ 这里可以在线编译、部署、调试调用合约，也十分方便。

本地网络测试

因为公开测试网络的存在，开发调试已经很方便了，可以忽略本章节。本地网络在交易确认速度上很有优势。

通过 npx hardhat node可以启动一个本机节点，同时会提供一些测试钱包地址和私钥。

$ npx hardhat node Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/

Accounts…

Metamask 添加本地网络时，需要修改一下链 ID。

【图片待补充】

使用npx hardhat run scripts/run.js --network localhost在本地网络运行合约

节点这边日志看到成功部署：

Contract deployment: Counter Contract address: 0x5fbdb2315678afecb367f032d93f642f64180aa3 Transaction: 0xdbd2def227498425ab0ebff63e56ba2b99a36101c7c1492c5dfb8365fbc345a3 From: 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 Value: 0 ETH Gas used: 135941 of 135941 Block #1: 0x500048e068c01c318a005f663c3210ebf72ec33335477435cdb98ff8fe62551f

deplyed at 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 count(1) is 0 count(2) is 1 count(3) is 2

0x2 再来写写 Web3.0 前端交互

回到我们熟悉的领域了，不过你需要先了解一下…

前端是如何跟链上智能合约通信的？

答案是使用浏览器插件。一般的 Web3.0 操作体验都是使用钱包登陆，钱包插件会在 window 上挂载 web3、ethereum。前端代码通过钱包插件与网关交互，网关再进行链上数据查询或更新。

那鲸探是怎么回事呢，抢 NTF 时为何没见过要折腾钱包？其原因是鲸探后端服务来替用户持有了链上账户，购买 NFT 后直接内部跟区块链交互了，门槛低了很多，但也少了开放性。（个人理解）

这里我们继续使用 MetaMask 钱包，使用 npm 包 ethers 来处理与钱包的连接工作。

主要流程

先创建个前端项目 npx create-react-app web3-fe --template typescript

与钱包交互的几个核心的方法如下：

const checkIfWalletConnected = async () => {
  try {
    const { ethereum } = window;

    if (!ethereum) {
      console.log(`please install metamask`);
      return;
    }

    const accounts = await ethereum.request({
      method: "eth_accounts",
    });
    if (accounts.length !== 0) {
      const account = accounts[0];
      console.log(`found account with address`, account);
      setAccount(account);
    } else {
      console.log(`no auth account found`);
    }
  } catch (err) {
    console.error(err);
  }
};

const connectWallet = async () => {
  try {
    const { ethereum } = window;

    if (!ethereum) {
      console.log(`please install metamask`);
      return;
    }

    const accounts = await ethereum.request({
      method: "eth_requestAccounts",
    });
    console.log(accounts[0]);
    setAccount(accounts[0]);
  } catch (err) {
    console.error(err);
  }
};

import { ethers } from "ethers";
import abi from "./utils/Counter.json";

const contractAddress = "0x4a37bDf634b6D56b0A84Ec60939E11F0f16c0B44";
const contractABI = abi.abi;

const getCount = async () => {
  try {
    const { ethereum } = window;

    const provider = new ethers.providers.Web3Provider(ethereum);
    const signer = provider.getSigner();
    const CounterContract = new ethers.Contract(
      contractAddress,
      contractABI,
      signer
    );

    const counts = await CounterContract.getCount();
    setCount(counts.toNumber());
  } catch (err) {
    console.error(err);
  }
};

const increment = async () => {
  try {
    const { ethereum } = window;
    const provider = new ethers.providers.Web3Provider(ethereum);
    const signer = provider.getSigner();
    const CounterContract = new ethers.Contract(
      contractAddress,
      contractABI,
      signer
    );
    const tx = await CounterContract.increment();
    await tx.wait();
    await getCount();
  } catch (err) {
    console.err(err);
  }
};

UI 部分自行发挥，最终效果见演示。

在请求交易时，浏览器钱包插件会弹出确认提示框：

【图片待补充】【图片待补充】

【图片待补充】

完整前端代码供参考：https://github.com/iola1999/web3-fe

0x3 不忘初心

掌握了以上知识，如何捞钱？常见的捞钱方式有以下几种：

发行 NTF

像素头像、盲盒、转赠售一应俱全 https://www.bilibili.com/video/BV1S341177sQ

发行数字货币

基于以太坊发行子货币 https://solidity-cn.readthedocs.io/zh/develop/introduction-to-smart-contracts.html#subcurrency

无门槛割韭菜，一键发行空气币 https://mp.weixin.qq.com/s/JRQgpJfhIMVV8erSK3Dfcw

区块链彩票

基于开源智能合约的彩票，投注、开奖流程链上可查，可信度高。

今天我们来重点演示一下这种方式如何捞钱，来这里体验：https://web3-fe.vercel.app/lottery 。

放心，智能合约、前端源码已开源在：https://github.com/iola1999/web3-fe ，非常之公平公正公开（比某彩高到不知哪里去了）。

【图片待补充】

【先演示一下钱包、连接、交易流程。】

可以在这里领取测试网的 ETH：https://faucet.egorfine.com/ ，也可以直接找我给你转账一些。

中奖者将获得奖池里一半的 ETH，当然在测试链上这并没有什么价值。但是：

最后祝您 — 财富自由。