Определение реального времени доступа к хосту

← →
Демо © (2010-04-01 16:16) [40]

Для проверки прокси:

каждый поток:
1. Выборка из общего списка следующего прокси (с синхронизацией, конечно)
2. connect к прокси
3. Передача строки на подключение к моему сайту (send "CONNECT <HOST:PORT HTTP/1.1")
4. Ожидание от прокси ответа "HTTP/1.0 200 Connection established"+#13#10#13#10
5. Ожидание ответа моего сервера
6. Поиск сингнатуры в ответе (Например, со своего сервера я получаю строку "testproxy")

Вот и всё, собственно.

← →
Медвежонок Пятачок © (2010-04-01 16:19) [41]

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

← →
Демо © (2010-04-01 16:43) [42]

> то есть хочешь сказать, что нитка проверяет один-единственный
> пароль, после чего помирает?

Забыл написать, что в цикле выбирается следующий прокси.

Это алгоритм проверки прокси, а не пароля.

← →
Демо © (2010-04-01 16:47) [43]

Проверка пароля - немного отличается алгоритм.

1. Выборка в цикле из общего списка следующего прокси
2. connect к прокси
3. Передача строки на подключение к моему сайту (send "CONNECT icq.login.com:5190 HTTP/1.1")
4. Ожидание от прокси ответа "HTTP/1.0 200 Connection established"+#13#10#13#10
5. Ожидание сигнатуры-запроса по протоколу OSCAR
6. Формирование и отправка запроса на подключение с логином/паролем
7. Получение блока данных с ответом от сервера о подключении/отказе и его проверка

← →
Медвежонок Пятачок © (2010-04-01 17:24) [44]

что-то мне как-то кажется, что создавать брут-нитки надо в количествах ну не больше сотни (если не меньше).

а задачу отыскать сотню быстрых проксей можно поручить одной-двум ниткам.

брут-нитки запускать по мере нахождения очередного быстрого прокси.

← →
Демо © (2010-04-01 17:37) [45]

> а задачу отыскать сотню быстрых проксей можно поручить одной-
> двум ниткам. брут-нитки запускать по мере нахождения очередного
> быстрого прокси.

Хорошая мысль.

Думаю, что можно это так сделать:

Десяток потоков сортируют прокси (в зависимости от количества это может от одной до 10 минут занимать), передаютупорядоченный список на обработку в потоки-бруты, сами продолжают работать с новым списком.

Бруты работают, пока полностью не исчерпают список (независимо от того, медленные или нет прокси), затем переключаются на новый, и так в цикле.
Во время работы можно подкладывать новые списки (либо этот процесс процесс автоматизировать - поиск по сайтам со списками)...

← →
[true]TRIx © (2010-04-01 23:01) [46]

стоп время.

посылка пакета

отклик от сервера

стоп время

сверка времен.

← →
Дмитрий Белькевич (2010-04-01 23:31) [47]

Если попробовать менее геморройные методы? В саппорт написать? Должен же какой-то саппорт у аси быть?

← →
Дмитрий Белькевич (2010-04-01 23:34) [48]

И - почему именно украли? Может просто глюк? У меня с гмэйлом так было - отписал им - восстановили, новый юзер и пасс выслали.

>В интернете почитал - официально восстанавливать - гиблое дело.

Ну, то есть - заранее - похороны? Имхо зря.

> Дмитрий Белькевич (01.04.2010 23:34:48) [48]

Воостанавливать, зря
Как с мобильниками, уронил не обращай внимания, иди дальше.

> [true]TRIx © (01.04.10 23:01) [46]
> стоп время.
> посылка пакета
> отклик от сервера
> стоп время
> сверка времен.

Вот как раз второе "стоп время" не может быть определено корректно.

Определение реального времени доступа к хосту Найти похожие ветки