В ходе некоторого проекта мне понадобилось создать объектник формата COFF, который в ходе своей работы вызывает API. Но возникла проблема - при линковке линкер ругается на unresolved external, т. е. нужна хотя бы kernel32.lib(которой изначально нет, т. к. то, к чему я линкую импортирует только из своего рантайма), хотя бы для GetProcAddress и LoadLibraryA. При подключении ошибок не возникает, но выходной файл теряет работоспособность - таблица импорта оказывается вообще пуста. Я попробовал импортить вирусными методами, т. е. находить через SEH базу kernel32.dll, однако под Windows Vista программа вылетала с ошибкой. Формат COFF вроде бы позволяет включить нужные импорты прямо в объектник(тот же VB позволяет добавить импорты в выходной файл, хотя использует тот же линкер, что и VC6), и для линковки не будет нужна библиотека импорта. Вопрос: как добавить импорт из DLL непосредственно в объектник, чтобы он собирался в PE без библиотек импорта?
Напиши отдельную прогу, которая будет добавлять пустую таблицу импорта. Может, и тупой вариант, но рабочий А почему нельзя просто импортировать любую функцию из кернела, например? На пару байт увеличится размер. Делов-то.. З.Ы. Под вистой действительно нужны импорты..
IceStudent Спасибо. Слинковалось, но пропали старые импорты(которые не мои, а уже были). Буду думать. Такое впечатление, что VB'шные объектники не совместимы с чем-либо ещё.
IceStudent Извините но не совсем так Импорт так не добавляется а добаляется метка туда на имя либы. Это чтобы в параметрах линкера их не указывать. А без библиотек импорта даже с этими директивами он не собирается Мы просто наверно поразному истолкавали его весёлый вопрос
Ладно, у меня в принципе DLL(пишу свою точку входа для VB-шных) и база есть изначально. Найду через таблицу импорта адрес внутри msvbvm60.dll(она всегда есть, ибо это местный рантайм), потом её базу и соответственно таблицу импорта. А там уже валяются ссылки на GetModuleHandle и GetProcAddress. Хотелось бы, конечно, чтобы был нормальный импорт, но похоже средств для его создания нет. А документация по секции COFF-объектников '.idata' довольно-таки скупа - так бы я её руками фасмом смастерил.
Здравствуйте. Пишу я небольшую программку без импорта. Поиск функций идет по хешам. На XP все работает (все функции загружаются), но на семерке возникает проблема - функции из kernel32 загружаются нормально, а из user32 - нет. После анализа ощибки выяснилось что проблема в том что в kernel32 OrdinalBase = 1, а в user32 = 0x5DC и в результате неправильно вычисляются смещения в таблице адресов. Алгоритм вычисления адресов у меня используется такой же как описано в Microsoft Portable Executable and Common Object File Format Specification r.6.0. В чем может быть проблема, подскажите. Почему Ordinal Base слишком большой, хотя при просмотре экспорта ординалы начинаются с 2 у user32?
Alexey Смотря чем просматриваете. Документация на тему ординалов неоднозначна и даже содержит ошибки, поэтому некоторые утилиты показывают индекс в таблице адресов в качестве ординала, а некоторые сумму этого индекса с Ordinal Base. В случае поиска функций по имени/хешу поле OrdinalBase не входит в рассчёт и учитываться не должно (несмотря на то, что в документации написано обратное).
Alexey Возьмите что-нибудь по-новее. PEiD ещё и кучу ошибок при разборе экспорта делает. Возьмите PE Editor из PE Tools или CFF Explorer или PE Explorer. Нет. Находите индекс в массиве адресов имён. По этому индексу в массиве ординалов берёте индекс в таблице адресов. Ordinal Base не брать и ни за что не принимать.
Спасибо. Сейчас попробую ... PS. Открыл user32.dll в PEeditor'e в PE Tools. Поля Export Directory он показывает также как и PEiD, а вот ординалы функций показывает не с 2-х как PEiD, а с 1500 (т.е. 0x5DC) , т.е. с базы. И в правду PEiD что-то врет ..
Alexey Я ведь написал, что здесь как раз можно сослаться на двусмысленность документации. PEiD в качестве ординалов показывает индексы в массиве адресов. С другой стороны он может точно так же неверно отображать эти индексы, а также адреса и смещения функций.
