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

  Хочу чтобы написанная мною библиотека как-то идентифицировала программу которая динамически загрузила ее к себе в память. В идеале узнать полный путь к 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, 

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