熱門話題
#
Bonk 生態迷因幣展現強韌勢頭
#
有消息稱 Pump.fun 計劃 40 億估值發幣，引發市場猜測
#
Solana 新代幣發射平臺 Boop.Fun 風頭正勁
這讓我想起了以太坊早期的 mempool 時代，那時我們不得不進行非常類似的 XOR calldata 混淆，以阻止競爭對手重新出價哈哈
有趣的是，實際上在 solanaland 還是有一片西部荒野。
12月4日 10:08
HumidiFi 交換指令數據混淆：
- 就地 XOR 基於流密碼。
- 對稱（f(f(x)) = x）並在 64 位塊上運作。
算法：
- 以 8 字節（u64）塊處理數據。
- 對於每個塊：
-- 與靜態 `HUMIDIFI_IX_DATA_KEY` 進行 XOR：[58, 255, 47, 255, 226, 186, 235, 195, 123, 131, 245, 8, 11, 233, 132, 219, 225, 40, 79, 119, 169, 121, 169, 58, 197, 1, 122, 9, 216, 164, 149, 97][0..7];
-- 與滾動的 `pos_mask` 進行 XOR（從 0 開始，每個塊增加 0x0001_0001_0001_0001）。
- 剩餘處理（如果 len % 8 != 0）：
- 將剩餘字節填充為 64 位。
- 應用相同的 XOR（密鑰 + 當前 pos_mask）。
- 將有效字節複製回原始切片。
輸入佈局（去混淆後）：
- 字節 0-7：`swap_id`（u64）
- 字節 8-15：`amount_in`（u64）
- 字節 16：`is_base_to_quote`（u8）
- 字節 17-23：填充
- 字節 24：選擇器（在反序列化之前彈出）
如果你在想「為什麼要編碼 calldata 而不是直接模擬」，答案很簡單：模擬在計算時間上是昂貴的，但出價是低延遲的，這意味著如果你在模擬 + 重新出價時，當你重新出價時，發起者已經發送了多個更新的交易。
這意味著你需要有一種方法來立即識別競爭對手的參數，以便你可以基於這些參數進行新的出價。這就是為什麼你要解析 calldata 而不是進行模擬。而當每個人都這樣做時，你需要領先一步，以一種無法在沒有手動逆向工程的情況下解碼的方式編碼 calldata。
罕見的技術評論。
4.33K
熱門
排行
收藏