解密变长串行协议

逆向工程 十六进制 串行通讯 协议 十六进制
2021-06-12 12:08:10

我有一个电动自行车，它由一个控制器和一个智能 LCD 组成，它可以调节电机的功率，它可以调节最大速度、功率输出、踏板辅助灵敏度等，并显示当前的电池电压、电机功率使用（瓦）和电机速度。
LCD 和控制器通过 5v rx/tx 线连接。我在串行线的中间串联了一个 arduino mega；控制器 rx/tx 到 arduino serial1 tx/rx，然后 arduino serial2 tx/rx 到 LCD rx/tx。
代码目前正在将所有从控制器接收到的数据直接传递给 LCD，反之亦然，这完美地工作，LCD 值是正确的。

我想分析协议，但似乎无法弄清楚其中的任何结构。目前专注于控制器 -> LCD 通信以提取电机值。似乎所有命令都以 02（AsciiTable 中的文本开头）开头，然后大多数命令都包含 0E，我最初怀疑它是消息长度，但是从以下命令中可以看出情况并非如此：

02 0E 40 40 00 00 03 0B B8 00 00 35 C8
02 0E 01 00 40 00 00 03 0B 98 00 35 C8
02 4E 40 40 00 00 03 0 0 B 8 0 4 0 0 B 8 0 4
0 0 B 00 4 0 0 B 35 C8
02 0E 01 00 50 00 D0 0B B8 00 00 05 FE

02 4E 40 40 00 00 03 0B B8 00 35 C8
02 4E 40 20 0A 00 03 0A B8 80 35 C8
02 4E 40 40 00 00 03 0B B8
4 0 0 4 0 8 DD 4 0 8 0 DD 4有限元

这是大约运行 60 秒后的完整 十六进制转储，消息源源不断：https :
//pastebin.com/iFFEWAFd 该转储将包含电池电压 (45-52.4V)、电机功率使用 (0-1000Watts,也可能是 0-10Amps ）和可能的轮速。可能还有其他一些参数。

命令

02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8

是迄今为止最受欢迎的占一半以上的消息。这可能是心跳吗？
这是没有该命令的相同粘贴，以便于阅读：https : //pastebin.com/b5iQugaY

LCD 的 PDF 手册：www.pedecs.co.uk 到目前为止
还没有找到任何类型的控制器手册。

感谢您提供的任何见解，我仍在了解整个逆向工程。

更新：我已经设法隔离了几个命令。以前认为是心跳的命令实际上是速度 0。这是自行车从 19mph 减速到 0mph 的转储：

02 0E 01 00 40 00 00 03 00 F5 00 00 35 8E 
02 0E 01 00 40 00 00 03 00 FD 00 00 35 86 
02 0E 01 00 40 00 00 03 01 05 00 00 35 7F 
02 0E 01 00 40 00 00 03 00 0C 00 00 35 74
02 0E 01 00 40 00 00 03 01 25 00 00 35 AE 
02 0E 01 00 40 00 00 03 01 3F 00 00 35 45 
02 0E 01 00 40 00 00 03 01 4F 00 00 35 35 
02 0E 01 00 40 00 00 03 01 4F 00 00 35 35 
02 0E 01 00 40 00 00 03 01 60 00 00 35 1A 
02 0E 01 00 40 00 00 03 01 60 00 00 35 1A 
02 0E 01 00 40 00 00 03 01 76 00 00 35 0C 
02 0E 01 00 40 00 00 03 01 76 00 00 35 0C 
02 0E 01 00 40 00 00 03 01 8E 00 00 35 F4 
02 0E 01 00 40 00 00 03 01 8E 00 00 35 F4 
02 0E 01 00 40 00 00 03 01 AB 00 00 35 D1 
02 0E 01 00 40 00 00 03 01 AB 00 00 35 D1 
02 0E 01 00 40 00 00 03 01 CE 00 00 35 B4 
02 0E 01 00 40 00 00 03 01 CE 00 00 35 B4 
02 0E 01 00 40 00 00 03 01 CE 00 00 35 B4 
02 0E 01 00 40 00 00 03 01 FC 00 00 35 86
02 0E 01 00 40 00 00 03 02 8A 00 00 35 F3 
02 0E 01 00 40 00 00 03 02 8A 00 00 35 F3 
02 0E 01 00 40 00 00 03 02 8A 00 00 35 F3 
02 0E 01 00 40 00 00 03 02 8A 00 00 35 F3 
02 0E 01 00 40 00 00 03 03 0C 00 00 35 74 
02 0E 01 00 40 00 00 03 03 0C 00 00 35 74 
02 0E 01 00 40 00 00 03 03 0C 00 00 35 74 
02 0E 01 00 40 00 00 03 03 0C 00 00 35 74 
02 0E 01 00 40 00 00 03 03 0C 00 00 35 74 
02 0E 01 00 40 00 00 03 04 05 00 00 35 7A 
02 0E 01 00 40 00 00 03 04 05 00 00 35 7A 
02 0E 01 00 40 00 00 03 04 05 00 00 35 7A 
02 0E 01 00 40 00 00 03 04 05 00 00 35 7A 
02 0E 01 00 40 00 00 03 04 05 00 00 35 7A 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 06 34 00 00 35 49 
02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8 
02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8 
02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8 
02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8 
02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8

只有字节 9,10 和 14 发生了变化。然而，这些值并不直接对应于速度，更可能以某种方式与 RPM 相关，因为当我手动更改预期的车轮尺寸值时，LCD 知道任何给定命令的车轮尺寸和显示的速度变化。

Update2：字节 9 和 10 组合输出 0-3000 之间的值。该值是车轮完整旋转之间的毫秒数，因此可以在您知道周长的情况下计算速度。字节 14 似乎是某种校验和，如果有人可以练习如何计算它会很方便。

1个回答

我知道您的 Arduino 充当控制器和 LCD 中间的继电器。你能做什么（不是很令人兴奋，但你没有提到你是否已经做过类似的实验，我希望我能很好地理解你的情况）：

  1. 单个位的修改。如果您目视观察显示器并在您的 Arduino 上连接一个开关作为触发器来修改显示器方向上的一个或多个单个位，并观察哪个显示指示发生变化。
  2. 反方向也一样。观察自行车是否改变其行为。
  3. 抑制你的心跳电报并观察会发生什么。
  4. 一个简单的实验是打开自行车的灯并观察电报的变化。
  5. 为您的电报添加时间戳。如果您在 Arduino 上安装触发器，也要给它一个时间戳，以便在电报日志中获得准确的更改时间。

简而言之，尝试在自行车上或电报或电报组中以定义的方式进行更改（一次一个），并观察它是否为您提供了有关内容的提示。

另一个问题是您是否交叉检查了 Arduino 电报解码，例如使用一些被动嗅探器。我知道您信任您的解码器，因为一切都像以前一样（中间没有 Arduino）。但这可能仅仅是因为损坏的电报被丢弃了。

粗略检查您的日志会显示不容易理解的属性。

示例：文件ebike_sw_hex_dump.txt中的#133和#134行（有心跳的那一行）：

02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8
02 0E 01 00 40 00 03 0B B8 00 00 35 C8

除了中间缺少零之外，第二个电报与第一个电报相同。特别是最后七个字节是相同的。如果我假设这最后七个字节的逻辑内容在两个电报中是相同的，那么解释器应该如何得出这个结论？

“协议切换”可能是40. 然而，这与最后七个字节含义相同的假设相矛盾。

从这个例子和其他奇怪的行，例如那些在末尾带有 FE 或 FF 的行，我建议对解码器进行独立的交叉检查，以确保您的日志显示正确的字节。与您怀疑的类似，在这样的系统中，我也希望电报长度保持不变。

当然，还有更多可以尝试的。这些只是一些简单的想法。

在https://endless-sphere.com/forums/viewtopic.php?f=2&t=73471#p1109048下的网络上发布了与您类似的实验，附加了解码协议，但是使用了不同的控制器，并且没有显示明显的与您的日志相似。但也许它也给出了一些提示。

无论如何，一个不错的学习！

其它你可能感兴趣的问题
上一篇Win32 SEH 地址 下一篇捕获 exe 和 mdb 之间的连接字符串