Кража фокуса

Question

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

Опять же, я на самом деле исследовал и не нашел ничего, кроме как взломать актуальную проблему, это не дубликат.

Я подготовил небольшое приложение, которое определяет, когда фокус меняется. Насколько я могу судить, это происходит во всех установленных мной приложениях. Ниже приведена копия окна вывода Visual Studio (с запущенным приложением):

Как я воспроизвел проблему:

• Вручную сфокусировал Окно Блокнота (появился журнал № 1).
• Нажал Ctrl, и журнал, связанный с потоком, и журнал № 2 обнаружились.

Содержание окна вывода:

1 - Оконная ручка: 723652 | Процесс: блокнот | Окно: Без названия - Блокнот | Exe-файл: C:\Windows\system32\notepad.exe Поток 0xafc завершился с кодом 259 (0x103). 2 - Оконная ручка: 526994 | Процесс: блокнот | Окно: Без названия - Блокнот | EXE-файл: C:\Windows\system32\notepad.exe

Что я пробовал:

• После потери фокуса нажмите ALT + F4, пытаясь закрыть процесс. [прежде чем придумать приложение].
• Использовал Process Explorer, чтобы попытаться идентифицировать процесс (но, поскольку я не могу закрыть его, никакой помощи нет)

Что я думаю, что это происходит:

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

Что я могу сделать, чтобы идентифицировать процесс, а не просто помешать приложениям изменить фокус?

Answer 1

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

Проверьте для более распространенных причин

Сначала я попытался бы определить, есть ли на моем компьютере какое-либо очевидное приложение, которое может быть причиной этого. Такие приложения будут:

• Поставщики быстрых клавиш
• Драйверы клавиатуры или мыши, которые могут в случае использования клавиатуры или мыши с дополнительными кнопками. Причина этого заключается в том, что многие из них имитируют использование определенных нажатий клавиш при нажатии или нажатии этих дополнительных кнопок.
• Некоторое другое программное обеспечение, которое может использоваться для имитации пользовательского ввода

Теперь, если это не выявит более очевидных причин, я бы пошел и продолжил с более продвинутыми подходами.

Возможное внедрение кода

Первое, что я хотел бы сделать, это попытаться проверить, не был ли какой-то дополнительный код вставлен в конкретное приложение (Notepad.exe в вашем случае), проверив, какие дескрипторы DLL открыты, и сравнив их со списком DLL, который можно получить из большинства сканеров зависимости.

Любой открытый дескриптор DLL к файлу DLL, о котором не сообщает сканер зависимостей, может быть внедренной DLL в ваш процесс.

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

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

После перезапуска я сначала проверил бы, является ли поведение все еще постоянным, а затем также проверил все приложения, которые могли бы использовать эту DLL самостоятельно, чтобы увидеть, работают ли они по-прежнему.

Введите мой собственный код / хук

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

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

Создать приложение-ловушку

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

Когда я думаю об этом, я, вероятно, сделал бы это, прежде чем пытаться использовать Code injection approach

Пока эти шаги приходят на ум. Но я мог бы прийти к некоторым дополнительным идеям во время процесса, а также.