Доброго времени суток

  Хочу чтобы написанная мною библиотека как-то идентифицировала программу которая динамически загрузила ее к себе в память. В идеале узнать полный путь к EXEфайлу или хотябы его имя... 
и если есть какие-то другие варианты - хотелось бы о них услышать

Первое , что пришло на ум  , в вашей библиотеке при событии DLL_PROCESS_ATTACH поулчить пид процесса ( GetCurrentProcessId() ) . 
Ну а потом CreateToolhelp32Snapshot , Process32First , Process32Next.

Это сообщение отредактировал(а) bra1ny - 26.12.2008, 22:29

кстати вариант, причем весьма хорош    

вот только если переименовать сам екзешник, это ведь кардинально все изменит. есть ли более "точные" способы опознавания программ?    

Это сообщение отредактировал(а) shara - 26.12.2008, 22:47

GetModuleFileName(0.. + crc32, поиск сигнатур, итд итп - все зависит от конечной цели, которую ты не описал. конкретизируй свою "идентификацию".

виноват, каюсь ...
 под идентификацией подразумеваю следующее: однажды определив екзешный файл (не важно каким способом), например мы знаем полный путь к нему, уметь в будущем, когда библиотека обрабатывает сообщение DLL_PROCESS_ATTACH, узнавать ранее обозначенный екзешник


 - подсчет контрольной суммы на мой взгляд это отличная идея     в связи с этим хочу спросить, может ли библиотека при обработке DLL_PROCESS_ATTACH  быстро узнать СRС32 файла к которому ее подключили, или же это придется делать так сказать вручную?

специальной api-функции для этого нету, посему вручную: GetModuleFileName, CreateFile, GetFileSize(если большой, то берем первые n килобайт), ReadFile, crc32, CloseHandle

если ты таким образом делаешь "привязку" к своей программе, то упаришься каждый раз crc пересчитывать...

тогда можно мапить файл , как вариант.

зачем грузить образ из файла если он уже есть в памяти?? считайте контрольную сумму 1й секции (кода) и будет вам щастье

dumb,  спасибо, где-то так я все это и представлял.

GoldFinch, 
а можно по подробнее, я что-то не до конца понимаю смысл сказанного...

непонятно зачем грузить в память файл если он уже загружен? мне тоже непонятно %)
или непонятно что такое секция файла и как вообще модуль располагается в памяти? так читайте документацию про PE-формат...

извеняйте ступил))

shara
описание PE формата

за описание PE формата спасибо =)

но я как думаю, узнать PID текущего процесса, открыть его ОpenProcess'ом и читаем n-байт при помощи ReadProcessMemory. ну а дальше дело техники - подсчет CRC этих самых n-байт

вот только вопрос, откуда начинать читать файл?? (так сказать пошлите меня по адресу   )


  MSDN
  ReadProcessMemory Function

  BOOL WINAPI ReadProcessMemory(
    __in          HANDLE hProcess,
    __in          LPCVOID lpBaseAddress,
    __out        LPVOID lpBuffer,
    __in          SIZE_T nSize,
    __out        SIZE_T* lpNumberOfBytesRead
  );

  Parameters
  ...
  lpBaseAddress 
  A pointer to the base address in the specified process from which to read. Before any data transfer 
  occurs, the system verifies that all data in the base address and memory of the specified size is
  accessible for read access, and if it is not accessible the function fails.
  ...


думается что lpBaseAddress устанавливать в 0 безсмысленно...  


если правильно все понимаю про PE то меня должен интересовать DWORD ImageBase из структуры typedef struct _IMAGE_OPTIONAL_HEADER 
уже не ругайте сильно если туплю где-то

Это сообщение отредактировал(а) shara - 9.1.2009, 01:21

чтобы читать свой данные своего процесса не нужно юзать ОpenProcess\ReadProcessMemory
база модуля совпадает с его хендлом

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

Это сообщение отредактировал(а) GoldFinch - 9.1.2009, 15:17

Да собственно и секция кода только по умолчанию статическая. Всё зависит от спефицики самого софта и установленного ПО на компе. 

Лично я не вижу особого смысла спускаться на такой низкий уровень, если нужна простая проверка(т.е. никто обойти её пытаться не будет), поэтому может посмотреть в сторону манифеста? Если он есть, там обычно сохраняется основная инфа о приложении и производителе, этого уже достаточно, чтобы идентифицировать, иначе завязка на конкретные цифры -- это до следующего билда exe. 

W4FhLF,  я все таки больше склоняюсь к привязке конкретными цифрами, т.е. к вполне конкретному EXEшнику. но за идею спасибо. если не затруднит, ссылку почитать про манифест.. не доводилось с ним раньше стыкаться 


GoldFinch, 

 поподробнее пожалуйста, а то вроде все понятно а вот что конкретно писать не знаю  

подробнее - в нормальных программах первая секция - это секция кода, и ее rva равен 0x1000
размер 1й секции (кода) можно прочитать из таблицы секций в заголовке

GoldFinch, 


я сколько не пытался так и не понял смысла этой строчки... и компилятор усиленно на нее ругается

а говориш формат PE файлов разобрал....

GoldFinch, 
это да, но против компилятора не попрешь...  сама идея понятна, вот с конкретной реализацией проблемы... в статьях что я нашел примеры не оч понятны

зачем тебе примеры если есть описание формата файла?
по смещению 0x3C находится raw offset PE заголовка, за PE заголовком находится таблица секций, тебе нужно поле SizeOfRawData первой секции, в нем лежит размер этой 1й секции в файле...

Добавлено через 3 минуты и 33 секунды
вот строчка которая должа компилиться
  int FirstSectionSize =*(int*)((char*)base+*(int*)((char*)base+0x3C)+0xF8+0x10);
0xF8 - размер PE заголовка, 0x10 смещение поля SizeOfRawData

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

но всеравно спасибо - я уже сам со всем разобрался. все таки PE штука классная. Главное узнать где он в файле начинается, отдельное спасибо за 
потом берем нужную структуру из winnt.h и присваем ей нужный адрес... ну а дальше дело техники 


вопрос можно снимать. 
кстати тестил на в разных версиях Винды - контрольная сумма (хеш) одинакова. - т.е. идея заслуживает на жизнь
пока все это писал, возник один вопрос: можно ли читать нужные мне биты файла, зная только начало PE заголовка + смещение нужного поля в структуре. тогда не нужно будет каждый раз работать со структурами а сразу читать байты из памяти по конкретному адресу. или все же для корректной работы в других ОС или возможно новых нововведениях в самой структуре PE лучше все оставить так как есть?

можно, pe формат никогда не поменяется, для 32-разрядных ОС по кр мере

http://www.pelib.com/index.php
гугл поможет не зная формата работать с ним)

блин, столкнулся с проблемой 
как можно узнать начало PE заголовка загруженного в память файла... у меня возникло бОльшое подозрение что GetModuleHandle(NULL) не всегда прав. 
пробовал искать РЕ по адресу 0х4000Е0 интересная штука получается, если любой файл откомпилить с опицей DEBUG то все нормально и PE находится по выше указанному адресу... компилю значит этот же файл с опцией RELIS и нифига - никакого PE по адресу 0х4000Е0 нет! че такое????      

Добавлено через 1 минуту и 21 секунду
jonie, всеже предпочитаю не использовать чужую либу, хочу сам разобраться   

shara, ты вообще про PE формат читал?
raw offset (и rva) PE-заголовка находится по смещению 0x3C (поле IMAGE_DOS_HEADER.e_lfanew)

Это сообщение отредактировал(а) GoldFinch - 15.1.2009, 21:43

вроде разобрался, для прийдешних поколений выкладываю простенький но рабочий исходник, который ищет сигнатуру PE в загруженном в память файле 
 

Добавлено через 2 минуты и 57 секунд
GoldFinch, 

да да да а я гдето в одной из статей краем глаза увидел +0хE0 на там файле на котором все тестировал проконало. когда пошел дальше начались глюки ... бывает, я не волшебник и с РЕ работаю всего второй день))))

да.. такими  темпами ты нескоро чтонить толковое сделаешь...

GoldFinch, а ты вправе кому-либо на это указывать, узнав о спецификации незадолго до shara?

тем более с такими высказываниями
shara, а это тебе место, где GoldFinch уже наступил на свои грабли и теперь зовет тебя на них наступить, чтобы ему не было так одиноко: http://forum.vingrad.ru/index.php?showtopi...t&p=1715653
дело, конечно твое, кого слушать, мое дело - предупредить )

GremlinProg, 
насчет использования ImageNtHeader я тоже подумывал, но мне важна скорость работы моего приложения потому-что оно будет запускаться очень много раз. а на работу АПИшных функций понадобиться время(пусть даже и не большое но это критичный параметр). решил все же использовать описание структур из файла Winnt.h и жестко к ним привязываться (жертвуем универсальностью за скорость) тут я согласен с  GoldFinch что PE врядли измениться в актуальное время

думаю что идея использованная мною в маленьком ЕХЕшнике описанном выше заслуживает на жизнь 


to 
GoldFinch, 
  я это все пишу на работе, в рабочее время, т.е. многозадачность рулит   

поверь, ты жертвуешь не универсальностью, а временем, причем своим же


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

GremlinProg, никто кроме наверное редких С(++) программистов не использует ImageNtHeader и прочие API функции заменяемые 1-2 инструкциями
в винде вообще есть немало странных API функций типа ws2_32.ntohl которые только место в коде занимают
Я так просто не могу юзать код который будет ассемблироваться в push eax\call __imp_ImageNtHeader\jmp [ImageNtHeader] вместо add eax,0x3c , религия знаете-ли запрещает.

PE заголовок не может измениться потому, что если это произойдет, куча программ перестанет работать, в том числе все упакованные программы (думаю ни в одном из упаковщиков не используется ImageNtHeader или другая подобная api)

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


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

Это сообщение отредактировал(а) GoldFinch - 16.1.2009, 09:24

а какова кстати цель такой идентификации? определить загрузила ли библиотеку своя программа или нет? тогда можно и без изысков с PE форматом обойтись, компилить эту свою программу с уникальным стабом (dos stub) и проверять с него ли начинается модуль
т.е. по адресу GetModuleHandle(NULL) должна будет лежать заранее известная последовательность байт

совсем будет красиво засунуть в стаб ехешки часть кода DllMain(), например декриптор дллки

ни чего не путаешь, может наоборот?
приведи список этого чрезвычайно опытного большинства, хотя бы десяток, которые не используют API там, где требуется соблюдение стандартов? Всем будет интересно увидеть подписавшихся под этим списком (я лично сомневаюсь, что ты получишь даже 1 голос от системных программистов, не всякий захочет ставить такое пятно на своей репутации)


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

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

ps: любой твой последующий неаргументированный выпад на майкрософт будет отражен у тебя в репутации со знаком минус, а при продолжении такого флуда, будет бан.

По-моему, ты злоупотребляешь. 

Например я никогда API для работы с PE не юзал, а опыт работы с PE у меня приличный. И никогда не видел, чтобы кто-нибудь их моих знакомых реверсеров или системщиков их юзал. Пишут ли они антируткит или протектор... всегда всё делается ручками. Хотя работать непосредственно со смещения -- глупость конечно, структуры/юнионы должны быть. 

Это сообщение отредактировал(а) W4FhLF - 16.1.2009, 14:54

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

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

Пока, что я вижу только, что ты в каждом посте пытаешься доказать ему обратное.



Чему я противоречу? Только из своего опыта я вспоминаю два проекта, где я работал с PE без API как минимум потому то не мог их использовать в прицнипе(это был драйвер под WinNT и бинарник под линукс для работы с PE). И я могу привести ещё много частных случаев, когда следует отбросить API. 

На самом деле вы оба впадаете в крайности. Один говорит: "API is the evil", а другой говорит "Only API", а фактически истина посередине. 

GremlinProg, раздел форума называется C/C++: Системное программирование и WinAPI, как видите апи здесь на последнем месте. Я прекрасно понимаю что без апи многого в винде не сделать, но во всем надо соблюдать меру - гдето использование апи бессмысленно, а гдето и вредно.

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


в данном случае для драйвера API меняется на  DDK, ее рекомендациям и нужно следовать, если там нет инструментов для работы с PE, значит native-API тут опускать, по крайней мере, бессмысленно. Под ядро даже SDK отличается. А линукс - есть линукс, майкрософт ни какой ответственности за него не несет. Надеюсь, я понятно объяснил, почему твои пример неуместны. Я понимаю, что ты хочешь смягчить обе стороны, но если склоняешься на одну, то хотя бы не подкупай вторую псевдоаргументами.

и не пишу я, что использовать нужно только API, но если уже есть решение проблемы, зачем изобретать самокат? Это не то, чтобы неправильно, но если привыкнешь лазать в омут, так его и будешь искать при любом удобном случае.

GoldFinch, если бы ты писал о системном программировании, но ты взялся разворачивать спецификацию, которая явно реализуется в функции API, так что держи удар как есть, здесь с названием раздела все в порядке.

GremlinProg, раз уж тебе хочется оставаться в рамках темы, то я думаю те следует признать что тема относится к защите ПО, а при написании защиты использования АПИ стараются избегать

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

Что ты объяснил? Я и так знаю, что такое DDK и что "Линукс != Виндовс". 



А кто изобретает самокат? Ты вообще посмотри, что за библиотека такая dbghelp.dll(новые версии этой библиотеки вообще являются исключительно частью debugging tools), тебя её название на какие мысли наводит? Там пара функций для непосредственно работы с PE, поэтому даже если сильно захотеть, при работе с PE одними API ты не ограничишься. Даже если ты используешь функции из этой библиотеки, параметрами выступают те же самые структуры, из одного и того же хедера. Т.е. в любом случае в программе ты привязываешься к этим структурам, только вместо обращения к члену структуры ты предлагаешь использовать API из библиотеки, которая вообще являются инструментом для других задач. 

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


ну и зачем опять вопрос, на который, подозреваю, ты и сам знаешь ответ:
как раз для debugging-инструментов она и поддерживается, а полноценно существует ее урезанная версия - ImageHlp, которая ни куда не исчезает.

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

GremlinProg, что-то я не понимаю о чём мы тогда спорим? Я говорю, что для работы с PE файлами АПИ использовать, ну, как бы сказать, совсем даже не гуд. Вот у меня за время работы с PE наваялась своя собственная библиотека(модуль на С++) с различными функциями. Я её и в драйверах, и в нативных приложениях, и в прикладных использую. Она даже кроссплатформена, т.е. под линухом тоже всё собирается. Ну а по-скольку PE формат не менялся уже лет 15 и меняться не собирается, то зачем я буду заботиться об этом? Получается наоборот, твои API ограничивают меня в плане переносимости, я должен думать есть ли данная библиотека у пользователя... Зачем мне всё это?

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

Давай ты не будешь обобщать. Я говорю про конкретную область, про PE формат. Предложенная тобой библиотека экономит 2-3 строки кода на самых элементарных вещах, для которых ничего городить не надо(может хватит уже бросаться столь страшными словами, это убедительности в споре со мной нисколько не придаёт). Если человек не знает как работают эти функции, он работать с PE не сможет. 

Поэтому прицнип твой в данном случае не работает. Ради 2-3х функций никакая библиотека здесь нафиг не сдалась.

Добавлено через 4 минуты и 28 секунд
А в общем случае согласен, что велосипеды -- зло.

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

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

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

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

зачем мне делать повторную работу майкрософт (к тому же небезопасную), если уместно использование API?
вопрос риторический

GremlinProg, что "фильтруй"?

1) как некорректный exe-шник может оказаться в памяти?
2) что значит "принятому в dll стандарту"?

3)какой смысл в функции которая возвращает сумму аргумента и константы или которая возвращает сумму двух аргументов?

GoldFinch, в таких случаях, пост нужно отредактировать, а не создавать новый,
что фильтровать ты уже понял

некорректный не может, а с непредсказуемым содержимым PE, которое не учитывается в твоей dll, но пропускает загрузчик - вполне

примеры, которые ты приводил для определения PE не соответствуют определению NT-заголовка, поскольку не соответствует спецификации, поэтому стандарт ты сам себе и заводишь в dll
NT-заголовок, как и DOS - маркируются сигнатурами, при соответствии которых спецификации, они и считаются соответственно NT и DOS

смысл я уже объяснил пару-тройку раз, не вижу смысла повторять, попробуй перечитать тему

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

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

GremlinProg, тебе надо задачу решать, а не багрепорты собирать

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

ого   

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



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

shara, 0x1000 байт можешь читать спокойно
dos stub не может быть больше 64кбайт

Ты хотел сказать байт? 

Уважаемые сэры! А вам не приходило в голову, что каждый конкретный код пишется прежде всего для того, чтобы решить одну маленькую задачу в большой череде задач различной сложности. 
Возможно, по эфективности решение использовать "прямые вычисления" vs API функций и получше. И разобраться в устройстве PE-формата тому, кто туда лезет, тоже неплохо. 
НО. Использование функций API - самодокументировано. А если там будет написано "адрес A" + "смещение B", то придется писать комментарий. Ах, я забыла, все настолько крутые, что по арифметическому выражению сразу поймут, что там написано. Ну так подумайте о тех, кто будет поддерживать этот код после вас. Хорошо написанный код должен читаться как рассказ об применяемом алгоритме, без лишних подробностей.
Конечно, бывают случаи, когда нужно что-то круто оптимизировать. Но разве этот случай такой?


Я часто именно так и делаю. Особенно, если вычисление идет через добывание переменных из структур\классов. Причем называю функцию так, чтобы она ясно читалось в контексте общего алгоритма. 

Короче, поддерживаю мнение GremlinProg. 

А кто предлагает писать арифметику? 



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

Это сообщение отредактировал(а) W4FhLF - 17.1.2009, 10:42

И к тому же что, надо мне получить указатель на IMAGE_NT_HEADER, я использую API, а если надо на IMAGE_FILE_HEADER, API такой нет, писать свою функцию придётся. Так в чём смысл использования этих 2-3х API для работы с PE, которые нам предлагает Windows? 

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

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

Добавлено @ 12:51
у меня есть другой вариант: часть функционала, без которого программа не может работать отправляется в службу, работающую в режиме ядра, а эта служба учится работать с лицеднзиями и проверять легальность копии =)
в этом случае сломать то-же возможно, но сложнее

Это сообщение отредактировал(а) Lazin - 17.1.2009, 13:01

W4FhLF, dos stub не может быть больше 64кбайт, т.е. смещение PE заголовка меньше 64кбайт

чтобы такого небыло, надо чтобы небыло проверки которую можно было бы забить nop'ами, т.е. ключ должен не только сравниваться, но и расшифровывать код

W4FhLF, у тя в код не соответствует ни спецификации ни загрузчику, вместо
local_psh = (PIMAGE_SECTION_HEADER)((PUCHAR)local_poh + sizeof(IMAGE_OPTIONAL_HEADER));
должно быть так
local_psh = (PIMAGE_SECTION_HEADER)((PUCHAR)local_poh + local_pfh.SizeOfOptionalHeader);
есть файлы, у которых SizeOfOptionalHeader не равен 0xE0

Ага, ты прав. Я помню об этом ещё читал в упаковщиках от Володи. Но исправить у себя забыл. 

Что ещё видно?

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

да вообще непонятно зачем все эти проверки, если можуль есть в памяти значит у него правильный заголовок (если его там не пропатчили)
и непонятно зачем использовать три отдельных указателя на структуры которые следуют друг за другом
    OUT PIMAGE_FILE_HEADER*        pfh OPTIONAL,
    OUT PIMAGE_OPTIONAL_HEADER*    poh OPTIONAL,
    OUT PIMAGE_SECTION_HEADER*    psh OPTIONAL
проще считать весь ПЕ-заголовок одной структурой, по крайней мере  FILE_HEADER и OPTIONAL_HEADER
это если тебе надо например PE и COFF различать они на два отдельных разбиты, а в PE-то зачем их разбивать %)

так что смысл этой функции мне не понятен, одно дело проверить правильность, если это действительно надо (базу модуля например найти)
а другое дело получить указатель на ПЕ заголовок (прибавить к базе его смещение)

Он может быть загружен в память и мной(MapOfViewFile). 



Как зачем? Это три отдельные сущности и работа с ними осуществляется по отдельности. Это вполне логично и неважно как они следуют в памяти. 

W4FhLF, почему отдельные-то? если не знать о спецификации, то ПЕ заголовок выглядит как одна большая структура