Question

我正在尝试编写一个tcp服务器来从Heacent 908 GPS跟踪器获取数据。从跟踪器建立连接后，我得到以下缓冲区输出。

<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>

我不确定如何将这些数据解码为正确的可读格式。

注意：当然我试图联系制造商，但他们根本没有回应。

TCP协议有哪些可能的编码格式？

第二天我得到了这样的数据

<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>

<Buffer 78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a>
<Buffer 78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a>

有些东西正在改变但不确定它是什么......

Answer 1

你问TCP有哪些可能的编码格式。这是一个奇怪的问题：使用TCP作为底层协议，有无限数量的编码格式。但无论如何，我们可以试着找出这一个！

您发布了一些示例消息。让我们看看我们是否可以翻译它们：

byte  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17
rev  17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
----------------------------------------------------------
hex  78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a
text  x  x \r -- -- -- --  1    --  H  B -- --  d -- \r \n
dec        13  1  3    17                 0 6 100    13 10
be32       [218170247] [288432262]       [   419006]
----------------------------------------------------------
hex  78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a
text                                        --  u  7
dec                                         7 117 55
be32                                     [   488759]
---------------------------------------------------------- 
hex  78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a
text                                        -- -- --
dec                                         8 141
be32                                     [   560576]
----------------------------------------------------- byte 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
hex  78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a
text       -- -- -- -- -- -- -- -- -- --  _ --  P -- -- -- --  2  5  9 -- -- -- -- -- -- -- -- -- xx --  z \r \n
---------------------------------------------------------- 
hex  78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a
text                                           --       -- --  A  5  @                         -- xx --  1

一些可能有趣的事实：

以“xx \ r \ _01”开头，这或多或少似乎是一个可能的标题。但后来的消息以“xx”和其他内容开头。无论如何，鉴于NMEA的前缀为“GP”，如果这些设备使用“xx”代表“不是NMEA的东西”，我不会感到震惊。
中间有“HB”，这可能意味着“心跳”，因为这是重复，也许正在等待服务器的回复。
以“\ r \ n”结尾，这是一个共同的行结尾（特别是在Windows上），但其余部分似乎并非完全是文本的。
早期的消息长18个字节，后面的消息长36个字节。猜测是短的是状态更新或心跳，而长的是实际的位置信息。如果我们计算36个字节就够了：
- 4字节纬度：如果捏（see）则为24位，更可能为25-32位
- 4字节经度：与纬度相同
- 6字节时间戳：如果使用以厘秒为单位的纪元时间，则为39位，更可能为32/48/64位
- 2字节高度：我怀疑这个设备根本没有发布高度，给出了一些文档

所以我认为发生的事情是你看到的这些消息只是设备“ping”服务器并等待响应。什么样的回应？好吧，你可以尝试暴力破解它，但更容易的是在你的程序中设置一个桥接器，它接收从设备接收到的任何东西，将它发送到制造商的服务器，并反过来做同样的事情。对设备的回应。通过这种方式，您可以快速收集有效消息的语料库，如果我们确实需要对此进行逆向工程，这将非常有用。或者如果你很幸运，在谈判初始会议之后会变成使用NMEA之类的标准协议。

编辑：既然你已经从设备上给了我们更多的消息，我们可以看到它确实发送了一些带有可变内容的东西。也许那是位置数据，但我现在没有时间尝试对其进行逆向工程。一个想法是物理地将单元从西向东或从北向南移动并捕获它在此期间发送的消息，以试图隔离消息的哪些部分是经度，哪些是纬度（也可能是时间戳）。

我认为很明显前两个字节是“xx”作为标题，最后两个字节是“\ r \ n”作为终结符。这会在较长的消息中留下32字节的有效负载，所有这些消息都显示为二进制数据。

Answer 2

这是GT06协议，你可以在这里找到它的规格：

如何解码TCP缓冲区数据

2 个答案: