Пишем упаковщик по шагам. Шаг пятый. Ресурсы.

Предыдущий шаг здесь.

Пора усовершенствовать наш упаковщик. Он уже способен упаковывать и запускать самые простые бинарники, имеющие лишь таблицу импорта. Бинарники с экспортами, ресурсами, TLS, DLL с релокациями ему пока что не под силу. Нужно над этим работать. Для начала сделаем обработку второй по важности вещи после импортов - директории ресурсов.

Сначала добавим пару полей в структуру packed_file_info:

//...
  DWORD original_resource_directory_rva;//Относительный адрес оригинальной директории ресурсов
  DWORD original_resource_directory_size;//Размер оригинальной директории ресурсов//...

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

Сначала займемся распаковщиком (проект unpacker), тем более, изменения будут минимальными. Добавим строки аналогично коду для директории импорта:

//...//Относительный виртуальный адрес директории ресурсов
  DWORD original_resource_directory_rva;//Виртуальный размер директории ресурсов
  DWORD original_resource_directory_size;
 
//...
 
  original_resource_directory_rva = info->original_resource_directory_rva;
  original_resource_directory_size = info->original_resource_directory_size;
 
//...
 
  //Указатель на директорию ресурсов
  IMAGE_DATA_DIRECTORY* resource_dir;
  resource_dir =reinterpret_cast<IMAGE_DATA_DIRECTORY*>(offset_to_directories +sizeof(IMAGE_DATA_DIRECTORY)* IMAGE_DIRECTORY_ENTRY_RESOURCE);//Записываем значения размера и виртуального адреса в соответствующие поля
  resource_dir->Size = original_resource_directory_size;
  resource_dir->VirtualAddress = original_resource_directory_rva;

С распаковщиком все. Переходим к упаковщику (проект simple_pe_packer). Добавим, опять-таки, аналогичные для директории импорта строки для директории ресурсов:

//...//Запоминаем относительный адрес и размер//оригинальной директории ресурсов упаковываемого файла
    basic_info.original_resource_directory_rva= image.get_directory_rva(IMAGE_DIRECTORY_ENTRY_RESOURCE);
    basic_info.original_resource_directory_size= image.get_directory_size(IMAGE_DIRECTORY_ENTRY_RESOURCE);//...

В принципе, этого уже должно быть достаточно, чтобы файл с ресурсами (формами, например) мог запуститься. Проблемы возникнут, если у файла есть xp manifest или что-то подобное. Поэтому нам теперь необходимо пересобрать директорию ресурсов в упаковщике, как я описывал выше. В начало файла main.cpp добавим новый #include <pe_resource_manager.h>. Он необходим для доступа к вспомогательным классам для работы с ресурсами. Код будем добавлять в то место упаковщика, где удаляются секции исходного файла (прямо перед этим действием):

//Новая пустая корневая директория ресурсов
      pe_base::resource_directory new_root_dir;
 
 
      if(image.has_resources()){
        std::cout<<"Repacking resources..."<< std::endl;
 
        //Получим ресурсы исходного файла (корневую директорию)
        pe_base::resource_directory root_dir = image.get_resources();//Оборачиваем оригинальную и новую директорию ресурсов//во вспомогательные классы
        pe_resource_viewer res(root_dir);
        pe_resource_manager new_res(new_root_dir);
 
        try{//Перечислим все именованные группы иконок//и группы иконок, имеющие ID
          pe_resource_viewer::resource_id_list icon_id_list(res.list_resource_ids(pe_resource_viewer::resource_icon_group));
          pe_resource_viewer::resource_name_list icon_name_list(res.list_resource_names(pe_resource_viewer::resource_icon_group));//Сначала всегда располагаются именованные ресурсы, поэтому проверим, есть ли ониif(!icon_name_list.empty()){//Получим самую первую иконку для самого первого языка (по индексу 0)//Если надо было бы перечислить языки для заданной иконки, можно было вызвать list_resource_languages//Если надо было бы получить иконку для конкретного языка, можно было вызвать get_icon_by_name (перегрузка с указанием языка)//Добавим группу иконок в новую директорию ресурсов
            new_res.add_icon(
              res.get_icon_by_name(icon_name_list[0]),
              icon_name_list[0],
              res.list_resource_languages(pe_resource_viewer::resource_icon_group, icon_name_list[0]).at(0));}elseif(!icon_id_list.empty())//Если нет именованных групп иконок, но есть группы с ID{//Получим самую первую иконку для самого первого языка (по индексу 0)//Если надо было бы перечислить языки для заданной иконки, можно было вызвать list_resource_languages//Если надо было бы получить иконку для конкретного языка, можно было вызвать get_icon_by_id_lang//Добавим группу иконок в новую директорию ресурсов
            new_res.add_icon(
              res.get_icon_by_id(icon_id_list[0]),
              icon_id_list[0],
              res.list_resource_languages(pe_resource_viewer::resource_icon_group, icon_id_list[0]).at(0));}}catch(const pe_exception&){//Если какая-то ошибка с ресурсами, например, иконок нет,//то ничего не делаем}
 
        try{//Получим список манифестов, имеющих ID
          pe_resource_viewer::resource_id_list manifest_id_list(res.list_resource_ids(pe_resource_viewer::resource_manifest));if(!manifest_id_list.empty())//Если манифест есть{//Получим самый первый манифест для самого первого языка (по индексу 0)//Добавим манифест в новую директорию ресурсов
            new_res.add_resource(
              res.get_resource_data_by_id(pe_resource_viewer::resource_manifest, manifest_id_list[0]).get_data(),
              pe_resource_viewer::resource_manifest,
              manifest_id_list[0],
              res.list_resource_languages(pe_resource_viewer::resource_manifest, manifest_id_list[0]).at(0));}}catch(const pe_exception&){//Если какая-то ошибка с ресурсами,//то ничего не делаем}
 
        try{//Получим список структур информаций о версии, имеющих ID
          pe_resource_viewer::resource_id_list version_info_id_list(res.list_resource_ids(pe_resource_viewer::resource_version));if(!version_info_id_list.empty())//Если информация о версии есть{//Получим самую первую структуру информации о версии для самого первого языка (по индексу 0)//Добавим информацию о версии в новую директорию ресурсов
            new_res.add_resource(
              res.get_resource_data_by_id(pe_resource_viewer::resource_version, version_info_id_list[0]).get_data(),
              pe_resource_viewer::resource_version,
              version_info_id_list[0],
              res.list_resource_languages(pe_resource_viewer::resource_version, version_info_id_list[0]).at(0));}}catch(const pe_exception&){//Если какая-то ошибка с ресурсами,//то ничего не делаем}}

Итак, что же происходит в этом куске кода? Если вкратце, то мы получаем ресурсы оригинального файла и ищем в них:
1. Иконки
2. Манифест
3. Информацию о версии

Эти три вида ресурсов необходимо в неупакованном виде положить в новую директорию ресурсов. Иконку (точнее, группу иконок) из оригинального файла мы возьмем самую первую, именно ее использует Windows как основную иконку файла. Манифест всегда у файла один, и в нем сказано, какие права нужны файлу для запуска и какие DLL-файлы используются. Там может храниться и другая информация. Наконец, информация о версии - это непосредственно информация о файле, которую также можно просмотреть в проводнике Windows.

Я до этого нигде не описывал, как устроена директория ресурсов, поэтому для общего развития приведу эту информацию сейчас. Посмотрим на ресурсы какого-нибудь exe-файла в CFF Explorer'е:

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

Так вот, в коде выше мы перечисляем все иконки, имеющие ID или имя. Так как в PE-файлах все ресурсы сортируются, причем сначала идут именованные ресурсы, а потом только ресурсы с ID, исходя из этого, мы и ищем самую первую иконку. Она и будет иконкой приложения, и ее мы добавляем в новую директорию ресурсов, сохраняя ее имя/ID и язык. Аналогично поступаем с манифестом и информацией о версии - у всех файлов не больше одной такой записи, причем всегда неименованные, т.е. имеющие ID, поэтому берем и сохраняем первую запись манифеста и первую запись информации о версии.

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

//Если у нас есть ресурсы для сборки,//отключим автоматическое урезание секции после//добавления в нее импортовif(!new_root_dir.get_entry_list().empty())
        settings.enable_auto_strip_last_section(false);
 
      //Пересоберем импорты
      image.rebuild_imports(imports, added_section, settings);

Дело в том, что все пересборщики в моей библиотеке для работы с PE автоматически уберут все нулевые байты с конца секции, в которую пересобирают импорты/экспорты/ресурсы и т.д., при условии, что секция последняя в файле. Это совершенно адекватное поведение, позволяющее уменьшить размер файла в пределах файлового выравнивания, так как загрузчик все равно нулевые байты восстановит, но уже в памяти, в количестве [выровненный виртуальный размер секции] минус [физический размер секции]. Таким образом, если у нас какие-то структуры внутри секции заканчиваются нулевым элементом (например, завершающий дескриптор таблицы импортов), физически в файл он записан не будет, если эта таблица импортов собирается в последней секции PE-файла. С этим, кстати, связаны интересные баги в таких редакторах, как CFF Explorer, он опирается только на физические данные файла, а не на виртуальные. Поэтому он может криво отобразить ту же таблицу импорта с отрезанными нулевыми байтами в конце.

Сейчас же нам необходимо, чтобы нулевые байты в конце секции, относящиеся к таблице импорта, не обрезались, так как мы сразу после импортов разместим ресурсы. Если мы обрежем эти нулевые байты, то директория ресурсов наслоится на директорию импортов, и получится полная хрень.

Идем дальше - пересобираем ресурсы:

//Пересоберем ресурсы, если есть, что пересобиратьif(!new_root_dir.get_entry_list().empty())
        image.rebuild_resources(new_root_dir, added_section, added_section.get_raw_data().size());

Здесь все ясно - если какие-то ресурсы есть, мы их записываем в новый PE-файл. Располагаем мы их в самом конце добавленной секции, сразу за импортами. Так как секция последняя на момент пересборки ресурсов, она расширится автоматически.

Осталось убрать одну строчку, которая убирает директорию ресурсов:

    image.remove_directory(IMAGE_DIRECTORY_ENTRY_RESOURCE);

Все готово! Можно проверить упаковщик на любом exe-файле, имеющем импорты, ресурсы и даже релокации (хотя мы их пока что не обрабатываем). Давайте возьмем какой-нибудь проект на MSVC++ с MFC и посмотрим с помощью CFF Explorer'а, какие ресурсы в нем были изначально:

После упаковки имеем:

Итак, осталась одна группа иконок с несколькими иконками в ней (иконки приложения), манифест (configuration files) и информация о версии. Разумеется, упакованный файл успешно запускается!

Полный солюшен для этого шага: Own PE Packer step 5

Также рекомендую почитать

 Обсудить на форуме


Источник: http://feedproxy.google.com/~r/kaimi/dev/~3/sv1MqHn6llo/

Читать комменты и комментировать

Добавить комментарий / отзыв



Защитный код
Обновить

Пишем упаковщик по шагам. Шаг пятый. Ресурсы. | | 2012-09-19 15:11:00 | | Блоги и всяко-разно | | Предыдущий шаг здесь.Пора усовершенствовать наш упаковщик. Он уже способен упаковывать и запускать самые простые бинарники, имеющие лишь таблицу импорта. Бинарники с экспортами, ресурсами, TLS, DLL с | РэдЛайн, создание сайта, заказать сайт, разработка сайтов, реклама в Интернете, продвижение, маркетинговые исследования, дизайн студия, веб дизайн, раскрутка сайта, создать сайт компании, сделать сайт, создание сайтов, изготовление сайта, обслуживание сайтов, изготовление сайтов, заказать интернет сайт, создать сайт, изготовить сайт, разработка сайта, web студия, создание веб сайта, поддержка сайта, сайт на заказ, сопровождение сайта, дизайн сайта, сайт под ключ, заказ сайта, реклама сайта, хостинг, регистрация доменов, хабаровск, краснодар, москва, комсомольск |
 
Поделиться с друзьями: