Подключение dll в python

[BaronPabloz]

Всем доброго времени суток, Господа. Есть вопрос: допустим в процессе реверса некой dll, мне бы хотелось подключить из нее пару функций. Так как под рукой есть python, то пытаюсь это делать в нем, через ctypes. Сам принцип ясен и с написанной собственноручно тестовой библиотекой проблем с вызовом функций через mydll = cdll.LoadLibrary("test.dll") mydll.testFunc() нет, все работает. Но как быть, если при реверсе чужой dll (от которой нет исходов) я не могу достоверно узнать имя функции? вернее IDA и objdump -p определяют нечто в виде "?AmlImg_check@CAlImagePack@@QAEHPAX@Z", а при этом в секции еxport самой либы эта же функция именуется как " CAmlImagePack::AmlImage_check(char const *)" при попытке вызвать функцию по обоим этим именам логично возникает invalid syntax error. Я знаю, что в мире реверса все возможно, нужно только разобраться :) Вообщем, прошу совета.

[BaronPabloz]

Отвечу сам себе...видимо ctypes не работает с либами написанными на с++ и в моем случае надо юзать boost.python

[Darwin]

Если твоя функция не метод класса, то её можно вызвать так:

Code: Python

import ctypes



lib = ctypes.cdll(r'test.dll')

AmlImg_check = getattr(lib, '?AmlImg_check@CAlImagePack@@QAEHPAX@Z')

AmlImg_check.argtypes = [c_char_p]

AmlImg_check.restype = c_void_p

Если класс, то ctypes о них ничего не знает. Нужно писать отдельную DLL, которая будет вызывать нужный тебе функционал. При этом еще нужно будет создавать требуемый объект класса для передачи в метод. Так как метод класса по сути представляет из себя функцию которая в первом параметре принимает указатель на объект класса:

CAmlImagePack::AmlImage_check(void * objCAmlImagePack, char const *)

Передача этого объекта в метод никак не стандартизирована.

[Darwin]

и в моем случае надо юзать boost.python

Это только если ты девелопер либы, но у тебя же чужая либа без сорцов.

[BaronPabloz]

Если твоя функция не метод класса, то её можно вызвать так:

вот такой код

Code: Python

from ctypes import * 



mydll = cdll.LoadLibrary("AmlImagePack.dll")

print (mydll)

AmlImg_check = getattr(mydll, '?AmlImg_check@CAmlImagePack@@QAEHPAX@Z')

print (AmlImg_check)                      #Darwin is a genius

AmlImg_check.argtypes = [c_char_p]        #тип аргументов

AmlImg_check.restype = c_void_p            #тип резалта

arg_cost = c_char_p(b'aml_upgrade_package.img')

AmlImg_check(arg_cost)

дает вот такой резалт :

<CDLL 'AmlImagePack.dll', handle 74cd0000 at 2cb9710>
<_FuncPtr object at 0x02CA3EB8>
Traceback (most recent call last):
  File "D:\#Research\crc_calc.py", line 39, in <module>
    AmlImg_check(arg_cost)
OSError: exception: access violation writing 0x00000000"

[Darwin]

Ты там реверсом занимаешься или гаданием на кофейной гуще))

То что можно получить указатель на функцию, совершенно не значит, что это чистая функция, а не метод.

Смотри в дизасм это метод класса.

[JKornev]

Передача этого объекта в метод никак не стандартизирована.

Почему не стандартизирована, в студии для x86 это __thiscall (регистр ECX), для x64 возможно RCX, а вообще в зависимости от компилятора может использоваться абсолютно любое соглашение вызовов

[Darwin]

компилятор != стандарт

Стандартизировано - это значит все компиляторы юзают одну и туже конвенцию, и это описано в соответствующих доках к языку.

[JKornev]

компилятор != стандарт

Стандартизировано - это значит все компиляторы юзают одну и туже конвенцию, и это описано в соответствующих доках к языку.

Вы написали что это нигде не стандартизировано, про стандарт языка тут речи не шло, покрайней мере я не вижу) Я лишь говорю что поведение это описано и искать его надо в доках к компилятору

[JKornev]

Да и разговор тут о другом, передача this обычно идет через ecx, поскольку метод класса экспортируется, он обязан строго придерживаться соглашению которое указано компилятору и скорее всего это будет thiscall

[JKornev]

Причем ?AmlImg_check@CAlImagePack@@QAEHPAX@Z говорит как раз о thiscall

[JKornev]

Погуглив немного выяснилось что ctypes поддерживает только сишные соглашения, но есть какие-то кастомные патчи для ctypes, работоспособность которых неизвестна. Вообще это изврат, автор юзай C++, сам такое делал в своё время и без C\С++ тут никак

[Darwin]

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

Тогда уточню, стандарт передачи параметров под конкретную платформу x86/x64, под ARM такой есть.

Да и разговор тут о другом, передача this обычно идет через ecx, поскольку метод класса экспортируется, он обязан строго придерживаться соглашению которое указано компилятору и скорее всего это будет thiscall

У тебя в одном предложении и столько сомнений "передача this обычно идет через ecx", "скорее всего это будет thiscall".

Обычно приложения пишут на MSVC, поэтому "обычно" this идет через ECX. Но мир не сошёлся клином на одном VC, есть еще другие компиляторы, в которых он передается по другому.

GCC к примеру поддержку thiscall (такую как в VC) ввел вообще только с версии 4.6 (https://gcc.gnu.org/gcc-4.6/changes.html). Сам он использует thiscall своей интерпретации.

Причем ?AmlImg_check@CAlImagePack@@QAEHPAX@Z говорит как раз о thiscall

Мангалинг тоже не стандартизирован.

[JKornev]

У тебя в одном предложении и столько сомнений "передача this обычно идет через ecx", "скорее всего это будет thiscall".

Потому что допускается использование абсолютно любого другого соглашения при обьявлении метода класса, отсюда и неуверенность

Вы что-то уходите от темы в какие-то левые дебри

[Darwin]

Почему не стандартизирована, в студии для x86 это __thiscall (регистр ECX), для x64 возможно RCX, а вообще в зависимости от компилятора может использоваться абсолютно любое соглашение вызовов

Стандарт на то и стандарт, что подразумевает использовать под одной сущностью одно и тоже. А не один компилятор юзает для этого thiscall (им же изобретенный), другой про него слышал и только недавно ввел для него ключевое слово, третий вообще ничего не знает про его использование.

Ну, а что будет если объекты классов будут некоторыми компиряторами передаваться по fastcall или даже можно проще предложить вариант, что если функция будет экспортироваться по fastcall?

Одна из причин, почему в ctypes не добавлен thiscall и fastcall они не поддерживаются другими компиляторами в какой-то одной стандартной форме.

Правильное решение этой проблемы для разработчиков ctypes, предоставить вариант полностью контролируемой надстройки передачи параметров (над cdecl и stdcall). Это не так уже и сложно сделать. Всего то добавить возможность указывать дополнительные параметры в виде регистров + настройку регистра под возвращаемое значение.