Имею ехе-шник со встроенными функциями, которые вызываются из скриптов (html, js).
Эти функции прописаны (их названия) в самом конце этого ехе-шника.
Названия этих функций и их параметры можно сохранить в файл *.IDL (с помощью Borland'овских утилит), что я и сделал [url=http://kulibin.rhlmod.ru/Fuctions.idl
]http://kulibin.rhlmod.ru/Fuctions.idl
[/url]
Утилита "Dependency Walker" не видит в этом ехе-шнике данных функций.

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

Если точнее - мне нужны адреса этих функций в ехе-шнике.

Может присоветуйте утилиту какую-нибудь....

Согласен на линк с описанием подобной проблемы.

:)

Это не API-функции. Это COM-методы.
Для того, чтобы узнать VA этих методов, потребуется сделать пару телодвижений. Читай

http://wasm.ru/article.php?article=msi

COM-интерфейс – радость для кракера?

volodya
Спасибо - оперативно

Да, кстати. Я, кажись, клал утилиту Питрека на васм - пошукай. Она умеет генерить dbg-файлы. Для TypeLib генеришь dbg-файл и пихаешь его в IDA. Кстати, скрипт был написан для IDA - см. в разделе "Примочки для IDA"

volodya
Ах как жаль, судя по всему у меня как раз вариант с
"Late Binding" и "IDispatch"

А утилиты на это видимо не рассчитаны...
Что посоветуешь?

Мда...
Хреново.
Ладно, дай я проконсультируюсь со своими консультантами по COM, может, чего умного скажут.

Вот ответ мне:


Позднее связывание - это использование интерфейса IDispatch. Вообще-то он
является наследником IUnknown, так что в некоторых случаях применимы уже
отработанные механизмы. Существуют так называемый дуальные интерфейсы, когда
объект поддерживает одновременно и раннее и позднее связывание. Здесь все более
и менее ясно: в vtbl сначала идут методы IUnknown, потом IDispatch, потом
собственный методы интерфейса.

Что же делать с чистым IDispatch? Вызовы его методов происходят с помощью
IDispacth::Invoke. Код этого метода в общем случае выглядит (упрощеноно)
следующим образом:

if (dispIdMember == ...) // dispIdMember - первый параметр IDispacth::Invoke,
содержит номер метода/свойства, который мы вызываем
{
// возможно, работаем с остальными параметрами IDispacth::Invoke, скорее всего с
5...7
// вызываем соотв. функцию или собственно метод, если он короткий может быть
описан здесь.
}
else
if (dispIdMember == ...)
{
// При обращении к свойствам, все может выглядеть вот так:
if (wFlags == DISPATCH_PROPERTYGET) // wFlags - 4-й параметр
// Вызываем что-то
else
if (wFlags == DISPATCH_PROPERTYPUT)
// Вызываем еще что-то
else
if (wFlags == DISPATCH_PROPERTYPUTREF) // Этот флаг используется довольно редко,
но все же
// Вызываем совсем другое что-то
}
else
...

Так что надо писать анализатор, который будет просматривать коды реализаций
IDispacth::Invoke, и выделять наиболее вероятных кандидатов... Чтобы получить
количество методов/свойств, надо использовать IDispatch::GetTypeInfoCount, чтобы
получить ID по имени метода/свойства IDispatch::GetIDsOfNames.

хммм...

я это не потяну. А жаль.

А кто говорит, что ты это будешь тянуть? Все мне, болезному, придется. Самый свободный, блин :(
Значит так, расковыряю перл, взломаю программу, напишу статью, потом займусь этим late binding...

volodya
ты только про третью часть не забывай - народ все еще ждет... ;)

Egorka

Брось-ка прямо сюда IDL твоего файла.

Ну вот не уместилось....

Плевать. Ясно что они dual, т.е. содержат vtbl и, одновременно берут IDispatch и унаследованы от IUnknown...
Ненавижу COM.

Egorka

Блин, а аттачи для кого сделаны?
Этож надо два километра листинга запостить :-)