墨水空 / 溶剂空 报警逻辑逆向

0. 白话版：三个最常见的问题

问：剩余耗材（还剩多少墨）是不是从 RFID 芯片里读出来的？

不是「芯片里存着一个余量数字」那种读法。芯片/读头这一侧只提供一个号码。 软件干的是两件事：

1. 看能不能读到号码 —— 读到的码只要「非零」就算有效（0x440E62 那四条比较，比的一律是 0， 软件里没有任何白名单表去比对「你这个码对不对」）。读到 = 有耗材。
2. 自己记一本账 —— 墨水量是自己会减少的（0x429CF0 sub）， 而且串口一重连就被清零（0x44CDA7 / 0x44CDB3）。

所以「墨水空」的真正含义是：软件这本账掉到 0 了，而不是芯片在报数。

但关键是：这本账的写入动作，就发生在处理读卡结果的那个函数里（0x440B60）。 而且顺序是两道关卡：

1. 完全读不到 → 报「墨水/溶剂 RFID 无法通讯」；
2. 读到了、但读回来的是 0 → 账本当场被写 0 → 报「墨水空 / 溶剂空」。
   （不需要累计几次，每次读到空编码都会立刻写 0。）

所以准确说法是：「空」由 RFID 读卡的成败驱动，但不是 RFID 芯片报出来的余量。 这一点已被现场实测验证 —— 关掉虚拟读头时软件报的是「无法通讯」，开了之后就变成「墨水空 + 溶剂空 都报」， 说明「无法通讯」和「空」是先后两道关卡，中间隔着的就是「读到的编码是不是 0」。 两个耗材同时报空，也是因为两路的校验共用了同一块内存（+0x1FC28）， 编码区整片为 0 时两路必然一起失败。

问：这条链路每一段字节分别是什么？

问：能不能自己买卡和读写器，自己做卡？

1. 先别急着买。这件事的前置条件有两个你目前还不知道：芯片是 13.56 MHz（IC 卡） 还是 125 kHz（ID 卡）。手机 NFC 贴上去有反应 = 13.56 MHz；完全没反应 = 125 kHz。 卡型不同，要买的读写器完全不同，买错了就是白花钱。
2. 但做卡大概率是多余的。因为软件对读到的码只检查「是不是 0」，不比对「是不是原厂那一个」 （0x440E62 一带没有任何查表）。也就是说：只要一张能返回非零码的、和读头同频段的卡，理论上就能过， 并不需要拿到原厂卡去克隆。
3. 如果目的只是让机器别报警，最省事的路不是买卡，而是第 7 节的 A 路线 —— 用 ChipSim 在软件侧冒充读头。不需要知道卡型、不需要买读写器、不碰硬件、零成本、可反复试。
4. 确实要做物理卡的话：需要「与读头同频段的读写器 + 可写空白卡」。 注意 Mifare Classic 的 UID 出厂固定、不能改（除非买「UID 可改写」的魔术卡）； 125 kHz 的 EM4100 是只读的，要改写得用 T5577 这类可写卡。

0x45457D  mov  dl, byte ptr [0x711677]   ; ← 下位机上报的 I/O 位字节
0x454585  and  al, 0x18                   ; 取 bit3 / bit4
0x454587  cmp  al, 8    → [0x1E4F4] = 0
0x454593  cmp  al, 0x18 → [0x1E4F4] = 2   ; 满缸
0x4545A5  cmp  al, 0x10 → 另一分支

1. 分析对象与地址映射（方法说明）

内嵌 exe 是 32 位 PE，imagebase 0x400000，节区表：

结论：文件偏移与 RVA 之间有一个随节区变化的偏移差，不存在通用的 「file offset = RVA」关系。《交接文档》第 2 节给的公式（只加 0x400000）在 .rdata 上恰好 少了 0x1000，它举的那个例子（0xB4814 → 0x4B5814）结果是对的，但公式本身不成立， 照搬到 .data / .rsrc 上会全错。

本报告所有地址均按 VA = imagebase + (文件偏移 − PointerToRawData + VirtualAddress) 换算，并用「在该 VA 处读出的字符串内容是否与预期一致」逐条自校验（下表的字符串全部读出成功）。

2. 关键提示语及其代码引用点

3. 判定链（自下而上）

软件里和「空」有关的判定分成三层，全部读完，链路是闭合的：

第 1 层 · 显示层：0x428280

0x428280  push ebp / mov ebp,esp
0x428283  cmp  [ebp+8], 1          ; 参数 == 1 ？
0x42828A  jne  0x4282B8
          ; --- 溶剂分支 ---
0x42828C  push 0x4B2118            ; "NoticeV"
0x428297  call [0x4A437C]          ; USER32!FindWindowExW（已存在就不重复弹）
0x4282A1  push eax / push 0x4B2118 / push 0x4B2110   ; ← "溶剂空"
0x4282AE  call 0x49AEC0            ; 通知窗口助手（157 处调用，是通用弹窗封装）
0x4282B8  ; --- 墨水分支（参数 ≠ 1）---
0x4282CD  push eax / push 0x4B2100 / push 0x4B20F8   ; ← "墨水空"

这个函数只负责「弹哪一个通知窗」，它自己不做判断。调用它的是主对话框刷新流程：

0x4168E9  push 1                     ; 1 = 溶剂
0x4168EA  lea  ecx, [eax + 0x10E90]
0x4168F0  call 0x428280              ; → 弹「溶剂空」
0x416906  push 2                     ; 2 = 墨水
0x41690E  call 0x428280              ; → 弹「墨水空」

第 2 层 · 判定层：主对话框 0x4168C1～0x41690E

0x4168C1  mov  eax, [0x7114D8]       ; 全局单例对象指针
0x4168DC  mov  edi, 1
0x4168E1  cmp  [eax + 0x1E4EC], edi  ; 溶剂状态 < 1 ？
0x4168E7  jge  0x4168FA              ; 否 → 跳过
0x4168F0  call 0x428280 (push 1)     ; 是 → 报「溶剂空」
0x4168FA  cmp  [eax + 0x1E4E8], edi  ; 墨水状态 < 1 ？
0x416900  jge  0x416583
0x41690E  call 0x428280 (push 2)     ; 是 → 报「墨水空」

第 3 层 · 状态生成层：0x42A390（余量 → 状态 的映射）

这是决定「状态字写 0 还是写 1」的地方。逻辑如下（墨水、溶剂两路对称）：

0x42A3CB  cmp [eax + 0x1FC54], 0x64   ; 溶剂余量 > 100 ？
0x42A3D5  jg  0x42A6BD                 ;   是 → 整个判定不成立，直接返回
0x42A3DB  cmp [eax + 0x1FC50], 0x64   ; 墨水余量 > 100 ？ 同上
0x42A3EA  cmp [eax + 0x1FC80], 0       ; 标志位为 0 → 返回
0x42A3F6  cmp [eax + 0x1FC7C], 0       ; 标志位为 0 → 返回

          ; ===== 溶剂路 =====
0x42A40D  cmp  ecx, 1                  ; 溶剂余量 vs 1
0x42A40F  jge  0x42A479                ;   ≥1 → 走「非空」分支
0x42A411  mov  [eax + 0x1E4EC], ebx    ;   余量 = 0  → 溶剂状态 := 0  ← 报警点
          ... 0x42A44A 弹 NoticeV + "溶剂空"

0x42A479  jle  0x42A4EC                ; 余量 = 1
0x42A47B  cmp  ecx, 5
0x42A47E  jg   0x42A4EC
0x42A480  mov  [eax + 0x1E4EC], esi    ;   1 ≤ 余量 ≤ 5 → 溶剂状态 := 1
0x42A4CC  push 0x4B283C                ;   并提示 "溶剂容量少,请及时更换"

          ; ===== 墨水路（同构）=====
0x42A55A  jge  0x42A5F9
0x42A560  mov  [eax + 0x1E4E8], ebx    ;   墨水余量 = 0 → 墨水状态 := 0  ← 报警点
0x42A5B1  push 0x4B20F8                ;   弹 NoticeI + "墨水空"

第 4 层 · 余量来源：0x440B60（表驱动的读卡结果处理函数）

这是整条链的入口。它的地址在整个文件里只出现一次，位于 .rdata 的 0x4B7AF8 —— 也就是说它是被 MFC 的消息表/函数指针表 间接调用的，没有直接 call。函数取三个参数，按第一个参数（数据类别码） 分派，第二个是事件码，第三个是数值：

0x440B60  函数入口（SEH 框架，__thiscall，this 在 ecx）
0x440B8A  eax = [ebp+8]        ; 参数1 = 数据类别码（0x468 / 0x469 / … / 0x4C9）
0x440B8D  ebx = [ebp+0x10]     ; 参数3 = 数值
0x440BBD  ecx = [ebp+0xC]      ; 参数2 = 事件码

; —— 类别码 0x468 分支：把参数 2、3 共 8 个字节拆开显示并保存 ——
0x440C14  push 0x4B7E98        ; " %C%C%C%C%C%C%C%C"  ← 8 个字节逐个 %C 格式化
0x440C1E  call [0x4A4AD0]      ; 输出到 [esi+0x1E760]（界面上的 UID / 编码栏）
0x440C39  mov  [edx + 0x1FC18], ecx   ; ┐ 组装成 64 位整数存入
0x440C47  mov  [eax + 0x1FC1C], edi   ; ┘
; 类别码 0x469 分支结构相同，写另一组（+0x1FC20）

; —— 事件码分派 ——
0x440D60  cmp  ecx, 6          ; 6 = 通讯失败
0x440D6A  cmp  ebx, 1  →  0x440D94  push 0x4B7DE8  ; "溶剂RFID无法通讯,请联系厂家解决"
0x440D9E  cmp  ebx, 2  →  0x440DBD  push 0x4B7D60  ; "Ink RFID cannot communicate, plz contact the supplier…"
                                                     并配 0x4B7D38 "墨水RFID无法通讯,请联系厂家解决"
0x440E41  cmp  ecx, 8          ; 8 = 另一类结果
0x440E51  cmp  ecx, 0xB        ; 11 = 墨水结果
0x440EEF  cmp  ecx, 0xC        ; 12 = 溶剂结果
0x440F8A  cmp  eax, 0x4C9      ; 另一类别码

+0x1FC18（8 字节）  ← 类别码 0x468 写入，同时被 %C×8 格式化显示
+0x1FC20（8 字节）  ← 类别码 0x469 写入
+0x1FC28（8 字节）  ← 第三块

墨水结果校验：+0x1FC18 块 与 +0x1FC28 块 都非零
溶剂结果校验：+0x1FC28 块 与 +0x1FC20 块 都非零

第 5 层 · 余量的递减与归零

注意 0x44CDA7 落在串口初始化函数内（同函数里紧挨着 SetCallbackFunc4(0x453940) 与 OpenSerial4 的调用点 0x44CC4A / 0x44CC38）， 说明每次串口重连都会把余量账本清 0。这一条现场值得留意：拔插串口线之后 重新读表，余量会回到 0，看起来就像「突然没墨了」。

3.6 现场实测交叉验证（2026-09-27 现场回报）

「两个都报」这一点反过来印证了本报告推断的内存布局：墨水那路的校验是 +0x1FC18 块 + +0x1FC28 块，溶剂那路是 +0x1FC28 块 + +0x1FC20 块 —— 两路共享 +0x1FC28 这一个块。所以当编码区整片是 0 时，三个块全为 0，两路必然同时判定失败、同时报空，与现场现象完全一致。

这条现象独立验证了本报告的判定链，并且把「空」的触发点精确落到了编码校验上：

两个提示是先后两道关卡，不是互相替代：ChipSim 把第一道打通了（有应答了）， 于是软件往下走，撞上了第二道 —— 而 ChipSim 默认档正好过不了第二道。原因是软件要的 不是「有个 8 字节数就行」，而是「几个 8 字节块都不能是 0」：

ChipSim.cmd -Port COM12,COM13 -Profile auto -Code "04 24 0D 1C 04 24 0D 1C 04 24 0D 1C 04 24 0D" -Seconds 0

4. 完整链路图

RFID 读头 ──串口──▶ VSNScd.dll ──回调 0x453940──▶ 消息分派 0x440B60
                                                        │
                        事件 0xB / 0xC + 数值 + 8 字节编码校验
                                                        ▼
                              [0x7114D8] + 0x1FC50（墨水余量）
                                          + 0x1FC54（溶剂余量）
                                                        │
                                          余量 → 状态 映射 0x42A390
                                                        ▼
                              [0x7114D8] + 0x1E4E8（墨水状态 0/1）
                                          + 0x1E4EC（溶剂状态 0/1）
                                                        │
                                          主对话框刷新 0x4168C1
                                                        ▼
                                      0x428280(int) → 弹 NoticeI / NoticeV
                                                       "墨水空" / "溶剂空"

5. 对《交接文档》的修正与补充

6. 与既有实测数据的互相印证

《ASM_实测数据解读》里有一个当时无法定性的问题：应答帧第 6 字节在 0x64(100) 与 0x00(0) 之间取值，并列了「A. 耗材余量百分比」与 「B. 读头检测状态」两种假设，未判定。

顺带解释了一个现场现象：《ASM_实测对比_v3》记录到「两次采集相隔 24 分钟数据一字未变」， 如果状态字节是余量，那么当时那支耗材的余量一直是 100，说明余量不随软件内的 用量扣减而变——它只在读头重新读数时被整体覆盖。这与 0x429CF0 的单向递减 （只减、由读头重置）是一致的。

7. 现场可执行的三条路径（针对「待办 #3」）

8. 证据边界（哪些是确证，哪些是推断）

本次未做：没有运行任何程序、没有动态调试、没有连接设备。 所有结论都可由 _extract\embedded_1_42MB.bin 静态复核。

9. 关键地址速查（给下一个接手的人）

10. 复核方法（可完全复现）

# 依赖：capstone、pefile
python -m pip install capstone pefile

# 1) 正确换算文件偏移 → VA
#    VA = 0x400000 + (off - RawOfSection + VAOfSection)
#    .text  (0x400→0x1000)   .rdata (0xA3000→0xA4000)   .data (0xDBE00→0xDD000)

# 2) 取字符串：在目标 VA 处读 UTF-16LE 到 \x00\x00
#    例：0x4B20F8 → "墨水空"

# 3) 找引用：在 .text 里搜 struct.pack('