これは昔のイーサリアムのメンプール時代を思い出させます。競合他社の再入札を防ぐために、非常に似たようなXORコールデータの難読化を行わなければならなかったのです(笑) ソラナランドにまだワイルドウェストが残っているのを見るのは楽しいですね。
Michael Morrell
Michael Morrell12月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:セレクタ(デシリア化前にポップ)
「シムできるのにコールデータをエンコードするなんて、なぜか」と疑問に思うなら答えは簡単です。シムは計算時間がかかりますが、入札はレイテンシが低いため、シミング+再入札をしている場合、再入札時にはオリジネーターがすでに複数の新しい取引を送っている状態です。 つまり、競合他社のパラメータを即座に認識し、新しい入札の基準にできる手段が必要です。だからこそ、シムではなく通話データを解析するのです。そして、みんながこれをやっているときは、一歩先を行って、手動のリバースエンジニアリングなしには解読不可能な方法で通話データをエンコードする必要があります。
珍しい技術的なコメントです。
4.33K