Dit herinnert me aan de oude mempool dagen op Ethereum toen we heel vergelijkbare XOR calldata obfuscatie moesten doen om concurrenten te stoppen met opnieuw bieden haha Leuk om te zien dat er eigenlijk nog steeds een Wild West is in solanaland.
Michael Morrell
Michael Morrell4 dec, 10:08
HumidiFi swap instructie data obfuscatie: - In-place XOR-gebaseerde stream cipher. - Symmetrisch (f(f(x)) = x) en werkt op 64-bits chunks. Algoritme: - Verwerk data in 8-byte (u64) chunks. - Voor elke chunk: -- XOR met statische `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 met rollende `pos_mask` (begint bij 0, verhoogt met 0x0001_0001_0001_0001 per chunk). - Restverwerking (als len % 8 != 0): - Vul resterende bytes aan tot 64 bits. - Pas dezelfde XOR's toe (sleutel + huidige pos_mask). - Kopieer geldige bytes terug naar de originele slice. Invoerindeling (na deobfuscatie): - Bytes 0-7: `swap_id` (u64) - Bytes 8-15: `amount_in` (u64) - Byte 16: `is_base_to_quote` (u8) - Bytes 17-23: Padding - Byte 24: Selector (verwijderd voor deserialisatie)
Als je je afvraagt "waarom calldata coderen als je kunt simmen", is het antwoord eenvoudig: sims zijn duur in termen van rekentijd, maar bieden is met lage latentie, wat betekent dat als je simt + opnieuw biedt, de originator al meerdere nieuwere tx's heeft verzonden tegen de tijd dat je opnieuw biedt. Dit betekent dat je een manier moet hebben om onmiddellijk de parameters van concurrenten te herkennen waarop je je nieuwe bod kunt baseren. Dit is waarom je calldata parseert in plaats van sims te doen. En wanneer iedereen dit doet, moet je een stap voor zijn en de calldata coderen op een manier die onmogelijk te decoderen is zonder handmatige reverse engineering.
Zeldzame technische opmerking.
5,01K