Добрый день! Сделал перехват сетевых ф-й из ws2_32.dll для приложение IE7 , логинг идет на ура. Но задача - заменить определенное слово в принимаемом пакете ф-ии recv на свое. Пытаюсь делать так: скачать полностью страницу, расшифровать gzip, зашифровать и отдать браузеру. Задача оказалась слишком сложной в том плане, что алгоритм работы осла не совсем однозначен - ясно, что используются неблокирующие сокеты, но пока не до конца понятна причина долбления на udp сокет (127.0.0.1) функцией send (а не sendto) и передачей символа "!". Интуиция подсказывает, что таким образом происходит разрыв ожидания на ф-ии select - собственно на ней пока и застрял. Если попытаться выкачать все данные с сокета с помощью неблокирующего режима, то на ф-ии select (оригинальной конечно же, полученной с помощью GetProcAddress) происходит зависание - когда данных больше нет (все выкачал уже), то ожидание на select будет длится пока не истечет таймаут. Это правильно, но как же осел умудряется узнать , что данных больше нет. Ведь никаких задержек делать недопустимо в перехваченных ф-ях и нужно как можно быстрее сделать замену и отдать измененный пакет! Скажите, удавалось ли кому-нибудь сделать такой перехват(не вининет, а именно винсок) для Internet Explorer (с поддержкой gzip еще) ? И еще интересует вопрос, например если gzip убрать, подменив в send запрос к северу, то можно ли эффективно сделать замену посылаемых данных, не выкачивая полностью страницу, а в отдельных вызовах recv - по частям принимаемых буферов? Ведь после вставки данных в пакет, размер последнего окажется больше и соответственно размеры нужно корректировать (можно ли переаллочить буфер, который система предоставляет для ф-ии recv, иными словами)
какой ленивый народ, какждый школьник считает своей обязанастью написать свой трой для http. при том даже не имя поняти о http протоколе.
все когда-то были школьниками. судя по всему, этот символ на УДП - проверка сети (так по крайней мере чаще всего пишут). в таком случае я, например, просто сразу делал return.. думаю, "переаллочить" буфер невозможно. его ведь выделяет ИЕ. в таком случае, скорее всего, нужно все время помнить, что не влезло.. такой вариант не пробовал..
djmans орфографии научитесь, уважаемый, прежде чем называть кого-то школьником saxon в сущности, получилось принять данные, и отдать - просто хидеры парсить приходиться (чтобы узнать колво данных). правда вот пока при рефреше висит на select-е, чето именно с этим удп сокетом связано, потому что в readfds передается именно он .... осел ждет чего-то ))
этот удп нельзя ИМХО трогать, нужно сразу return делать. а что плохого в парсинге пакета на количество данных? структура пакетов описана в RFC. и все равно парсить нужно пакеты. так какая уже разница. П.С. я сам почти с таким же вопросом в соседнем треде
saxon плохого в парсинге нет ничего по сути, и правда в любом случае придется парсить, - при подмене скажем. А у тебя трансляция норм идет кстати? имею в виду - вот ты получаешь данные, после отдаешь - причем за раз отдать нельзя, а порциями. я еще отсеиваю ненужные сокеты - например те, на которые картинки идут или яваскрипт - делаю в myrecv вызов оригинальной recv , c флагом MSG_PEEK - чекаю заголовок, если там не text/html , структуру с сокетом удаляю (создавал ее в connect) - у осла каждый ресурс на свой сокет идет. Ну и передаю просто буфер оригинальной ф-ии и возвращаю значение которое вернет оригинальная. Все работает, да вот собака при рефреше идут постоянные вызовы select - идут и идут (в readfds этот удп сокет). будто бы браузер ждет чего-то от меня). Кстати, если не отбрасывать сокеты - все ок, да вот только притупливает местами загрузка страниц!
я вообще не трогаю ничего, кроме recv/send. пока не понял, зачем select и все остальное перезватывать? просто ловлю пакет нужный, с него беру сокет. но я качаю сразу всю страницу, а потом обрабатываю
ну я тоже так делаю. остальное перехватывать - просто чтобы видеть вызовы которые осел делает. весьма полезно для понимания алгоритма его работы. Только я на connect-е создаю элемент связного списка, где все данные про сокеты, связанные буфера. Например если выкачал все данные по recv, теперь надо отдать, кусками. Вот как раз и сохраняю буфер с данными и текущей позицией. В принципе уже все ок, там утечки были и переполнения буферов оказывается. Пока на 7м осле делаю. Судя по твоим сообщениям из соседней ветки, 6й осел другие ф-ии вызывает... МДа.По-моему проще wininet перехватывать, сокеты перехватывать уже не так универсально, как казалось раньше.
а зачем расшифровывать g-zip? можно просто подменять content type в хедерах при вызове send и данные будут идти не сжатыми. и select зачем трогать? можно обойтись и без него, качай страницу с помощью WSARecv в msdn был где то пример, переделать 5 минут, будет более универсально, т.к. фф и опера юзают её. а djmans прав, нужно учить хттп протокол, paymera здесь ведь не форум по русскому языку, поэтому не стоит делать замечаний по этому поводу
