这个传输包含什么？（射频水池温度传感器基本单元接收器）

逆向工程 文件格式 开箱 串行通讯 编码
2021-06-21 13:55:43

注意：我在 EE stackexchange 上在从信号中提取位方面取得了进展（参见https://electronics.stackexchange.com/questions/145714/what-encoding-is-used-in-this-signal），但现在我认为这个小组可能对确定含义更感兴趣。

嗅探接收器模块上的数据引脚，我每分钟收到一个 64 位数据包。

制造商将温度范围声明为 0F-158F（参见https://support.acurite.com/acurite/topics/what-is-the-temperature-range-of-the-00617）

更改站代码（传感器和基站上都有 A/B/C 开关），我已经能够确定前两位是唯一影响 (00=A, 01=B, 10= C）。

传感器和底座各有 C/F 开关，但由于 a) 1F 小于 1C 并且没有分数显示，并且 b) 制造商似乎更喜欢在 F 中说明范围，并且 c) F 范围是严格的非负，在我看来，数据很可能是按照 F 传输的。

为了发送 159 个不同的电平，它只需要 8 个比特，所以剩下的 54 个（64 - 2 个站 - 8 个最小数据）比特可能是产品 ID、电池电量信息的某种组合（它有一个“低传感器电池”基础上的指标）、额外（未显示）精度和校验和/crcs。（值得注意的是，尽管传感器和底座显示器都显示最小/最大读数，但它们似乎是分离的——重置一个会将其最小/最大值重置为下一个当前读数——所以我认为传感器不会传输其最小/最大值.)

以下是一些示例捕获。我意识到我还没有足够严格地控制温度，但有趣的是，即使显示屏没有变化，位也会发生一些变化。有两件事情，我怀疑可能导致此- 1）也许有有额外的未示出的精确位和/或2）有一些噪声在信号，通过查看在模拟范围，这经常跟踪证实显示了一些长度在 0 和 1 之间不确定的位。（这也支持校验和的想法，因为我没有观察到基站显示器上的故障数据。）

另请注意，我不知道此处任何数据的位顺序（或字节序）（除了可能是 MSB 优先 b/c 站代码 B 是“01”而 C 是“ 10 英寸，但我不会对此施加太多重量）。

一些非常原始的初始捕获：

0000011110011000110000000000000000000000100011100000001100101101 # 73F (h76F,l69F,bat ok)
0000011110011000110000000000000000000000100011100000001100101101
00000111 10011000 11000000 00000000 00000000 10001110 00000011 00101101 # bytes? probably not.
0000011110011000110000000000000000000000100011101000010010101010
000001111001100011[22x0                ]100011101000010010101010 # lotta zeroes.
0000011110011000110000000000000000000000100011100000001100101101 # 73F (h76F,l69F,bat ok)
0000011110011000110000000000000000000000100011101000010010101010 # 73F (h76F,l69F,bat ok)
0000011110011000110000000000000000000000100011100000010100101011 # 73F (h76F,l69F,bat ok)
                                                ^--first difference.

当“坐着不动”时，靠近然后结束的几位改变：

0000011110011000110000000000000000000000100011101000010010101010 # 20(min)/23(cur)/25(max)
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x-----xxx-----xx changing bits.
0000011110011000110000000000000000000000100011100000001100101101
                                                     x       x   add'l changing bits.

我最初寻找 23d，因为摄氏度似乎更可能是传感器输出：

0000 0111 1001 1000 1100 0000 0000 0000 0000 0000 1000 1110   0000 0101 0010 1011
   0    7    9    8    C    0    0    0    0    0    8    E      0    5    2    B
0    E    9    1    3    0    0    0    0    0    1    7      0    A    4    D

0000 0111 1001 1000 1100 0000 0000 0000 0000 0000 1000 1110   1000 0100 1010 1010
   0    7    9    8    C    0    0    0    0    0    8    E      8    4    A    A
0    E    9    1    3    0    0    0    0    0    1    7      1    2    5    5

                                                  ^^^^^^-- 0x17 = 23C, which is 73.4F ?
                                                       ^^^^^^^^-- a more realistic 0x17 ?
                                                            no, b/c of the 0x07 above it.

Maybe we need to be looking for ~230(dec) instead of 23? 230=0xE6, 225=0xE1, 235=0xEB, 239=0xEF.
Those are (from 225 up): 11100001, 11100110, 11101011, 11101111. the "1110" is here, MSB-first:
      vvvv                                  vvvv
0000011110011000110000000000000000000000100011100000001100101101
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
0000011110011000110000000000000000000000100011101000000110101111 <--.
0000011110011000110000000000000000000000100011101000001010101100    |
0000011110011000110000000000000000000000100011101000010010101010    |
0000011110011000110000000000000000000000100011101000010010101010    |
    ^^^^                                   ^^^^            ^^^^(but only once)
and here, LSB-first.

A pair of them is interesting b/c the cur and max are both 23C, while the min is 21C.

21C is listed as the min temp seen, and 210(degC*10)=0xD2=11010010. (21.9C=0xDB).
So that means we'd expect to see a 1101. Do we? MSB first, then LSB first:
                                             vvvv      vvvv vvvv (not consistent)
0000011110011000110000000000000000000000100011100000001100101101
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000010100101011
0000011110011000110000000000000000000000100011100000011000101000
0000011110011000110000000000000000000000100011101000000110101111
0000011110011000110000000000000000000000100011101000001010101100
0000011110011000110000000000000000000000100011101000010010101010
0000011110011000110000000000000000000000100011101000010010101010
                                                          ^^^^
                                                            ^^^^ (not consistent)
Not really.

Let's reset the sender. Now min/cur/max are all 23C / 74F (yes, up from the 73F before).

0000011110011000110000000000000000000000100011101000100010100110

Do we see 3 of the same pattern anywhere?

       vvvvvvvv vvvv 3x 1100 MSB-first
0000011110011000110000000000000000000000100011101000100010100110

0000011110011000110000000000000000000000100011101000100010100110
   ^^^^  ^^^^ ^^^^                        ^^^^             ^^^^ 5x 1100 LSB-first


0000011110011000110000000000000000000000100011101000100010100110
  ^^^^^      ^^^^^                       ^^^^^             ^^^^ 3x 11000 LSB-first

Oddly, 11000b=24d, which is a bit of a near-miss for 23C readings. Probably not
relevant for the 74F unless there's a 50F offset... though come to think of it,
reading down to 50F probably covers the range people would want... Let's see
what the product manual says it can do:

  Temperature Range: 0º to 158º F, -18º C to 70º C
  Temperature Accuracy: +/- 2°

That... looks like degF might be worthwhile to consider.

Oh, but that was the webpage... the PDF says:

  32ºF to 158ºF; 0ºC to 70ºC

which frankly seems more likely.

我开始粗略地操纵温度并观察位上升 (^) 和下降 (v)：

(Initially around 23C/74F):
0000011110011000110000000000000000000000100011101000100010100110
                                                v     ^ v     v
0000011110011000110000000000000000000000100011100000101000100100

Breathed on it up to 27C (81F):
                                ^      ^    vvv^    v v ^    v
0000011110011000110000000000000010000001100000010000000010100000

It fell to 24C (75F):
                                v      vv   ^^^ ^    ^  v   ^ ^^
0000011110011000110000000000000000000000000011111000010000101011
                                                v    v  ^    ^
0000011110011000110000000000000000000000000011110000000010101111

Then to 24C (74F):
                                        ^      v    ^^^^v   vvv
0000011110011000110000000000000000000000100011100000111100100001

Then to 23C (74F):
                                                     vv      ^^
0000011110011000110000000000000000000000100011100000100100100111
                                                      ^v      vv
0000011110011000110000000000000000000000100011100000101000100100

Still 23C (74F)  [max 27C (81F), min 23C (74F)].

Moved the sensor outside to let the temp fall.
Current & min fell to 20C (68F):
                                        v     v ^     v
0000011110011000110000000000000000000000000011001000100000100100

Then to 19C (66F):
                                        ^    v^^      ^^^    v
0000011110011000110000000000000000000000100010111000101110100000

Down to 17C (63F):
                                        v      v        v      ^
0000011110011000110000000000000000000000000010101000101100100001

Down to 16C (62F):
                                                    v^vv    ^^^v
0000011110011000110000000000000000000000000010101000010000101110

温度数据从哪里开始？我们唯一一次在前 40 位上有一点变化是在我呼吸的时候。让我们重复一遍，看看这些是否是故障：

33C (91F):
                                ^      ^^   v^v v     ^ ^   vv ^
0000011110011000110000000000000010000001100001000000011010100011

显然不是故障。这是第 33 位的 1，就像以前一样。也许前32位是ID？或者，由于温度又上升了 67F(!!!)，也许所有这些零都只是温度的高位。（目前观测范围只有62F-91F（29degF），仅为0F-158F（158degF）中间的1/5）。

这是我确定车站代码的地方。到目前为止，它已设置为“A”。还有B和C。

73F A:
0000011110011000110000000000000000000000100011101000000110101111

72F B:
 ^                                            v^v   ^^^ v^  vv v
0100011110011000110000000000000000000000100011010000111101100010
                                                ^     v ^     v
0100011110011000110000000000000000000000100011011000110111100000

72F C:
^v                                                      vv
1000011110011000110000000000000000000000100011011000110100100000
                                                v     ^ ^     ^
1000011110011000110000000000000000000000100011010000111110100010

Okay, well, the first two bits are clearly station code.
  00=A, 01=B, 10=C

我探索了一些位作为型号的想法，但无济于事：

What are the ways to represent 00617, the model number?
617d=0x269=1001101001b

6 1 7 = 110 001 111b = 0110 0001 0111b

ASCII for "617" is x36 x31 x37 = 00110110 00110001 00110111

Not seeing it in [000111100110001100000000000000]

更多漂移而不改变显示：

1000011110011000110000000000000000000000100011011000101100100110 a
                                                v      v^      ^
1000011110011000110000000000000000000000100011010000101010100111  b
                                                ^     v v     v
1000011110011000110000000000000000000000100011011000100000100101   c
                                                v     ^ ^     ^
1000011110011000110000000000000000000000100011010000101010100111  b
22C (71F):
                                                ^     v v     v
1000011110011000110000000000000000000000100011011000100000100101   c

回顾数据，我真的需要在得出结论之前探索更多的温度范围。低于 32F 的水浴需要盐，这很烦人，但至少 158F 对塑料外壳来说不算太糟糕（根据http://www.machinist-materials.com/comparison_table_for_plastics.htm和http:// Plastictroubleshooter.com/ThePlasticTroubleshooter/melt_temps.htm，尽管它确实感觉它可能是 PVC ......）。

当前假设：

ss0001111001100011dddddddddddddddddddddddddddddddddddddddddddddd
--________________----------------------------------------------
|  |               |
|  |               `-- 46 bits of data (temp and maybe batt and checksum
|  |
|  `-- 16 bits of ID (and/or maybe battery health?). Hasn't changed yet.
|
`-- 2 bits of station code (00=A, 01=B, 10=C)
1个回答

回到 Electronics SE ( https://electronics.stackexchange.com/a/257112/24681 ) 的人们已经破解了这个案例。

实际上，一条消息中有 8 个字节的数据。

最后一个字节 (8) 是一个 XOR 校验和——也就是说，对包括它在内的所有字节进行 XOR 运算会产生 0xFF。

校验和（5-7）之前的三个字节是摄氏温度，但编码有点奇怪——每个字节的低半字节（4位）是温度数据，高位（高半字节）用于为整个字节提供偶数奇偶校验。

整个消息的前两位是站号（A=00，B=01，C=10）。

其余的位仍然未知，但我也没有看到它们发生变化。它们可能是电池电量不足和产品 ID。

例如

1000011110011000110000000000000000000000100011100000001110101101

分解成字节：

10000111 10011000 11000000 00000000 00000000 10001110 00000011 10101101
^^-- station "C"                                               ^^^^^^^^-- checksum
                       temperature--^^^^^^^^-^^^^^^^^-^^^^^^^^

温度编码为：

                                    00000000 10001110 00000011
        even parity for each byte --^--------^--------^
                                        ^^^^-----^^^^-----^^^^-- data (0E3h)

0E3h是227d，这很简单22.7°C。

其它你可能感兴趣的问题
上一篇尝试通过 DLL 注入调用进程中的函数，如果可能，需要 IDA 的帮助 下一篇逆向 Qt 应用