Авторствo: germans
Издательствo: runion
Кароче, чекеры, брутеры, и прочий хлам. Рынок не переполнен всем этим на удивление, к примеру я не увидел еще ни одного слитого/написанного в дар чекера owa-почт. Мы сегодня напишем с вами чекер на эти почты с мультипоточностью, подключением прокси и всем остальным. Разберемся сначала - 'а чо это такое ваши чекеры'. Если ответить вкратце и по сути, то программка, проверяющая входные данные на верность, самое банальное, что вы можете привести человеку в пример - так это проверка по алгоритму Луны, ведь у каждого человека есть банковская карточка и думаю, что человек сообразит быстро в тех ситуациях, которых он был. К примеру промахнулся циферкой, а ему уже кричат из-за всех щелей, что гавно. Уйдем от введения и перейдем к сути.
Писать мы будем на языке Python, с моего взгляда это самый комфортный язык для чекеров после Go. Не нужно выдумывать велосипеды и писать чекеры на плюсах, шарпах, ведь они никогда не были предназначены для таких целей.. У нас двa пути, а именно сам принцип - как проверять то?? Первый, наилучший вариант - это запросы, бесспорно, не нужно даже сравнивать это ни с чем другим, тут мы получаем максимальную скорость какая только возможна, кроме подключения к БД самого сервера, тут мы зависим только от качества наших проксей. Второй, наихудший вариант - эмуляция, тут я имею в виду эмуляция браузера/телефона/планшета и любого другого устройства, конечно нам не придется заморачиваться с защитой на запросах, но вы только представьте какая это маленькая скорость, сколько это ресурсов жрет??..- Представили, ресурсов дохренища, скорость нихренища. Этот вариант нас не устраивает, если мы конечно не мазохисты.
Перейдем ближе к разбору нашей цели, как я говорил ранее - это owa-почты. Для начала заходим кликаться с браузера, не забываем подключить инструменты разработчика (Dev Tools) тыкайте F12 и будем вам счастье.
Переходим в инструментах разработчика в раздел 'Сеть', пробуем залогиниться, отлавливаем запросы. И ищем нужный запрос именно нам, а конкретней где мы передаем почту и пароль.
Находим такой после успешного валида в нашу почту, теперь пора лезть в 'полезную нагрузку' aka Payload. Там мы увидим тело данных, которое передается. Так же не забываем отметить факт, что запрос у нас с методом POST.
Увидели какие данные передаются, все, чхать нам на это все, пора лезть в нашу IDE. Так как мы будем писать полнофункциональный чекер с мультипотоком, и всякими наворотами саму функцию чека вынесем отдельно. Я использую Visual Studio, но честно, вообще без разницы на это, пишите где вам удобно, хоть в блокноте.
Cам код функции, отвечающая за проверку. Маленькое разъяснение, что, кого, куда, зачем, почему. Импортируем библиотеку requests, она позволяет нам засылать запросы на сайт, ведь в начале мы решили, что будем действовать именно так, никак по другому. Создаем нашу функцию, которая будет принимать такие значение как url, username, password. Вешаем на это все блок try-except, который позволяет нам отлавливать ошибки, но мы будем его использовать как часть проверки. Session - это как профиль в любом антике грубо говоря, настроив один раз мы больше не паримся, так же сохраняются все cookie в эту самую сессию, что нам понадобится для проверки. После чего мы составляем нашу полезную нагрузку или же пейлод, исходя из скриншота на прошлой странице. В destination мы заменяем у ссылки '/auth/logon.aspx' на пустоту, ведь нам нужен домен, тут мы могли использовать библиотеку urlparse для большей точности, но пока остановимся на этом. Остальное кроме username и password заполняем как было указано в дате. После чего наша сессия отправляет post запрос на эндпоинт проверки, в ней так же заменяем конечную точку на нужную нам (указано раньше в инструментах разработчика). После самое важное, как же именно проверять.. Тут может быть множество дыр, можно проверять по тому на какую страницу нас заредиректит, по элементам в ответе, и так далее, но самым надежным способом будет проверять куки, которые нам возвращает. Тут мы уже никак не можем промахнуться как с проверкой на элементы, ведь там нас может просто закидывать на совершенной другой юрл, к примеру некоторые ова почты, редиректят на сайт майкрософт где надо зайти. По окончательным редиректам тоже спорный вопрос, может вылезти какая нибудь хрень, из-за которой постоянно будем получать невалид по тысяче раз. После получаем наш словарик с куки по session, пытаемся и извлечь кук 'cadata', который возвращается при валидном аккаунте. Если у нас не получается его извлечь, то мы выбиваемся в ошибку и функция возвращает False. Разобрали функцию самого чека, вернемся к нашей мультипоточности.
Мультипоточность вырисовываем из библиотеки concurrent.futures , импортируем класс ThreadPoolExecutor из нее, она позволяет нам создавать пул потоков, функции там будут выполняться асинхронно. Именно через него и работает наша мультипоточность. Executor.map принимает у нас функцию и объект, который будет обрабатываться, все это у нас лежит под 'tqdm', она позволит нам графически отображать прогресс нашей проверки, self.total_lines служит для tqdm, то есть сколько всего строк то, работает эта библиотека как на Linux, так и на Windows. max_workers служит для обозначения кол-ва потоков, пока медленно начинаем перетекать в основной функции main. Тут все довольно таки базово, рассказывать нечего, просим указать файл пока не будет он валидным, после чего такое же и с потоками. Читаем файл, и передаем его в класс Checker, который уже запустит нам все это дело.
Пример работы выше, думаю на этом стоит завершать статью. Всем благ, скрипт приложен в архиве файлом здесь.
Вложения
1715537911278.png
check.zip
Издательствo: runion
Кароче, чекеры, брутеры, и прочий хлам. Рынок не переполнен всем этим на удивление, к примеру я не увидел еще ни одного слитого/написанного в дар чекера owa-почт. Мы сегодня напишем с вами чекер на эти почты с мультипоточностью, подключением прокси и всем остальным. Разберемся сначала - 'а чо это такое ваши чекеры'. Если ответить вкратце и по сути, то программка, проверяющая входные данные на верность, самое банальное, что вы можете привести человеку в пример - так это проверка по алгоритму Луны, ведь у каждого человека есть банковская карточка и думаю, что человек сообразит быстро в тех ситуациях, которых он был. К примеру промахнулся циферкой, а ему уже кричат из-за всех щелей, что гавно. Уйдем от введения и перейдем к сути.
Писать мы будем на языке Python, с моего взгляда это самый комфортный язык для чекеров после Go. Не нужно выдумывать велосипеды и писать чекеры на плюсах, шарпах, ведь они никогда не были предназначены для таких целей.. У нас двa пути, а именно сам принцип - как проверять то?? Первый, наилучший вариант - это запросы, бесспорно, не нужно даже сравнивать это ни с чем другим, тут мы получаем максимальную скорость какая только возможна, кроме подключения к БД самого сервера, тут мы зависим только от качества наших проксей. Второй, наихудший вариант - эмуляция, тут я имею в виду эмуляция браузера/телефона/планшета и любого другого устройства, конечно нам не придется заморачиваться с защитой на запросах, но вы только представьте какая это маленькая скорость, сколько это ресурсов жрет??..- Представили, ресурсов дохренища, скорость нихренища. Этот вариант нас не устраивает, если мы конечно не мазохисты.
Перейдем ближе к разбору нашей цели, как я говорил ранее - это owa-почты. Для начала заходим кликаться с браузера, не забываем подключить инструменты разработчика (Dev Tools) тыкайте F12 и будем вам счастье.
Переходим в инструментах разработчика в раздел 'Сеть', пробуем залогиниться, отлавливаем запросы. И ищем нужный запрос именно нам, а конкретней где мы передаем почту и пароль.
Находим такой после успешного валида в нашу почту, теперь пора лезть в 'полезную нагрузку' aka Payload. Там мы увидим тело данных, которое передается. Так же не забываем отметить факт, что запрос у нас с методом POST.
Увидели какие данные передаются, все, чхать нам на это все, пора лезть в нашу IDE. Так как мы будем писать полнофункциональный чекер с мультипотоком, и всякими наворотами саму функцию чека вынесем отдельно. Я использую Visual Studio, но честно, вообще без разницы на это, пишите где вам удобно, хоть в блокноте.
Cам код функции, отвечающая за проверку. Маленькое разъяснение, что, кого, куда, зачем, почему. Импортируем библиотеку requests, она позволяет нам засылать запросы на сайт, ведь в начале мы решили, что будем действовать именно так, никак по другому. Создаем нашу функцию, которая будет принимать такие значение как url, username, password. Вешаем на это все блок try-except, который позволяет нам отлавливать ошибки, но мы будем его использовать как часть проверки. Session - это как профиль в любом антике грубо говоря, настроив один раз мы больше не паримся, так же сохраняются все cookie в эту самую сессию, что нам понадобится для проверки. После чего мы составляем нашу полезную нагрузку или же пейлод, исходя из скриншота на прошлой странице. В destination мы заменяем у ссылки '/auth/logon.aspx' на пустоту, ведь нам нужен домен, тут мы могли использовать библиотеку urlparse для большей точности, но пока остановимся на этом. Остальное кроме username и password заполняем как было указано в дате. После чего наша сессия отправляет post запрос на эндпоинт проверки, в ней так же заменяем конечную точку на нужную нам (указано раньше в инструментах разработчика). После самое важное, как же именно проверять.. Тут может быть множество дыр, можно проверять по тому на какую страницу нас заредиректит, по элементам в ответе, и так далее, но самым надежным способом будет проверять куки, которые нам возвращает. Тут мы уже никак не можем промахнуться как с проверкой на элементы, ведь там нас может просто закидывать на совершенной другой юрл, к примеру некоторые ова почты, редиректят на сайт майкрософт где надо зайти. По окончательным редиректам тоже спорный вопрос, может вылезти какая нибудь хрень, из-за которой постоянно будем получать невалид по тысяче раз. После получаем наш словарик с куки по session, пытаемся и извлечь кук 'cadata', который возвращается при валидном аккаунте. Если у нас не получается его извлечь, то мы выбиваемся в ошибку и функция возвращает False. Разобрали функцию самого чека, вернемся к нашей мультипоточности.
Мультипоточность вырисовываем из библиотеки concurrent.futures , импортируем класс ThreadPoolExecutor из нее, она позволяет нам создавать пул потоков, функции там будут выполняться асинхронно. Именно через него и работает наша мультипоточность. Executor.map принимает у нас функцию и объект, который будет обрабатываться, все это у нас лежит под 'tqdm', она позволит нам графически отображать прогресс нашей проверки, self.total_lines служит для tqdm, то есть сколько всего строк то, работает эта библиотека как на Linux, так и на Windows. max_workers служит для обозначения кол-ва потоков, пока медленно начинаем перетекать в основной функции main. Тут все довольно таки базово, рассказывать нечего, просим указать файл пока не будет он валидным, после чего такое же и с потоками. Читаем файл, и передаем его в класс Checker, который уже запустит нам все это дело.
Пример работы выше, думаю на этом стоит завершать статью. Всем благ, скрипт приложен в архиве файлом здесь.
Вложения
1715537911278.png
check.zip
