Как написать расширение браузера в виде dll для windows, которое перехватывает максимум событий и модифицирует максимум данных, в том числе, которое модифицирует страницы и перехватывает клики мышью в реальном времени?
В современном мире, и, в частности, на хабре, очень много говорят об универсальности, о библиотеках, и об удобных функциях, предоставляемых библиотеками. У меня вопрос: я хочу написать расширение для браузера, изменяющее содержимое веб-страниц. Всех. Абсолютно всех. Без исключения. И чтобы со стороны сайтов это расширение невозможно было детектировать. А так же, перехватывающее все основные события, которые делает пользователь за браузером: все клики мышью, загрузки файлов, и т.д. А также, события, генерируемые веб-страницами, в особенности, открытие окон, запрос на использование камеры и микрофона (главным образом, чтобы сказать, что их нет), загрузку iframe'ов, ну и так далее. В общем - полное господство и, при необходимости, изменение. Ещё нужно перехватывать обращения к сокетам. Все. Абсолютно. Ещё нужно смотреть, к каким сертификатам производится обращение, как сертификаты проверяются, при необходимости говорить, что сертификат на сервере дохлый, или что, наоборот, сертификат плохой, но жить можно, как бы на http без ssl.
Браузеры: яндекс, фаерфокс, работают на windows. Права администратора, права на установку корневых сертификатов, и другие необходимые права, есть.
Писать хочу на Си (visual studio или clang) или на старых версиях delphi (3, 5, 6, 7). В школе была Delphi 7, в университете - один семестр язык Си и один семестр - программирование, Кнута изучали в основном. Библиотеку DLL написать могу, что такое stdcall, pchar, и как распарсить html, и что делать с callback'ом - представляю и могу с этим работать. В том числе, как жить с многопоточными вызовами callback'ов, про критические секции там и синхронизацию - тоже знаю. Что делать, если мою dll загрузит несколько экзешников браузера и данные нужно будет связывать - тоже знаю.
Собственно вопрос: как подключить DLL библиотеку к браузеру так, чтобы через неё проходили все события и чтобы можно было изменять данные и ходить по DOM веб-страницы?
Мне не нужно публиковать моё расширение где-то. Это, конечно, можно, но не критично и далеко не приоритетно. Мне просто нужно, чтобы всё работало, локально, чтобы это всё было прозрачно и понятно. То есть, никаких extension-market'ов, и stor'ов, только локальная dll, пропускающая через себя события и данные.
Как это сделать? Как, условно говоря, просто написать xml, положить этот xml и мою dll в папку с экзешником браузера, и чтобы потом браузер сам загружал мою dll и чтобы всё работало?
Слышала, что расширения для браузеров пишут на java script - но мне это видится извращением каким-то. Ну то есть можно понять какие-то странные расширения, которые грузятся как скрипты и что-то там делают - но мне-то надо как можно более нативно перехватывать и модифицировать данные, с которыми работает браузер. Возможно, работать со внутренними структурами данных браузера. И т.д. Мне нужно, чтобы из своей dll я могла заблокировать выполнение скриптов на странице, или переопределить результат вызова какого-либо js-обработчика. Или выборочно не загружать скрипты совсем. А не воевать с javascript-кодом на страницах. И не быть на одном уровне со скриптами, которые страницы пытаются грузить.
Также желательна возможность установить пару своих кнопок рядом с адресной строкой в браузере, чтобы говорить что-то делать моей dll.
Браузер переписать - это, мягко сказать, запредельно сложно. Да и смысл? Как то, года три назад, ещё в университете, я пыталась откомпилировать firefox - у меня не получилось. И хочется всё таки именно расширение, чтобы исполняемые файлы браузера не трогать.
То, что вы хотите в описании, ближе подходит под тестовую среду Selenium. В нем есть все инструменты, чтобы управлять окружением браузера. Но эту среду придумали, не чтобы деформировать политики безопасности браузера в угоду пользователя, а для автоматизированного тестирования веб-приложений без непосредственного заглядывания в сам браузер.
Вопрос выглядит как типичная XY problem. Нужно исходить из реальных практических задач и под них искать инструменты, которые помогают их решить. Скажем, если нужно вырезать из страницы баннеры и кнопки интеграций фейсбука, добавить какие-то отсутствующие на сайте client-side функции (такие, как управление скоростью воспроизведения в тэге video), то это одни инструменты. Если надо автоматизированно без участия пользователя нажимать на кнопки, переходить по ссылкам, сохранять полезное содержимое страниц - другие. Если надо отслеживать актуальность сертификатов или контролировать доступность камеры - третьи и четвёртые. Кстати, для последнего в браузерах уже давно есть защита - никакому сайту не даёт получать доступ к камере без явного разрешения пользователя.
Далее, dll - это всего лишь формат загружаемых библиотек с возможностью вызова функций из них. Их кто-то должен куда-то загружать и как-то вызывать. Выбрать сразу dll без чёткого указания того, кто и как их будет использовать - это уже сразу неправильно. Конкретно в случае браузеров в принципе нет никакого интерфейса для взаимодействия с ними (NPAPI и PPAPI вроде уже наконец похоронили вместе с флешом [upd: NPAPI полностью удалён в Chrome 45 и Firefox 85, PPAPI в Chrome тоже планируется удалить]), не говоря уже о том, чтобы вызывать эти функции вообще при каждом чихе браузера.
Зачем в вопросе указаны три языка программирования? Это, кстати, нарушение правил сайта, так как вопрос к этим языкам ну вообще никак не относится. И да, если в браузерах принято использовать javascript, значит, надо использовать javascript. Если в научном мире принято говорить на English, а в медицине используется латинский, то нет смысла в них пользоваться суахили назло всем.
Если речь про т.н. плагины NPAPI или его производные — на любом. Условием является возможность создать динамически подгружаемую библиотеку (.dll/.so), реализующую и экспортирующую ряд функций с определенным API.
На практике, чаще всего используют C, как наиболее привыкшийся разработчикам.
Если речь идет о т.н. расширениях (1, 2) — как правило, на JavaScript, или, как вариант, компилируемые в него языки.
Чаще всего, пожалуй, рациональнее писать расширение, нежели плагин. Плагин нужен, если требуется что-то довольно специфичное, например кодирование видео, или работа с устройствами компьютера.
Имхо по моему легче написать прокси и подменить сертификаты
К сожалению, это не поможет для борьбы с деятельностью скриптов, которые в количестве много штук на сайт и меняются каждую неделю. Писать парсер скрипта, строить и анализировать граф исполнения, и модифицировать всё это потом для изменения функционала - полагаю, это даже не полиномиальная задача. К тому же, парсер java script'а, или type script'а, или на чём там сайты сейчас пишут ... это ж целый язык учить надо ... это сложно. молчу про web assembly, который сейчас уже везде. нет. лучше перехватывать точки взаимодействия скрипта со внешним миром (ну то есть с внутренностями браузера), и не давать ему доступ туда, куда ему по определению не нужно.
NPAPI и PPAPI, которые упоминались, нужны для воплощения тегов object и embed, и это не ваш случай, это не про перехват. Вам нужны ActiveX и XPCOM, но на них сейчас уже практически невозможно делать расширения.
Так что для вашего случая подойдёт только WebExtensions. Там обязательно писать часть кода на JavaScript. Вы можете свой перехватчик написать в виде локального веб-сервера и общаться между браузером и перехватчиком по HTTP. Ну или WebSocket. Или даже чистый сокет, расширению можно их открывать. Если ваше расширение относительно тупое, а локальный веб-сервер умный, то локальный веб-сервер на чём угодно можно писать.
Это реальная практика. Например, Контур.Эльба состоит из двух частей, из агента (HTTP-сервер) и расширения. Для всяких пенсионных и страховых фондов нужно свои расширения и агенты ставить, чтоб до ЭЦП достучаться, вот они все примерно по одному принципу сейчас делаются.
При этом нужно иметь в виду, как сделаны расширения. Браузеры сейчас работают в несколько процессов и несколько потоков. У расширения есть возможность чего-нибудь повыполнять в самом главном потоке окна браузера, где живут дополнительные кнопки панели, но такой код стремятся свести к минимуму. Ещё у расширения есть невидимая вкладка, в которой исполняется background.js, и большинство кода, по идее, переносится в неё. Но из этой вкладки напрямую нельзя достучаться до DOM вкладок с сайтами, поэтому есть отдельный механизм, как забрасывать привилегированные скрипты во вкладки с сайтами. И потом разрозненные части расширения между разными потоками и процессами должны общаться сообщениями.
Чтоб перехватить нажатие клавиши, это как раз нужно забросить в чужую вкладку скрипт. Дальше начинается вопрос, что с этим делать. Ваш гипотетический умный HTTP-сервер на localhost должен получить сигнал о перехваченной клавише, среагировать и послать ответ. Но асинхронная модель исполнения браузера не позволит получить ответ сразу. А обработчик события клавиши должен принять какое-то решение. Впитать клавишу, не пропустить её обработку дальше, или пропустить. return false или return true. Тут либо в JavaScript закодировать принятие решения, либо использовать нерекомендуемый синхронный XHR.
Даже если пробить брешь, и как-нибудь через не хочу подгрузить библиотеку, есть такая особенность. В операционных системах есть API, чтобы лишить процесс привилегий, и рабочие процессы браузеров создаются как раз такими. Безправными и слепыми. Их доступ во внешний мир сделан через трубу с основным процессом браузера, через спроецированную память и так далее. Не имея доступа к этой трубе и не зная, как ей пользоваться, вы библиотекой там ничего особо не поделаете. Устройство DOM отличается у каждого браузера и переплетено со сборкой мусора JavaScript. Если разработчики не предоставили специального, совместимого со сборкой мусора, интерфейса, как это было раньше в Firefox и Internet Explorer, там никак стабильно и переносимо не подкопаться, кроме как через JavaScript.
Я-бы подобное амбициозно ТЗ оценил в несколько лет разработки для 1 разработчика. С учетом кодинга на сях и того что браузеры Mozilla, Chrome e.t.c. имеют скорее всего разные API Extensions и под каждого из них надо оценивать и создавать отдельный проект.
Данное требование
изменяющее содержимое веб-страниц. Всех. Абсолютно всех. Без исключения. И чтобы со стороны сайтов это расширение невозможно было детектировать.
имеет противоречия. Ну я-бы по крайней мере не взялся такое обеспечить никогда.
Вы уже ломаете логику написанную сайтом и при этом хотите чтобы
"со стороны" сайтов это прошло незаметным. Будет заметен баг. Да что там
говорить. Баги и по более мелким поводам возникали.
Вообще что за злостный троян вы делаете? Просто интересно. Я не верю
что для рекламы и продвижения надо так глубоко хачить.
Если в целом, то вопрос слишком большой. Но у вас явно прослеживаются проблемы с пониманием работы веба.
как сертификаты проверяются, при необходимости говорить, что сертификат на сервере дохлый, или что, наоборот, сертификат плохой, но жить можно, как бы на http без ssl.
Браузер сам говорит об этом и куче подозрительных вещей, непонятно зачем для этого писать отдельный софт.
Слышала, что расширения для браузеров пишут на java script - но мне это видится извращением каким-то.
Честно говоря наобот, js создавался для браузера.
У меня вопрос: я хочу написать расширение для браузера, изменяющее содержимое веб-страниц. Всех. Абсолютно всех. Без исключения.
Что именно должно делать расширение?
И чтобы со стороны сайтов это расширение невозможно было детектировать.
Можете сказать зачем - это нужно? И в целом содержимое страниц постоянно меняется из-за динамических запросов.
...как распарсить html
парсинг в целом это не проблема, большая проблема получить html, который получит конечный пользователь, для примера попробуйте получить html-код для конечного пользователя с переводом текста из google translate без selenium.
Возможно, работать со внутренними структурами данных браузера.
Что это значит, слишком расплывчато сформулировано?
В общем всё что вы описали решается с помощью js в разы проще(на счет сокетов только уверен), то что вы хотите сделать выглядит очень специфично, возможно вам смогут помочь на тематических формах конкретного браузера.
Из всего вопроса я понял, что вам расширение для блокировки скриптов, в целом можно сказать, что блокировщики рекламы не всегда с этим справляются, т.к. нет универсальных правил блокировки.
P.S. а зачем писать расширение на C? Так же не делают как раз из-за вопросов безопасности.
Средний
Средний
Простой
