E
Ну поправить, конечно, надо будет
раз такое пошло, то вопрос для интереса
чем обычно дизассемблируете?
Size: a a a
2021 August 07
ДЦ
E
Да, ты прав.
Если нет
Странно, конечно. Ещё в гугле ничего по этому поводу не нашёл, попозже залезу в дизассемблер ядра
Если нет
gdi32.dll - он выбивает EXCEPTION_ACCESS_VIOLATION с STATUS_USER_CALLBACK
Можно её подгрузить, и не использовать, тогда всё нормально.Странно, конечно. Ещё в гугле ничего по этому поводу не нашёл, попозже залезу в дизассемблер ядра
E
IDA Pro, если на Windows
Если на Linux - radare2 (если нужно что-то быстро посмотреть), или на его основе Cutter
Если на Linux - radare2 (если нужно что-то быстро посмотреть), или на его основе Cutter
E
Кстати, проблема только с GDI (win32k)
Функции NT выполняются без зависимостей (на самом деле, это логично, система же ntdll с kernel32 сама подгружает, а вот GDI нужно ручками)
Функции NT выполняются без зависимостей (на самом деле, это логично, система же ntdll с kernel32 сама подгружает, а вот GDI нужно ручками)
E
Он вообще ничего не делает.
Если я подгружаю gdi32, то вместе с ним грузится user32, и выполняется
Если я подгружаю gdi32, то вместе с ним грузится user32, и выполняется
UserClientDllInitialize
GDI32 выполняется самым последним:INT3 точка останова "DllMain (user32.dll)" на <user32.UserClientDllInitialize> (0000000077419E80)!
INT3 точка останова на user32.0000000077419C85 (0000000077419C85)!
DLL загружена: 000007FEFF700000 C:\Windows\System32\imm32.dll
Точка останова по адресу 000007FEFF541064 (DllMain (msctf.dll)) установлена!
DLL загружена: 000007FEFF540000 C:\Windows\System32\msctf.dll
INT3 точка останова "DllMain (msctf.dll)" на <msctf.EntryPoint> (000007FEFF541064)!
INT3 точка останова "DllMain (imm32.dll)" на <imm32.EntryPoint> (000007FEFF701010)!
INT3 точка останова "DllMain (msvcrt.dll)" на <msvcrt.EntryPoint> (000007FEFF751B20)!
INT3 точка останова "DllMain (usp10.dll)" на <usp10.EntryPoint> (000007FEFD60BBB4)!
INT3 точка останова "DllMain (lpk.dll)" на <lpk.LpkDllInitialize> (000007FEFF651080)!
INT3 точка останова "DllMain (gdi32.dll)" на <gdi32.EntryPoint> (000007FEFF0AB1EC)!E
На самом деле, так ничего не узнаешь. Это нужно искать в дизассемблере системной функции. Наверное, он обращается к какой-то функции GDI32, или проверяет его наличие... (но скорее всего первое)
n
у меня он зависал если небыло либы. И зависал на попытке перейти по таблице вроде внутри TEB (точно не скажу, точно там или нет) на адрес где выполняется код. Когда я чекал эту таблицу без либы, там были нули. А при загрузке либы, там появился адрес. Изменило значение скорее всего dllmain при загрузке. Блин я бы и сам проверил бы, но пока изолирован от компа на отпуск
E
Не, не то.
У меня он никуда не переходил, просто крашил на переходе в системную функцию:
KiUserCallbackDispatcher:
call qword[r9+r8*8] = EXCEPTION_ACCESS_VIOLATION
У меня он никуда не переходил, просто крашил на переходе в системную функцию:
KiUserCallbackDispatcher:
call qword[r9+r8*8] = EXCEPTION_ACCESS_VIOLATION
E
Да любую из GDI
E
Ну тоже самое
NtUserCreateWindowEx
NtUserCreateWindowEx
E
EXCEPTION_ACCESS_VIOLATION
На вызове
На вызове
E
Если подробнее:
r8 = 0x4A
r9 = 0x6FF00
Это инвалид адрес. Т.е, да, он прыгает вникуда
А вот если подключить user32:
r8 = 0x4A
r9 = 0x77489500
И при r9+r8*8 = 000000007741A3E0
(Как подсказал ниже s54816, это из PEB он берёт адрес user32 KernelCallbackTable)
Это адрес функции user32:
r8 = 0x4A
r9 = 0x6FF00
Это инвалид адрес. Т.е, да, он прыгает вникуда
А вот если подключить user32:
r8 = 0x4A
r9 = 0x77489500
И при r9+r8*8 = 000000007741A3E0
(Как подсказал ниже s54816, это из PEB он берёт адрес user32 KernelCallbackTable)
Это адрес функции user32:
E
Да, тоже самое