Це нагадує мені старі часи мемпулу на Ethereum, коли нам доводилося робити дуже схожу обфускацію даних calldata XOR, щоб зупинити конкурентів від повторних торгів, ха-ха Цікаво бачити, що в Соланаленді досі існує Дикий Захід.
Michael Morrell
Michael Morrell4 груд., 10:08
Обфускація даних інструкцій через обмін HumidiFi: - Вбудований потоковий шифр на основі XOR. - Симетричний (f(f(x)) = x) і працює з 64-бітними чанками. Алгоритм: - Обробка даних у 8-байтових (u64) чанках. - Для кожного фрагмента: -- XOR зі статичним '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 з киданням 'pos_mask' (починається з 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, якщо можна симулятори», відповідь проста: SIM-карти дорогі за часом обчислень, але торги мають низьку затримку, тобто якщо ви симулюєте + повторно подаєте, до моменту повторної ставки оригінал уже надіслав кілька нових TX. Це означає, що вам потрібно мати спосіб миттєво розпізнавати параметри конкурентів, на яких можна базуватися на новій ставці. Ось чому ви обробляєте calldata замість SIMS. І коли всі це роблять, потрібно бути на крок попереду і кодувати дані викликів так, щоб їх неможливо розшифрувати без ручного зворотного інжинірингу.
Рідкісний технічний коментар.
4,33K