Access hash telegram что это
Перейти к содержимому

Access hash telegram что это

Статья Автоматизированный сбор данных в чатах и рассылка для Telegram на Python

Plane-Network-Application-Social-Internet-Telegram-5952446.jpg

Ссылка на готовый код с гитхаб в конце статьи.
У нас будет три основные части программы: коннектор клиента( как это назвать по-русски?? ), сбор участников чата и рассылка по пользователям.

Будем использовать библиотеку telethon. Документация по библиотеке —

Устанавливаем библиотеку telethon

2022-04-29_17-10.png

Создаем app, копируем необходимое и создаем переменные:

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

В текущей директории создается файл *.session. Был момент, когда я долго разбирался как работает подключение и коннектился огромное количество раз, и Телеграм забанил меня на несколько суток. Если такое случится, нужно удалить это файл сессии и приконнектиться заново.

Получаем список чатов:

.get_dialogs – получить все диалоги
.is_group — проверка является ли диалог групповым чатом/megagroup-чатом
.is_channel – то же самое для каналов.
То есть вместе два этих условия дают спарсить групповые чаты от каналов(пабликов). Отдельно .is_channel можно спарсить участников канала, только если имеются админские права.

Дальше берем в переменную выбор пользователя.

Можно также спарсить такие параметры как:
id, bot(False or True), scam(False or True), fake(False or True), access_hash, first_name, last_name, phone, и status(когда в последний раз был онлайн)

Далее можно добавить опцию выбора: сохранить или спамить по списку. А можно и не добавлять. Взрослые люди все-таки, сами можете выбрать есть мороженное на завтрак или в обед.

Accessing the Full API¶

The TelegramClient doesn’t offer a method for every single request the Telegram API supports. However, it’s very simple to call or invoke any request. Whenever you need something, don’t forget to check the documentation and look for the method you need. There you can go through a sorted list of everything you can do.

The reason to keep both https://lonamiwebs.github.io/Telethon and this documentation alive is that the former allows instant search results as you type, and a “Copy import” button. If you like namespaces, you can also do from telethon.tl import types, functions . Both work.

You should also refer to the documentation to see what the objects (constructors) Telegram returns look like. Every constructor inherits from a common type, and that’s the reason for this distinction.

Say client.send_message() didn’t exist, we could use the search to look for “message”. There we would find SendMessageRequest, which we can work with.

Every request is a Python class, and has the parameters needed for you to invoke it. You can also call help(request) for information on what input parameters it takes. Remember to “Copy import to the clipboard”, or your script won’t be aware of this class! Now we have:

Мобильный протокол: подробное описание

Рекомендуем вам сначала ознакомиться с техническим FAQ.

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

Ключ юзера вместе с ключом сообщения определяет актуальный (текущий) 256-битный ключ и 256-битный вектор инициализации, который шифрует сообщение, используя AES-256 шифрование с расширением неопределённого искажения (infinite garble extension, IGE).

Обратите внимание, что часть сообщения, которая должна быть зашифрована, содержит переменные данные (сессию, ID сообщения, порядковый номер, соль сервера), которые явно оказывают влияние на ключ сообщения (и таким образом на ключ AES и iv). Ключ сообщения определяется 128 битами нижнего порядка от SHA1 тела сообщения (включая сессию, ID сообщения, и т. д.) Составные сообщения шифруются как одно сообщение.

Терминология

Ключ авторизации

2048-битный ключ, которым обмениваются девайс клиента и сервер, созданный непосредственно во время регистрации юзера на устройстве клиента, чтобы обмениваться ключами Диффи-Хеллмана, и никогда не передаваемый через сеть. Каждый ключ авторизации существует только для конкретного пользователя. Ничто не мешает юзеру иметь несколько ключей (которые согласовываются с «перманентными сессиями» на разных девайсах), некоторые из них могут быть заблокированы навсегда, если девайс утерян.

Ключ сервера

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

Идентификатор ключа

64 бита нижнего порядка хеша SHA1 ключа авторизации используется, чтобы показать, какой именно ключ был использован для шифрования сообщения. Ключи должны уникально определяться 64-мя битами нижнего порядка их SHA1, и в случае коллизии/столкновения, ключ авторизации генерируется заново. Нулевой идентификатор ключа (zero key identifier) означает, что шифрование не было использовано, что разрешено для ограниченного набора типов сообщений, используемых во время регистрации для генерации ключа авторизации, основанного на обмене Диффи-Хеллмана.

Сессия

(Рандомное) 64-битное число, сгенерированное клиентом для того, чтобы различать отдельные (индивидуальные) сессии (например, между разными инстанциями приложения, созданными с помощью одного и того же ключа авторизации). Сессия вместе с идентификатором ключа согласовывается с инстанцией приложения. Сервер может поддерживать состояние сессии. Ни в коем случае сообщение, предназначенное для одной сессии, не может быть отправлено в другой сессии. Сервер может в одностороннем порядке забыть любые сессии клиента; клиенты должны быть способны справиться с этим.

Соль сервера (Server Salt)

(Рандомное) 64-битное число, периодически (например, каждые 24 часа) изменяемое (отдельно для каждой сессии) по запросу сервера. Все последующие сообщения должны содержать новый salt (хотя, сообщения со старым salt’ом принимаются на протяжении следующих 300 секунд). Предназначается для защиты против атак повторного воспроизведения, и для определённых уловок/трюков, связанных с регулировкой часов клиента к моменту в отдалённом будущем.

Идентификатор сообщения (msg_id)

(Зависимое от времени) 64-битное число, используемое для того, чтобы уникально идентифицировать сообщение внутри сессии. Идентификаторы сообщения клиента кратны четырём (делятся на 4), остаток от деления идентификатора сообщения сервера на 4 приравнивается к 1 если сообщение является ответом на сообщение клиента, и к трём в остальных случаях. Идентификаторы сообщения клиента должны увеличиваться монотонно (внутри одной сессии), так же как идентификаторы сообщений сервера, и должны примерно равняться unixtime*2^32. Таким образом, идентификатор сообщения указывает на приблизительный момент времени, в который сообщение было создано. Сообщение отклоняется через 300 секунд после того, как оно было создано, или за 30 секунд до того как оно будет создано (это необходимо для защиты против атак повторного воспроизведения). В этой ситуации, оно должно быть отправлено заново с другим идентификатором (или помещено в контейнер с более высоким идентификатором). Идентификатор контейнера сообщений обязательно должен быть больше, чем идентификатор вложенных в него сообщений.

Важно: чтобы противостоять атакам повторного воспроизведения, нижние 32 бита msg_id переданные клиентом, должны быть не пустые и должны представлять собой дробную часть от момента времени, в который было создано сообщение. Довольно быстро сервер начнёт игнорировать сообщения, в которых нижние 32 бита msg_id содержат слишком много нулей.

Сообщение, связанное с контентом

Сообщение, требующее точного подтверждения. Это включает все сообщения юзера и многие из сообщений сервера, фактически все, кроме контейнеров и подтверждений.

Порядковый номер сообщения (msg_seqno)

32-битное число, равное двойному числу «связанных с контентом» сообщений (которые требуют подтверждения, и в частности те, которые не являются контейнерами) созданных отправителем до этого сообщения и впоследствии увеличивающееся на один если текущее сообщение является сообщением, связанным с контентом. Контейнер всегда генерируется после того, как генерируется то, что он содержит; таким образом, его порядковый номер больше либо равен порядковым номерам сообщения, содержащимся в нём.

Ключ сообщения

128 бит нижнего порядка хеша SHA1 части сообщения, которая будет зашифрована (включая внутренний заголовок и исключая байты выравнивания данных).

Внутренний (криптографический) заголовок

Заголовок (16 байт), добавляемый перед сообщением или контейнером до того, как они все вместе будут зашифрованы. Состоит из соли сервера (64 бита) и сессии (64 бита).

Внешний (криптографический) заголовок

Заголовок (24 байта), добавляемый перед зашифрованным сообщением или контейнером. Состоит из идентификатора ключа (64 бита) и ключа сообщения (128 бит).

Payload (полезная нагрузка)

Внешний заголовок + зашифрованное сообщение или контейнер.

Определение ключа AES и вектора инициализации

2048-битный ключ авторизации ( auth_key ) и 128-битный ключ сообщения ( msg_key ) используются для вычисления 256-битного ключа AES ( aes_key ) и 256-битного вектора инициализации ( aes_iv ), которые в дальнейшем используются, чтобы зашифровать часть сообщения, которая должна быть зашифрована (то есть всё за исключением внешнего заголовка, который добавляется позднее) с AES-256 в режиме расширения неопределённого искажения (infinite garble extension, IGE).

Алгоритм для вычисления aes_key и aes_iv из auth_key and msg_key таков:

Где x = 0 для сообщений передаваемых от клиента к серверу и x = 8 для сообщений от сервера клиенту.

1024 бита нижнего порядка auth_key не включены в вычисление. Они могут (вместе с оставшимися битами или отдельно) использоваться на девайсе клиента для шифрования локальной копии данных, полученных от сервера. 512 бит нижнего порядка auth_key не хранятся на сервере; следовательно, если девайс клиента использует их, чтобы зашифровать локальные данные, и если юзер теряет ключ или пароль, расшифровка локальных данных невозможна (даже если могут быть получены данные с сервера).

Когда AES используется для шифровки блока данных длиной, не делимой по 16 байт, данные подбиваются рандомными байтами до минимальной длины, делимой по 16 байт, непосредственно перед тем как будут зашифрованы.

Важные тесты

Когда зашифрованное сообщение получено, должно быть проверено, что msg_key фактически равен 128 битам нижнего порядка хэша SHA1 от предварительно зашифрованной порции, и что msg_id имеет чётный результат для сообщений от клиента к серверу, и нечётный — для сообщений от сервера к клиенту.

Примечание переводчика: имеется в виду бит чётности. Вычисляется сложением по модулю 2, результат 0 считается чётным, результат 1 — нечётным.

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

Дополнительно, значения msg_id , относящиеся ко времени более 30 секунд в будущем и более 300 секунд в прошлом, игнорируются. Это особенно важно для сервера. Для клиента это также будет полезным (для защиты от атаки повторного воспроизведения), но только если он его настройки времени точны (например, если его время было синхронизировано с временем сервера).

Определённые сервисные сообщения «от клиента к серверу», содержащие данные, отправленные клиентом серверу (например, msg_id последнего запроса клиента) могут, тем не менее, быть обработаны на/в клиенте даже если время «неправильное». Это особенно верно для сообщений, которые меняют сервер-salt и уведомлений о неправильных настройках времени у клиента. См. мобильный протокол: сервисные сообщения.

Сохранение ключа авторизации на клиенте

Юзерам, заботящимся о безопасности, может быть предложено защитить паролем ключ авторизации — примерно таким же способом как в ssh. Это достигается добавлением SHA1 ключа впереди ключа, после чего вся строка шифруется с использованием AES в режиме CBC и ключа, равного юзерскому (текстовому) паролю. Когда юзер вводит пароль, сохранённый защищённый пароль расшифровывается и проверяется сравнением с SHA1. С точки зрения юзера, это практически то же самое, что и использования пароля вебсайта или приложения.

Незашифрованные сообщения

Специальные только-текстовые сообщения могут быть использованы для создания ключа авторизации, также как для выполнения синхронизации времени. Они начинаются с auth_key_id = 0 (64 бита), что означает что здесь нет auth_key . За этим следует непосредственно тело сообщения в сериализованном формате без внутреннего и внешнего заголовка. Идентификатор сообщения (64 бита) и длина тела в байтах (32 байта) добавляются до тела сообщения.

Только очень ограниченное количество сообщений определённых типов могут быть переданы как только-текстовые.

Добавить комментарий

Ваш адрес email не будет опубликован.