Tämä muistuttaa minua vanhoista mempool-ajoista Ethereumissa, jolloin jouduimme tekemään hyvin samanlaista XOR-calldatan hämärrystä, jotta kilpailijat eivät tarjoaisi uudelleen, haha Hauska nähdä, että Solanamaassa on oikeasti vielä villi länsi.
Michael Morrell
Michael Morrell4.12. klo 10.08
HumidiFi-vaihtokäskytietojen hämärtyminen: - Paikan päällä oleva XOR-pohjainen virtasalaus. - Symmetrinen (f(f(x)) = x) ja toimii 64-bittisissä lohkoissa. Algoritmi: - Datan käsittely 8 tavun (u64) lohkoissa. - Jokaiselle lohkolle: -- XOR staattisella 'HUMIDIFI_IX_DATA_KEY':llä: [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 rullaavalla 'pos_mask' (alkaa 0:sta, 0x0001_0001_0001_0001 per lohko). - Jäännöskäsittely (jos len % 8 != 0): - Nollata jäljellä olevat tavut 64 bittiin. - Sovella samoja XOReja (avain + virta pos_mask). - Kopioi kelvolliset tavut takaisin alkuperäiseen viipaleeseen. Syötteen asettelu (deobfuskaamisen jälkeen): - Tavut 0-7: 'swap_id' (u64) - Tavut 8-15: 'amount_in' (u64) - Tavu 16: 'is_base_to_quote' (u8) - Tavut 17-23: Täyte - Tavu 24: Valitsin (aktivoitu ennen deserialisointia)
Jos mietit "miksi koodata calldata, kun voit simuloida", vastaus on yksinkertainen: simit ovat kalliita laskenta-ajan suhteen, mutta tarjous on matalaviiveinen, mikä tarkoittaa, että jos simmaat + rebiddaat, alkuperäisen käyttäjän on jo lähettänyt useita uudempia viestejä. Tämä tarkoittaa, että sinun täytyy tunnistaa välittömästi kilpailijoiden parametrit, joihin voit perustaa uuden tarjouksesi. Siksi sinun täytyy jäsentää puheludataa SIM-korttien sijaan. Ja kun kaikki tekevät tätä, sinun täytyy olla askeleen edellä ja koodata puheludata tavalla, jota ei voi purkaa ilman manuaalista käänteistä suunnittelua.
Harvinainen tekninen kommentti.
4,34K