Расшифровка недокументированных COM-интерфейсов - PullRequest
2 голосов
/ 20 августа 2010

У меня есть указатель на COM-объект, который реализует недокументированный интерфейс. Я действительно, действительно хотел бы иметь возможность использовать указанный интерфейс. Все, что у меня есть, хотя IID. Главный аналитик программного обеспечения Джефф Чаппелл задокументировал множество этих недокументированных COM-интерфейсов на своем сайте; см., например, IListView . Каким-то образом ему даже удалось получить имена функций и подписи. Как такое возможно даже возможно? Это догадки?

Может ли кто-нибудь указать мне правильное направление относительно того, как бы я поступил примерно так? Я знаю риск использования чего-либо недокументированного.

Чтобы уточнить, интересующий меня объект - это печально известный документ ExplorerFrame.dll. Установив хук API для CoCreateInstance, я вижу, что объект создается с определенным недокументированным IID в качестве основного интерфейса. Я предполагаю, что это интерфейс, через который манипулирует элемент управления, поэтому я заинтересован в выяснении его членов.

Ответы [ 3 ]

5 голосов
/ 09 декабря 2010

Вы знаете, вы могли бы написать мне и спросить!Было время, когда я прямо писал, что имена и прототипы взяты из общедоступных файлов символов Microsoft, но я давно отказался от этого как словоблудия.Каким бы я был реверс-инженером, если бы всегда объяснял, как я получил свою информацию!Я буду оскорблять тех из моих читателей, которые являются реверс-инженерами, и я рискну скучать тем, кто просто хочет получить информацию (что, давайте посмотрим правде в глаза, как правило, не клепает).

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

Учитывая, что у вас есть исполняемый файл и его общедоступный символьный файл, получение IID и перечисление методов - это почти простейший метод обратной разработки.Может быть, это слишком сложно для надежной автоматизации - хотя я бы хотел, чтобы в этом ошиблись.

Вы, вероятно, знаете об интерфейсе, потому что у вас есть таблица виртуальных функций для реализации.Скорее всего, вы нашли это, потому что вы перепроектировали класс, и в этом случае вы находите таблицы виртуальных функций для всех его интерфейсов, работая из конструктора или деструктора.Таблица виртуальных функций - это массив указателей на функции.Публичные файлы символов дают вам оформленные названия этих функций.Компетентный реверс-инженер в большинстве случаев может декорировать эти символы визуально, и Visual C ++ предоставляет инструмент UNDNAME (и ваш отладчик или дизассемблер может в любом случае сделать эту работу за вас).Для нахождения IID обычно требуется проверка метода QueryInterface на соответствие известному смещению таблицы виртуальных функций интерфейса от начала класса.

Для простого интерфейса, скажем, с полдюжины методов, весь процесс написания простого базового списка IID, смещений и прототипов может занять 10 минут в хороший день и не более 30, еслиты ленивый.Конечно, с большим количеством этих недокументированных интерфейсов вы можете проверить, что реализация и IID одинаковы в нескольких версиях, что может быстро превратить хороший день в плохой.

Кстати, если я угадаю что-то или сделаю гипотезу, я постараюсь быть уверенным в том, чтобы сказать это.Например, ближе к концу документации, которую вы цитируете в противном случае недокументированному интерфейсу IListView, я говорю об оконном сообщении: вы можете знать, что имя, которое я даю, составлено мной, потому что я говорю «возможно, назвал что-то вроде».

2 голосов
/ 12 декабря 2010

Окончательный интерпретатор файлов PDB - MSPDBxx.DLL.Основным инструментом для интерпретации файлов PDB является отладчик, и в настоящее время он также является компоновщиком Microsoft Visual C ++ в виде дизассемблера DUMPBIN.Они не показывают все из файлов PDB, но они делают все основные вещи, такие как перечисление всех символов, маркировка кода и данных, и суммирование из любой информации о типе в файле (который обычно отсутствует в файлах общедоступных символов),

Как обычно, компетентный - хорошо выполненный - инженер-реверс может прочесть эти файлы на виду для получения информации, которая не отображается стандартными инструментами.Наиболее ярким примером является информация о вкладе в раздел, которая настолько близка, насколько файлы открытых символов подходят к коду, совпадающему с исходными файлами.

Как вы указываете отладчики на файлы символов, хорошо задокументировано.Моя практика составления списка с помощью DUMPBIN - просто копировать двоичный файл и соответствующий файл PDB в текущий каталог.Пока имя файла PDB-файла совпадает с именем файла в каталоге отладки двоичного файла, DUMPBIN работает с файлом PDB автоматически.Это действительно не может быть проще.

Я полагаю, что дизассемблеры и декомпиляторы сторонних разработчиков, по крайней мере, способны использовать любой файл PDB, доступный для целевого двоичного файла.

0 голосов
/ 20 августа 2010

Если ваш указатель подразумевает IDispatch (что вполне вероятно), вы можете использовать QueryInterface для этого, а затем GetIDsOfNames.Вы, вероятно, в конечном итоге угадываете, какие интерфейсы он может использовать, и вызываете QI, чтобы посмотреть, что работает:)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...