交易初始化与GPO：SELECT命令详解
各位好，我是老周。今天咱们聊聊EMV交易的第一步——初始化。说白了，就是卡片和终端怎么互相认识的过程。
我做了这么多年安全分析，发现很多人对SELECT命令的理解停留在表面。其实这里面的门道不少。你想想看，终端怎么知道插进来的是张信用卡还是借记卡？靠的就是SELECT命令。
SELECT命令到底在干什么
SELECT命令，全称是SELECT FILE命令。它的作用就是让终端告诉卡片：「嘿，我要访问你的某个应用」。卡片收到后，会返回这个应用的基本信息。
我记得刚入行那会儿，总觉得SELECT就是选个应用而已，没什么技术含量。直到有一次做渗透测试，发现有人利用SELECT命令的响应数据做文章，我才意识到这里的水有多深。
核心要点：SELECT命令是终端与卡片建立通信的第一步，它决定了后续所有交互的基础。
SELECT命令的APDU结构
咱们来看看SELECT命令长什么样。APDU（应用协议数据单元）是终端和卡片通信的基本单位。
CLA INS P1 P2 Lc Data_field Le
00 A4 04 00 0E 2PAY.SYS.DDF01 00解释一下：
- CLA (00)：命令类别，00表示ISO标准
- INS (A4)：指令码，A4就是SELECT
- P1 (04)：选择方式，04表示按名称选择
- P2 (00)：第一个或唯一一个
- Lc (0E)：数据长度，14字节
- Data_field：要选择的应用ID（AID）
- Le (00)：期望返回的最大长度
这里有个坑，我踩过。P1参数的值很关键。04是按名称选择，00是按文件标识符选择。有些卡片只支持其中一种，选错了直接返回6A81（不支持的功能）。
避坑指南：我曾经在测试某银行的卡片时，发现它只响应P1=04的SELECT命令。后来查资料才知道，EMV规范要求终端必须优先使用按名称选择。
SELECT命令的响应
卡片收到SELECT命令后，会返回一堆数据。这些数据里藏着很多信息。
6F 38 84 0E 2PAY.SYS.DDF01 A5 26 9F38 18 9F6604 9F0206 9F0306 9F1A02 9F3501 9F3303 9F3403 9F4E14 BF0C 0C 9F4D 0A 0A 01 02 03 04 05 06 07 08 09 0A 90 00响应数据是TLV格式的。我习惯把它拆开来看：
- 6F：文件控制信息模板
- 84：应用标识符（AID）
- A5：文件控制信息专用模板
- 9F38：处理选项数据对象列表（PDOL）
- BF0C：文件控制信息发行者数据
嗯，这里要注意PDOL。它告诉终端：「我需要哪些数据才能继续处理」。终端必须按照PDOL的要求提供数据，否则卡片会拒绝后续操作。
GET PROCESSING OPTIONS命令
SELECT命令完成后，终端知道了卡片支持什么应用。接下来要问卡片：「你想怎么处理这笔交易？」这就是GET PROCESSING OPTIONS（GPO）命令的作用。
说白了，GPO就是终端问卡片：「这笔交易，你打算怎么走？」卡片会回答：「用这些数据，按这个流程来」。
GPO命令的APDU结构
80 A8 00 00 1C 83 1A 9F0206 000000010000 9F0306 000000000000 9F1A02 0156 9F3501 21 9F3303 E0F0C8 9F3403 030201 9F4E14 0102030405060708090A0B0C0D0E0F10111213 00GPO命令的CLA是80，INS是A8。数据部分就是PDOL里要求的数据。
我见过很多开发者在构造GPO命令时出错。最常见的问题就是数据顺序不对。PDOL里列出的数据对象，必须按顺序提供，一个都不能少，一个都不能多。
小技巧：我个人习惯在解析PDOL时，先把它转成列表，然后逐个匹配。这样不容易漏掉或搞错顺序。
GPO的响应：AIP与AFL
GPO命令的响应里，最重要的两个数据对象是AIP和AFL。
AIP（应用交互配置文件）：告诉终端卡片支持哪些功能。比如是否支持SDA、DDA、CDA，是否支持联机处理等。
AFL（应用文件定位器）：告诉终端要去读哪些记录。每个AFL条目包含SFI（短文件标识符）和记录范围。
我举个例子，AIP的值可能是7C00：
- Bit 8 (0x80)：支持SDA
- Bit 7 (0x40)：支持DDA
- Bit 6 (0x20)：支持CDA
- Bit 5 (0x10)：支持终端风险管理
- Bit 4 (0x08)：支持发行方认证
你看，一个字节就包含了这么多信息。这就是为什么我说逆向分析时，AIP是必看的数据。
PDOL与终端数据
PDOL（处理选项数据对象列表）是卡片发给终端的「需求清单」。它告诉终端：「我需要这些数据，你准备好再叫我」。
PDOL的格式很简单，就是一系列的数据对象标签和长度。比如：
9F0206 9F0306 9F1A02 9F3501 9F3303 9F3403 9F4E14这表示卡片需要：
- 9F02（授权金额）：6字节
- 9F03（其他金额）：6字节
- 9F1A（终端国家代码）：2字节
- 9F35（终端类型）：1字节
- 9F33（终端能力）：3字节
- 9F34（终端执行选项）：3字节
- 9F4E（商户名称）：20字节
终端收到PDOL后，必须从自己的数据池里找到这些数据，然后组装成GPO命令的数据部分。
实战经验：我在做EMV终端模拟器时，发现很多卡片对终端数据的格式要求很严格。比如金额字段，必须是右对齐左补零。有一次我忘了补零，卡片直接返回了6985（条件不满足）。
知识体系总览
为了让大家更直观地理解交易初始化的流程，我画了一张图：
这张图把整个流程串起来了。从SELECT开始，到解析PDOL，再到GPO，最后根据AFL读取记录。每一步都有它的意义。
做逆向分析时，我建议你重点关注两个地方：一是SELECT命令返回的PDOL，它决定了终端要准备哪些数据；二是GPO返回的AIP和AFL，它们决定了后续的认证流程和数据读取范围。
个人建议：刚开始接触EMV的朋友，可以先从抓包分析入手。用PC/SC工具抓一次完整的交易流程，对照规范看每个字节的含义。我当年就是这么入门的，效果很好。
好了，交易初始化这部分就聊到这儿。记住，SELECT和GPO是EMV交易的基石，搞懂了它们，后面的流程就顺理成章了。
公众号:蓝海资料掘金营，微信deep3321