Всем хай.

Надоело каждый раз изобретать велосипед, по нахождению одних и тех же данных,
то точку входа, то кол-во секций, то еще что нить.

Вот и задумал, написать паккадж, но возник вопрос, как у нормального ленивого человека: "А вдруг уже есть?". Полез в гугл, спросил, а он говорит, что вроде бы нету.

вот и спрашиваю, есть у кого нить уже готовое че нить?
Если нет, то может кто-то подсодиниться к проекту, чтобы я его более грамотным сделал и более нужным!

-----
My love is very cool girl.

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

Black Neuromancer
Велосипед одно, но работа с этим форматом файла относитя не к низкому уровню, к уровню Прикладных ПО, а для такого уровня Delphi очень даже хорошо справляется. А то что чуть лишнего изобретешь, это ж не критично!

>>ты не прав, важен не код, у тебя он вполне понятен даже при
Очень даже важно, иначе бы мы не писали компоненты и макросы!

Я пока добился того что у меня работа сводится к следующему:

objPEFile.AdressOfEntryPoint := $1000;
or
objPEFile.ImageBase := $40000;

Это своего рода вынесение в одну структуру все значения подструктур. Но уж очень большой список полей получается!

Сделал компонент: TPEFile, TPEEmloyee - где первый это доступ к полям файла, а второй это функции необходимые при работе с форматом файла, к примеру:

objPEEmployee.Rva2Offset := Value;
or
if objPEEmployee.Valid then
// работа с файлом

Я еще на стадии продумывания, к тому же никак не могу продумать средство накопления трюков. Что я понимаю под этим, очень много авторов с форматом творят что хотят и необходимо опыт ковыряния таких файлов накапливать, вот и придумываю стурктуры БД и механизма поиска "неисправностей" и возможного устранения. Это позволит соглассно опыту, автоматически справляться с файлами в будующем.

ЗЫ: Сорри за сумбур, но мысли пока еще не структурированы, пока еще на стадии записи в IDEF0 моддель )))

-----
My love is very cool girl.

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

www.mitec.cz/pe.html

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

seeq
Интересно, но нет сорца!

-----
My love is very cool girl.

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

да ничё интересного... так набросали компонент да не оттестили, у мну раз 10 упал (надо знать на чём тестить) но больше всего меня поразило:

The cost of a site license is currently 50 EUR.

ну этоже вообще п***** за такую "шнягу" 50 евро, я в шоке...
аффтары убейте себя

-----
[nice coder and reverser]

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

Небольшая просьба, если кто имеет хорошие иконки 24х24 которые можно ассоциировать с компонентами для работы с PE-форматом, если такие люди найдутся то буду рад!

-----
My love is very cool girl.

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

Столкнулся с некоторыми вопросами:

I.
Как лучше извещать пользователя компонента об ошибке:

if FHFile = INVALID_HANDLE_VALUE then
begin
if Assigned(FOnError) then FOnError(Self,Windows.GetLastError)
else
raise
Exception.Create(SysErrorMessage(Windows.GetLastError));
end;
Если так, то его заставит пользователя моего компонента сделать обработчик ошибки и тем самым как бы принуждает писать правильный код, или же мне сделать спомощью функции возврающую ИСТЕНУ или ВРАНЬЕ, но в этом случае не факт что пользователь будет обрабатывать ошибку ?

II.
При обращении к свойству mLog.lines.text := pefile.AddressOfEntryPoint; должно произойти:
-Чтение NT загловка(чтение происходит , тогда когда он не был прочитан ранее)
-Чтение Dos - заголовка(если он не прочитан ранее, для того чтобы узнать где же читать NT-заголовок)

Отсуда если он не прочитан ранее, а как это узнать? По каким полям, т.е. если я выделю:
FDos : TIMAGE_DOS_HEADER; // Dos Header
FNT : TIMAGE_NT_HEADERS; // NT Header
какие в них поля не имеют право находится в нулевом значении?

мысли в слух:
Для дос полагаю сигнатура или e_lfanew, для Nt тоже сигнатура.

На что лучше завязать проверку?

-----
My love is very cool girl.

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

theCollision пишет:
Как лучше извещать пользователя компонента об ошибке:
Лучше уж true-false - если не обрабатывать ошибки, в любом случае ничего хорошего не произойдет, а обработка возвр. значения проще ИМХО

theCollision пишет:
Отсуда если он не прочитан ранее, а как это узнать?
На мой взгляд - при инициализации просто считывать обе структуры, если NT_Headers не валидна - обнуляешь соответствующий указатель

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

кста сделай фичу "удаление секций", мало где эт есть

> мысли в слух:
> Для дос полагаю сигнатура или e_lfanew, для Nt тоже сигнатура.
всмысле?
пусть есть dosh :PImageDosHeader и peh :PImageNtHeaders. (файл верный и peh := PImageNtHeaders(DWord(dosh) + DWord(dosh.e_magic)) ;)
в dosh.e_lfanew должно быть IMAGE_DOS_SOGNATURE; в peh.Signature = IMAGE_NT_SIGNATURE... это сигнатуры зашиты в windows.pas и равны mz и pe#0#0 соответственно....

-----
Shalom ebanats!

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

SLV
Вот что я имел ввиду:
procedure TPEformat.ReadDosHeader;
var
BytesRead : Cardinal; // Кол-во прочитанных байт
begin
if FDos.e_magic = 0 then
begin
Windows.SetFilePointer(FHFile,0,Nil,FILE_BEGIN);
if not Windows.ReadFile(FHFile,FDos,SizeOf(TIMAGE_DOS_HEADER),BytesRead,Nil)
then
begin
if Assigned(FOnError) then FOnError(Self,Windows.GetLastError)
else
raise
Exception.Create(SysErrorMessage(Windows.GetLastError));
end;
end;
end;

Т.е. когда когда компонент создается, то с ним создаются и память под переменные, конструктор тут виноват, так вот у меня есть методы pefile.Open - открытие pefile.Close - закрытие.
Теперь думаем, одно дело закрыть файл, другое убить компонент, так вот,если компонент уже существует, то надо проверить, а был ли прочитан заголовок ранее, зачем его сразу же читать, вдруг для этого файла уже прочитан заголовок ранее?
В малом коде легко отследить, а вот в большом уже труднее, потому компонент сам должен отслеживать все!

Теперь вопрос:
Все мы привыкли видеть конструкции вида:

pe.dos.e_lfanew; - легко вроде для понимания
pe.nt.FileHeader.NumberOfSection; - уже труднее но понять все таки можно
pe.nt.DataDirectory[INDX_EXPORT].VirtualSize; - при обилии в коде записей подобной этой код затрудняется, даже оператор

with pe.nt do
begin
DataDirectoryp[INDX_EXPOR].VirtualSize;

не очень то и спасает.

Скажите гуру так уж необходимо видеть в коде что поле из nt.FileHeader ?
Исходя из этого я начал думать, что проще чем записей ниже нет:
pe.e_lfanew;
pe.NumberOfSections;
pe.Sections.VAExport;
pe.Sections.SizeExport;

но код исходника становится сложнее, ладно я буду его поддерживать, но вдруг другой чел решит чтото добавить, будет ли ему легко со всем этим разобраться?

Прошу подсказать как лучше организовать работу с компонентом для используещего мой компонент?

-----
My love is very cool girl.

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

theCollision пишет:
так вот,если компонент уже существует, то надо проверить, а был ли прочитан заголовок ранее,
Тогда заводи флаг - bIsLoaded кот. обозначает загрузку всех первичных структур.

theCollision пишет:
Теперь вопрос
ИМХО не особо важно. Плюсы есть и там, и там. Для начала лучше не заморачивайся и сделай в традиционной форме - pe.nt.DataDirectory[INDX_EXPORT].VirtualSize.

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

HoBleen
1.
Флаг не нужен, уже решено смотри примеры кода выше

2.
Уже заморочился,для этого пишу класс-хэлпер, для BDS2005 и выше это будет так:

TPEformatHelper = class helper for TPEformat
end;

тогда, для тех кто юзате BDS2005 будет удобство, для тех же кто не юзает будет не очень удобно, т.к.
при обилии:
pe.nt.OptionalHeader.DataDirectory[INDX_EXPORT].VirtualSize
код сильно засоряется!

зы:
Хелперы позволяют наслаивать дополнения к любому классу, БЕЗ наследования! Это выгодно если класс в *.dcu

-----
My love is very cool girl.

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