xmz7891/ykxmz
1
0
Fork 0
mirror of https://gitee.com/xmz7891/ykxmz.git synced 2026-10-18 13:40:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
130 Commits 1 Branch 18 Tags
v2.1.6
Commit Graph
7 Commits
Author SHA1 Message Date
xmz7891 4d97e40280 2.1.6：静默自动更新 + 远程鼠标控制 + 一键显示桌面 
用户这次提了一整套升级。这个提交先落地三块（其余几块在做）。

== 一、静默自动更新 ==

用户原话："手表端点击一个更新按钮，电脑端就可以自动进行静默更新，
其他什么设置都不变 …… 不弹任何窗口出来"。

链路：

    手表点按钮 -> 被控端问中转"最新是哪版"
               -> 下载到 %TEMP%\ykxmz-update\
               -> 校验 sha256
               -> 起一个**分离的 .cmd 帮手**
               -> 自己退出
               -> 帮手等它退出 -> 静默跑安装器 -> 重新拉起

关键设计说明：

  * **为什么要有那个 .cmd 帮手**：Windows 上正在运行的 exe 是锁着的，
    安装器覆盖不了，所以必须"先退出、再装、再起来"，而这三步
    不能由被控端自己做（它一退出就没人执行后面的了）。
    用 DETACHED_PROCESS 起的助手不受父进程退出影响。

  * **配置为什么不会丢**：配置在 %ProgramData%\ykxmz\data\，
    **不在程序目录里**。安装器升级只替换 {app} 下的文件，
    不碰 ProgramData —— 中转地址、配对码、各种开关原样保留。
    这是这个功能能做的前提。

  * **更新源是用户自己的中转站**，不是作者的服务器，也不是任何
    写死的公网地址。被控端问的是它自己配置的那个地址。
    中转没有这个接口（老版本服务端）时会明确提示"先手动升级一次服务端"。

  * **sha256 必须校验**：自更新最大的风险是下到一半断了或被换了，
    装上去是个坏程序、而且它还会自己再更新 —— 螺旋下去很难救。
    对不上就**放弃这一轮**，保持现状（现状至少能用）。

中转新增：GET /v1/update/latest?platform=windows
返回 version / name / url / size / sha256。版本比较按**数字段**
（不能按字符串，否则 "1.9.0" > "2.1.4"）。sha256 按
(文件名,大小,mtime) 缓存，避免每次重算 9MB。

手表端："电脑端版本：点这里查看" 按钮，查完显示
"电脑端 2.1.4 → 2.1.5（点这里更新）"，确认后才真的更新。

== 二、远程鼠标控制 ==

新增 windows/lanremote/input.py，用 SendInput 模拟鼠标键盘。

  * **为什么用 SendInput 而不是 mouse_event**：后者是 Win95 时代的
    API，会被 UIPI 拦，而且没有 dwExtraInfo（多个注入源会互相干扰）。
    SendInput 还能一次打包多个事件，按下+抬起之间不会插进别的输入。

  * **坐标是 0..65535 归一化**，而且**必须除以 (屏幕宽-1)**。
    少了那个 -1，最右边和最下边几像素点不到 —— 表现为
    "鼠标到不了屏幕边缘"，任务栏在底下的机器上尤其明显。

  * **INPUT 结构在 32/64 位下大小不同**（28 / 40），
    ctypes 里按进程位数算，不能写死。

  * 权限说明：目标窗口如果是管理员权限的（UAC 提升过的），
    普通权限的注入会被 UIPI 拦掉。这不是 bug，是 Windows 的设计。
    被控端以管理员运行就都能点。

== 三、一键显示桌面 ==

用户要求快捷栏里那个"不能改"的按钮就是这个功能，等于 Win+D。
和鼠标控制共用 input.py。

== 顺手修的一个自己造的坑 ==

往 server.py 插方法时，**两次**把 dispatch 的兜底
`return {"ok": False, "error": f"未知命令: {cmd}"}` 一起卷进了新方法里：

  * pyflakes 报 "undefined name 'cmd'"
  * 而且 dispatch 丢了兜底分支（未知命令会返回 None）

第一次靠 pyflakes 抓到，第二次也是。为了以后不再犯，
`_tests/test_update_flow.py` 里加了**结构断言**：
兜底必须在带 CMD_UPDATE 的那个方法体里，而各新方法里不能出现它。

（那条断言第一版写得太死 —— 要求"紧跟 CMD_UPDATE 分支"，
 后来往 dispatch 里插了新分支就误报了。改成验结构真相。）

== 验证 ==

    全量回归（含新增的 3a10 / 3a11 两关）全部 PASS
    静默自动更新：协议 + updater 15 项 + 服务端结构 8 项
    远程鼠标：坐标归一化 / 滚轮夹取 / Win+D 事件顺序 / 非法参数 22 项
    610 个 Python 文件语法通过
    实际注入鼠标成功（move / click / scroll / show_desktop）

== 还没做的（下一批） ==

    手表顶部快捷栏（可自定义最多 4 个，1 个固定"显示桌面"）
    屏幕镜像去掉提示条、去掉所有弹窗
    托盘图标改成设置项
    「允许新设备连接」开关（中转后台 + 安卓端）
    弹文字窗口位置/大小可自定义
    中转后台设备列表显示版本 + 远程点更新

== 顺手清理 ==

_tests/out_app/ 下面那堆 .class 是 Java 编译检查的产物，
以前误提交进仓库了（152 个文件）。这次从索引里移除并加进 .gitignore。
 2026-10-09 22:12:09 +08:00
xmz7891 be59a20036 2.1.5：修「Windows 7 装完报 dll 缺失」 
用户报：学校的电脑是 Windows 7，装完提示缺 DLL。

== 根因不是漏打包，是 Python 版本越界 ==

    Python 3.8    -> 最后一个支持 Windows 7 的版本
    Python 3.9+   -> 只支持 Windows 8 及以上

Python 3.9 起用到了 api-ms-win-core-path-l1-1-0.dll 里的
PathCchCanonicalizeEx，而这个 DLL **Windows 7 上根本不存在**，
也没法用 api-set 转发（那套机制只在 Win8+ 生效）。

所以之前用 3.11 打出来的包，在 Win7 上必然报缺 DLL ——
**那个 DLL 不是"忘了放进包"，是"放进去也没用"。**

顺带说明：包里那 47 个 api-ms-win-core-*.dll 转发库正是
Python 为兼容 Win7 才带上的 —— 上游本来就考虑过 Win7，
只是 3.11 这个版本号越界了。

== 改法 ==

1. **改用 Python 3.8 打包，而且选 32 位**
   32 位在 Win7 的 32 位和 64 位系统上都能跑，学校不用分两种发。
   （64 位的包在 32 位 Windows 上直接起不来。）

   依赖固定到 3.8 能用的版本：
       Pillow==9.5.0（最后一个支持 3.8 的）
       pyinstaller 6.x（保持 _internal 布局，和安装包/测试/卸载逻辑一致；
                       5.x 会把依赖摊在根目录，导致"_internal 在"那一项失败）

2. **打包脚本主动拦**
   windows\build_exe.ps1 打包前先校验 Python：
     * 找不到 3.8 -> 报错并给出安装命令
     * 版本不是 3.8 -> 直接 throw，而不是默默打一个别人装不上的包
     * 不是 32 位 -> 警告
   Python 从 YKXMZ_PY 环境变量或常见路径里找，不写死。

3. **新增 Win7 兼容校验** _build\check_win7_compat.py
   盯三件事：内嵌是不是 3.8 的运行库、**有没有**那个要命的 DLL、
   exe 是不是 32 位。打包时和回归套件（3a9 关）里都会跑，
   不过就拒绝出包。

== 顺手修的 ==

_build/test_installer_cycle.py 里写死了 ykxmz-setup-1.8.2.exe，
于是一直在**装一个不存在的旧包** -> 静默失败 -> 报出一堆
莫名其妙的失败（"配对码实际是 xxx"、"版本显示 v1.8.2"）。
改成自动找 dist 下版本号最新的包（按数字段排序，不能按字符串，
否则 1.9.0 会排到 2.1.4 前面）。

== 验证（用户要求：自己测一遍，没问题再上传）==

    全量回归 42 个阶段全 PASS（含新的 "Windows 7 兼容" 关）
    安装包完整周期 20/20
    Win7 校验：python38.dll / 无 api-ms-win-core-path / 32 位
    实际启动打包的 EXE：进程活着、TCP 监听、UDP 自动发现在听、
                        连接能建立（日志里有"设备接入"）
    产物扫描：三件全部干净（无旧密码、无服务器 IP）
    提交前泄漏闸门通过

安装包体积 14.4 MB -> 9.0 MB。
 2026-10-09 13:16:31 +08:00
xmz7891 9bdd36cf56 2.1.4：修 URL 协议头 bug + 清理对外材料里泄漏的服务器信息 
用户报了三件事，一起处理。

== 一、发行版介绍里泄漏了服务器公网 IP ==

_build/CHANGELOG.md 的 2.1.3 那节写了服务器公网 IP，而发布脚本
把这个文件当"更新说明"传给 Gitee，于是发行版介绍里就带出去了。

为什么 IP 不该公开：直接打 IP 就绕过 Cloudflare 了 ——
没有 CDN、没有防护、没有速率限制。源站本来就不该被人知道是谁
（这也是为什么 nginx 那层只认域名、中转只绑 127.0.0.1）。

处理：
  * 已发的 v2.1.3 发行版介绍用 API 改掉（扫了全部 11 个发行版，只它一个）
  * 仓库里 16 个文件里的 IP 全部换成域名或占位符
  * 运维脚本改成从环境变量读，公开仓库里不留具体地址

顺手发现**更严重的一处**：旧管理员密码硬编码在
docs/AFTER-INSTALL.txt（会打进服务端 zip）和
installer/license-combined.txt（**安装包的许可页，每个装的人都能看到**）里。
而用户当前密码就含这个串，等于公开了一半。一并清掉，
公开材料里改成"密码在你服务器上"的说明。

== 二、手表端填了地址却连不上 ==

用户截图：填域名（没写协议头）-> 点「检查服务器」报

    MalformedURLException: no protocol: <域名>/v1/health

根因：补协议头的逻辑只写在连接那条路（RelayTransport 的构造函数）上，
checkServer() 直接拿原始字符串拼 URL —— 同一个地址，连接能用、检查却崩。

修法：把规范化收到 relayUrl() 这**唯一一个入口**，所有调用方都从那里取。
规则和电脑端一致：IP / localhost / *.local -> http，域名 -> https。

顺带补了 _tests/test_relay_url_normalize.py 盯住它（含 9 个用例实算）。

== 三、Gitee 的 README 被判"可能含有违规信息" ==

Gitee 挂的是软性公告（可自行修改或申诉），但确实挂在那。
逐项看了 README，改掉几处**不准确**且容易误判的表述：

  * 原文写"看看学生机是不是在打游戏" —— 这是**错的**：
    被控端只装在一台电脑上（讲台那台），根本看不到别的机器。
    既不准确又像监控软件，改成"作用于被控端那一台"
  * 课堂那几项功能如实说明：改的是本机 hosts、结束的是本机进程，
    都可逆，下课点「一键恢复全部」就还原
  * "免杀对抗""伪装成系统进程"这类词（虽然是在说"我们不做这些"）
    本身就在审核词库里，换成正面的说法
  * 成品文件名从 1.8.2 更新到当前版本，并且以后发版自动跟着改
    （把 README 加进了 bump 脚本；以前一直停在 1.8.2，
     用户照着 README 去 releases 根本找不到那个文件）

== 四、做这件事时自己踩的坑（都写进注释了）==

  * 批量替换时**没排除 gitignore 的文件**，把本地密码文件也改了
  * 替换时往字典字面量中间塞注释，**弄坏了 5 个文件的语法**
  * 修的时候手写"坏文件列表"，漏了 2 个 ——
    改成全仓库扫模式（列表是观察到的，不是穷尽的）
  * 清理工具自己又成了泄漏点（脚本里写了要匹配的 IP/密码），
    加了 _build/precommit_leak_gate.py 当闸门才抓到

教训：批量替换要先排除不该碰的文件，而且不能往表达式中间塞东西。

== 按用户要求：测完再提交 ==

    全量回归 41 个阶段全 PASS（2 项因锁屏 SKIP）
    601 个 Python 文件语法通过
    pyflakes 干净
    安装包完整周期 20/20
    对外材料清洁度 15/15
    提交前泄漏闸门通过

（这条信息是补写的：上一个提交因为 heredoc 把提交说明打到屏幕而不是
 文件，信息变成空的 "remove temp" 了，内容本身是对的。）
 2026-10-08 23:51:17 +08:00
xmz7891 8880e7033d 修「经中转几次后永久哑掉」——「按一下没反应」的真因 
== 现象 ==

用户报：
  * 局域网能搜到电脑，IP/端口/配对码都对，连上后**没有任何反应**
  * 走中转「已配对」，但点按钮没反应

局域网那一半已经修过（preferLan）。这次抓到的是**经中转**那一半，
而且比预想的严重得多。

== 证据链（插桩复现出来的）==

被控端日志里直接抛了未捕获异常，线程当场死：

    Exception in thread client-relay:
      server.py:407  session.send(reply)
      relay.py:166   self._link.send_to_client(data)
      relay.py:357   self._post("/v1/agent/send", ...)
      relay.py:766   raise RelayError(f"请求失败: {last_error}")
    lanremote.relay.RelayError: 请求失败: Idle

之后的状态：
  * client-relay 线程没了 —— 电脑再也不往手表回任何东西
  * relay-link 线程还活着、还在长轮询 —— 中转那边看着「设备在线」
  * **手表看到的就是「连上了，但按一下毫无反应」**

写入仓库的测试 _tests/test_relay_local.py 一直是这个形状：
前面几项 PASS、跑到经中转发命令就卡死。之前没人深挖。

== 根因 1：一条 HTTP/1.1 连接被两个线程同时用 ==

_post() 里锁只包住「取连接」那一段：

    with self._http_lock:
        connection = self._http      # 锁到这里就放了
    try:
        connection.request("POST", ...)   # 锁外发请求

于是两个线程会同时用同一条 connection：
  * relay-link 线程跑 /v1/agent/poll —— 长轮询，一条请求挂 180 秒
  * client-relay 线程同时 POST /v1/agent/send

HTTP/1.1 一条连接同一时刻只能有一个在途请求，第二个线程一进来
就撞上 http.client 状态机，抛 CannotSendRequest("Idle")。

_post 的「重试一次」也救不了：它 _drop_http() 之后，另一个线程
手里还攥着那条旧连接对象在发，照样坏。

修法：
  * **发命令用独立连接**（_post 加 dedicated 参数）。
    长轮询那条常年被占着，发命令不该去挤它，各走各的。
  * 两条连接各自一把锁**锁住整个「发请求 + 读响应」周期**，
    不再只锁取连接那一下。
  * 普通请求若发现缓存连接正忙（长轮询在途），临时另开一条用完即关。
  * _drop_http(dedicated=) 区分清哪条；finally 里一定归还占用
    （否则那条连接会被永久标记为忙）。

== 根因 2：回包失败会打死整个会话线程 ==

server.py 的 _client_loop 里：

    if reply is not None:
        session.send(reply)      # <- 不在任何 try 里
    ...
    except OSError:              # <- 外层只捕获 OSError
        pass

而中转链路上 send 抛的是 RelayError，直接冒出去把线程打死。
**死一次就永久哑**，代价太大。

修法：session.send() 单独兜住所有异常，失败就断开这个会话
（让手表重连），绝不让线程消失。外层也补一个兜底 except。

== 修复效果 ==

    修复前：pair OK -> ping OK -> ping 卡死 -> 线程崩溃，永久哑
    修复后：pair 21ms -> ping 82ms -> ping 4ms -> ping 6ms，零异常

_tests/test_relay_local.py：**之前完全卡死 -> 现在 21/21 全过**

这个测试之前一直是红的，说明「35 个阶段的回归全绿」这件事
本身就不成立过 —— 某个阶段卡住时看起来像环境问题而不是缺陷。

== 同批修掉验证阶段找到的其它问题 ==

1. **TTL 清理 + 关掉接入开关 = 设备永久锁死**（严重）
   register() 用 `device_id in self.devices` 判断老设备，但超时清理
   把设备从 devices 和 codes 都删了。电脑关机过夜（必然 > 6 小时）
   第二天开机就会被自己的开关挡住，而且**重启也救不回来**
   （清 codes 时没落盘，重启后又当孤儿清一遍，自我维系）。
   管理员在页面上还看不到这台设备，不知道该放开谁。
   修法：状态文件里单独存 knownDevices 设备历史，超时清理绝不动它；
   register 改查这份历史；清理后补 _save()；delete_device 才真正忘记。

2. **管理页 JS 语法错误 -> 所有按钮失效**（严重）
   admin.py 里 ADMIN_JS 是普通三引号字符串，我在 Python 源码里写的
   `\n` 被变成真实换行，拼进 JS 就是字符串里的裸换行 ->
   整段 <script> 不执行 -> 改码/删除/批量删除/全选全变幽灵按键。
   元凶是我加改码功能那次提交。改成 `\\n`。

3. **--relay / --relay-status 崩溃**（严重）
   RelayLink.start(url) 的 url 是必填参数，我把默认地址改空白时
   run_agent.py 两处调用没跟着改。一处被 try 吞成「测试失败：missing
   1 required positional argument」（用户以为地址填错了），
   一处直接报栈。两处都补上 url。

4. 非法 deviceId（控制字符 / 路径分隔符）现在被拒（白名单：
   字母数字 + - _ . :）

5. enable_relay() 第二次调用不再谎报成功（加 RelayLink.running 属性，
   返回值反映真实运行状态；不再用「对象建过没有」判断）

6. snapshot() 清孤儿码后补 _save()，磁盘和内存不再脱节

== 局域网全面优化（task-2，另一个智能体完成）==

4 个真问题：
  * **网段判断写死 /24** —— 在 /16 网络上 10.8.1.5 和 10.8.2.5
    被判成不同网络，明明能直连却去走中转还费流量。
    改成按网卡真实掩码比较。
  * **广播只发一个包** —— 丢一个就整轮搜不到。改成 5 个时间点重发。
  * **只探一个网段** —— 多网卡手表搜不到另一网段的电脑。改成全探。
  * **走中转之后再也回不到局域网** —— 出门再回家永远挂中转。
    新增定期回切（先便宜地 TCP ping，通了才动真格，
    不破坏正在工作的中转连接）。

实测：局域网握手 2ms、50/50 = 100%、中位 0ms。
（跨网络那半之前拿不到数字，就是被上面那个线程崩溃挡住的 ——
  现已修复。）

顺带：instance.py 单实例锁端口加 YKXMZ_LOCK_PORT 覆盖（默认不变）。
用户自己那台被控端正跑在这台机器上占着 8767/TCP + 8766/UDP，
是这次排查里好几个「测试怎么都不通」的根因。

== 服务端一键部署脚本（task-1，另一个智能体完成）==

relay/deploy.sh + relay/deploy-tune.sh，随服务端 zip 发布：
  * 自动检查并安装 cloudflared
  * 部署程序、装 4 个 systemd 服务、网络调优、配隧道、自检打公网地址
  * **不传 --hostname 且没有 TUNNEL_TOKEN 时明确提示要填**，
    不会静默用一个写死的域名（用户明确说过这个中转站是他自己用的，
    不对外开放，绝不能把私人域名烧成默认值）
  * 重跑 = 升级，已有数据/配对码/管理密码/凭据都不动

顺带修了发布包一直缺 site_shots/ 的老 bug
（package_remote.py 用 iterdir()+is_file() 收文件，目录进不去，
新机器装完官网截图全是 404）。

== 默认中转地址改成空白 ==

用户要求：软件默认不带任何中转地址，由用户自己填。
四处硬编码全部清空（server.py / MainActivity.java / run_agent.py /
relay.py 的注释和文档示例），全仓已无非注释的硬编码地址。

== 文档同步（task-5，另一个智能体完成）==

README / BEFORE-INSTALL / AFTER-INSTALL / 打包模板：
  * 新增「软件里不带任何中转地址」告示，讲清跨网络要自己部署
  * 修正 Android 版本（写的是 9.0/API28，实际 API 24 / Android 7.0）
  * 删掉「地址已经内置好了」（现在是错的）
  * AGENT_README 原来把作者自己的中转地址当成「内置地址」发给用户，已重写
  * RELAY_README 原来写「两条隧道同时跑会互相争抢」，
    和真机/CHANGELOG 矛盾；按实测改成「两种协议同时在跑（故意的）」
 2026-10-07 17:59:39 +08:00
xmz7891 81e923a0aa 1.7.1：修白屏 + 配对 + 官网管理页分家 
手表端
- 修「连上后一片白屏」：initTabs() 从来没被调用过，
  导致 tabDefs 为 null、selectTab 直接 return，
  标签栏里只剩一个孤立的滑动指示器
- 应用名改成 ykxmz

被控端
- 修「设备已关闭新设备配对」：配对码本身就是密钥，
  拿着正确的码就该放行。老逻辑"首台配对后自动关窗"会把
  手表重装的人永久挡在外面
- 应用名改成 ykxmz

服务器端
- / 改成官网（公开，简洁介绍 + 下载）
- /zhingzhuanzhan 中转站管理（要登录），/admin 自动跳转
- 管理账号 xmz7891，可改
- 官网 / 登录页 / 管理页都加上 favicon
 2026-10-06 23:08:07 +08:00
xmz7891 07e96a9595 1.6.0：重写 README，面向老师 / 电教 / 开发者 / 普通用户 
README
- 原来的 README 是开发者视角（在解释我为什么没做某功能），
  而且通篇 AI 腔。这次按用户视角重写，讲怎么用。
- 开头就分流：老师 / 电教 / 开发者 / 普通用户，各看各的
- 定位改成教室电脑手表遥控，主场景是老师上课管教室那台电脑
- 加了电教专用一节：机房同传部署、脚本批量推、网络规划、权限收口
- 加了开发者一节：三端怎么编译、怎么跑测试、怎么打包
- 加了通信协议一节
- 常见问题、排错顺序、错误对照表都补全

版本号
- 1.5.0 -> 1.6.0（versionCode 107）
- 顺手写了通用的版本升级脚本 _build/bump_version_generic.py，
  以后升版本一条命令就行，不用手改十几个文件
 2026-10-06 23:08:07 +08:00
xmz7891 b62ac865ea ykxmz 1.5.0：修复手表端 TLS 证书校验 + MTU 修复网络稳定性 
被控端
- 修复 MTU 问题：夹 MSS + 路径 MTU 探测（公网可用率 48% -> 100%）
- 复用 HTTP 连接（免掉每次新建 TLS 的 30% 握手失败）
- 每分钟回头找局域网，自动切回快 400 倍的路径
- 画面心跳帧：静止时省流量，客户端仍知道流是活的
- 锁屏时给出可操作的提示

手表端
- 内置 GTS Root R4 / GlobalSign Root CA，修 SSLHandshakeException
- 连接错误翻译成人话（证书/时间/解析/超时分别提示）
- 经中转连上后用服务器报的地址刷新已配对记录
- 新增局域网连接页面、服务器延迟检测

服务器端
- 支持 chunked 请求体（修每 16 秒一次的连接错乱与大面积 502）
- 网络调优脚本 net-tune.sh（开机自动应用）
- 管理页：批量删除、网络体检、下载区
- 隧道改 HTTP/2 + 双连接

文档
- 许可协议 / 安装前必读 / 安装后须知（作者：小麦子）
 2026-10-06 19:01:05 +08:00