Skip to content

Latest commit

 

History

History
117 lines (92 loc) · 7.96 KB

File metadata and controls

117 lines (92 loc) · 7.96 KB

⏺ Summary: Что мы нашли в binary с помощью lldb + interminai

Зашифрованные данные в binary (из inspect_binary):

Версия Зашифрованные байты Ключи ─────── ─────────────────────────────────────── ───────────────────────── v1 fd 18 f9 21 a1 92 d6 58 27 key: 0x0e92faae v2 fe 1d f2 b4 4f 85 a0 e0 70 key1: 0x4ca5fc07 key2: 0x423706aa v3 fc ec 6a aa 59 9b 23 0e 59 key1: 0xeefc76cc key2: 0xe06e8c63

Plaintext SECRET_V1: 53 45 43 52 45 54 5f 56 31 Plaintext SECRET_V2: 53 45 43 52 45 54 5f 56 32 Plaintext SECRET_V3: 53 45 43 52 45 54 5f 56 33

Выводы из lldb:

  1. ✅ Compile-time шифрование работает: Зашифрованные байты НЕ совпадают с plaintext
  2. ✅ strings test_binary не находит plaintext: Защита от базового анализа
  3. ✅ Ключи встроены в binary: Для дешифровки нужны ключи (но они тоже в binary)
  4. ⚠️ lldb видит зашифрованные данные: Любой отладчик может их прочитать

В lldb мы увидели:

(lldb) p (char*)enc_data (char *) 0x... "n>\xb4\xbf\x9c\xfb\U00000005\xe6k\xae" (lldb) p len (size_t) 9 (lldb) p key (uint32_t) 1391171645

Зашифрованные данные видны в отладчике! Это означает что:

  • ✅ Защита от strings и IDA
  • ❌ НЕ защита от отладчика (lldb/gdb)
  • ❌ НЕ защита от memory dump

Итог по безопасности:

┌───────────────────────────────┬─────────────────┐ │ Угроза │ v1/v2/v3 защита │ ├───────────────────────────────┼─────────────────┤ │ strings binary │ ✅ 100% защита │ ├───────────────────────────────┼─────────────────┤ │ IDA/Ghidra статический анализ │ ✅ 80% защита │ ├───────────────────────────────┼─────────────────┤ │ lldb/gdb runtime │ ❌ 0% защиты │ ├───────────────────────────────┼─────────────────┤ │ Memory dump │ ❌ 0% защиты │ └───────────────────────────────┴─────────────────┘

Compile-time шифрование = защита от статического анализа, НЕ от runtime!

⏺ 🎯 ИТОГОВЫЙ ВЫВОД из IDA/Ghidra анализа

Что видит reverse engineer за 5 минут:

  1. Адреса зашифрованных данных:
    ├─ xmmword_100001D88 → v1 encrypted bytes
    ├─ unk_100001DA8 → v2 encrypted bytes
    └─ unk_100001DD0 → v3 encrypted bytes

  2. Все ключи в открытом виде: ├─ v1: 0x0E92FAAE ├─ v2: 0x4CA5FC07, 0x423706AA └─ v3: 0xEEFC76CC, 0x0E06E8C63

  3. Алгоритм шифрования: ├─ rotl32(), rotr32() функции ├─ XOR с (rotl(key, i) + i) └─ 2-слойный шифр для v2/v3

  4. Размер всех строк: 10 байт

📊 Матрица защиты vs Угроза:

┌────────────────┬─────────┬──────────────┐ │ Угроза │ Защита │ Время взлома │ ├────────────────┼─────────┼──────────────┤ │ strings binary │ ✅ 100% │ Нельзя │ ├────────────────┼─────────┼──────────────┤ │ grep │ ✅ 100% │ Нельзя │ ├────────────────┼─────────┼──────────────┤ │ Hex editor │ ✅ 95% │ ~1 час │ ├────────────────┼─────────┼──────────────┤ │ IDA/Ghidra │ ❌ 0% │ ~5 мин │ ├────────────────┼─────────┼──────────────┤ │ lldb/gdb │ ❌ 0% │ ~1 мин │ ├────────────────┼─────────┼──────────────┤ │ Memory dump │ ❌ 0% │ ~1 мин │ └────────────────┴─────────┴──────────────┘

💡 Главный вывод:

Compile-time шифрование = "Security Theatre" против серьёзного атакующего

┌─────────────────────────────────────────────────┐ │ Защита СКРЫВАЕТ строки от новичка │ │ НО НЕ от reverse engineer с IDA/Ghidra │ │ │ │ Для реальной защиты нужно: │ │ ├─ Ключи вне процесса (HSM, external vault) │ │ ├─ Runtime генерация ключей │ │ ├─ Обфускация кода (VMProtect, Themida) │ │ └─ Anti-debugging techniques │ └─────────────────────────────────────────────────┘

Recommendation: Используйте compile-time шифрование для:

  • ✅ Защиты от утечек через strings
  • ✅ Усложнения жизни Script Kiddies
  • ✅ Скрытия API endpoints, URLs

Но НЕ полагайтесь на него для:

  • ❌ Реальной защиты секретов
  • ❌ Защиты от瞪逆向 (dedicated reverse engineers)
  • ❌ Compliance требований к безопасности