@WinstonCherchil

Добрый день.

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

Спасибо.

0

Убежденный

Нет, конечно !
Я бы сказал, что хуки являются одним из примитивнейших решений
этой задачи, и решением далеко не самым лучшим.

Обычно для таких вещей пишут всякие фильтры типа LSP, TDI, WFP или
NDIS (Intermediate/Lightweight). В любом случае задача не из простых.
Мягко говоря.

1

@WinstonCherchil

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

Добавлено через 11 минут
WFP тоже заинтересовал. Тот же вопрос и про него.

Ориентируюсь на Win-7 и старше. (Ну может быть еще Свиста.)

Добавлено через 1 час 23 минуты
Всё, большое спасибо, Убежденный. Остановлюсь на WFP. Прямо то что нужно. И справка хорошая, и примеры есть и гуглится хорошо. Вы мне очень много времени сэкономили =)

0

Убежденный

LSP хороша в первую очередь тем, что программируется целиком в режиме
пользователя, и если вы более-менее знакомы с разными моделями сокетного
ввода-вывода в Windows, ничего особо нового осваивать не придется.
Достаточно раскопать где-нибудь парочку мануалов и повкуривать несколько
вечеров исходники стандартного примера из Windiws SDK.

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

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

1

@WinstonCherchil

Учитывая то, что моя цель не протокол TCP/IP, а протокол самих приложений, думаю мне не придется менять заголовки пакетов, и прочие низкоуровневые кошмары. По большому счету все что требуется от программы это менять информацию отправленную клиентом к серверу (или наоборот), выкидывать некоторые сообщения и посылать собственные, от лица клиента или сервера.

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

0

Убежденный

В Windows прикладные протоколы можно фильтровать только на уровне
TCP/IP или ниже. Перехватывать сразу "готовый" HTTP или FTP не выйдет.
На TCP/IP действительно не нужно будет возиться с заголовками IP-пакетов
или сбором из них потока данных, но не в этом дело. Там и без этого масса
других "заморочек", которые сильно все усложняют. Можно на примере
фильтрации HTTP рассмотреть, там простая на вид задача - вырезать
некоторое содержимое с веб-страниц - выливается в разработку целого
конвейера обработчиков, с задержкой запросов-ответов, правкой заголовков,
поддержкой gzip/zlib, кодировок и всяких специфических вещей типа
100-Continue, chunked encoding и т.д.

1

@WinstonCherchil

Предназначение программы, которую я пишу - создание автоматических тестов других программ. Например, тот же эмулятор сервера. Что бы исправить в нем какие-то ошибки или добавить функционал, очевидно, его надо остановить и пересобрать (если пишется на С++). Соответственно все клиенты которые были к нему подключены потеряют сессию с ним. Что бы после запуска опробывать новый функционал или проверить исправлена ли ошибка, может понадобиться подключение тех же клиентов, пройти этапы авторизации, открытие окошек с добавлеными/исправлеными модулями. Затем уже тестировщик, а то и сам програмист уже в этом окошке будет тыкать мышкой, что бы посмотреть как его детище работает. И что бы тестировщикам не приходилось каждый раз тратить время на прохождение исправных этапов работы программы, моя программа будет делать это за них, со свойсвенной компьютеру скоростью. Т.е. кликать мышкой по кнопкам, вводить логин и пароль, путешествовать по менюшкам и т.п.

Модуль моей программы, связанный с перехватом трафика нужен для визуализации этого трафика в первую очередь. Во вторую для того что бы программа могла реагировать на сообщения TCP, вводом мышкой и клавиатурой в тестируемое ПО. В третью (если кто-то из комьюнити написал соответствующие расширения для моей проги) уже для редактирования этого трафика, уничтожения или создания сообщений. Скорее всего это будет использоваться для создания илюзии валидности клиента или сервера, при написании своих клиентов или серверов.

С тойже целью в програму планируется добавить возможность чтения памяти процесса, перехват сообщений виндоус, ну и какой-нибудь функционал для реагирования на окружение тестируемого ПО. (Объемы дисков или ОЗУ, для очищения кешей или перезапуска ПО, работа других программ, время/дата, фаза Луны)

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

Таким образом заранее знать какое ПО будут тестировать моей программой невозможно (хотя я догадываюсь кому она приглянется в первую очередь). Соответственно нет никакой возможности реализовывать какие-то конкретные прикладные протоколы. Хотя для заманухи придется сделать пару родных расширений, хотя бы с целью проверки и тестирования АПИ.

0

Убежденный

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

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

Сам прокси можно (и нужно) сделать целиком в user mode, лучше на базе
готовых компонентов, возможно на каком-нибудь .NET/Java или вообще на скриптах.
Получится в итоге просто, надежно и расширяемо.

1

@WinstonCherchil

Да это именно то что мне и нужно.

Для этого редиректора ВФП подойдет? Или эта задача решается более простыми методами? Прокси я откинул, потому что, насколько мне известно, это отдельный протокол, и сами приложения должны уметь с ними работать, в противном случае придется много извращаться с теми же редиректорами, в которых реализован этот протокол. (Я правильно все понимаю?) Ну а то что сетевой модуль будет во многом напоминать проси - это правда.

0

Убежденный

Подойдет. Редирект в WFP появился в Windows 7, на Vista тоже возможен,
только чуть посложнее.

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

1

@WinstonCherchil

Спасибо за исчерпывающие ответы. Чуствую скоро вернусь с глупыми вопросами про WFP =)

0