Привет всем! Есть программа (моя)использующая одну функцию из чужой DLL'ки. Имя и параметры функции я знаю, но вот не хочеться таскать со своей прогой эту DLL. (В ней есть еще куча функций (мне не нужных) и размер у нее 5 мегабайт.) Так вот возникла мысль, можно ли как-то выдрать только эту функцию из билиотеки ? На ум пришли дизассемблерры. Попробовал несколько (WDasm, PVDasm и еще что-то). Все они дизассемблируют, но не делают asm файла (или я не смог это сделать). Попробовал IDA. Она сделала asm файл, но чем его откомпилировать? Пробовал tasm32, nasm - не хотят. Чем можно без правки asm файл от IDA откомпилировать ? Может есть какие-нибудь тулзы, чтоб выдрать (получить ассемблерный код) функции из DLL со всеми используемыми этой функцией переменными, данными, вызываемыми ей функциями и т.д. ??? Может кто что дельное посоветует ? Заранее благодарен! С уважением, Василий.
Без правки, имхо, нельзя никак. Берешь иду, выдираешь из нее нужную функцию, правишь ее так, чтобы ассемблер смог ее скомпилить, выписываешь из дллки нужные для функции данные и т.д. Вроде не так уж и сложно.
Спасибо за совет! Но муторно получаеться. Если функция использует много других функций (не экспортируемых, а внутренних), те в свою очередь могут вызывать еще функции. У каждых из них есть свои внешние переменные, данные и т.д. . . . :-( Я думал, может есть тулза которая более менее автоматизирует это процесс и упростит его.
Arvensis > Но в конечную программу попадут только нужные функции, не так ли? Нет, не так, в программу попадёт весь код либы сгенеренный утилитой Dll2Lib, потому что эта либа будет состоять из одного объектника, не считая объектника с кодом для показа nag'а
SolarWarez вот как раз недавно этим и страдал. использовал MASM - он лучше всех "понимает" сгенеренные IDA-ой asm файлы. По поводу использования внешних переменных и др. функций - а что ты хотел, так и выходит. Нажимаешь скомпилить, получаешь 100 ошибок. Берешь в руки мышь, и вперед - "скопировать\найти" в асм файле недостающие имена переменных и функций. Потом переносишь их в свой файлик. Чтоб заранее узнать сколько же придется переносить хвостов - посмотри в ИДА графическое представление нужной функции. Вот того монстра, который из твоей функции растет и нужно будет по кускам переносить. На одну среднюю функцию уходит до дня работы. Потом, если нужно несоклько функций вырипать, то в одной проге разные функции используют одинаковые процедуры, поэтому последующие функции уже требуют намного меньше трудозатрат
Всем спасиюо за участие! Broken Sword - я так и думал, что примерно так придеться делать . . . Просто была надежда, что есть что-то готовое для этих целей. Кстати, если IDA может рисовать граф функции со всеми связями с другими функциями, то наверное, очень легко было-бы добавить функцию экспорта в asm этой функции со всеми ее зависимостями... Разработчикам это в голову не приходило или это очень редко кому нужно ? Еще раз всем спасибо! С уважением, Василий.
Asterix Можно 3 вопроса: 1. comdlg32.dll пропущена через dll2lib. Полученный comdlg32.lib прилинкован к ехе-файлу, вызывающему GetOpenFileName и GetSaveFileName. Почему размер ехе не вырастает на величину comdlg32.lib (285 кб) ? Остается прежним, как и с "родной" либой из пакета vc++, т.е. 88 кБ. 2. Почему размер либы так сильно отличается от "родной" либы (7,5 кБ) Если это из-за NAG'а, то: 3. Куда подевался NAG? При запуске программы и вызове диалогов открытия/сохранения файла NAG'а нет. P.S. Пробовал как патченную, так и непатченную dll2lib
cresta Значит функции продолжают вызываться из comdlg32.dll, а не из статической либы. Надо под отладчиком глянуть.
Quantum Что-то не сходится. Пустил через dll2lib свою asm-овую CustomDll.Dll. Получил CustomDll.lib(8,17кБ). Прилинковал к ехе, и размер ехе вырос на 4кБ с 88 до 92 кБ вместо ожидаемых 8,17кБ. Получается, не вся либа цепляется, только вызываемая процедура, и процедуры из masm32.lib, вызываемые через неё. В OllyDbg видно, что в ехе добавился код из либы и masm32.lib. Самой dll ни в sysdir, ни в windir, ни в app-path нет. Ехе работает.
cresta Так это своя либа, а не comdlg32.dll. Надо учитывать выравнивание. Оно может быть на границу 4K, например. Тогда вплоть до половины либы может занять выравнивание. А формат у либы такой, что в ней символы всякие определены (чтоб линкер мог их ресолвить), но в экзешник символы не попадают. Из-за этого "полезный" размер либы всегда меньше размера файла *.lib
Выравнивание учёл, а вот про символьные проморгал А для чего тогда весь код цепляется? Разве так сложно отследить цепочку вызовов и только её включать в ехе?
cresta Компилятор VC для этой цели умеет помещать каждую функцию в отдельный объектник (в конфигурации нужно указать "function-level linking"). Линкер в таком случае включает в экзешник только те функции, которые реально используются/экспортируются. Но если всё в одном объектнике, то линкеру уже слабО следить за цепочкой вызовов - претензии к MS.
