Reverse engineering global hot key block

Question

Я пытаюсь перепроектировать (OllyDbg) приложение (игру), которое отключает (захватывает/перехватывает/блокирует) все глобальные горячие клавиши, пока его окно (D3D) активно (кроме Ctrl-Alt -del).

Вопрос в том, каким образом это приложение могло бы захватывать или отключать глобальные горячие клавиши (в том числе мигание, CTRL + Esc и глобальные горячие клавиши, установленные в других приложениях), в то время как его окно активно?

Кажется, что используется DirectInput (если это имеет значение). Я вижу, что он не устанавливает крючки низкого уровня (SetWindowsHookEx). В каких других случаях это можно сделать?

Наблюдения:

• Когда приложение приостанавливается (в то время как его окно все еще находится в фокусе) горячие клавиши остаются отключенными, пока окно находится в фокусе. Переключение окна на что-то другое позволяет им. Возврат к окну приостановленных приложений снова отключает горячие клавиши.
• Если вы делаете то же самое, но приостанавливаете приложение после того, как окно потеряло фокус, а затем переключитесь обратно в приостановленное окно, горячие клавиши полностью работают.
• Редактировать: Приложение, похоже, блокирует глобальные горячие клавиши, установленные с RegisterHotKey, но не отключает горячие клавиши, сделанные с помощью крючка (SetWindowsHookEx).

Эксперимент выше, по-видимому, указывает, что это некоторые настройки, связанные с окном, которое работает даже до того, как приложение приостановлено. Может ли это быть какой-то настройкой DirectInput? (Altho единственный вызов функции API DINPUT, который я вижу, это DINPUT8.DirectInput8Create.)

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

Answer 1

Точно так же, как предложил Ханс Пассант в комментариях, это вызвало это поведение из-за флага DISCL_EXCLUSIVE, установленного с IDirectInputDevice8::SetCooperativeLevel.