Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 393 раз в 366 постах
|
Простите что вмешиваюсь, но после прочтения стало любопытно, нет ли возможности выловить окно, которое ловит нажатия клавиш и допустим "перекрасить", при этом пусть ловит нажатия и генерирует ключ в штатном режиме (то есть не заменять на свое окно, а поменять вид штатного окна, не меняя сертифицированного исполняемого кода). Если фризится один поток, я полагаю это не проблема запустить отдельный поток и из него вызвать функцию, а в это время другим потоком найти окно и перекрасить. Или окно защищено от измений? Или фризятся все потоки?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 12.08.2013(UTC) Сообщений: 834 Откуда: Москва Сказал «Спасибо»: 5 раз Поблагодарили: 215 раз в 174 постах
|
Автор: two_oceans Простите что вмешиваюсь, но после прочтения стало любопытно, нет ли возможности выловить окно, которое ловит нажатия клавиш и допустим "перекрасить", при этом пусть ловит нажатия и генерирует ключ в штатном режиме (то есть не заменять на свое окно, а поменять вид штатного окна, не меняя сертифицированного исполняемого кода). Если фризится один поток, я полагаю это не проблема запустить отдельный поток и из него вызвать функцию, а в это время другим потоком найти окно и перекрасить. Или окно защищено от измений? Или фризятся все потоки? Речь про Windows? Наверное, можно повесить хук на показ окошка и подменить в нём шаблон, но не уверен, что это: - не противоречит правилам пользования СКЗИ; - вообще технически будет работать, т.к. колбэки окна обычно завязаны на конкретные ресурсы, связанные с шаблоном диалога. |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 393 раз в 366 постах
|
Автор: Агафьин Сергей Автор: two_oceans Простите что вмешиваюсь, но после прочтения стало любопытно, нет ли возможности выловить окно, которое ловит нажатия клавиш и допустим "перекрасить", при этом пусть ловит нажатия и генерирует ключ в штатном режиме (то есть не заменять на свое окно, а поменять вид штатного окна, не меняя сертифицированного исполняемого кода). Если фризится один поток, я полагаю это не проблема запустить отдельный поток и из него вызвать функцию, а в это время другим потоком найти окно и перекрасить. Или окно защищено от измений? Или фризятся все потоки? Речь про Windows? Наверное, можно повесить хук на показ окошка и подменить в нём шаблон, но не уверен, что это: - не противоречит правилам пользования СКЗИ; - вообще технически будет работать, т.к. колбэки окна обычно завязаны на конкретные ресурсы, связанные с шаблоном диалога. Да, хотя бы про Windows для ясности. Пожалуй соглашусь, что такой грубый метод как подмена шаблона не будет работать. Хотя колбэки наверно можно связать, но это наверняка будет считаться как вмешательство в памяти в сертифицированный код. Я имел ввиду факт, что любое приложение для отображения окна сначала регистрирует некий класс окон и потом по имени класса можно найти уже существующее (то есть уже "развернутое из шаблона") окно в системе (пример может быть неудачный, но этим широко пользуются программы типа "посмотри пароль под звездочками" либо отыскавающие по имени класса элемент ввода пароля либо считывающие текст из элемента под мышкой) и попробовать что-то с окном сделать - подвинуть там или скрыть или что-то дорисовать. Уже потом поставить хук на единственное событие перерисовки и отдельно обрабатывать дорисованные элементы, вызывая следующий обработчик (которым как правило окажется "штатный"). Правда не уверен как это работает если окно на безопасном рабочем столе (там может отображаться окно криптопровайдера). Про правила пользования СКЗИ тоже есть сомнения, но косметические изменения ведь не помешают функционированию.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 12.08.2013(UTC) Сообщений: 834 Откуда: Москва Сказал «Спасибо»: 5 раз Поблагодарили: 215 раз в 174 постах
|
Автор: two_oceans Я имел ввиду факт, что любое приложение для отображения окна сначала регистрирует некий класс окон и потом по имени класса можно найти уже существующее (то есть уже "развернутое из шаблона") окно в системе (пример может быть неудачный, но этим широко пользуются программы типа "посмотри пароль под звездочками" либо отыскавающие по имени класса элемент ввода пароля либо считывающие текст из элемента под мышкой) и попробовать что-то с окном сделать - подвинуть там или скрыть или что-то дорисовать. Уже потом поставить хук на единственное событие перерисовки и отдельно обрабатывать дорисованные элементы, вызывая следующий обработчик (которым как правило окажется "штатный"). Правда не уверен как это работает если окно на безопасном рабочем столе (там может отображаться окно криптопровайдера). Про правила пользования СКЗИ тоже есть сомнения, но косметические изменения ведь не помешают функционированию. Сложный вопрос. Всё же, одно дело, передача пароля, например: тут нам не особо интересно, откуда берется ПИН. Пользователь может рисовать какие-угодно окна в своей системе, а нам отдавать только результат. ДСЧ, всё же, крайне критичный с точки зрения безопасности элемент. Если даже описанный вами подход можно реализовать, как доказать, что внешний обработчик не затрагивает базовые события, на основе которых генерируется гамма, а только "подменяет цвета". Ради такой мелочи строить обоснование корректности встраивания СКЗИ? Согласен, что было бы красиво отделить тут логику от отображения, но WinAPI в плане GUI - настолько лунная вещь, что при его использовании в ДСЧ единственный путь: чем проще, тем безопаснее. |
|
1 пользователь поблагодарил Grey за этот пост.
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close