研究了一下，暫時沒有解出來，先說下我的想法：
首先，建議樓主提供更多信息，譬如這個系統是用在哪裏，主機和從機都是 MCU 還是 電腦，還是分別爲 MCU 及電腦，什麼級別的 MCU，譬如都是使用 MCU 的話，那麼因其空間受限，使用複雜算法、甚至是多套算法的可能性就可以降低。
回到問題本身，希望求一個函數，輸入請求數據輸出回覆數據，如果數據是比較有規律的話，使用機器學習就可以實現，但在加密領域完全不能實現，譬如一個簡單的 CRC 算法，只要有一個 bit 改變，結果也完全不同，沒法學習。
然後，返回的數據通常並非爲請求數據直接加密而來，實際上流程可能是：主機加密 -> 從機解密 -> 從機再次加密回覆數據 -> 主機對比回覆的加密數據。
這種情況下，如果是我設計的話，請求的數據其明文包含 3 個部分：固定的標識、目標設備號（這樣一個解碼器只能綁定一個主機）、隨機值；返回數據明文爲：正確與否 + 相同的隨機值（防止黑客抓到成功回覆包後重複使用）。加密部分如果是 MCU 的話，應該是共用同一套算法，否則太耗資源，猜測應該是按區塊加密，一個區塊寬度爲 32 bit（因爲回覆數據是 32 bit），加密算法可能是精簡的對稱加密算法，也可能是 XOR 某個 32 bit 的數，回覆也可能是經過 CRC 這樣的 HASH 處理。 如果真是類似這樣的設計，那麼樓主在表格前兩個頁面自己發送隨機數去試，其意義不大。
如果它真的只是發送一個隨機數，按特定算法返回結果，那到有另外一個思路，不去**它，拿一個解碼器配置一個服務器，然後你自己生產很多解碼器，通過網絡請求服務器返回結果即可。0.5 秒一次請求也差不多夠用了，畢竟只是初始化的時候請求一次，只是希望沒有次數限制。
另一個思路是** MCU 硬件，逆向工程其固件（或是 PC 端軟件，如果一方是 PC 的話）。
如果是我設計的那種方式，由於要傳其它信息，隨機數肯定要小於 64 bit, 如果是按 32 bit 區塊獨立加密，那麼隨機數一定要分佈在兩個區塊，否則數據看起來就會有一個區塊是固定的數據。
因爲回覆的是 32 bit, 所以隨機數很有可能是 32 bit 以下，這樣的話，隨機數會有一定的可能重複，所以我的思路是再多抓一些系統自身的數據，直到抓到一兩個至少返回的數據相同的情況，然後再來猜它的運作方式可能會有更多思路。建議搞一個硬件自動重啓系統來自動抓包，這樣一來可以方便抓到更多樣本，不會搞錯數據，人也不累（我看到表格裏面有些數據是空白，應該是人工填寫漏掉了）。
我寫了個腳本查了一下，目前還沒有相同的回覆，最後一條樣品是我手動加的爲了測試：
|
楼主
