#python #winapi #reverse-engineering #ctypes
#python #winapi #обратная разработка #ctypes
Вопрос:
Предыстория
Использовать Python для вызова неэкспортированной функции DLL. Вызываемая функция предполагает, что один из общих регистров уже установлен в местоположение буфера — он не устанавливается через переменные стека. Буфер будет принадлежать скрипту Python. В идеале решение должно выполняться автономно, а не в контексте отладчика.
Проблема
Можно ли использовать Python для установки одного из регистров x86, в данном случае ECX, в ячейку памяти переменной Python перед вызовом функции DLL? (и без процесса получения / сохранения регистра, уничтожающего его).
Рассмотренные подходы
Я рассмотрел несколько подходов, все из которых кажутся относительно тяжеловесными, и я быстро достигаю уровня своих знаний:
- Использование GetThreadContext — я полагаю, для этого потребуется запустить функцию DLL в отдельном потоке, получить и обновить контекст потока — если это будет хорошим способом, было бы неплохо использовать высокоуровневый подход
- Использование некоторой формы corepy / pyasm для создания небольшой программы может привести к уничтожению регистров перед вызовом функции DLL.
- Использование скрипта Python в отладчике, таком как Immunity Debugger — это решило бы большинство проблем, но в идеале мы хотели бы, чтобы скрипт выполнялся автономно.
Я был бы очень благодарен за любые предложения о том, как подойти к этому.
Ответ №1:
Я думаю, что единственный практический способ сделать это — написать код, который вызывает функцию в asm. Только контролируя его на этом уровне, вы можете быть уверены, что никакая другая сторона не изменит регистр.
Одним из способов было бы сделать это статически и заставить компилятор / компоновщик создать DLL, которую вы можете вызывать из своего кода Python, передавая любую необходимую информацию. В частности, адрес функции и любые параметры, необходимые для передачи функции.
Другим способом было бы сгенерировать код во время выполнения с помощью какого-то дрожания, например, генератора динамического кода. Этот подход, вероятно, сложнее понять правильно, хотя он предлагает перспективу большей гибкости.