先搞懂基础规则：ISO/IEC 14443 Type A 奇偶校验逻辑 #

MIFARE Classic基于ISO/IEC 14443 Type A标准通信，每传输1个字节（8位数据），都会额外附带1个奇偶校验位，核心逻辑很直白：

• 奇偶位的取值要保证「8位数据位 + 1位奇偶位」中，1的总数为偶数
• 传输顺序是先发送字节的最低位（LSB），最后再传输这个奇偶校验位

结合你提供的认证交互数据逐一拆解 #

咱们顺着你给出的失败认证追踪记录，一步步看奇偶位的处理细节：

1. 唤醒&防碰撞初始阶段 #

reader: 26 | tag: 02 00

• 阅读器发送的0x26（二进制00100110）：数据位里有3个1（奇数），所以奇偶位设为1，确保总1数变成偶数（4个），符合规则。
• 标签响应的0x02（00000010）：只有1个1（奇数），奇偶位为1；0x00全是0，1的数量为0（偶数），奇偶位为0。

reader: 93 20 | tag: c1 08 41 6a e2

• 阅读器的0x93（10010011）：数据位里有4个1（偶数），奇偶位为0；0x20（00100000）只有1个1（奇数），奇偶位为1。
• 标签返回的UID相关数据也严格遵循规则：比如0xC1（11000001）有3个1，奇偶位为1；0x08只有1个1，奇偶位同样为1。

2. 防碰撞确认阶段 #

reader: 93 70 c1 08 41 6a e2 e4 7c | tag: 18 37 cd

• 阅读器最后发送的0xE4（11100100）有4个1，奇偶位为0；0x7C（01111100）有5个1，奇偶位为1。这一步是UID确认帧，每个字节的奇偶位都按规则生成。
• 标签响应的0x37（00110111）有5个1，奇偶位为1；0xCD（11001101）同样有5个1，奇偶位为1，完全符合校验要求。

3. 认证请求&错误响应阶段 #

reader: 60 00 f5 7b | tag: ab cd 19 49

• 这是密钥A的认证请求帧：0x60有2个1，奇偶位为0；0xF5（11110101）有6个1，奇偶位为0；所有字节都遵循奇偶校验规则。

reader: 59 d5 92 0f 15 b9 d5 53 | tag: a //error code: 0x5

• 阅读器发送的这组加密数据，每个字节也都会附加对应的奇偶位。标签返回的0xA有2个1，奇偶位为0，但返回错误码0x5（认证失败）——这个错误和奇偶位无关，大概率是密钥不匹配或加密挑战响应逻辑出错，但传输过程的奇偶位依然合规。

补充你提到的奇偶位安全漏洞 #

你说的奇偶位相关漏洞，本质是阅读器生成奇偶位完全依赖字节内1的数量，攻击者可以通过篡改奇偶位、观察标签响应（比如是否返回NAK、是否静默），反向推导标签内部的加密状态甚至密钥片段——这是一种侧信道攻击思路，利用了奇偶校验的强关联性。

内容的提问来源于stack exchange，提问作者L.Acmery