ValidateHwnd для Win32

Всем привет. Вот универсальная версия ValidateHwnd для Win32. Проверялось мной на XP/7.

Код (Text):

1. ValidateHwnd PROC hWnd:HWND
2.     invoke CloseWindow, -1
3.     mov eax, [esp - 16]
4.     add eax, [eax - 4]
5.     mov ecx, hWnd
6.     call eax
7.     ret
8. ValidateHwnd ENDP

Пользуйтесь на здоровье

 

Чем Вас не устраивает портабельная IsWindow?

 

Вы не в теме

 

7mm
Пусть я не в теме
Но зачем CloseWindow(-1)?

 

Код (Text):

1. .text:77D75C58 __stdcall CloseWindow(x) proc near
2. .text:77D75C58
3. .text:77D75C58 hWnd            = dword ptr  8
4. .text:77D75C58
5. .text:77D75C58                 mov     edi, edi
6. .text:77D75C5A                 push    ebp
7. .text:77D75C5B                 mov     ebp, esp
8. .text:77D75C5D                 mov     ecx, [ebp+hWnd]
9. .text:77D75C60                 call    ValidateHwnd(x)
10. .text:77D75C65                 test    eax, eax
11. .text:77D75C67                 jz      short loc_77D75C7C
12. ...
13. .text:77D75C7C loc_77D75C7C:                           ; CODE XREF: CloseWindow(x)+Fj
14. .text:77D75C7C                 pop     ebp
15. .text:77D75C7D                 retn    4

в стеке остаётся адрес возврата

 

Круто)

 

Стек ниже текущей его границы юзать запрещено в любом случае, вне зависимости от простоты решения.
Более того этот стаб шадова очень активно юзается, заглушка для HMValidateHandle(). Большое число экспортируемых функций шадова начинаются с вызова ValidateHwnd(), это GetDlgItem(), IsChild() и сотни других. HMValidateHandle() также может быть найдена очень просто: GetMenuState() и есчо очень большая группа функцию юзает её. Можно и самостоятельно реализовать.
Топик ниочём.)

 

И реализуется просто, и находится просто. У меня такое решение - возможно у него и есть некоторые ограничения, связанные с обращением к стеку, ниже его границы. Но они скорее всего теоретические. Или нет?..

 

7mm
Нет.

 

Как смоделировать?

 

o Трейс.
o Морфинг и любые подобные изменения.
o Исключения.
o APC, таймеры и пр.
...
И есчо стопяцот проблем.
-
У вас недостатки:
o Использование стека не принадлежащего потоку.
o Динамическое определение.
o Также используется импорт, при этом нет необходимости чтото вызывать для поиска, можно просто взять смещение из подходящей апи.

 

Clerk

OK, при определённых допущениях мой код будет работать. Да, основная опасность - APC и прочие асинхронности использующие стек, ниже стека потока.

 

7mm
По сути передача управления в шадов это передача управления вникуда и вы можите только надеяться что апи отработает успешно.)

 

Clerk
А что меняется в случае, если искать адреса shadow-стабов по сигнатурам? Так что, везде есть свои условности.

 

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

 

Clerk
OK, благодарю за советы. По поводу стека, я с вами согласен. Он может быть затёрт в случае доставки APС, например. И всё же, это всего лишь сужает границы использования, но не делает приведённое решение неверным.