» Как узнать параметры функций и процедур в .dll?

Собственно сабж

Вариант 1) Погуглить и найти готовую обвязку. Для стандартных длл они есть. Правда обычно на С
Вариант 2) Отладчик/Дизассемблер в зубы и в гущу. Имена функций узнать просто, а вот параметры - это уже очень интересная задача.

Общего метода (типа запустил утилиту и она всё написала) нет и врядли будет в ближайшее время.

Но есть одно исключение - эта длл написана на .NET - тогда можно применить рефоектор - он ещё и исходники выдаст, если хорошо попросить

Спасибо за ответ.
Так и знал, что не все так просто

Иногда можно по имени процедуры сделать предположение о параметрах . А если попробовать написать подборщик параметров? Если параметры - простые типы и их штук 1 - 3, думаю это реально...

Воспользуйся дизассемблером IDA Pro 5.0
Очень мощная штука: если DLL-ка не упакована/не запротекчена, можно в большинстве случаев определить количество параметров и их типы. Пятая версия этого дизассемблера меня поразила - она комментирует назначение параметров системных вызовов Windows.

Скорее всего, системные вызовы Windows там где-то все прописаны, вот IDA их и раскладывает по полочкам. А с неизвестной DLL - это еще вопрос.

SteelMaster
Для всех системных библиотек MS дает отладочные версии, и соответственно символы. У Иды они прописаны и она их определяет. Вот и весь фокус.
Если добавишь символы от своей DLL, то и они будут показываться :)

Цитата:

SteelMaster
Для всех системных библиотек MS дает отладочные версии, и соответственно символы. У Иды они прописаны и она их определяет. Вот и весь фокус.
Если добавишь символы от своей DLL, то и они будут показываться

Позволь частично согласиться с тобой. Да символы есть, ида их юзать может.
Но она также может восстанавливать количество аргументов и их типы в библиотеках, написанных на C++, где присутсвует декорация имен.

А если dll - это ActiveX, то просто выдераешь typelib, в нем все прописано.
Если обычная dll, то в таблице экспорта все имена с адресами указаны, число параметров легко определить по манипуляциям со стеком перед return.

HANDLE

Цитата:

Если обычная dll, то в таблице экспорта все имена с адресами указаны

Согласен

Цитата:

число параметров легко определить по манипуляциям со стеком перед return

Никак не могу не согласиться. Если длл написана на Delphi, то до 3 параметров может передаваться через регистры. Тут никакая манипуляция стеком не поможет. Её просто не будет. Всё зависит от формата вызова. И их у нас кажеться 4.

Цитата:

А если dll - это ActiveX, то просто выдераешь typelib, в нем все прописано.

Речь видимо идет только про функции, явно экспортируемые DLL (так-то "внутри" DLL намного больше функций и методов, начиная с RTL и т.д.). А методы интерфейсов (ActiveX, COM) обычно не экспортируются.

В общем случае нетривиальная задача.
Кроме перечня параметров (их количества и типов) нужно также знать соглашение о вызове (stdcall, fastcall и др), а зачастую даже сам создатель .dll-не знает чего он накомпилил (как результат, бывает, что вызовы из VC работают на ура, а например прога на BCB начинает втихушку глючить...)
Если дана только .dll и больше ничего (например, нету ни .pdb, ни.dbg, ни хотя бы .lib), то я бы не побоялся сказать, что задача может быть неразрешимой (ну кроме метода тыка конечно). Есть техники, иногда позволяющие путем анализа ассемблерного кода "восстановить" интерфейс вызова функции, но эти методики далеко не универсальны.

Передаваемые параметры можно опеределить дебаггером - поставив бряк на вызов функции посмотрев какие push перед этим идут и что передается чеерез регистры. Уже не раз этим пользовался.

ЗЫ: Из .dll .lib можно сделать за минуту - достаточно воспользоваться DLL2Lib или implib.

Цитата:

Передаваемые параметры можно опеределить дебаггером...

Можно, и в большинстве случаев это помогает, никто не спорит. Но не всегда.

Насчет .lib.
Имелось ввиду, что .lib, созданный именно при компиляции программы, в некоторых случаях может содержать информацию не только об именах функции, но и список параметров + соглашение о вызовах (и то, за последнее не ручаюсь, но если такая информация есть - то наверняка она будет корректна).
А вот про .lib, созданную автоматом только по имеющейся .dll (т.е. как бы "восстановленную") такого сказать нельзя.
Из .dll можно "автоматом" сделать .lib (если быть корректнее - то только библиотеку импорта, ведь .lib-ы разные бывают), которая будет содержать список экспортируемых функций. Но о соглашении о вызовах (сalling convention) в исходной .dll информация не содержится - соответственно, и в .lib-файле этой информации либо не будет, либо она может оказаться неверной.

Т.е. сварганить .lib дело простое, но проблемы это не решает. Тем более, что список экспортируемых функций можно выцепить и так, напрямую из .dll, без промежуточного создания .lib (и об этом упоминалось выше), утилитами типа DumpBIN.exe, DumpPE.exe, TDump.exe).

еще есть name-mangling. В принципе, если он используется, то корректнее всего помогает расшифровать параметры (а также используемый компилятор). Но опять же, о calling convention информации не содержит и можно только надеяться на то, что создатель .dll использовал обычно применяемый calling convention для использованного компилятора. Но, по большому счету, можно заставить компилятор использовать не "стандартное" соглашение.

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

Пробовал dll2lib Ничего путного не выдал, список функций(вызовов), чего слегка не соответсвовало действительности, я примерно знаю что в ДЛЛ.
и как жить?

Может приведешь тут список имен функций, который выдала dll2lib?
И который должен быть по-твоему мнению.
Хотя бы будет видно, задекорированные они или нет, а там видно будет.

или просто поясни...
Цитата:

слегка не соответсвовало действительности

чем именно несоответствовало?

Если нет - то только дизассемблировать и т.д.
Попутно может стоит задать вопрос в Андеграунд-е.

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