1. 从一张“刷不开”的门禁卡说起这个分析仪到底在解决什么问题手里攒了一堆卡片——门禁卡、食堂卡、公交卡、银行卡还有几张不知道干嘛用的白色IC卡。某天你突然想搞清楚这些卡到底用的什么协议里面存了什么数据为什么有的卡贴上去秒响应有的卡要蹭半天更实际一点的需求是公司门禁卡丢了能不能自己复制一张备用小区门禁能不能写进手机里这些问题背后其实指向同一件事你需要一个能跟卡片“对话”的工具。不是那种只能读个卡号就完事的廉价读卡器而是能真正理解ISO 7816协议、能处理非接触式支付卡通信的分析仪。我手上这个便携式分析仪就是干这个的。它支持ISO 7816接触式协议和非接触式支付卡两大模式能完成从物理层信号到应用层数据的完整解析。说白了它既能把卡片激活、复位、发送APDU指令也能通过射频接口跟非接触卡进行数据交换最后把原始数据、协议帧结构、甚至卡片返回的状态字都清清楚楚地展示出来。这个东西适合谁用如果你是嵌入式开发者想调试自己的智能卡读写方案它能帮你抓协议层的问题如果你是安全研究者想分析卡片的认证流程和数据结构它能给你提供底层视角如果你只是个爱折腾的极客想搞明白自己每天刷的卡到底怎么回事它也能让你看个明白。当然前提是你得在法律允许的范围内使用——分析自己的卡、做技术学习这没问题但拿去搞别人的卡那就是另一回事了。我最初做这个分析仪的动机很简单市面上的读卡器要么太贵要么太封闭要么只支持一种协议。我想要一个能同时处理接触式和非接触式、协议解析透明、方便二次开发的工具。于是就有了这个项目。下面我会从硬件选型、协议栈实现、非接触式通信的坑、以及实际调试经验几个方面把整个东西拆开来讲。2. 硬件选型为什么最后选了这套组合2.1 接触式接口的芯片选择与电平匹配问题ISO 7816接触式接口的核心是电平转换和时序控制。卡片的工作电压有Class A5V、Class B3V、Class C1.8V三种而大多数微控制器的IO是3.3V。你不能直接把3.3V的IO接到卡座上——如果卡片是5V的3.3V可能驱动不起来如果卡片是1.8V的3.3V直接怼上去可能把卡打坏。我一开始想用分立MOS管做电平转换搭了个电路测试发现时序根本对不上。ISO 7816的复位应答ATR对时序要求很严格上升沿和下降沿的时间窗口很窄分立方案的一致性太差。后来换成了专用的ISO 7816接口芯片比如TDA8035或者ST8024这类。这类芯片内部集成了电平转换、过流保护、时钟分频你只需要给它供电、给时钟、给复位信号它就能帮你完成卡片激活的全套流程。具体接线是这样的微控制器通过UART或者SPI跟接口芯片通信接口芯片再通过C1VCC、C2RST、C3CLK、C5GND、C7I/O跟卡片连接。这里有个细节C4和C8在ISO 7816标准里是预留的但很多卡片会把它用作辅助触点如果你不接有些卡可能不工作。我在PCB上把C4和C8都引出来了通过跳线选择是否连接实测下来大部分卡不接也没问题但个别老卡确实需要。注意卡片插入检测最好用机械开关加软件去抖不要只靠电流检测。我试过用电流检测判断卡片是否插入结果有些低功耗卡在待机时电流太小根本检测不到。2.2 非接触式13.56MHz射频前端的设计取舍非接触式支付卡工作在13.56MHz遵循ISO 14443标准。这部分比接触式麻烦得多因为涉及到射频匹配、天线设计、载波调制和解调。我试过三种方案。第一种是用分立元件搭射频前端包括振荡器、功放、检波电路。搭出来能读到卡但读距只有几毫米而且稍微动一下卡片就丢数据。第二种是用现成的射频读写芯片比如MFRC522或者PN532。这类芯片集成度高SPI接口简单但问题是它们对ISO 14443-4层的支持有限尤其是处理支付卡那种复杂的APDU交互时经常需要自己补协议栈。最后我选了支持ISO 14443-4的射频前端芯片配合一个可调匹配网络。天线用的是PCB印刷天线四圈矩形走线电感量大概1.5微亨。匹配网络用两个电容做谐振调到13.56MHz。这里有个经验天线的Q值不要调太高。Q值高了读距远但带宽窄卡片稍微偏离中心就通信失败。我最后把Q值控制在20左右读距大概3到5厘米但容错性好很多。射频部分的供电要特别注意。功放工作时电流波动很大如果电源纹波大载波上会叠加噪声导致解调误码。我在电源入口加了LC滤波功放单独用一路LDO供电跟数字部分隔离开。实测下来这样处理后误码率明显下降。2.3 主控与存储为什么选了带硬件加密的MCU主控选的是带硬件加密引擎的MCU。原因很简单分析支付卡时你可能会遇到需要计算MAC或者做认证的场景。如果纯软件实现DES或者AES速度慢不说还容易被侧信道攻击。硬件加密引擎虽然不能完全防侧信道但至少比软件实现强。存储方面我挂了一片SPI Flash用来存日志和抓包数据。分析仪工作时会把所有APDU交互都记录下来包括时间戳、方向、数据内容。这些数据量不小一次完整的支付流程可能产生几十KB的日志。Flash容量选了8MB够存几百次交互记录。屏幕用的是一块小尺寸TFT240x320分辨率SPI接口。显示内容主要是菜单、状态、以及十六进制数据。按键用了五个上、下、确认、返回、复位。操作逻辑很简单就是树形菜单不搞花哨的UI。3. ISO 7816协议栈从冷复位到APDU交互的完整链路3.1 卡片激活流程与ATR解析中的常见异常ISO 7816的卡片激活流程分几步上电、时钟供给、复位释放、等待ATR。听起来简单但每一步都有坑。上电顺序很重要。标准要求先给VCC和GND再给CLK和RST。我一开始图省事同时上电结果有些卡直接不响应。后来老老实实按顺序来VCC上电延时1msCLK启动延时1msRST拉低再拉高。这样下来卡片激活成功率明显提高。ATRAnswer To Reset是卡片返回的第一串数据格式是TS T0 接口字节 历史字节 校验字节。TS是初始字符通常是0x3B直接约定或者0x3F反向约定。T0的高四位表示后续接口字节的数量低四位表示历史字节的数量。接口字节TA、TB、TC、TD分别描述协议参数、时钟频率、等待时间、以及后续协议类型。我遇到过一种情况卡片返回的ATR里TD1指向T1协议但我的代码默认按T0处理结果后续通信全部失败。后来加了协议自动识别逻辑根据TD字节判断用T0还是T1。T0是面向字符的T1是面向块的两者在帧格式和错误处理上完全不同。实操心得ATR解析不要只读前几个字节就下结论。有些卡会在历史字节里放厂商信息但历史字节的格式没有统一标准不同厂商不一样。我一般把完整ATR打印出来人工看一眼再决定后续参数。3.2 T0与T1协议的帧结构差异及代码实现T0协议是面向字符的。每个字节独立传输每个字节有一个起始位、八个数据位、一个奇偶校验位、一个停止位。接收方如果校验失败会在下一个字节的采样点拉低I/O线发送方检测到后重发。这种机制叫错误信号。T0的APDU命令头是5个字节CLA、INS、P1、P2、P3。P3表示后续数据的长度。如果命令有数据要发给卡P3就是数据长度如果命令期望卡返回数据P3就是期望返回的最大长度。卡返回的数据后面会跟两个字节的状态字SW1和SW2表示执行结果。T1协议是面向块的。数据被组织成块每个块有 NAD、PCB、LEN、INF、EDC 几个字段。NAD是节点地址PCB是协议控制字节LEN是数据长度INF是信息字段EDC是校验码。T1支持块链一个APDU可以分成多个块传输适合大数据量场景。代码实现上T0相对简单就是字节收发加奇偶校验。T1复杂一些需要处理块的组装和拆分还要管理发送序号和接收序号。我一开始只实现了T0后来遇到一张卡只支持T1不得不补上。补的时候发现T1的EDC校验有两种LRC和CRC。LRC是异或校验CRC是16位循环冗余校验。具体用哪种要看ATR里的TC字节或者协议协商结果。// T0字节收发示例伪代码 uint8_t t0_transceive(uint8_t byte) { uint8_t rx 0; io_low(); // 起始位 delay_half_bit(); for (int i 0; i 8; i) { if (byte 0x01) io_high(); else io_low(); delay_bit(); byte 1; } // 奇偶校验位 if (parity(byte)) io_high(); else io_low(); delay_bit(); io_high(); // 停止位 delay_bit(); // 接收卡片返回 // ... return rx; }3.3 APDU命令构造与状态字处理的实战细节APDU是应用层协议数据单元分命令APDU和响应APDU。命令APDU的格式是CLA INS P1 P2 Lc Data Le。响应APDU是Data SW1 SW2。构造命令时最容易出错的是Le字段。Le表示期望返回的数据长度。如果Le0表示期望返回256字节在短APDU模式下。如果Le不写表示不关心返回长度。我一开始经常搞混导致卡片返回6700长度错误或者6Cxx长度不对xx是实际长度。状态字SW1 SW2的含义需要查ISO 7816-4标准。常见的比如9000表示成功6A82表示文件未找到6982表示安全状态不满足6Cxx表示长度错误。实际调试时我建议把状态字含义做成一个查找表遇到不认识的就去查标准文档。有个细节61xx状态字表示卡片还有xx字节数据待取。这时候你需要发送GET RESPONSE命令CLA00, INSC0把剩余数据取回来。我遇到过一张卡返回61xx后我直接发下一条命令结果卡片返回6985使用条件不满足。后来才知道必须先GET RESPONSE。注意不同卡对APDU的兼容性差异很大。同一套命令在A卡上能跑通在B卡上可能就报错。调试时最好先用简单的SELECT命令测试确认基本通信正常后再上复杂命令。4. 非接触式支付卡分析射频通信与支付流程拆解4.1 ISO 14443-3防冲突与UID获取的实操要点非接触式卡进入射频场后首先经历防冲突流程。因为读卡器可能同时面对多张卡需要一套机制选出一张来通信。ISO 14443-3定义了REQA/WUPA命令和防冲突循环。REQA是请求命令卡片收到后返回ATQAAnswer To Request。ATQA里包含UID的长度信息。然后读卡器发送防冲突命令卡片返回UID的一部分。如果有多张卡读卡器会检测到冲突调整防冲突命令的参数直到选出唯一一张卡。实操中防冲突失败是最常见的问题。原因可能是多张卡同时在场也可能是卡片刚进入射频场还没稳定。我的做法是先发REQA如果没响应就等10ms再发连续三次没响应就报错。如果有响应但防冲突失败就重新走一遍防冲突流程最多重试五次。UID的长度有4字节、7字节、10字节三种。4字节UID的卡通常叫短UID卡7字节和10字节的叫长UID卡。有些门禁系统只认短UID长UID卡读出来会被拒绝。如果你要复制门禁卡这一点要特别注意。// 防冲突流程简化示例 uint8_t uid[10]; uint8_t uid_len 0; send_reqa(); if (wait_atqa()) { // 防冲突级别1 send_anticoll(0x93, 0x20); if (read_uid_cl1(uid, uid_len)) { // 检查是否有更多UID if (uid_len 4) { // 短UID完成 } else { // 继续防冲突级别2 send_anticoll(0x95, 0x20); read_uid_cl2(uid 4, uid_len); } } }4.2 RATS与PPS协商进入ISO 14443-4层的必经之路拿到UID后如果要进行支付相关的交互需要进入ISO 14443-4层。这一步通过RATSRequest for Answer To Select命令完成。卡片收到RATS后返回ATSAnswer To Select里面包含卡片支持的参数比如最大帧长度、是否支持CID等。RATS命令的格式是0xE0 参数字节。参数字节的高四位表示CID逻辑通道号低四位表示FSDI帧大小指示。FSDI决定后续通信的最大帧长度从16字节到256字节不等。ATS返回后可能还需要PPSProtocol and Parameter Selection协商。PPS用来调整通信速率从106kbps到848kbps。不过很多支付卡不支持高速率PPS协商会失败这时候就保持默认的106kbps。我踩过一个坑RATS命令的CID字段。如果卡片不支持CID你发了带CID的RATS卡片可能不响应。我一开始没注意给所有卡都发CID1的RATS结果有些卡直接沉默。后来改成先发CID0的RATS确认卡片支持后再尝试其他CID。实操心得RATS之后如果卡片返回ATS说明已经进入ISO 14443-4层。这时候就可以发送APDU命令了。但要注意非接触式的APDU封装在块传输协议里跟接触式的T0/T1不一样。ISO 14443-4的块格式是PCB CID NAD INF CRC需要单独实现。4.3 支付卡APDU交互流程与常见状态字解读支付卡的APDU交互通常从SELECT PPSE开始。PPSE是Proximity Payment System Environment里面列出了卡片支持的支付应用。命令是SELECTAID是2PAY.SYS.DDF01。SELECT成功后返回FCIFile Control Information里面包含应用列表。然后你需要SELECT具体的支付应用比如某卡组织的AID。SELECT成功后会返回PDOLProcessing Options Data Object List告诉读卡器需要提供哪些数据。接下来是GPOGet Processing Options命令。读卡器根据PDOL构造数据发给卡片。卡片返回AIPApplication Interchange Profile和AFLApplication File Locator。AIP表示卡片支持的功能AFL告诉读卡器去读哪些文件。然后就是READ RECORD循环根据AFL读取卡片上的记录。这些记录里包含卡号、有效期、持卡人姓名等信息。最后可能还有GENERATE AC命令用于生成交易密文。常见状态字方面除了前面提到的9000、6A82、6982支付卡还会返回6283卡片被锁定、6300认证失败、6D00指令不支持。我遇到最多的是6985通常是命令顺序不对比如没SELECT就直接GPO。// SELECT PPSE示例 uint8_t cmd[] { 0x00, 0xA4, 0x04, 0x00, 0x0E, 0x32, 0x50, 0x41, 0x59, 0x2E, 0x53, 0x59, 0x53, 0x2E, 0x44, 0x44, 0x46, 0x30, 0x31, 0x00 }; // 发送命令并解析响应 // 响应格式6F 长度 84 长度 DF名称 A5 长度 BF0C ...5. 调试过程中踩过的坑与排查思路5.1 接触式卡片不响应的排查链路有一次一张卡插进去死活不响应。我按以下顺序排查第一步检查供电。用万用表量C1和C5之间的电压发现只有1.2V明显不对。正常应该是3V或5V。查电路发现是LDO输出电容虚焊补焊后电压恢复正常。第二步检查时钟。用示波器看C3引脚发现没有时钟信号。查代码发现时钟配置寄存器写错了分频系数设得太大实际输出只有几百赫兹。改回正确分频后时钟恢复。第三步检查复位时序。用逻辑分析仪抓RST和I/O线的波形发现RST释放后I/O线一直是高电平没有ATR返回。怀疑是卡片坏了换了一张卡正常。确认是卡片问题。这个排查链路我后来固化成了流程先查供电再查时钟再查复位最后查卡片本身。大部分问题在前三步就能定位。5.2 非接触式读距短与丢包的优化过程非接触式读距短我一开始以为是天线问题换了更大的天线读距确实远了但丢包率也上去了。后来用频谱仪看载波信号发现载波上有很多谐波导致解调器误判。优化过程分几步。首先调整匹配网络。把谐振电容从原来的值微调让谐振点更准地落在13.56MHz。其次降低功放增益。增益太高虽然读距远但信号失真严重。降了3dB后读距略近但丢包率大幅下降。最后优化解调阈值。解调器的比较阈值原来设得偏高导致弱信号被忽略。调低阈值后读距和稳定性都改善了。最终读距稳定在3到5厘米丢包率低于1%。对于便携式设备来说这个表现够用了。5.3 支付卡认证失败的原因分类与应对支付卡认证失败我遇到过几种情况。一种是密钥不匹配。卡片和读卡器之间的认证需要共享密钥。如果密钥不对卡片会返回6300。这种情况没法绕过只能确认密钥是否正确。另一种是随机数生成问题。认证过程中读卡器需要生成随机数发给卡片。如果随机数质量差比如重复或者可预测卡片可能拒绝。我后来用了MCU的硬件随机数生成器问题解决。还有一种是时间窗口超时。支付卡对认证过程有时间限制如果读卡器响应太慢卡片会终止会话。我优化了代码把认证流程的执行时间从200ms压缩到50ms以内超时问题不再出现。注意分析支付卡时不要尝试修改卡片数据。支付卡通常有防篡改机制一旦检测到异常写入可能永久锁定。分析仪的设计原则是只读不写除非你明确知道自己在做什么。6. 从分析仪到实际应用几个可复现的扩展方向6.1 把分析仪变成门禁卡模拟器分析仪本身是读卡设备但加上卡模拟功能后就能变成门禁卡模拟器。实现方式是用MCU的射频前端发送载波然后按照ISO 14443-3的协议响应读卡器的命令。具体步骤先分析目标门禁卡的UID和认证流程然后在MCU里模拟相同的响应。对于只认UID的门禁系统模拟UID就够了。对于需要认证的系统还需要模拟认证过程。我试过模拟一张短UID门禁卡成功刷开了公司的门禁。但要注意模拟卡和真卡不能同时在场否则会发生防冲突两个都不工作。6.2 用脚本自动化批量分析卡片分析仪支持通过串口跟电脑通信。我写了一个Python脚本通过串口发送命令自动执行SELECT、GPO、READ RECORD等操作然后把结果保存成JSON文件。import serial import json ser serial.Serial(COM3, 115200, timeout1) def send_apdu(apdu_hex): ser.write(bytes.fromhex(apdu_hex)) response ser.read(1024) return response.hex() # 批量分析 cards [] for i in range(10): print(f请插入第{i1}张卡...) input() uid send_apdu(00A404000E325041592E5359532E444446303100) cards.append({index: i, uid: uid}) with open(cards.json, w) as f: json.dump(cards, f, indent2)这个脚本帮我快速建立了一个卡片数据库记录了每张卡的UID、支持的协议、以及基本数据。6.3 协议模糊测试用分析仪找卡片实现的边界分析仪还可以用来做协议模糊测试。就是发送一些非标准的、边界情况的APDU命令看卡片怎么响应。比如发送超长的Le、非法的CLA、不存在的INS等。我测试过一张卡发送CLAFF的命令卡片返回6E00类别不支持。发送INSFF返回6D00指令不支持。发送P3255但实际数据只有10字节卡片返回6700长度错误。这些响应都符合标准。但也遇到过不按标准来的卡。有一张卡发送非法命令后直接不响应需要复位才能恢复。这种卡在实际使用中可能会因为异常命令而挂死值得注意。模糊测试的边界要控制好不要发送可能触发卡片自毁的命令。对于支付卡尤其要小心。7. 一些零散但重要的经验关于电源管理。便携设备靠电池供电功耗控制很重要。我的做法是接触式接口不工作时断电非接触式射频前端在待机时进入低功耗模式MCU在空闲时降频。这样下来一块2000mAh的电池能撑一整天。关于固件升级。分析仪预留了USB接口支持固件升级。升级协议用的是简单的XMODEM稳定可靠。升级时要注意不要断电否则可能变砖。我在Flash里放了bootloader即使应用固件损坏也能通过bootloader恢复。关于外壳。3D打印的外壳材料是ABS。打印时要注意射频天线区域不要被金属遮挡否则读距会大幅下降。我把天线区域的外壳厚度控制在1mm以内并且没有放任何金属件。关于法律合规。这一点必须强调分析仪只能用于分析你自己拥有的卡片或者你明确获得授权的卡片。未经授权读取、复制他人卡片信息在很多地方是违法的。技术本身没有对错但使用方式有边界。关于调试工具。逻辑分析仪和示波器是必备的。逻辑分析仪用来抓协议时序示波器用来看射频波形。我用的是一台入门级逻辑分析仪和一台100MHz带宽的示波器够用了。如果预算有限逻辑分析仪优先因为协议层的调试需求更多。关于代码组织。协议栈代码分三层物理层字节收发、传输层T0/T1/块传输、应用层APDU构造和解析。层与层之间通过明确的接口通信方便替换和测试。我一开始把三层混在一起写后来重构了一次清晰多了。关于测试用例。我建了一个测试卡集合包含不同厂商、不同协议、不同应用的卡片。每次修改代码后跑一遍测试用例确保没有回归。这个习惯帮我避免了很多低级错误。关于文档。ISO 7816和ISO 14443的标准文档很厚但值得花时间读。我一开始只看别人写的摘要结果遇到细节问题还是要回去翻标准。标准文档里有很多“看起来没用但实际很重要”的细节比如时序参数、状态字含义、命令格式的边界情况。关于社区。智能卡和RFID领域有很多活跃的社区和开源项目。遇到问题时先搜一下有没有人遇到过类似情况。我很多问题的答案都是从社区里找到的。当然自己也要贡献把踩过的坑写出来帮助后来人。关于迭代节奏。这个项目我从最初的想法到能用的版本花了大概三个月。中间经历了两次大的重构。我的建议是先跑通最小可用版本再逐步加功能。不要一开始就追求完美那样容易卡住。关于成本。整个分析仪的物料成本大概在200到300元之间主要花费在射频前端芯片和MCU上。如果只是做接触式分析成本可以降到100元以内。对于个人项目来说这个成本是可以接受的。关于下一步。我打算加一个蓝牙模块把分析仪的数据实时传到手机上。这样调试时不用一直盯着小屏幕手机上就能看十六进制数据。另外还想加一个SD卡槽方便导出大量日志。这些都在计划中等实现了再分享。
1. 从一张“刷不开”的门禁卡说起这个分析仪到底在解决什么问题手里攒了一堆卡片——门禁卡、食堂卡、公交卡、银行卡还有几张不知道干嘛用的白色IC卡。某天你突然想搞清楚这些卡到底用的什么协议里面存了什么数据为什么有的卡贴上去秒响应有的卡要蹭半天更实际一点的需求是公司门禁卡丢了能不能自己复制一张备用小区门禁能不能写进手机里这些问题背后其实指向同一件事你需要一个能跟卡片“对话”的工具。不是那种只能读个卡号就完事的廉价读卡器而是能真正理解ISO 7816协议、能处理非接触式支付卡通信的分析仪。我手上这个便携式分析仪就是干这个的。它支持ISO 7816接触式协议和非接触式支付卡两大模式能完成从物理层信号到应用层数据的完整解析。说白了它既能把卡片激活、复位、发送APDU指令也能通过射频接口跟非接触卡进行数据交换最后把原始数据、协议帧结构、甚至卡片返回的状态字都清清楚楚地展示出来。这个东西适合谁用如果你是嵌入式开发者想调试自己的智能卡读写方案它能帮你抓协议层的问题如果你是安全研究者想分析卡片的认证流程和数据结构它能给你提供底层视角如果你只是个爱折腾的极客想搞明白自己每天刷的卡到底怎么回事它也能让你看个明白。当然前提是你得在法律允许的范围内使用——分析自己的卡、做技术学习这没问题但拿去搞别人的卡那就是另一回事了。我最初做这个分析仪的动机很简单市面上的读卡器要么太贵要么太封闭要么只支持一种协议。我想要一个能同时处理接触式和非接触式、协议解析透明、方便二次开发的工具。于是就有了这个项目。下面我会从硬件选型、协议栈实现、非接触式通信的坑、以及实际调试经验几个方面把整个东西拆开来讲。2. 硬件选型为什么最后选了这套组合2.1 接触式接口的芯片选择与电平匹配问题ISO 7816接触式接口的核心是电平转换和时序控制。卡片的工作电压有Class A5V、Class B3V、Class C1.8V三种而大多数微控制器的IO是3.3V。你不能直接把3.3V的IO接到卡座上——如果卡片是5V的3.3V可能驱动不起来如果卡片是1.8V的3.3V直接怼上去可能把卡打坏。我一开始想用分立MOS管做电平转换搭了个电路测试发现时序根本对不上。ISO 7816的复位应答ATR对时序要求很严格上升沿和下降沿的时间窗口很窄分立方案的一致性太差。后来换成了专用的ISO 7816接口芯片比如TDA8035或者ST8024这类。这类芯片内部集成了电平转换、过流保护、时钟分频你只需要给它供电、给时钟、给复位信号它就能帮你完成卡片激活的全套流程。具体接线是这样的微控制器通过UART或者SPI跟接口芯片通信接口芯片再通过C1VCC、C2RST、C3CLK、C5GND、C7I/O跟卡片连接。这里有个细节C4和C8在ISO 7816标准里是预留的但很多卡片会把它用作辅助触点如果你不接有些卡可能不工作。我在PCB上把C4和C8都引出来了通过跳线选择是否连接实测下来大部分卡不接也没问题但个别老卡确实需要。注意卡片插入检测最好用机械开关加软件去抖不要只靠电流检测。我试过用电流检测判断卡片是否插入结果有些低功耗卡在待机时电流太小根本检测不到。2.2 非接触式13.56MHz射频前端的设计取舍非接触式支付卡工作在13.56MHz遵循ISO 14443标准。这部分比接触式麻烦得多因为涉及到射频匹配、天线设计、载波调制和解调。我试过三种方案。第一种是用分立元件搭射频前端包括振荡器、功放、检波电路。搭出来能读到卡但读距只有几毫米而且稍微动一下卡片就丢数据。第二种是用现成的射频读写芯片比如MFRC522或者PN532。这类芯片集成度高SPI接口简单但问题是它们对ISO 14443-4层的支持有限尤其是处理支付卡那种复杂的APDU交互时经常需要自己补协议栈。最后我选了支持ISO 14443-4的射频前端芯片配合一个可调匹配网络。天线用的是PCB印刷天线四圈矩形走线电感量大概1.5微亨。匹配网络用两个电容做谐振调到13.56MHz。这里有个经验天线的Q值不要调太高。Q值高了读距远但带宽窄卡片稍微偏离中心就通信失败。我最后把Q值控制在20左右读距大概3到5厘米但容错性好很多。射频部分的供电要特别注意。功放工作时电流波动很大如果电源纹波大载波上会叠加噪声导致解调误码。我在电源入口加了LC滤波功放单独用一路LDO供电跟数字部分隔离开。实测下来这样处理后误码率明显下降。2.3 主控与存储为什么选了带硬件加密的MCU主控选的是带硬件加密引擎的MCU。原因很简单分析支付卡时你可能会遇到需要计算MAC或者做认证的场景。如果纯软件实现DES或者AES速度慢不说还容易被侧信道攻击。硬件加密引擎虽然不能完全防侧信道但至少比软件实现强。存储方面我挂了一片SPI Flash用来存日志和抓包数据。分析仪工作时会把所有APDU交互都记录下来包括时间戳、方向、数据内容。这些数据量不小一次完整的支付流程可能产生几十KB的日志。Flash容量选了8MB够存几百次交互记录。屏幕用的是一块小尺寸TFT240x320分辨率SPI接口。显示内容主要是菜单、状态、以及十六进制数据。按键用了五个上、下、确认、返回、复位。操作逻辑很简单就是树形菜单不搞花哨的UI。3. ISO 7816协议栈从冷复位到APDU交互的完整链路3.1 卡片激活流程与ATR解析中的常见异常ISO 7816的卡片激活流程分几步上电、时钟供给、复位释放、等待ATR。听起来简单但每一步都有坑。上电顺序很重要。标准要求先给VCC和GND再给CLK和RST。我一开始图省事同时上电结果有些卡直接不响应。后来老老实实按顺序来VCC上电延时1msCLK启动延时1msRST拉低再拉高。这样下来卡片激活成功率明显提高。ATRAnswer To Reset是卡片返回的第一串数据格式是TS T0 接口字节 历史字节 校验字节。TS是初始字符通常是0x3B直接约定或者0x3F反向约定。T0的高四位表示后续接口字节的数量低四位表示历史字节的数量。接口字节TA、TB、TC、TD分别描述协议参数、时钟频率、等待时间、以及后续协议类型。我遇到过一种情况卡片返回的ATR里TD1指向T1协议但我的代码默认按T0处理结果后续通信全部失败。后来加了协议自动识别逻辑根据TD字节判断用T0还是T1。T0是面向字符的T1是面向块的两者在帧格式和错误处理上完全不同。实操心得ATR解析不要只读前几个字节就下结论。有些卡会在历史字节里放厂商信息但历史字节的格式没有统一标准不同厂商不一样。我一般把完整ATR打印出来人工看一眼再决定后续参数。3.2 T0与T1协议的帧结构差异及代码实现T0协议是面向字符的。每个字节独立传输每个字节有一个起始位、八个数据位、一个奇偶校验位、一个停止位。接收方如果校验失败会在下一个字节的采样点拉低I/O线发送方检测到后重发。这种机制叫错误信号。T0的APDU命令头是5个字节CLA、INS、P1、P2、P3。P3表示后续数据的长度。如果命令有数据要发给卡P3就是数据长度如果命令期望卡返回数据P3就是期望返回的最大长度。卡返回的数据后面会跟两个字节的状态字SW1和SW2表示执行结果。T1协议是面向块的。数据被组织成块每个块有 NAD、PCB、LEN、INF、EDC 几个字段。NAD是节点地址PCB是协议控制字节LEN是数据长度INF是信息字段EDC是校验码。T1支持块链一个APDU可以分成多个块传输适合大数据量场景。代码实现上T0相对简单就是字节收发加奇偶校验。T1复杂一些需要处理块的组装和拆分还要管理发送序号和接收序号。我一开始只实现了T0后来遇到一张卡只支持T1不得不补上。补的时候发现T1的EDC校验有两种LRC和CRC。LRC是异或校验CRC是16位循环冗余校验。具体用哪种要看ATR里的TC字节或者协议协商结果。// T0字节收发示例伪代码 uint8_t t0_transceive(uint8_t byte) { uint8_t rx 0; io_low(); // 起始位 delay_half_bit(); for (int i 0; i 8; i) { if (byte 0x01) io_high(); else io_low(); delay_bit(); byte 1; } // 奇偶校验位 if (parity(byte)) io_high(); else io_low(); delay_bit(); io_high(); // 停止位 delay_bit(); // 接收卡片返回 // ... return rx; }3.3 APDU命令构造与状态字处理的实战细节APDU是应用层协议数据单元分命令APDU和响应APDU。命令APDU的格式是CLA INS P1 P2 Lc Data Le。响应APDU是Data SW1 SW2。构造命令时最容易出错的是Le字段。Le表示期望返回的数据长度。如果Le0表示期望返回256字节在短APDU模式下。如果Le不写表示不关心返回长度。我一开始经常搞混导致卡片返回6700长度错误或者6Cxx长度不对xx是实际长度。状态字SW1 SW2的含义需要查ISO 7816-4标准。常见的比如9000表示成功6A82表示文件未找到6982表示安全状态不满足6Cxx表示长度错误。实际调试时我建议把状态字含义做成一个查找表遇到不认识的就去查标准文档。有个细节61xx状态字表示卡片还有xx字节数据待取。这时候你需要发送GET RESPONSE命令CLA00, INSC0把剩余数据取回来。我遇到过一张卡返回61xx后我直接发下一条命令结果卡片返回6985使用条件不满足。后来才知道必须先GET RESPONSE。注意不同卡对APDU的兼容性差异很大。同一套命令在A卡上能跑通在B卡上可能就报错。调试时最好先用简单的SELECT命令测试确认基本通信正常后再上复杂命令。4. 非接触式支付卡分析射频通信与支付流程拆解4.1 ISO 14443-3防冲突与UID获取的实操要点非接触式卡进入射频场后首先经历防冲突流程。因为读卡器可能同时面对多张卡需要一套机制选出一张来通信。ISO 14443-3定义了REQA/WUPA命令和防冲突循环。REQA是请求命令卡片收到后返回ATQAAnswer To Request。ATQA里包含UID的长度信息。然后读卡器发送防冲突命令卡片返回UID的一部分。如果有多张卡读卡器会检测到冲突调整防冲突命令的参数直到选出唯一一张卡。实操中防冲突失败是最常见的问题。原因可能是多张卡同时在场也可能是卡片刚进入射频场还没稳定。我的做法是先发REQA如果没响应就等10ms再发连续三次没响应就报错。如果有响应但防冲突失败就重新走一遍防冲突流程最多重试五次。UID的长度有4字节、7字节、10字节三种。4字节UID的卡通常叫短UID卡7字节和10字节的叫长UID卡。有些门禁系统只认短UID长UID卡读出来会被拒绝。如果你要复制门禁卡这一点要特别注意。// 防冲突流程简化示例 uint8_t uid[10]; uint8_t uid_len 0; send_reqa(); if (wait_atqa()) { // 防冲突级别1 send_anticoll(0x93, 0x20); if (read_uid_cl1(uid, uid_len)) { // 检查是否有更多UID if (uid_len 4) { // 短UID完成 } else { // 继续防冲突级别2 send_anticoll(0x95, 0x20); read_uid_cl2(uid 4, uid_len); } } }4.2 RATS与PPS协商进入ISO 14443-4层的必经之路拿到UID后如果要进行支付相关的交互需要进入ISO 14443-4层。这一步通过RATSRequest for Answer To Select命令完成。卡片收到RATS后返回ATSAnswer To Select里面包含卡片支持的参数比如最大帧长度、是否支持CID等。RATS命令的格式是0xE0 参数字节。参数字节的高四位表示CID逻辑通道号低四位表示FSDI帧大小指示。FSDI决定后续通信的最大帧长度从16字节到256字节不等。ATS返回后可能还需要PPSProtocol and Parameter Selection协商。PPS用来调整通信速率从106kbps到848kbps。不过很多支付卡不支持高速率PPS协商会失败这时候就保持默认的106kbps。我踩过一个坑RATS命令的CID字段。如果卡片不支持CID你发了带CID的RATS卡片可能不响应。我一开始没注意给所有卡都发CID1的RATS结果有些卡直接沉默。后来改成先发CID0的RATS确认卡片支持后再尝试其他CID。实操心得RATS之后如果卡片返回ATS说明已经进入ISO 14443-4层。这时候就可以发送APDU命令了。但要注意非接触式的APDU封装在块传输协议里跟接触式的T0/T1不一样。ISO 14443-4的块格式是PCB CID NAD INF CRC需要单独实现。4.3 支付卡APDU交互流程与常见状态字解读支付卡的APDU交互通常从SELECT PPSE开始。PPSE是Proximity Payment System Environment里面列出了卡片支持的支付应用。命令是SELECTAID是2PAY.SYS.DDF01。SELECT成功后返回FCIFile Control Information里面包含应用列表。然后你需要SELECT具体的支付应用比如某卡组织的AID。SELECT成功后会返回PDOLProcessing Options Data Object List告诉读卡器需要提供哪些数据。接下来是GPOGet Processing Options命令。读卡器根据PDOL构造数据发给卡片。卡片返回AIPApplication Interchange Profile和AFLApplication File Locator。AIP表示卡片支持的功能AFL告诉读卡器去读哪些文件。然后就是READ RECORD循环根据AFL读取卡片上的记录。这些记录里包含卡号、有效期、持卡人姓名等信息。最后可能还有GENERATE AC命令用于生成交易密文。常见状态字方面除了前面提到的9000、6A82、6982支付卡还会返回6283卡片被锁定、6300认证失败、6D00指令不支持。我遇到最多的是6985通常是命令顺序不对比如没SELECT就直接GPO。// SELECT PPSE示例 uint8_t cmd[] { 0x00, 0xA4, 0x04, 0x00, 0x0E, 0x32, 0x50, 0x41, 0x59, 0x2E, 0x53, 0x59, 0x53, 0x2E, 0x44, 0x44, 0x46, 0x30, 0x31, 0x00 }; // 发送命令并解析响应 // 响应格式6F 长度 84 长度 DF名称 A5 长度 BF0C ...5. 调试过程中踩过的坑与排查思路5.1 接触式卡片不响应的排查链路有一次一张卡插进去死活不响应。我按以下顺序排查第一步检查供电。用万用表量C1和C5之间的电压发现只有1.2V明显不对。正常应该是3V或5V。查电路发现是LDO输出电容虚焊补焊后电压恢复正常。第二步检查时钟。用示波器看C3引脚发现没有时钟信号。查代码发现时钟配置寄存器写错了分频系数设得太大实际输出只有几百赫兹。改回正确分频后时钟恢复。第三步检查复位时序。用逻辑分析仪抓RST和I/O线的波形发现RST释放后I/O线一直是高电平没有ATR返回。怀疑是卡片坏了换了一张卡正常。确认是卡片问题。这个排查链路我后来固化成了流程先查供电再查时钟再查复位最后查卡片本身。大部分问题在前三步就能定位。5.2 非接触式读距短与丢包的优化过程非接触式读距短我一开始以为是天线问题换了更大的天线读距确实远了但丢包率也上去了。后来用频谱仪看载波信号发现载波上有很多谐波导致解调器误判。优化过程分几步。首先调整匹配网络。把谐振电容从原来的值微调让谐振点更准地落在13.56MHz。其次降低功放增益。增益太高虽然读距远但信号失真严重。降了3dB后读距略近但丢包率大幅下降。最后优化解调阈值。解调器的比较阈值原来设得偏高导致弱信号被忽略。调低阈值后读距和稳定性都改善了。最终读距稳定在3到5厘米丢包率低于1%。对于便携式设备来说这个表现够用了。5.3 支付卡认证失败的原因分类与应对支付卡认证失败我遇到过几种情况。一种是密钥不匹配。卡片和读卡器之间的认证需要共享密钥。如果密钥不对卡片会返回6300。这种情况没法绕过只能确认密钥是否正确。另一种是随机数生成问题。认证过程中读卡器需要生成随机数发给卡片。如果随机数质量差比如重复或者可预测卡片可能拒绝。我后来用了MCU的硬件随机数生成器问题解决。还有一种是时间窗口超时。支付卡对认证过程有时间限制如果读卡器响应太慢卡片会终止会话。我优化了代码把认证流程的执行时间从200ms压缩到50ms以内超时问题不再出现。注意分析支付卡时不要尝试修改卡片数据。支付卡通常有防篡改机制一旦检测到异常写入可能永久锁定。分析仪的设计原则是只读不写除非你明确知道自己在做什么。6. 从分析仪到实际应用几个可复现的扩展方向6.1 把分析仪变成门禁卡模拟器分析仪本身是读卡设备但加上卡模拟功能后就能变成门禁卡模拟器。实现方式是用MCU的射频前端发送载波然后按照ISO 14443-3的协议响应读卡器的命令。具体步骤先分析目标门禁卡的UID和认证流程然后在MCU里模拟相同的响应。对于只认UID的门禁系统模拟UID就够了。对于需要认证的系统还需要模拟认证过程。我试过模拟一张短UID门禁卡成功刷开了公司的门禁。但要注意模拟卡和真卡不能同时在场否则会发生防冲突两个都不工作。6.2 用脚本自动化批量分析卡片分析仪支持通过串口跟电脑通信。我写了一个Python脚本通过串口发送命令自动执行SELECT、GPO、READ RECORD等操作然后把结果保存成JSON文件。import serial import json ser serial.Serial(COM3, 115200, timeout1) def send_apdu(apdu_hex): ser.write(bytes.fromhex(apdu_hex)) response ser.read(1024) return response.hex() # 批量分析 cards [] for i in range(10): print(f请插入第{i1}张卡...) input() uid send_apdu(00A404000E325041592E5359532E444446303100) cards.append({index: i, uid: uid}) with open(cards.json, w) as f: json.dump(cards, f, indent2)这个脚本帮我快速建立了一个卡片数据库记录了每张卡的UID、支持的协议、以及基本数据。6.3 协议模糊测试用分析仪找卡片实现的边界分析仪还可以用来做协议模糊测试。就是发送一些非标准的、边界情况的APDU命令看卡片怎么响应。比如发送超长的Le、非法的CLA、不存在的INS等。我测试过一张卡发送CLAFF的命令卡片返回6E00类别不支持。发送INSFF返回6D00指令不支持。发送P3255但实际数据只有10字节卡片返回6700长度错误。这些响应都符合标准。但也遇到过不按标准来的卡。有一张卡发送非法命令后直接不响应需要复位才能恢复。这种卡在实际使用中可能会因为异常命令而挂死值得注意。模糊测试的边界要控制好不要发送可能触发卡片自毁的命令。对于支付卡尤其要小心。7. 一些零散但重要的经验关于电源管理。便携设备靠电池供电功耗控制很重要。我的做法是接触式接口不工作时断电非接触式射频前端在待机时进入低功耗模式MCU在空闲时降频。这样下来一块2000mAh的电池能撑一整天。关于固件升级。分析仪预留了USB接口支持固件升级。升级协议用的是简单的XMODEM稳定可靠。升级时要注意不要断电否则可能变砖。我在Flash里放了bootloader即使应用固件损坏也能通过bootloader恢复。关于外壳。3D打印的外壳材料是ABS。打印时要注意射频天线区域不要被金属遮挡否则读距会大幅下降。我把天线区域的外壳厚度控制在1mm以内并且没有放任何金属件。关于法律合规。这一点必须强调分析仪只能用于分析你自己拥有的卡片或者你明确获得授权的卡片。未经授权读取、复制他人卡片信息在很多地方是违法的。技术本身没有对错但使用方式有边界。关于调试工具。逻辑分析仪和示波器是必备的。逻辑分析仪用来抓协议时序示波器用来看射频波形。我用的是一台入门级逻辑分析仪和一台100MHz带宽的示波器够用了。如果预算有限逻辑分析仪优先因为协议层的调试需求更多。关于代码组织。协议栈代码分三层物理层字节收发、传输层T0/T1/块传输、应用层APDU构造和解析。层与层之间通过明确的接口通信方便替换和测试。我一开始把三层混在一起写后来重构了一次清晰多了。关于测试用例。我建了一个测试卡集合包含不同厂商、不同协议、不同应用的卡片。每次修改代码后跑一遍测试用例确保没有回归。这个习惯帮我避免了很多低级错误。关于文档。ISO 7816和ISO 14443的标准文档很厚但值得花时间读。我一开始只看别人写的摘要结果遇到细节问题还是要回去翻标准。标准文档里有很多“看起来没用但实际很重要”的细节比如时序参数、状态字含义、命令格式的边界情况。关于社区。智能卡和RFID领域有很多活跃的社区和开源项目。遇到问题时先搜一下有没有人遇到过类似情况。我很多问题的答案都是从社区里找到的。当然自己也要贡献把踩过的坑写出来帮助后来人。关于迭代节奏。这个项目我从最初的想法到能用的版本花了大概三个月。中间经历了两次大的重构。我的建议是先跑通最小可用版本再逐步加功能。不要一开始就追求完美那样容易卡住。关于成本。整个分析仪的物料成本大概在200到300元之间主要花费在射频前端芯片和MCU上。如果只是做接触式分析成本可以降到100元以内。对于个人项目来说这个成本是可以接受的。关于下一步。我打算加一个蓝牙模块把分析仪的数据实时传到手机上。这样调试时不用一直盯着小屏幕手机上就能看十六进制数据。另外还想加一个SD卡槽方便导出大量日志。这些都在计划中等实现了再分享。
