Как увидеть и изменить таблицу конфигурации (Configuration Table) в PE-файле

Если вы попали сюда, скорее всего, вам нужно поправить поведение исполняемого файла без перекомпиляции — поменять путь к DLL, сменить адрес сервера, отключить проверку лицензии или что-то в этом духе. Configuration Table внутри PE-файла — это один из удобных способов хранить настройки прямо в бинарнике. Разберёмся, где она находится, как её прочитать и безопасно отредактировать.

Что такое Configuration Table в PE-файле

В контексте PE-под Windows Configuration Table — это структура, через которую система или само приложение может читать параметры конфигурации, зашитые прямо в исполняемый файл. Это не отдельная секция с красивым именем .config, а именно таблица — набор записей с парами ключ-значение или иными полями, определённые разработчиком приложения.

Чаще всего под этим подразумевают одну из трёх вещей:

• Встроенный конфиг .NET-приложения — таблица строк или бинарных данных в metadata сборки.
• Custom configuration table — самодельная структура в секции данных, которую разработчик прописал в коде.
• AppDomain configuration entries — записи в секции ресурсов или в специальных структурах CLR.

Если вы работаете с .NET-исполняемым файлом, скорее всего, вы имеете дело с таблицами метаданных. Если с нативным C/C++ — это будет что-то вроде массива структур в секции .data или .rdata.

Как найти Configuration Table в PE-файле

Шаг 1. Определите, с каким файлом имеете дело

Откройте файл в CFF Explorer или PE-bear (оба бесплатны). Посмотрите на наличие директории COM Descriptor (для .NET) или на структуру секций.

Если видите признаки .NET — есть директория COM Descriptor, секция .text с метаданными — значит, конфиг нужно искать в метаданных. Если это нативный файл — ищите в секциях данных.

Шаг 2. Для .NET — ищем в метаданных

В CFF Explorer перейдите в раздел Metadata → Tables. Там вы увидите список всех таблиц CLI-метаданных. Configuration Table в .NET представлена как таблица с типом 0x17 (User Strings Heap) или может быть частью других таблиц в зависимости от реализации.

На практике проще всего найти нужные строки через dnSpy:

1. Откройте файл в dnSpy.
2. Перейдите в дерево узлов сборки → найдите ресурсы или строки.
3. Используйте поиск (Ctrl+F) по известному значению из конфига.
4. Когда найдёте строку — станет понятно, в какой именно таблице или ресурсе лежит конфиг.

Шаг 3. Для нативных файлов — ищем в секциях

Откройте PE-bear или CFF Explorer, посмотрите на секции. Обычно конфигурационные данные лежат в:

• .rdata — только для чтения, строки и константы.
• .data — изменяемые данные.
• Пользовательская секция с именем типа .config или .cfg.

Если знаете хотя бы одно значение из конфига (например, адрес сервера или имя ключа), можно открыть файл в HEX-редакторе (HxD — бесплатный и удобный) и просто найти эту строку. От найденного места уже можно двигаться вверх и вниз, чтобы понять структуру таблицы.

Как изменить Configuration Table

Вариант 1: .NET-файл через dnSpy

dnSpy — самый удобный инструмент для этой задачи. Пошагово:

1. Откройте файл в dnSpy.
2. Найдите нужный метод или поле, которое отвечает за чтение конфига.
3. Кликните правой кнопкой → Edit Method (C#) или Edit IL Instructions.
4. Найдите строку или значение, которое нужно изменить, и поправьте.
5. Нажмите Compile — метод перекомпилируется на лету.
6. Перейдите в родительский узел (класс, модуль) и сохраните сборку через File → Save Module.

Если конфиг хранится в ресурсах — найдите ресурс в дереве узлов, кликните правой кнопкой и замените содержимое.

Вариант 2: Нативный файл через HEX-редактор

Здесь всё руками. Алгоритм такой:

1. Найдите нужную строку в HXD (поиск по тексту или HEX).
2. Запишите смещение (offset) данных в файле.
3. Определите формат — ANSI, UTF-8, UTF-16LE. В Windows часто используется UTF-16LE (каждый символ — 2 байта, между ними нули).
4. Замените значение. Важное правило: новая строка должна быть той же длины или короче. Если короче — дополняйте нулями.
5. Если строка длиннее — вы не можете просто так её записать, потому что это затрет следующие данные. В этом случае придётся либо найти свободное место в файле (cave), либо перестраивать структуру таблицы.
6. Сохраните файл и проверьте, что он запускается.

Вариант 3: Через паттерн-поиск в x64dbg

Если нужно понять, как именно программа читает конфиг, и пропатчить не данные, а логику чтения:

1. Запустите файл в x64dbg.
2. Поставьте брейкпоинт на функции чтения строк/файлов (например, GetPrivateProfileString, ReadFile, RegQueryValueEx).
3. Посмотрите, откуда читаются данные — это укажет на расположение таблицы.
4. Найдите в памяти нужное значение и измените его прямо в отладчике.
5. Если нужно сохранить — используйте плагин Scylla для дампа пропатченного образа.

Сравнение подходов к редактированию

Что делать в зависимости от вашей ситуации

У вас .NET-приложение и нужно поменять строку в конфиге: открывайте dnSpy, ищите строку, редактируйте, сохраняйте модуль. Это самый быстрый путь, который не требует глубоких знаний.

У вас нативный файл и нужно заменить строку фиксированной длины: HXD + поиск по HEX. Главное — не выходите за границы исходной строки, иначе повредите соседние данные.

Нужно добавить новую запись в таблицу или изменить структуру: тут без x64dbg и понимания формата таблицы не обойтись. Сначала изучите структуру в отладчике, потом уже правьте.

Файл обфусцирован или упакован (UPX, Themida, VMProtect): сначала снимите упаковку. Для UPX — upx -d file.exe. Для остальных — нужен опыт в реверс-инжиниринге, это отдельная тема.

Частые ошибки при редактировании

• Запись строки длиннее оригинала без сдвига данных. Это самая частая ошибка. Вы перезаписываете байты за пределами своей строки, и файл либо не запустится, либо упадёт с непонятной ошибкой. Если новая строка длиннее — ищите свободное пространство (code cave) или используйте относительные адреса для перенаправления.
• Неправильная кодировка. Если программа использует UTF-16LE, а вы пишете в ANSI — данные будут испорчены. Всегда проверяйте формат через HEX: в UTF-16LE между символами ASCII стоят нулевые байты.
• Изменение файла без бэкапа. Сделайте копию оригинала. Одна неправильная запись — и файл невозможно запустить без восстановления.
• Редактирование с нарушением выравнивания. Некоторые таблицы требуют выравнивания записей по границам 4 или 8 байт. Если сдвинете начало записи — программа будет читать данные со смещением.
• Забыли про контрольные суммы. Некоторые программы проверяют целостность конфига (CRC, хэш). Если изменить данные без пересчёта контрольной суммы — программа может проигнорировать изменения или выдать ошибку.

Практические рекомендации

1. Всегда работайте с копией. Оригинал должен быть неприкосновен. Если что-то пойдёт не так — вы просто начнёте заново с копии.
2. Фиксируйте смещения. Запишите, что и по какому адресу вы изменили. Это поможет откатить изменения или понять, что пошло не так.
3. Проверяйте контрольные суммы PE. После редактирования нативного файла пересчитайте контрольную сумму в заголовке PE (CFF Explorer делает это автоматически при сохранении).
4. Тестируйте на стенде. Не запускайте пропатченный файл сразу на рабочей машине. Используйте виртуальную машину или тестовую среду.
5. Документируйте изменения. Если вы работаете в команде или вернётесь к этому файлу через месяц — записи о том, что и зачем было изменено, сэкономят часы времени.

Итог

Configuration Table в PE-файле — это не магия, а просто структура данных, которую можно найти и изменить, если понимать, с чем вы работаете. Для .NET — dnSpy ваш лучший друг. Для нативных файлов — HEX-редактор для простых замен и x64dbg для сложных случаев. Главные правила: не выходите за границы исходных данных, всегда делайте бэкап и проверяйте кодировку. Если файл упакован или обфусцирован — сначала снимите защиту, потом уже лезьте в конфиг.