【原创】机械键盘USB协议逆向和利用

2021-06-28 16:02 作者:吾爱破解论坛 0人读过 | 我要投稿

作者论坛账号： JuncoJet

[.前言]
Hello大家好，我应该有好久没在52发帖了吧，灌水除外。原因大概，近段时间都在搞（补习）硬件（模电）方面的东西，不涉及软件/逆向等。不过现在终于得住机会，能够有个擦边内容可以拟个帖子分享大家了。
最近新入手了个D87 RGB单模机械键盘，整体都不错，奢华内涵有档次，就这。

以前用过的键盘不少，青轴60%、青轴104、静电容108等，大多数没有RGB灯，有灯的只有蓝牙控制，台式电脑也没蓝牙，用手机去控制也不方便，这就问尴尬不尴尬。这次新键盘有比较完善的键盘驱动，可以设置键盘宏和灯效，软件界面友好功能完善。只可惜灯效方面只能内置（动态）和自定义静态灯效。然后萌生出一个新奇的想法，能否让键盘灯效玩贪吃蛇，像某贼船键盘一样。但后来我放弃了，原因并不是不行，而是这灯厂太华丽了。
下面内容由逆向分析展开，以及程序验证POC，最终写成一个完整的开发框架。

[.USB协议逆向]
逆向，其实是挺有意思的东西，和推理一样，把已知的线索都罗列出来，推理是用时间线贯穿，逆向则是用逻辑贯穿。去除掉所有的干扰和不可能，剩下的无论怎么不可思议，他都是正确的结果。虽然会有弯路，但总是乐此不疲。
说了这么多，只是要告诉大家，逆向分析都是会比较绕，有很多弯路，请耐心看完。

首先，安装驱动、打开键盘设置软件，灯效设置。使用USBlyzer进行抓包。

设置第一个按键（ESC）为红色，然后我们可以看到抓取到的USB数据如下图

接着我们把颜色改成绿色，可以看到抓取的数据如下图，看上去没有加密，这是个好兆头。

然后抓取第二个键F1，

发现这好像有空了3个字节

继续验证后面的按键，可能键盘空的地方，其实是存在按键的？
经过一系列的抓包，然后整理出来一些猜测，比如每个按键的控制都是明码，传输的是RGB数据占用3字节。
每条报文（是这么叫的么？）头部有12字节是协议头或者命令，共计发送6条数据给键盘

分析之初其实还是有很多弯路的，这是我的笔记，避免把你们看的云里雾里的我就略过了，比如猜测RGB数据是RGB还是RGBA。
很多错误的东西我就不提了，感兴趣可以看下这个笔记的截图

最终整理得到这样的一组信息，后面还会介绍到

[.程序验证POC]
本来打算用VB6来写的，开发速度快，贼好用。后来想想还是算了，QT来写，使用C++开发框架，这样的话方便开源大家一起来完善。而且还能移植到Linux等环境，底层USB库使用libusb-1.0本身具备跨平台性。

第0个简单的验证程序如图，点亮所有LED，变幻颜色。验证失败！
键盘死了，USB Bulk数据发送给键盘后貌似需要读出返回的数据，不然键盘会假死（可能真）状态。
返回的数据，明面上看的话可能是覆盖灯效前的原始数据，未具体研究和验证，因为对我来说用途不大。修正BUG后，接着验证。
如此低级错误，就不补图了，例子同下面，只是缺少发送后接收数据的代码。

第1个简单的验证程序如图，点亮所有LED，变幻颜色。验证成功！

第2个验证程序如图，顺序点亮所有的LED。验证失败！

失败的主要原因，猜测可能存在空键位，当顺序点亮到空键位的时候，会出现IO错乱问题

因为一般键盘或者LED灯（无关共阴极、共阳极），都采用矩阵结构，这样可以减少MCU GPIO的使用。如果不使用矩阵结构的话，87个RGB LED，需要261 GPIO来控制，这是相当烧钱的（需要更高级的MCU或者更多MCU分工、或者使用到锁存器）。
对协议分析，大致的能够推测出空键位所在位置，然后对键位建立映射关系，实现一个完整的控制、开发框架。经过很漫长的分析，最终结果就是上面一张图说明问题。

[.完整开发框架]
通过逆向和上面的验证，基本上了解到了几个信息，USB协议共计发送数据6次，每次发送的是一行键位的RGB数据，每个RGB以3字节存储。键位有可能存在空位，也就是我们必须去除掉这些空位，并且提升实际对键盘灯效操作时的简洁度。所以我大致的把程序写成这么几层

TKbdObj 键盘类。继承下面这些东西，改动下面内容可保持上层名称统一。

TKeyMap 按键映射层。负责转换键盘键值名称到XY矩阵数据，提供on/off和转换方法。