（写在前面：翻译这篇文章实在有点力不从心，作者可能太极客，文章的逻辑不太强，语言指代有时候也不明确。我自己对于NFC也不是特别懂，还请大家将就着看，有疑惑请参照原文：https://www.pentestpartners.com/security-blog/building-half-a-proxmark-for-10/）

Proxmark是一款出色的设备，我们机构有一些。 但对于NFC（近场通讯）业余爱好者来说，Proxmark有些过于昂贵，而可用的仿制设备则更少。但如果你有些焊接技能，通过学习下面的方法，用大约10美元的元件，便可以构造出一款NFC标签模拟器。

本篇文章将展示如何逆向构建ISO-14443A标准的协议，以查看哪里存在可利用的弱点。 我们创建了一个能够模拟Mifare标签的设备，尽管其加密技术存在已知的弱点，但它们通常被认为是具有严格和模糊访问控制的黑盒子。 我打算在加密层之外找到弱点，因为这些都是完全开放的。

本项目中，我决定不用这种平台下的任何传统调试装置来开发这个设备。这包括一个传统的USB NFC读写器，如下所示：

https://www.amazon.co.uk/Yosoo-ACR122U-Contactless-Reader-5xMifare/dp/B00GYPIZG6/ref=sr_1_6?ie=UTF8&qid=1516009490&sr=8-6&keywords=nfc+reader

我也决定不用Proxmark3或Chameleon Mini这种更倾向服务于安全专业人士的工具：

https://store.ryscc.com/products/new-proxmark3-kit

https://www.kickstarter.com/projects/1980078555/chameleonmini-a-versatile-nfc-card-emulator-and-mo

在开发过程中，我发现了一个类似的项目（网址如下），它使用了可能已经改编的类似硬件。尽管这个项目有一些很好的想法，但我还是想从头开始设计。

http://blog.nonan.net/2013/11/simple-nfc.html

我想自己开发的原因是，尽管这些工具在性能上肯定非常优越，同时可以根据用户的需要随时修改。但仅仅使用这些工具，并不能让我得到与自己从头开发设备相同的见解。

调试本项目的关键装置是我的Hobby Components Logic Analyzer和RTL-SDR。 对于编程和开发，我使用了Arduino来编写成为项目核心的ATTiny84，并使用了STM32f401re开发板进行调试（后面会说明为什么必须这样做）。

在开发过程中，我发现必须通过带外数据的方式来分析读写器中的命令 。 读取器本身无法直接访问这些信息，因为它的USB实现完全是作为HID（人机界面设备）进行设置的，对设备上的NFC硬件访问受限。 我决定了使用我信任的RTL-SDR来获取必要信息是最佳选择。 在过去，RTL-SDR已被证明能够查看NFC数据包，因此我觉得可以创建一个应用程序来执行此操作。

最初，我使用了我早前的一个项目，它允许用户查看SDR IQ样本及其幅度，并使用传统的逻辑分析软件对其进行分析：

https://github.com/Iskuri/RTLSDR-to-Pulseview

关于这个项目首先要注意的是，标准的RTL-SDR无法调谐到NFC读写器使用的相同频率，即13.56Mhz。但是，它不仅可以调谐到它的谐波频率之一 - 27.12Mhz ，同时我们在调谐至该频率并通过运行分析仪后发现，读写器的传输易于用标准进行查看，因此编写应用程序将其解码用于分析很简单。但可惜的是，由于使用了传输和调制方案（稍后会详细介绍），RTL-SDR标签的响应将不可见。考虑到这一信息，我创建了一个采样频率为27.12Mhz，采样率为1.695Mhz的应用程序（选择此采样率是因为它处于RTL-SDR的允许采样率范围内，并且也是读写器数据率的倍数）。从这里输出的数据中，我可以解析出读写器的命令，以便查看它们进行调试，最终创建这个小工具：

https://github.com/Iskuri/RTLSDR-NFC

不幸的是，由于这个工具只能分析读写器的命令，而不能分析标签的命令，所以在之后的调试中，特别是调试加密层时，还是有问题。通过使用逻辑分析仪来跟踪命令和响应，可以缓解这些问题。

我决定使用ATTiny84作为设备的核心MCU（微控制器），因为它可以很容易地使用外部时钟，具有相当大的程序空间，并且还具有板载EEPROM。 为了以正确的频率工作，我使用了一个13.56Mhz的晶体，配合适当的电容来匹配它，并且为了接收来自读写器的命令，我使用了一个谐振电感耦合器：

https://en.wikipedia.org/wiki/Resonant_inductive_coupling

馈入一个包络检测器

https://en.wikipedia.org/wiki/Envelope_detector

然后将其连接到GPIO输入引脚以接收信号。

使用该芯片有一个关键的弱点，那就是外部晶振的引脚与UART使用的引脚相同。 由于我为了实现在线串行编程器而安装的Arduino 不能通过任何其他方法进行调试，因此必须通过不同引脚上的任何调试字符串将时钟输出到STM32f401re板，该板再将其转换为UART。因为基于软件的UART 在这些频率上太不一致了。

为了减少噪音，我在电源和接地引脚之间增加了电解电容和超级电容。

然后将它汇总到以下原型电路板中：

低级NFC协议非常简单。 读写器和标签使用两种不同的编码方案进行通信。

读写器使用一种称为修改米勒的编码方案，定义如下：

•      0比特跟着0比特：传输的前四分之一是低位，之后都是高位。

•      1比特：传输的前二分之一是高位，之后四分之一是低位，再之后都是高位。

•      1比特跟着1比特：整个传输都是高位。

用于发送命令的编码示例如下：

当读写器与标签进行通信时，会降低提供给标签用以通信的功率。 这种编码方案是专门设计用于当电源被禁用时，让标签有足够的剩余电力来处理交易。

标签使用了一种更传统的无线电通信编码 - 曼彻斯特编码。

该协议使用从高位到低位的设置来编码1，或者从低位到高位的设置来编码0.为了使用这个协议进行通信，它使用了所谓的“负载调制”。 这调制了一个信号，以便在发送给标签的功率上产生阻力，读写器可以将其理解为响应。

有关这些编码方案的更多信息，请查看：http://www.radio-electronics.com/info/wireless/nfc/near-field-communications-modulation-rf-signal-interface.php.

数据包由帧开始位，随后是帧的一个字节，以及基于字节中置位和未置位位数的奇偶校验位构成。 字节按顺序发送，先传送最低有效位，例如下面的命令：

上面的命令是REQA命令，用于请求任何新的读写器响应标签。

命令由标签发送和响应，以便在两个设备之间进行通信的状态机进行处理：

由于在ATTiny上实现协议产生了一些问题，我进行了一些迭代处理，其中最关键的是时钟漂移。 一般情况下对于ATTiny来说，时钟漂移会有很大的问题，因此，我最初试图纯粹使用时钟和间隔来实现协议，以便为发送的修改的密勒比特接收一个位掩码，比如：

只有60%的情况下通信能顺利完成。这是不够的，因为读写器会一直认为标签被移除，然后重新引入场。

由于这个原因，我们将定时器与GPIO中断一起使用，并检查每次引脚设置为低电平之间的时间，从而允许有足够的时钟漂移量，同时仍然获得完整的通信。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课