Questo mi ricorda i vecchi giorni del mempool su Ethereum quando dovevamo fare una obfuscazione simile del calldata XOR per fermare i concorrenti dal rilanciare haha Divertente vedere che c'è ancora un vero Far West in solanaland.
Michael Morrell
Michael Morrell4 dic, 10:08
Obfuscazione dei dati delle istruzioni di scambio HumidiFi: - Cifratura a flusso basata su XOR in loco. - Simmetrica (f(f(x)) = x) e opera su blocchi da 64 bit. Algoritmo: - Elabora i dati in blocchi da 8 byte (u64). - Per ogni blocco: -- XOR con la chiave statica `HUMIDIFI_IX_DATA_KEY`: [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]; -- XOR con il `pos_mask` rotante (inizia a 0, incrementa di 0x0001_0001_0001_0001 per blocco). - Gestione del resto (se len % 8 != 0): - Aggiungi zeri ai byte rimanenti fino a 64 bit. - Applica gli stessi XOR (chiave + pos_mask corrente). - Copia i byte validi nel segmento originale. Layout di input (dopo deobfuscazione): - Byte 0-7: `swap_id` (u64) - Byte 8-15: `amount_in` (u64) - Byte 16: `is_base_to_quote` (u8) - Byte 17-23: Padding - Byte 24: Selettore (estratto prima della deserializzazione)
Se ti stai chiedendo "perché codificare il calldata quando puoi simulare", la risposta è semplice: le simulazioni sono costose in termini di tempo di calcolo, ma le offerte hanno una bassa latenza, il che significa che se stai simulando + rilanciando, nel momento in cui rilanci, l'originatore avrà già inviato più tx più recenti. Questo significa che devi avere un modo per riconoscere istantaneamente i parametri dei concorrenti su cui puoi basare la tua nuova offerta. Ecco perché analizzi il calldata invece di fare simulazioni. E quando tutti lo fanno, devi essere un passo avanti e codificare il calldata in un modo che sia impossibile da decodificare senza un reverse engineering manuale.
Commento tecnico raro.
4,33K