最近调试openwifi（开源WiFi芯片），觉得FPGA里的low MAC状态机错综复杂，实在头大（自食其果，自作自受）。于是萌生了“重构”的念头。我深知这是一个危险的想法，但也是一个充满诱惑的想法，想想就刺激。但不妨碍先想想，想想而不动手，这就是传说中的yy吧。
用FPGA状态机来实现WiFi low MAC最大的好处是实时性无人能敌，在低于0.01us的时间上精确地闪转腾挪，如入无人之境，但可惜可维护性，易读性，调试性，实在不好。当功能随着协议的升级越来越复杂，这些状态机令人头大的程度呈几何级数增长。理想的low MAC应该是一套实时软件来实现，兼顾实时性和可维护性等方面。就像大多数高级点的WiFi芯片那样，芯片内有个小MCU，跑着程序，掌控一切。
这些WiFi芯片上跑的程序的binary image一般是Linux加载WiFi网卡驱动的时候由网卡驱动加载到芯片内。这个binary就叫做blob，泛指不开源的firmware image，firmware也称作固件。根据wiki（Proprietary device driver https://en.wikipedia.org/wiki...），提供非开源blob形式驱动的主要有显卡（比如著名的被Linus竖中指的Nvidia），无线网卡和RAID控制器
上面这些当然也都是Linux生态比较头疼的重灾区。首先从Linux的驱动程序层面，要想为这些芯片的驱动打补丁（比如厂家早就停止支持这款芯片，只能社区自己维护，或者有时候就算厂家支持，时效性也难以保证），或者写更好的开源驱动，就得对芯片里固件的功能十（猜）分（来）了（猜）解（去）。不过这一步好歹有原厂的驱动程序做参考，大概的样子是知道的。
如果要比Linux驱动更进一步（进入驱动之下的芯片），比如想修改这些芯片里的固件或者给芯片写一个开源固件？那更是难上加难。你面对一个黑黑的芯片，需要搞清楚里面用了什么CPU，这个CPU在芯片内有什么外设，相应的寄存器定义，地址空间定义，开发工具是什么，固件如何加载进去（加密、校验、保护什么的），这个CPU如何和外部的主机通信，又是如何控制芯片里的Radio部分的，等等等等。
想修改或者重写WiFi芯片里的固件，就要搞清楚上面这些问题。目前社区里的黑客们搞清楚上面这些问题的主要手段就是反向工程。反向工程的具体手段包括但不限于：
- 对固件的反编译（毕竟固件文件是从Linux这边传过去的，可以拿得到）
- 对固件加载过程的监测
- 尝试找到WiFi板子上的调试接口（JTAG，串口等），然后进入一探究竟
- 泄露出来的芯片内部文档（比如从这个芯片的某些大客户那里）
- 一些芯片厂员工（或者离职员工）在某些论坛上的只言片语
- 社工
- 对于某些WiFi芯片，上面的那些问题已经搞的比较清楚，人们甚至已经可以修改、重写WiFi芯片里的CPU（ARM居多）上的程序，让WiFi芯片的DAC发射任意信号（IQ sample，类似USRP那样）。比如这个nexmon项目（seemoo-lab/nexmon）。
未完待续。
