Возможно ли узнать сигнатуру виртуального метода из рантайма?

Question

[xomachine]

Существует проект для подмены соглашений о вызовах MSVC на GCC для steam API. Саму подмену успешно реализует WINE, но требует для этого заголовочные файлы steam API.
Всё бы ничего, но steam API постоянно меняется и старые приложения из стима используют старые версии (запрашивают у steamclient.{so, dll} нужную версию) API. Доступа к заголовочным файлам для старых версий API нет.

Это было предисловие, а теперь непосредственно к проблеме
Согласно соглашению о вызовах thiscall в MSVC аргументы вызываемого метода помещаются в стек, и вызываемый метод должен удалить их из стека перед возвращением управления.
В аналогичной ситуации GCC возлагает обязанность удаления аргументов из стека на вызывающий код.
(подробнее)
(и ещё подробнее на примере stdcall и cdecl)
Таким образом если я хочу обернуть вызов мне нужно в прослойке между кодом MSVC и GCC очистить стек от аргументов метода (и провести ещё несколько операций, но это уже проще), а для этого нужно знать сигнатуру метода. А её-то, как я уже заметил в предисловии, я и не знаю для старых версий steam API.

Соответственно вопрос: возможно ли на уровне рантайма узнать сколько аргументов было помещено в стек перед вызовом виртуального метода (по виду стека, по виртуальной таблице объекта или другой информации доступной в рантайме)?
Или в другой формулировке: Как не спутать аргумент метода в стеке с локальной переменной из кода верхнего уровня?

Comments

[Станислав Силин]

Насколько я понял вы в курсе как управлять стеком из GCC, тогда что вам мешает запомнить его состояние(позицию stack pointer-a) перед вызовом, а потом после вызова вернуть его обратно? В таком случаи вообще пофиг, что осталось после предыдущего вызова или так сдвинуть stack pointer неполучиться?

[xomachine]

Станислав Силин, Проблема в том, что вызов осуществляет код скомпилированный в MSVC (код игры из steam) и я (обёртка) получаю управление с уже забитыми аргументами в стек. Код, осуществляющий вызов ожидает от меня, что я знаю, сколько аргументов положено в стек и сам их оттуда вытащу.

В то же время я передаю управление коду, скомпилированному в GCC (steamclient.so), знающему какие аргументы были переданы, но не очищающему стек (не возвращающему esp в положение до помещения в стек аргументов).

Получается, что мой код должен не зная сколько аргументов было помещено в стек, вытащить их оттуда (или вернуть esp на позицию до помещения туда аргументов).

Answer 1

[xomachine]

Сам спросил, сам нашёл решение (пусть и не универсальное)
Можно с высокой долей вероятности успешно вычислить сигнатуру метода по глубине стека, на которую обращаются инструкции. Для этого потребуется дизассемблировать метод и отследить регистры связанные со стеком.
Рабочий прототип отслеживающей процедуры для моего случая можно найти тут. Прототип написан на Nim с использованием libopcode и libbfd из пакета binutils, который входит в большинство дистрибутивов линукс.

На скриншоте результат подобного угадывания количества аргументов методов (CAdapterSteamClient017, справа) и (слева) кусок исходника, соответствующий данному классу. (надеюсь, Valve меня не забанят за публикацию скриншота с маленьким куском исходников)
Как видно из скриншота, предсказанное количество аргументов соответствует реальному.

Answer 2

[jcmvbkbc]

возможно ли на уровне рантайма узнать сколько аргументов было помещено в стек перед вызовом виртуального метода (по виду стека, по виртуальной таблице объекта или другой информации доступной в рантайме)?

Традиционно в C++ типы параметров функции кодируются компилятором в её имени.

Comments

[xomachine]

Об этом я знаю, но возникает вопрос: где в рантайме можно найти информацию о закодированном имени виртуального метода? Заранее мне не известно как выглядит объект, возвращаемый steamclient.so, а значит максимум что я могу о нём узнать - количество виртуальных методов (из виртуальной таблицы) и информацию о наследовании.

Насколько мне известно, в определённых ситуациях компилятор может вообще не производить кодирование имён виртуальных методов. И, кажется, это как раз тот случай, так как из steamclient.so эти методы ни в каком виде не торчат при objdump'е. Хотя возможно steamclient.so просто берёт эти объекты из других либ steam, но отследить этот путь мне пока не удалось.

UPD: я нашёл виртуальную таблицу для каждой из версий классов в steamclient.so, но имён методов там нигде нет.

[xomachine]

kloppspb, я собственно и расчитывал в этом вопросе узнать какие-нибудь грязные хаки, недокументированное поведение компилятора или что-то ещё, за что можно зацепиться. Среди диких, но нерабочих идей у меня были даже подсчёты push'ей в вызывающей функции.
Но пока самая адекватная - брать IDA и долго, муторно выписывать сигнатуры методов из всех найденых версий виртуальных таблиц. Единственная сложность, что IDA не всегда правильно угадывает эти сигнатуры (да и саму точку входа в метод).

[xomachine]

kloppspb, да собственно ответ на вопрос "зачем?" прямо в самом верху оригинального вопроса. Краткий ответ на него: "потому что Valve не публикует все заголовочные файлы".

Если вопрос касается именно моей мотивации, то можно сказать у меня хобби такое: взять проприеритарщину, которой я пользуюсь, и попытаться устранить неудобства, которые она вызывает при использовании под linux. В конкретно этом случае успех почти достигнут, но до полноценного продукта как раз не хватает работоспособности со всеми версиями API без танцев с бубном.