Chrome, Opera splicing

Тема в разделе "WASM.NETWORKS", создана пользователем saxon, 16 янв 2012.

  1. saxon

    saxon New Member

    Публикаций:
    0
    Регистрация:
    24 июн 2009
    Сообщения:
    23
    Привет, народ.
    Что можно почитать про socket splicing в сабжах?
    Нужно просто заблокировать определенные IP адреса в этих браузерах. FF, IE все норм. А сабжы выдают ошибку "Невозможно подключиться... Проверьте подключение..."
    Они одинаково работают на WSAAsyncSelect()
    Мне нужно подменить обработать только connect() и по необходимости перенаправить на другой адрес.
    В обработчике OnConnect() делаю просто вызов RealConnect(..) возвращает -1 и ошибку 10035
    Пробовал перед этим вызвать WSAAsyncSelect() с параметрами, как это делает сам браузер, но это ничего не меняет.
     
  2. Malfoy

    Malfoy New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2012
    Сообщения:
    698
    saxon
    Уж не собрались ли вы патчить и иначе портить модуля..

    Во первых нужно определить нормальный способ похачить сокеты, в самом простейшем случае это переписать копии SockProcTable(UpCallTable).

    Во вторых зачем что то делать с системными механизмами, если известны конкретные приложения, которые эти механизмы будут использовать. Тоесть опера содержит массив векторов на стабы, которые переходники к WSA. В хроме массив ссылок на процедуры. Достаточно свои туда прогрузить. Да и это более годно, чем пониже что либо юзать, так к примеру какой нибудь хитрожопый детектор типо виньчека может обнаружить фильтр. А на уровне приложения такое нельзя задетектить.
     
  3. saxon

    saxon New Member

    Публикаций:
    0
    Регистрация:
    24 июн 2009
    Сообщения:
    23
    в целом потому, что на опере и хроме список не заканчивается.
    Необходима обработка любого приложения.
    В итоге может перерасти в блокировку на основе контента и запросов.
    Поэтому под конкретные приложения делать не вижу смысла
     
  4. Malfoy

    Malfoy New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2012
    Сообщения:
    698
    saxon
    Есть стандартный LSP-механизм. Можно его заюзать, но по мойму палево. Чего вы хотите не понятно.
     
  5. saxon

    saxon New Member

    Публикаций:
    0
    Регистрация:
    24 июн 2009
    Сообщения:
    23
    я хочу сплайсинга. connect() мне пока достаточно. и я вижу, как могу расширить решение в будущем при необходимости.
    Что мне необходимо, так это выяснить, почему опера и хром так просто не заводятся с полоборота, как ИЕ и ФФ.
    Т.е. у них обоих используется тупая виндовая нотификация WSAAsyncSelect(), за которую нужно оторвать руки.
    Так вот мне необходимо всего лишь в обработчике connect() вызывать свой connect(). для этого нужна какая-то магия.
    С помощью плагина к OleDbg для трейсинга WinSock просмотрел всю последовательность вызовов.
    Перед любым connect() вызывается этот самый WSAAsyncSelect(). Я делаю то же самое со своими параметрами и ничего хорошего с этого не выходит.
    Код (Text):
    1. /*static*/ int WINAPI Connect::OnConnect( SOCKET s, const struct sockaddr *name, int namelen )
    2. {
    3.     EC_ASSERT( m_this.get() != 0 );
    4.  
    5.     EC_LOG4A( "Ip", GetIpAddress( name ), "Port", GetPort(name) );
    6.    
    7.     if( std::string( GetIpAddress( name ) ) == "127.0.0.1" )
    8.     {
    9.         return Connect::m_realConnect( s, name, namelen );
    10.     }
    11.     else
    12.     {
    13.         sockaddr_in &connectionInfo = reinterpret_cast< sockaddr_in & >( const_cast< sockaddr & >( *name ) );
    14.         sockaddr_in newInfo = {0};
    15.  
    16.         ///........
    17.  
    18.         int iResult = 0;
    19.         u_long iMode = 0;
    20.         iResult = ioctlsocket( s, FIONBIO, &iMode );
    21.         DWORD aas = WSAGetLastError();
    22.  
    23.  
    24. //          WSAAsyncSelect( s, (HWND)0x003F02C8, WM_USER + 0x1E, FD_CONNECT ); // То же самое делает опера
    25.         int result = Connect::m_realConnect( s, reinterpret_cast< const sockaddr * >(&newInfo), sizeof(newInfo) );
    26.         if( SOCKET_ERROR == result )
    27.         {
    28.             EC_LOG2A( "Proxy connect error: ", WSAGetLastError() ); // 10035 !!!! здесь беда
    29.             return Connect::m_realConnect( s, name, namelen );
    30.         }
    31.     //...
    32. }
     
  6. saxon

    saxon New Member

    Публикаций:
    0
    Регистрация:
    24 июн 2009
    Сообщения:
    23
    Это настолько сложная тема?!
     
  7. Kaimi

    Kaimi Андрей

    Публикаций:
    0
    Регистрация:
    15 апр 2010
    Сообщения:
    120
    А что вы ждете? Ну отлично, кусок кода, который мало что показывает, ибо может реализация перехвата подкачала, может какая-то из Ваших кастомных функций что-то не то делает, может быть...

    Отличная формулировка для человека, который в состоянии пользоваться отладчиком. Не выходит что?
    А при трассировке на каком именно моменте "ничего не выходит"?

    Также не особо понимаю зачем ioctlsocket и прочее в приведенном коде, ну вызывает движок браузера какие-то функции из винапи, но в перехвате то целью является изменить нечто в рамках функции connect, то бишь, по-идее, достаточно было бы взять детурс и написать кастомную функцию типа (если целью стоит простой коннект по другому ip):

    Код (Text):
    1. int My_Connect(SOCKET s, const struct sockaddr *name, int namelen)
    2. {
    3.     if(((sockaddr_in*)name)->sin_addr.S_un.S_addr == inet_addr("127.0.0.1"))
    4.     {
    5.         ((sockaddr_in*)name)->sin_addr.S_un.S_addr = inet_addr("8.8.8.8");
    6.     }
    7.  
    8.     return Real_connect(s, name, namelen);
    9. }
    Или тут есть скрытые мотивы и неочевидные концепции?