Упакованный и зашифрованный раздел в обращении x86, без отключения энтропийной эвристики

Question

ЗАДАЧА:

Я создаю набор задач обратного инжиниринга сборки x86, из которых я уже выполнил двадцать или около того.Они просто для развлечения / образования.

Текущая задача - одна из наиболее продвинутых и включает в себя некоторые хитрости, из-за которых создается впечатление, что EP на самом деле входит в обычную программу, но на самом деле он упакован вдругой раздел PE.

Вот основной поток:

• Запускается, как если бы это было обычное приложение MSVC ++.
• Внедрил скрытый вызов в группутрюков анти-отладчика.
• Если они проходят, DWORD в памяти устанавливается на 1.
• Позже в потоке программы он проверяет, что это значение равно 1, и если это работаетрасшифровывает небольшую таблицу вызовов.Если происходит сбой, он отправляет их в погоню за ложными уловками, препятствующими отладке, и в конечном итоге просто падает.
• Таблица вызовов указывает на реальные процедуры дешифрования, которые дешифруют секцию действительного кода программы.
• Вызываются процедуры дешифрования, и они дешифруются с использованием базового зацикленного xor (C ^ k ^ n, где C - это зашифрованный текст, k - это 32-битный ключ, а n - текущее смещение данных)
• VirtualProtectиспользуется для переключения флагов защиты раздела с RW на RX.
• Поток управления перенаправлен на OEP, программа запускается.

Идея состоит в том, что, поскольку они думают, что они в нормепрограммный поток, он заставляет их пропустить анти-отладочный вызов и последующие проверки.В любом случае, все работает нормально.

ПРОБЛЕМА:

В настоящее время проблема заключается в том, что OllyDbg и несколько других инструментов смотрят на упакованный раздел и видят, что он имеет высокую энтропиюи выбросить предупреждение, что оно упаковано.Указатель на секцию кода в заголовке PE установлен правильно, поэтому он не получает этого от наличия внешнего кода EP - это чисто энтропийный анализ.

ВОПРОС:

Есть ли способ шифрования, который я могу использовать, который сохраняет низкую энтропию, но все еще прост в реализации в asm x86?Я не хочу использовать простой xor, так как это слишком просто, но я также не хочу, чтобы он поймал его как упакованный и выдал игру.

Я думал о чем-то вроде шаффлера (как-тосоздать ключевой поток и использовать его для обмена 4-байтовыми блоками кода), но я не уверен, что это сработает или даже будет простым.

У кого-нибудь есть идеи?

Answer 1

Не упаковывайте / не шифруйте ваш весь программный код.Просто зашифруйте небольшой процент байтов, случайно выбранных из кода вашей программы.Если они не расшифрованы, программа вскоре завершит работу, если попытается запустить код в любом случае - и поскольку большая часть программы не изменилась, проверки на основе энтропии не будут установлены.

Answer 2

На самом деле, OllyDbg работает так: псевдокод:

useful_bytes = number_of_bytes_in_section - count_bytes_with_values(0x00, 0x90, 0xCC)
warn about compression if useful_bytes > 0x2000 and count_bytes_with_values(0xFF, 0xE8, 0x8B, 0x89, 0x83) / useful_bytes < 0.075

Таким образом, способ избежать этого предупреждения - использовать достаточно байтов со значениями 0xFF 0xE8 0x8B 0x89 0x83 в сжатом разделе.

Answer 3

РЕДАКТИРОВАТЬ: Неправильное предположение, это не так, как работает Олли.Смотрите мой другой ответ.Это относится и к инструментам, отличным от OllyDbg, который вычисляет энтропию.

Расширение комментария ninjaljs:

Пока я не проверил, значение энтропии, которое OllyDbg вычисляет, скорее всего, без контекста,См. Как рассчитать энтропию файла? , чтобы найти общий алгоритм для этого.

Этот алгоритм дает последовательности 0 1 2 ... 254 255 максимально возможную энтропию,несмотря на то, что полностью предсказуемо.Последовательность случайных байтов в диапазоне от 0 до 255 получит слегка меньшую энтропию, поскольку она не будет иметь точно такое же число каждого возможного значения.

Некоторые быстрые проверки несжатых исполняемых файлов с помощью pefile говорит мне, что несжатый код x86 имеет энтропию от 6,3 до 6,6.Сжатый код с энтропией 8.0, закодированный с помощью base64, имеет энтропию 6.0.Таким образом, base64 достаточно просто, чтобы остановить этот алгоритм от поиска сжатого кода.

Answer 4

Как насчет простого обращения байтов (от последнего к первому)?Инструкции Intel для ассемблера не имеют фиксированной длины, так что это немного их перемешает.Или вы можете просто повернуть каждый байт на фиксированную величину ...