Russian Qt Forum

Собственно вопрос состоит в следующем.

Перехватывается процедура рисования текста стороннего приложения с помощью инжекта. Цель - определить в каком окне процесса рисуется данный текст, или если проще - получить HWND окна в котором производится рисование.

Перехватываемая функция Внутри можем использовать всё что угодно для идентификации того, в каком окне это рисуется.

Pid процесса для всех окон одинаковый. Поток рисования тоже один. Все функции WinApi, которые позволяют получить данные об окне, требуют HWND окна, который нам неизвестен.
Размеры/положение окна недоступны, координаты рисования нам известны, но они локальные для опять таки окна.
Единственная подходящая функция HWND WindowFromDC(HDC), выдаёт ноль, т.е. устройство рисования не имеет прямой зависимости к окну...

Собственно прошу мозгового штурма.

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

Подобные "системные" задачи - бездарное разбазаривание интеллектуальных ресурсов. Т.к. кратность использования все равно единица, то лучше уж полазить отладчиком в стороннем приложении и найти как оно выводит, а потом уж может и перехватывать

Я жду ваших предложений.

Найти в чужом приложении неизвестную структуру с неизвестными данными - довольно легко.
Найти нужную структуру - труднее.
Ещё труднее найти константный указатель на данную структуру.

Предложите другой способ перехвата рисуемого текста с окна чужого приложения. Шрифт/размер могут меняться, символы - полный набор юникода.

PS да, всё перехватывается. Да, всё стабильно работает на одном окне. Но в будущем возможно будет расширение функционала на несколько окон.

PPS а найти в памяти несколько таких структур, каким то образом соотнести их с окнами и выдирать оттуда данные - задачка на миллион.

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

Аууу, Igors, куда вы делись, кладезь невыдаваемой фентезийной информации?

:) Понимаете, говорить с человеком у которого "сдвинуты оценки" (скажем так) - ничего хорошего не выйдет. Это мелкий, грязный (бомжацкий) хак - и ничего более как бы Вы ни старались. Если по каким-то причинам он нужен - ну значит нужен, но никакой "общности" и перспектив он не имеет. А Вы тут
Да бог с Вами, что-то удалось - ну и хорошо. Изменится хакаемое приложение - ну опять придется что-то городить (если удастся). Если автор приложения захочет это пресечь - пресечет. К этому надо спокойно, нормально относиться, не строить глупых иллюзий
 

Так вы приведите "не хак".
Если вы видите его мелким, грязным, жутким хаком - приведите благопристойный вариант. А то сейчас ситуация как с хлебом - он черствый, он в луже, его есть противно даже бомжам... А другого нет.
И вы в данном случае тоже будете его есть. Просто вам ситуация не попадалась.

PS жду от вас дельных предложений "не хака".
PPS я ещё думаю, что вы хороший специалист, могущий дать совет. Если нет - так и скажите.

Связаться с автором приложения, взять исходники и адаптировать их для своих нужд. На худой конец послать ему feature request. Если такой возможности нет (или она не укладывается в бюджет) - то по крайней мере попытаться в след раз не попадать в такой положение, альтернативы всегда есть. 

Так я сразу и ответил
Хотя Вы это и без меня прекрасно знали. Да и этот вариант не единственный - напр можно через OpenGL рисовать. Так чего Вы хотите? "В WinAPI нету - но если очень хочется..". Если уж хакать, то Вы сформулировали задачу слишком узко - уперлись в перехват текста, и все. Тут и посоветовать нечего. Дайте больше инфы, может удастся подлезть с др стороны - на Вашей платформе обычно удается  :)

Верес, ну раз вы уже перехватываете DrawTextW, то перехватывайте сразу и BitBlt. При вызове DrawTextW сохраняйте хендл контекста, куда выводился текст, дальше ждем вызов BitBlt с hdcSrc == сохраненному, берем hdcDesc и пытаемся по нему получить hWnd, если не получается, сохраняем уже этот контекст и дальше ждем BitBlt, пока он не окажется привязанным к окну.

Просто и гениально, Old. О результатах отпишусь.

to Igors: перехват тектовых/числовых данных с экрана приложения, защищенного от чтения/записи памяти, зато разрешающего перехват функций winapi. Вариант "попросить исходники" кнечно идеален, но недостижим - приложение, а в особенности создатели приложения не должны быть в курсе :)

Это про то масло что не содержит холестерина? (В любом ОС читать/писать в память др процесса просто так нельзя) Давно не брал в руки вындозный отладчик, но помню что все вызовы API он показывает прекрасно. Остановитесь на пойманном DrawText и смотрите какие вызовы API за ним следуют - а там видно будет чего перехватывать. Да, и месяги уже изучили?

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

Как можно посмотреть вызовы WinApi, если при попытке чтения памяти приложение закрывается? Т.е. при попытке подключить отладчик к процессу следует закрытие приложения :)

Мессаги WinApi тут не помогут, ибо приложение использует не "окошки" с данными, а рисует само картинку.

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

А без отладчика вслепую тыкать можно ну очень долго. Впрочем так Вам и надо - нечего лазить по чужим огородам  :)

Прямое чтение/запись памяти легко перехватывается хуком на эти функции. И добавить exit() ещё до их выполнения - дело секунд.

Если и можно обойти это ограничение, что равняется взлому защиты, то это задача не программиста, а хакера скорее :)