Хочу переписать простую прокси-дллку с 32 бит, и почему-то она криво работает на 64 бит. Не получается сделать ни на Си, ни на Масм, приложение тупо падает. Это version.dll , 32 битная версия такая: --> Link <-- (лишнее вырезано).

64 битная (масм) --> Link <-- - запускается, т.е. отрабатывает DbgString, но падает где-то в недрах comctl32 , а мб где-то еще
64 битная (Си) --> Link <-- - не работает вообще, прога падает. Вероятно, оно очень кривое, но я не пойму, как без асм-вставок сделать эту переадресацию.

Добавлено спустя 4 минуты
Или может есть тулзы какие-то готовые. Все, что нашел - заточено под 32 бита.

| Сообщение посчитали полезным:

morgot
Собственно есть 2 варианта (которые без геморроя), либо подрубить масм в студии, либо юзать конпиль от интел(так же легко подрубить к студии)

| Сообщение посчитали полезным:

SReg пишет:
либо подрубить масм в студии
Я нашел другой вариант, где юзается масм в х64 , но или студия глючит, или я..пишет ошибку. Как его там включить? Студия 2015. Добавляю новый асм файл в проект, там код вида


В Си пишу


Project->Build depend..->Build customization выбираю MASM , но получаю ошибку , что линкер не видит этот RunASM

| Сообщение посчитали полезным:

ну давай я за тебя поищу
--> Link <--
--> Link <--

| Сообщение посчитали полезным: morgot

DllMain поставьте
как точку входа Компоновщик - > Дополнительно - >Точка входа
Укажите импорт явно в том же компоновщике и
используйте DEF файл

телега https://t.me/VIRTEAM

JID: virteamplus@sj.ms

| Сообщение посчитали полезным:

Storage
Отличный способ отхватить дедлок - использовать LoadLibrary в DllMain.

-----
старый пень

| Сообщение посчитали полезным:

morgot, делал по этой инструкции http://lallouslab.net/2016/01/11/introduction-to-writing-x64-assembly-in-visual-studio/
проблем не было (студии 2015 и 2019).

r_e пишет:
Отличный способ отхватить дедлок - использовать LoadLibrary в DllMain
Можно пояснить почему?

| Сообщение посчитали полезным: morgot

Потому что MSDN.
--> DllMain MSDN <--

The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.

| Сообщение посчитали полезным:

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

-----
vx

| Сообщение посчитали полезным:

morgot
уж если ставил редиректы так бы и вписал путь к реальной длл и все эти твои лоад либрари не нужны.

| Сообщение посчитали полезным:

Спасибо всем. Я вроде указывал в студии masm building, но не собирало и все. Переделал еще раз с нуля, по инструкции - и заработало. Мистика.
Или может, я указывал этот масм в настройках win32 проекта, а компилировал 64 битный? Может такое быть или этот Masm добавляется сразу в весь solution?
Почему вообще не сделали его поддержку по дефолту?

r_e пишет:
Отличный способ отхватить дедлок - использовать LoadLibrary в DllMain.
Когда-то на васме обсуждали эту тему, как все таки правильно? Создавать поток в DllMain тоже не советуют. Ну вот когда есть дллка, которая должна что-то там пропатчить и т.д.

difexacaw пишет:
Нужно послать APC
Т.е. вместо потока или явного вызова LoadLibrary нужно вызвать QueueUserApc ,передав адрес процедуры, где идет основная работа? Или что имелось ввиду?

Alchemistry пишет:
вписал путь к реальной длл
Как и куда вписывать?

| Сообщение посчитали полезным:

morgot

> Создавать поток в DllMain тоже не советуют.

Создавать потоки в dll.EP можно. Когда поток запустится он войдёт в ожидание в загрузчике, пока текущий поток(который выполняет dll.EP) не покинет загрузчик, затем поток выйдет из ожидания и продолжит выполнять загрузчик. Если выполнить при этом в dll.EP синхронизацию с новым потоком, то возникнет деадлок.

> Т.е. вместо потока или явного вызова LoadLibrary нужно вызвать QueueUserApc

Да, разница в синхронизации такой загрузки. Придётся обождать через туже APC запуск потока, а поэтому для такой синхронной загрузки во втором потоке нет смысла. Это нужно обычно для инжектов, когда в произвольный момент времени нужно подгрузиться.

-----
vx

| Сообщение посчитали полезным: morgot

morgot

сюда

#pragma comment(linker, "/export:VerQueryValueW=version.VerQueryValueW")

на пример

https://github.com/Panupong9844/metasploit-framework/blob/eb11a5993a88d49a11039c454b109ab64b9a8a81/data/templates/src/pe/dll_gdiplus/template.h

хоть с локалхоста задай

| Сообщение посчитали полезным: morgot

код FASM - прокси 64х для d3d9.dll

2f37_24.02.2020_EXELAB.rU.tgz - d3d9.asm

| Сообщение посчитали полезным: morgot

Возвращаясь к длл, написанной чисто на Масм64. Когда я сравнил ее с рабочим 64 битным вариантом, то нашел ошибку. Масм почему-то генерит с такого кода



вот такой


Если вручную занопить пролог (enter , sub rsp ), то все работает. Но - откуда это берется и можно ли это отключить? Ведь в студии тот же масм такое не генерит.

| Сообщение посчитали полезным:

option prologue ?

Добавлено спустя 9 минут
Пример наглядный тебе с синхроном apc:



25c0_24.02.2020_EXELAB.rU.tgz - L.7z

-----
vx

| Сообщение посчитали полезным:

difexacaw
спасибо, это оно.

| Сообщение посчитали полезным:

А ты как хотел? Задал как процедуру-получи фрейм стека.

| Сообщение посчитали полезным:

Archer

Наверно можно было конвенцию задать, proc C например.

-----
vx

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

morgot

Он имел ввиду что при дефолтном прототипе формируется фрейм, opt prol. что бы ты все стабы не переписывал(врядле ты макро используешь). Асм отличается от высокоуровневых яп, нужно вначале ознакомиться с опциями сборки, так как все настройки задаются напрямую.

-----
vx

| Сообщение посчитали полезным: