algorithm - 谁能帮我识别算法？

Question

这个专有网络协议(protocol)使用了一种我以前从未见过的奇怪的(CRC？)散列算法。它从端口计算。

根据调查，我得到了以下哈希值:

0-85
1-84
85-d0

7770-df
7771-de
7772-c9
7773-d0
7774-db
7775-da 
7776-e5 
7777-e4
7778-e7

这是在连接数据包的 0x03 处提交的，并根据端口号而变化。

谢谢，

Answer 1

对于单字节输入算法:

f x = 0x80 .|. (0xF0 .&. x `shiftL` 4) .|. x `xor` 0x05

或 C 风格:

#define F(x) (0x80 | (0xF0 & (x << 4)) | (x ^ 0x05))

编辑:我将 0xF 更改为 0xF0，这是我的意思。

匹配给定示例(需要更多示例)。

你是两个字节的例子是不够的(见我的评论)所以我不会打扰那些。

编辑:我是如何解决这个问题的:

第一步:用位写下所有内容，用空格分隔半字节(4 位)，因为设计通常在半字节边界上做一些不同的事情 - 即它们可能会做 x & 0x80 | x ^ 0x05 但很少使用 x & 0x84 | x ^ 0x01。

0000 0000 --> 1000 0101
0000 0001 --> 1000 0100

看到了，看起来我们免费(或)得到了 0x80，第二个半字节得到了异或 0x05。测试 0 和 1 很聪明。汉明距离一值和零值始终是很好的测试。所以现在我认为算法是:

#define f(x) (x ^ 0x85)

然后我们得到测试对0x85到0xd0:

1000 0101 --> 1101 0000

因此低半字节看起来仍然正确(与 0x05 异或)但高半字节需要更改为 OR，而不是 XOR:

#define f(x) ( (0xF0 & x | 0x80) \ // Upper nibble
             | 0x0F & (x ^ 0x05))   // Lower nibble

这是一样的

#define f(x) ( x^0x05 | 0x80)

但是还是不行!请注意，我们在生成的高位半字节中得到与输入低位半字节中相同的位模式，看到 0101 了吗？让下半字节与上半字节进行 OR 操作，并将其称为上半字节:

#define f(x) ( (x^0x05) | 0x80 | (0xF0 & (x << 4))

现在我们匹配所有三个测试用例(实际上并不多)

这不是我在上面放置的您接受的内容，也许您将我的 0xF 拼写错误改成了预期的 0xF0？如果没有，请确保您注意到该错误并更改您的代码。如果这是为了任何严肃的用途，您甚至可以包括一些已知答案的单元测试。

哦，因为我手头有它，所以它是可运行的形式。

#include <stdio.h>
#define F(x) (0x80 | (0xF0 & (x << 4)) | (x ^ 0x05))

void main()
{
        printf("%02x %02x %02x\n", F(0), F(1), F(0x85));
}