2011-03-24 154 views
1

這個專有的網絡協議使用了我以前沒見過的奇怪的(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時提交,改變依賴於端口號。

感謝,

+0

刪除加密標籤,因爲它是不相關的這樣小的值。 – 2011-03-24 21:34:37

+1

你是兩字節的例子很差(他們是十六進制?)。如果你有兩個字節的低位字節爲零(例如:0x7700),而另一些字符在第一個字節(0x0100,0x0200,0x1000,0x2000,0xFF00,0x0101等等)中有一些值),否則「or」與「nothing」或「xor」與「and」之間的區別是無法區分的。 – 2011-03-24 22:22:47

回答

1

對於一個字節輸入算法:

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

或風格:

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

編輯:我改變了0xF0xF0,這是什麼我換。

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

你是兩字節的例子是不夠的(見我的評論),所以我不會打擾那些。

編輯:我是如何工作了這一點:

步驟一:以位什麼都寫下來,空間分隔半字節(4位),因爲設計通常做一些半字節邊界上的不同 - 這是他們可能做x & 0x80 | x^0x05但不太經常做x & 0x84 | x^0x01

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

看到的是,它看起來像我們得到一個0x80的免費(或)和第二四位得到了一個XOR爲0x05。測試0和1很聰明。漢明距離一個值和零值總是很好的測試。所以現在我想的是ALG:

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

然後我們得到的測試對0x85到0xd0:

1000 0101 --> 1101 0000 

所以低四位看起來還是正確的(與爲0x05 XOR),但上四位需要改變到一個OR,而不是XOR:

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

這是一樣的

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

但這仍然不行!注意我們在我們得到的高位半字節中獲得了與我們輸入的低半字節相同的位模式,請參見0101?出租或與上,下半字節調用上:

#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)); 
} 
+0

謝謝,它的工作。你是怎麼解決這個問題的? – 2011-03-25 13:06:02

+0

@Jay看我的編輯(它也修復了一個bug) – 2011-03-25 14:42:43

相關問題