Основные фичи библиотеки:
[+] Чтение 32-разрядных и 64-разрядных PE-файлов (PE, PE+) для Windows, возможность единообразной работы с обоими форматами
[+] Создание PE/PE+ файлов с нуля
[+] Пересборка 32-разрядных и 64-разрядных PE-файлов
[+] Работа с директориями и заголовками
[+] Конвертирование адресов
[+] Чтение и редактирование секций PE-файла
[+] Чтение и редактирование таблицы импортов
[+] Чтение и редактирование таблицы экспортов
[+] Чтение и редактирование таблиц релокаций
[+] Чтение и редактирование ресурсов
[+] Чтение и редактирование TLS
[+] Чтение конфигурации образа (image config)
[+] Чтение базовой информации .NET
[+] Чтение информации о привязанном импорте
[+] Чтение директории исключений (только PE+)
[+] Чтение отладочной директории с расширенной информацией
[+] Вычисление энтропии
[+] Изменение файлового выравнивания
[+] Изменение базового адреса загрузки
[+] Работа с DOS Stub'ом и Rich overlay
[+] Высокоуровневое чтение ресурсов: картинки, иконки, курсоры, информация о версии, строковые таблицы, таблицы сообщений
[+] Высокоуровневое редактирование ресурсов: картинки, иконки, курсоры, информация о версии

Словом, все, что вы хотели сделать с PE, но боялись спросить, как. Весь код библиотеки снабжен обильными комментариями на английском языке. В проект включено 25 примеров работы с библиотекой, которые показывают, как работать с той или иной частью библиотеки (комментарии на русском языке). Имеются солюшены для MSVC++ 2008 и 2010. Справочной информации пока нет, возможно, соберусь ее как-нибудь написать.

Библиотека не использует WinAPI или другие библиотеки, только STL.

Библиотека и примеры собираются под Windows x86 и x64, но для того, чтобы работать с PE+, собирать под x64 необязательно. Библиотека не исполняет считываемые файлы, не маппит их в память, поэтому с ее помощью можно спокойно открывать подозрительные исполняемые файлы и работать с ними. Теперь собирается еще и под Linux.

Проект залит на code.google.com на случай возможных правок и улучшений, так как сейчас библиотека в стадии альфа-версии.

Автор: dx
Репозиторий: --> Link <--
Комментарии принимаются тут: --> Link <--

2970_08.09.2012_EXELAB.rU.tgz - pe_lib.zip

| Сообщение посчитали полезным: SWR, gena-m, mak, Dynamic, r_e, ntldr, NikolayD, SReg, _ruzmaz_, =TS=, Gideon Vi, MasterSoft, BAHEK, sivorog, vnekrilov, Functor, UniSoft, hlmadip, HandMill, plutos, Veliant, -= ALEX =-, elch, invalid, Artem_N, t0ShA, HiEndsoft, verdizela, obfuskator, tomac, sendersu, nick8606, MarcElBichon, ValdiS, Coderess

Таки мельком глянул:

1) template<
typename NtHeadersType,
typename OptHeadersType,
WORD IdVal,
typename BaseSizeType,
BaseSizeType ImportSnapFlagVal,
typename TLSStructType,
typename ConfigStructType>
class pe_class_type
Дизайн вообще не проектировался. Похоже сразу писался код.

2) dos_header_.e_cblp = 0x90; //HardCode

3) throw pe_exception("Specified directory does not exist", pe_exception::directory_does_not_exist);
Чувак не в курсах, что такое Logging Subsystem и бросает исключения Маловероятно, что такой код сможет пройти элементарное юнит-тестирование.

4)if(va == 0) break; // if(!va)

5) Размер кода в функции превосходит размер страницы - такой код не поддерживается профессиональными разрабами, размер тела функции не должен превышать размер страницы печатного текста.
7) BlockDiagram для методов не разрабатывались перед написанием кода, о чём говорят многочисленные вложенные операторы ветвления.

8) Методы шаблонного класса вытащили из хэдера в сппшник - интересно!
//Two used instantiations for PE32 (PE) and PE64 (PE+)

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

| Сообщение посчитали полезным:

Про юнит-тесты - продукт заинклудивший либу, может упасть в том случае если хотя бы один из интерфейсных методов либы приводит к segfault'у(unhandled exception, * null pointer и т.д.). Поэтому перед включением все интерфейсные методы должны быть вызваны с корректными и некорректными параметрами и их корреляциями. Лишь после того как проверится, что либа не окажет негативного влияния на функционал продукта, она инклудится. Упрощённо примерно так... На самом деле, конечно сложнее интерфейсы теcтируются не у либы, а у каждого класса в либе

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным: SReg, plutos, ressa, HandMill

1. Дизайн вообще не проектировался. Похоже сразу писался код.
Нет, проектировался, а эта длинная хрень специально вынесена в отдельный шаблонный класс, и про это даже есть коммент. Она нужна для задания значений и структур, специфичных для двух форматов - PE и PE+.

2. dos_header_.e_cblp = 0x90; //HardCode
Перед этими строчками есть спец-коммент, что когда мы создаем бинарник с нуля, я юзаю значения, которые в хедеры пишет MSVC++10, и вот они все.
//Magic numbers from MSVC++ build
dos_header_.e_maxalloc = 0xFFFF;
dos_header_.e_cblp = 0x90;

3. Чувак не в курсах, что такое Logging Subsystem и бросает исключения Маловероятно, что такой код сможет пройти элементарное юнит-тестирование.
Boost и ClanLib например бросают исключения и при этом проходят юнит-тесты.

4. if(va == 0) break; // if(!va)
Ну да, такая-то ошибка.

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

6. BlockDiagram для методов не разрабатывались перед написанием кода, о чём говорят многочисленные вложенные операторы ветвления.
Рекомендую попробовать разобрать мегавложенные структуры PE без операторов ветвления. Хотя этот пункт скорее тоже к предыдущему относится.

7. Методы шаблонного класса вытащили из хэдера в сппшник - интересно!
Конечно, про это есть коммент, зачем это сделано. Затем, чтобы каждый раз это не компилялось при юзании либы, и т.к. всего две возможны инстанциации шаблона, то их проще перенести в цппшник, да и интерфейс класса в хедере будет удобно виден.

| Сообщение посчитали полезным:

Kaimi
Да ты его меньше слушай. Студент какой-то недавний учит всех плюсам.

-----
старый пень

| Сообщение посчитали полезным:

Kaimi
Либа нужная. Заметил, что не обновляется cheksum при rebuild_pe, если была не 0;

-----
продавец резиновых утёнков

| Сообщение посчитали полезным:

HiEndsoft пишет:
Либа нужная. Заметил, что не обновляется cheksum при rebuild_pe, если была не 0;
В семпле под названием full_pe_rebuilder есть кусок кода из трех строк, который показывает, как пересчитать checksum. Загрузчик ее только в дровах проверяет, в остальных бинарниках ему на нее пофиг.

| Сообщение посчитали полезным:

TheNozza пишет:
5) Размер кода в функции превосходит размер страницы - такой код не поддерживается профессиональными разрабами, размер тела функции не должен превышать размер страницы печатного текста.
Ты это скажи разработчикам boost, poco, qt или тот же crt, а то посоны не знают.
Это носит рекомендательный характер если только не указанно в рабочем стандарте, а когда сам пилишь, то зачастую на это ложиться пися.
BlockDiagram для методов не разрабатывались перед написанием кода
Проект не того уровня что бы строить uml картинки под него, не спорю что красиво, но зачастую бесполезная трата времени.

| Сообщение посчитали полезным:

Красивый дизайн, 100% покрытие тестами, uml картинки и красочные презентации это круто, но если над всем этим задрачиваться, то когда работать? Вам шашечки или ехать?

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: plutos, =TS=

Да уж, если б мой код кто увидел, так расплакались бы, а потом обняли бы меня и спросили: " Чувак, ну как ты живёшь так, без мозгов-то?"

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

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: plutos, hors

<<<Рекомендую попробовать разобрать мегавложенные структуры PE без операторов ветвления.

В простых случаях от ветвлений (if/else) избавляются так:
а) switching //довольно старый вариант, не могу сказать что хороший
б) mapping (map<key, function pointer>) //активно используется в настоящее время

В сложных случаях применяют стэйтмашины, способные обрабатывать условия колоссальной сложности и вложенности. Можно обратиться к книге "Приёмы объектно ориентированного проектирования. Паттерны", среди прочего там разобран паттерн "State" - это и есть стэйтмашина.

| Сообщение посчитали полезным:

Позволю себе повторить просьбу г. Gideon Vi:

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

А пиzдеть-то мы все мастера!

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным: ARCHANGEL, SReg, KingSise, hors, [wl]

TheNozza
А взять написать патч, протестить и скинут Kaimi не или хотя бы баг репорт накатать?
Я рад за вас что вы узнали основы программирования и проектирования, только нах всем это рассказывать?
Тут многие закончили институт когда вы еще какались.

| Сообщение посчитали полезным: plutos

TheNozza пишет:
обратиться к книге "Приёмы объектно ориентированного проектирования. Паттерны"

можно
на практике все совсем по другому.......
ет вам, не пожалеете

http://www.ozon.ru/context/detail/id/4883702/

| Сообщение посчитали полезным: plutos

TheNozza - нафаня?

| Сообщение посчитали полезным:

Просто TheNozza - советчик (предыдущее выкладывание данного видоса было потерто)

З.Ы. "Давай, Арч, три мой пост, три мой пост полностью!"(с)

| Сообщение посчитали полезным:

TheNozza пишет:
Можно обратиться к книге "Приёмы объектно ориентированного проектирования. Паттерны"
Ссылка специально для вас.
Вы читаете умные книги - Мы просто пишем код блять!
Вы учите паттерны и модные приемы ООП - Мы просто пишем код блять!
Вы чертите uml диаграммы и продумываете архитектуру - Мы просто пишем код блять!
Вы ругаете if и приходите в бешенство от goto - мы не заморачиваемся, а просто пишем код блять!
Все сроки прошли и вы только начали писать - а мы давно написали и уже рубим бабки, блять!
Говорите код получится не поддерживаемым? А вы уверены что его нужно поддерживать? Вы уверены что не потребуются изменения ломающие вашу выстраданную архитектуру? Мы не пытаемся угадывать будущее и делать ненужную работу, мы просто пишем код блять! А архитектура... Она сама сложится или не понадобится.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: HiEndsoft, NikolayD, TryAga1n, nick8606, Veliant, 2nd, void, OnLyOnE, sendersu, Ra1n0, SWR, Gideon Vi, HandMill, DimitarSerg, =TS=, obfuskator, hors, Simargl

ntldr пишет:
Вы уверены что не потребуются изменения ломающие вашу выстраданную архитектуру?

Собственно, вот она, фраза дня. Сакральное, я бы даже сказал.

| Сообщение посчитали полезным:

ntldr пишет:
просто пишем код блять!
неплохой, кстати, способ завести проект в тупик, из которого не захочется выходить

| Сообщение посчитали полезным:

Ни кто не против наличия продуманной архитектуры, даже эти, с манифестом. Задрачивать на на этом не надо, вот и все. dx сделал годную библиотеку с костылями, TheNozza ни сделал ничего.

| Сообщение посчитали полезным: plutos

_ruzmaz_
Я слишком много видел проектов с архитектурой но без кода, они были эпически провалены, при этом разработчики винили во всём тупое начальство принявшее волевое решение о прекращении проекта (а что еще делать если дедлайны проваливались 5 раз подряд, все разумные и неразумные сроки давно вышли, заказчик негодует и обещает лютые кары). Одна команда сотворившая такое была уволена с позором.
Огромное количество проектов пишется ситуационно, когда архитектура выстраивается по ходу работы, а то что в нее не вписывается - прикручивается сбоку. Если срок жизни проекта исчисляется не десятилетиями, до тупика не успевают добраться. И не всегда из тупика нужно выходить.

В целом я не против паттернов программирования и умных подходов к разработке, но важно не забывать что работаем на результат.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Теперь библиотека собирается под Linux

| Сообщение посчитали полезным:

ntldr пишет:
проектов с архитектурой но без кода
ну это в конторах, для любительских же проектов, думаю, более характерен обратный вариант

| Сообщение посчитали полезным:

<<dx сделал годную библиотеку с костылями, TheNozza ни сделал ничего.
О том чего я сделал и чего не сделал думаю судить не Вам. Если вы имеете ввиду, что для форума ничего не сделал - так тут всё вполне очевидно: я не разрабатываю open source software.

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

<<А архитектура... Она сама сложится или не понадобится.
Детский лепет ребёнка, не нюхавшего пороха, который не сталкивался с рефакторингом существующего кода. Без понимая концепции гибкой, расширяемой архитектуры о профессиональной разработке не может идти и речи.

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

| Сообщение посчитали полезным:

<<Мы просто пишем код
А Вы не пробовали подняться на следующий level и начать мыслить не в синтаксических конструкциях C++ (if/else/switch/и.тд.), а на более высоком высоком уровне абстракции о дизайне: классы, у которых определены интерфейсы для клиентов, связи между внутренними компонентами программной системы (композиция, агрегация, наследование). Лишь только после того, как выделены логические сущности и между ними выбраны оптимальные связи обычно приступают к написанию кода, а не наоборот. Проектированию так же учатся как и программированию, естественно это посложнее.

| Сообщение посчитали полезным:

TheNozza, ты утомил уже, давай ты больше в это теме больше не пишешь?

plutos пишет:
TheNozza, любопытно увидеть хоть один стоящий инструмент от Вас. В сырках.

так как насчет этого вопроса?

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

О том чего я сделал и чего не сделал думаю судить не Вам.
Аффтар как бе намекает...

Из этой Занозы вышел бы прекрасный армейский политработник:
"Рот закрыл - рабочее место убрано!"

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

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

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

TheNozza нафаня давай свои творения посмотрим на них) даю слово, буду оценивать их честно))

| Сообщение посчитали полезным: