tangro Mar 23 2015 at 13:08

Использование технологии Microsoft Active Accessibility для доступа к содержимому браузера

6 min

13K

Инфопульс Украина corporate blogProgramming*C++*Browsers

Tutorial

+14

Comments 20

Cobolorum Mar 23 2015 at 13:29

Напомнило «Знаете, у нас есть крутой вирус, но для его работы нужны админские права»

tangro Mar 23 2015 at 13:43

Ну, это как с топором, которым можно рубить дрова, а можно зарубить соседа. MSAA даёт доступ к контенту в браузере, а уж будете вы это использовать для написания screen magnifier или для слежения за пользователем — это уже ваше личное дело.

lolopolosko Mar 23 2015 at 13:57

Для IE и Firefox можно использовать DDE
Для Хрома, насколько я понял, необходимо парсить окно полностью пока не найдем необходимый нам элемент

if (name.find(L"Адресная строка и строка поиска") != -1)

А что если у нас это не «Адресная строка и строка поиска». Тогда получается нужно добавлять несколько вариантов, для каждой локали Хрома

tangro Mar 23 2015 at 14:52

Ага. Второй вариант — отталкиваться от положения элемента в дереве (тип, номер в группе, тип родителя). Но тут мы уже никак не застрахованы от изменений в будущих версиях браузеров.

printf Mar 23 2015 at 15:27

Вот еще кривой способ: захват текста через буфер обмена.

Находим окно, отправляем в него Ctrl+L (фокус на строку адреса), Ctrl+A (на всякий случай), Ctrl+C.

Возможно, забираем искомый адрес из буфера обмена. Или не забираем. Как повезет.

Veliant Mar 23 2015 at 15:45

С 5 не согласен. С помощью хуков на API можно достать данных из любых браузеров с шифрованием и без него. Вы просто не ту API ловите

naum Mar 23 2015 at 16:42

DrawText? :)

tangro Mar 23 2015 at 22:08

А ну ка расскажите, что можно ловить в том же Хроме, который рисует всё окно одной картинкой, которая в итоге выводится через DirectX одной цельной текстурой?

Veliant Mar 24 2015 at 10:02

а чего Вы к отрисовке текста привязались? обычно троянцы перехватывабт данные на этапе отправки, шифрования, получения данных.

tangro Mar 24 2015 at 11:29

Как я писал в разделе о снифферах — они бесполезны для HTTPS и HTTP/2 — а именно там всё интересное и бегает. Что касается шифрования, то Хром не использует ни виндовые функции шифрования, ни OpenSSL, так что я повторю вопрос — куда вешать хуки?

Demogor Mar 24 2015 at 11:30

Не совсем так — fiddler умеет https, насчет http/2 не в курсе.

tangro Mar 24 2015 at 13:06

fiddler умеет https через импорт своего фейкового сертификата в доверенное хранилище системы. Это решение чисто для отладки, запускать такое на машине конечного пользователя нельзя.

Demogor Mar 24 2015 at 14:24

Согласен, хотя в контексте «получить данные из 'интернет-обозревателя'(С)» и «А напишите в комментариях, какие ещё решения вам приходят в голову и мы подумаем, получится или нет.», сойдет.
Да и статья, как я понимаю, про MSAA, а не то, как стырить данные из браузера)

zenden2k Mar 23 2015 at 16:42

А можно как-нибудь поменять текстовый инпут на страничке, кроссбраузерно? Скажем открывается клиент-банк, вводится номер счета им все деньги переводятся мне (шуточный пример).

-1

Demogor Mar 23 2015 at 17:23

См. следующий комментарий — fiddler+js.
А за вопросы такие еще в детстве по жопе бить нужно(за шуточные — шуточно) ).

Demogor Mar 23 2015 at 17:22

Есть еще один способ(по крайней мере, под шарп) — использование FiddlerCore.
Перехватываем все исходящие/входящие соединения и, если перехваченный трафик содержит в себе html, добавляем к нему js.
А внутри js уже можно писать любую необходимую логику, да и доступ к dom-елементам никто не отменял

ixSci Mar 23 2015 at 17:36

В своё время занимался похожей задачей, даже статью по этому поводу писал. Правда с тех пор браузеры изменились и, возможно, многое из этого уже не работает. Но, я уверен, что решения можно найти в файлах браузера. Так, я добывал URL хрома и FF из их же файлов в Linux. Т.е. я ничего против вашего решения не имею, но, на мой взгляд, универсальное решение, которое будет работать в других OS, всё же лучше.

Tseikovets Mar 23 2015 at 18:11

Ваш вариант
А напишите в комментариях, какие ещё решения вам приходят в голову и мы подумаем, получится или нет.

Напрямую выскабливать дерево DOM. Между прочем, многие программы чтения экрана используют для обеспечения невизуальной доступности web-страницы именно прямое выскабливание контента из DOM, потому что accessibility API зачастую даёт недостаточный объём информации.

Под тот же Chrome есть вообще специальная локальная программа чтения экрана на JavaScript, которая работает исключительно с DOM, потому что нужно обеспечить кросс-платформенность. Называется ChromeVox, исходники можно посмотреть здесь.

А вообще статью надо было назвать «Забиваем гвозди костылями». :-)

tangro Mar 23 2015 at 22:12

«Забиваем гвозди костылями» — это клёво :)

Код вообще писался для другого — нынче есть мода писать всё-подряд в виде кастомизированного Хромиума. Например, десктопные клиенты Spotify или Slack — это просто обточенный напильником Хромиум с вшитыми ресурсами. Если хочется с этим монстриком как-то взаимодействовать — вот получаются такие костыли для гвоздей.

apixosoft Mar 29 2017 at 19:40

Спасибо за решение! Тут — самый лучший код во всём интернете =) Но… проверил на классической Опере и IE 11 — не берёт.
Что-то не так с кодом, или архитектура приложений несколько отличается?