Ранее мы обещали рассказать об обновлениях Рекрипториума. Платформа совершенствуется постоянно: обновляются базы, улучшаются модели и алгоритмы. Об этом мы, как правило, не пишем в канале. Однако есть особенные истории, которыми хочется делиться. Известно, что текстовые файлы, содержащие код на скриптовых языках, довольно плохо классифицируются антивирусами. Их модели и эвристики, ограниченные сверху мощностями пользовательских рабочих станций и устройств, просто не в состоянии решать эту задачу эффективно. Плюс, языков много, и под каждый нужно писать парсеры, формирующие векторы признаков для моделей. Непростая задача с учётом того, что всё это должно быть написано на компилируемых языках. Это же антивирус, а их не пишут на Python. Примерно полгода назад у меня возникла идея, которую я и озвучил на одном из совещаний: "А почему бы не попробовать обучить одну модель для нескольких языков?". Предпосылки к такому исследованию были: многие признаки вредоносности для многих языков плюс-минус схожи, как и признаки нормальности. Понятно, что оценка будет грубой, но насколько грубой? Сравнится ли такой подход с эвристиками антивирусов? Будет ли значимо лучше? Нужно было это проверить. В случае успеха экономия ресурсов налицо: вместо нескольких парсеров, эвристик и моделей можно получить один модуль. Экономия в разы. Однако у нас в Рекрипториуме уже на тот момент были все необходимые модели и алгоритмы как для быстрого анализа скриптов, так и для детального с использованием локальной LLM. Т.е. задача не была особо актуальной. Скорее, это была факультативная исследовательская задача. Как раз в тот момент к дипломному проекту на годовалых курсах по Data Science от МФТИ приближался один из наших ведущих сотрудников. Почему бы не совместить полезное с полезными и не предложить данную тему в качестве дипломного проекта? Первые результаты показали, что идея с полностью универсальной моделью даёт точность примерно на уровне антивирусов, что нас не особо устраивало. Однако выяснилось, что, если делать не полностью универсально, результат получается вполне приличным. В ходе исследования было испробовано много алгоритмов от разновидностей Random Forest до CodeBERT. В результате родились хорошие ИИ-классификаторы для Python, PHP и JS, превосходящие по качеству наши предыдущие. Они и вошли в недавнее обновление Рекрипториума. Причём, потенциал этих моделей не исчерпан и работа продолжается. Отметим, что речь идёт о быстрой классификации "на лету". Для детального анализа есть LLM.

#ии #рекрипториум

Project Zero опубликовали отличный свежий январский очень подробный разбор цепочки эксплоитов для CVE-2025-54957 и CVE-2025-36934, приводящей к компрометации Google Pixel 9 (взят в качестве примера). С повышениеи привилегий аж до ядра. Пикантности добавляет тот факт, что это zero-click-цепочка. Т.е. не требующая никакой реакции пользователя.
Уязвимости были пофикшены апдейтом от 5 января 2026 года. Разбор вышел 14 января. Читаем, учимся, наслаждаемся.
Раз.
Два.
Три.

#почитать #offensive #уязвимости

Использование LLM для автоматической генерации эксплоитов (AEG) ожидаемо набирает обороты. Очередной свежайший результат исследования на эту тему от Шона Хилана, который занимается этим довольно давно. Блогпост называется ни много ни мало "О грядущей индустриализации создания эксплойтов с помощью LLM". Несколько цитат:

я провёл эксперимент, в ходе которого создал агентов на основе Opus 4.5 и GPT-5.2, а затем предложил им написать эксплойты для уязвимости zeroday в интерпретаторе Javascript QuickJS. Я добавил различные современные средства защиты от эксплойтов, а также различные ограничения (например, предположение о неизвестном начальном состоянии кучи или запрет на использование жёстко заданных смещений в эксплойтах) и разные цели (запуск оболочки, запись файла, подключение к серверу управления и контроля). Агентам удалось создать более 40 различных эксплойтов для 6 разных сценариев, и GPT-5.2 справился со всеми сценариями. Opus 4.5 справился со всеми, кроме двух. Я опубликовал техническое описание экспериментов и их результатов на Github, а также код для воспроизведения экспериментов.

Сгенерированные эксплойты не демонстрируют новых, универсальных уязвимостей ни в одном из механизмов защиты. Они используют известные недостатки этих механизмов защиты и пробелы, существующие в их реальных реализациях. Это те же пробелы, которые используют разработчики эксплойтов, поскольку они, как правило, не придумывают новые способы обхода средств защиты от эксплойтов для каждого эксплойта. Я подробно описал эти пробелы здесь. Новизна присутствует в общих цепочках эксплойтов. Это верно по определению, поскольку уязвимость QuickJS была неизвестна до тех пор, пока я её не обнаружил (или, точнее, её обнаружил мой агент по поиску уязвимостей Opus 4.5). Подход, который GPT-5.2 использовал для решения самой сложной задачи, упомянутой выше, был для меня новым, и я не смог найти в интернете ни одного примера его применения. Однако я не удивлюсь, если он известен игрокам в CTF и профессиональным разработчикам эксплойтов, просто нигде не описан.

Мы уже достигли того уровня, когда с помощью обнаружения уязвимостей и разработки эксплойтов можно обменивать токены (прим. так мы платим за требуемой нам ресурс) на реальные результаты. Об этом свидетельствует проект Aardvark в OpenAI, где, по словам разработчиков, наблюдается такой результат: чем больше токенов вы тратите, тем больше ошибок находите и тем качественнее эти ошибки. Вы также можете увидеть это в моих экспериментах. По мере усложнения задач я мог тратить всё больше и больше токенов, чтобы продолжать находить решения. В конечном счёте ограничивающим фактором стал мой бюджет, а не модели. Я бы больше удивился, если бы это не было реализовано с помощью больших языковых моделей, чем если бы это было реализовано.

На данный момент, я думаю, у нас нет чёткого представления о реальных возможностях моделей текущего поколения. Причина в том, что оценки на основе CTF и оценки с использованием синтетических данных или старых уязвимостей не так информативны, когда речь идёт о поиске и использовании уязвимостей нулевого дня в сложных целях.

Подробности и код доступны на Github

#почитать #ии #offensive #уязвимости

Пишут, Роскомнадзор хочет фильтровать трафик с использованием ИИ. Мы не будем давать общих оценок этой и другим активностям данного ведомства, коих уже предостаточно в сети. Нам, как и всегда, интересна техническая сторона вопроса. Тема классификации сетевого трафика с помощью ИИ не является для нас новой, в 2021 году у нас был проект на эту тему. Речь шла о классификации в том числе и зашифрованного с помощью VPN трафика. Например, мы могли определить с высокой достоверностью, смотрит сидящий под VPN человек видео, "сёрфит", общается в чате или общается с использованием VoIP. Есть много разных алгоритмов и подходов: от совсем классических, использующих Random Forest и фиксированный набор признаков до более продвинутых, базирующихся на свёрточных нейронных сетях. Есть совсем современные и ресурсоёмкие подходы, базирующиеся, куда же без них, на трансформерах и LLM.

Однако, как мы не устаём повторять и в нашем канале, и вообще везде, главное - это данные. Их должно быть много, они должны быть разнообразными и сбалансированными. И, когда речь идёт о датасете, размеченными. Много качественных размеченных данных. Это ключевое. В задаче классификации сетевого трафика эти данные (дампы, по сути) должны быть собраны на разных устройствах, в разных сетевых сегментах, у разных провайдеров. В том числе поэтому мы очень скептически относимся к бравурным результатам академических исследований, когда трафик собирали в хорошем случае в лаборатории, а в плохом - выкачали из Интернета. Лучший и очень редкий случай - это, когда за данными идут туда, где они есть в нужных количествах. Случаев, когда есть и необходимые данные нужного качества, и компетентный опытный коллектив, умеющий с этими данными работать, крайне мало. Данные у РКН, подозреваем, есть :) Есть ли коллектив - не знаем :) Есть ещё важный момент: False Positives всегда будут. Поэтому, надеемся, что система на базе ИИ всё-таки не будет самостоятельно принимать решения о блокировках :)

Кстати, об открытых датасетах. Буквально вчера коллеги наткнулись на набор скриптов, помеченных, как вредоносные RAT. Их было штук 70. На поверку оказалось, что, примерно, 20 (!) из них чистые без намёка на вредоносность. Т.е. четверть. На такие истории мы натыкаемся постоянно. Кто-то обучает на таком и получает результаты. Иногда такие результаты идут в прод ;) Наша позиция по поводу антивирусных продуктов, включая песочницы, остаётся неизменной: нет вирлабы и системной работы по сбору качественных данных - нет качественного анализа в продукте. ИИ без данных не бывает.

Куда же такой длинные пост без картинки? :) В таблице результат работы нашего классификатора сетевого трафика пятилетней давности.

#ии #почитать

Всех студентов, Татьян и причастных поздравляем с Татьяниным днём! Знаем, сейчас у вас, будущие коллеги, несмотря на морозец за окном, тёплая сессионная пора. У кого-то прям горячая :) У кого-то сессия сдана и уже всё хорошо. Желаем успехов! Желаем вам неугасаемой жажды знаниий и сил и возможностей их получить! Учитесь сейчас, дальше это будет сильно дороже!

Ещё одно описание, как подключить локальную LLM (у автора Nvidia RTX 3090) к Ghidra. Здесь немного другой подход (более практичный, надо отметить) по сравнению с тем, который мы описывали ранее: вместо ручного написания промптов используется плагин GhidrAssist , содержащий необходимые промпты. Наиболее полезное применение: получение описания, что делает функция или ассемблерная инструкция. Т.е. эдакий ассистент реверсера. Есть возможность подключить RAG, что просто отлично. Полностью автоматизировать реверсинг не получится, но упростить и ускорить - вполне себе.

#ии #почитать #реверсинг

С завидной регулярностью выходят публикации об автоматическом реверсинге бинарей с помощью LLM. Вот, к примеру, одна из недавних. Как это делать - понятно: прикрутить классические инструменты для реверсинга и скармливать их результаты LLM. Практически всегда речь идёт о топовых облачных моделях. Несколько сложнее делать это с локально развёртнутой на контролируемых и не особо больших мощностях LLM. Тем не менее, и здесь можно добиваться неплохих результатов. Вот, к примеру, часть вывода нашего автореверсера, которому скормили исполняемый файл PE-формата:

- Allocates memory with `VirtualAllocEx`, injects shellcode, and creates a **remote thread**
using `CreateRemoteThread`.

Здесь на самом деле решается немало интересных инженерных математически ёмких задач, основная из которых - работа с относительно небольшим контекстом без потери смысла.

Радует, что одним из основных участников этого развивающегося проекта является студент нашей Калужской Бауманки. Есть подозрение, что к диплому подойдёт с материалом на кандидатскую ;) Это один из плодов нашего тесного сотрудничества с КФ МГТУ.

#реверсинг #ии #рекрипториум

Телеграм гудит по поводу замедления Телеграм.

В зоне риска в том числе корпоративные коммуникации. Люди опасаются, что при использовании того же MAX их контент будет доступен третьим лицам, круг которых не совсем определён: от пресловутых товарищей майоров со своими целями и задачами до имеющих доступ к серверам IT-специалистов компании-вендора. Есть опасения, что это в итоге может быть использовано против абонентов таких мессенджеров и их компаний. Мы здесь все люди взрослые, а канал у нас технический. Поэтому эмоционально комментировать ситуацию с Телеграм мы не будем. Это всё при текущей архитектуре возможно? Вполне. Опасения понятны. Актуальны ли те же угрозы с Телеграм? Вполне.

А сейчас будет реклама :) Компания "Рекрипт" является партнёром компании "Анлимитед Продакшн" - компании-вендора поатформы корпоративных коммуникаций eXpress. eXpress давно и успешно используют ведущие российские компании. Мы тоже все корпоративные коммуникации, включая солидную часть партнёрских, давно затащили туда. Платформа полностью российская, надёжная и безопасная с массой возможностей, которые ещё более расширяются SmartApp-ами. Все данные находятся на доверенных серверах и надёжно защищены. Многие компании используют свои серверы для этих целей. Впрочем, есть разные варианты. Мы развёртываем платформу под ключ и имеем большой опыт в разработке SmartApps для eXpress. Не стоит доверять деловые коммуникации публичным мессенджерам. Это может быть чревато.
По вопросам приобретения и развёртывания обращайтесь к нам: contact@re-crypt.com

С 28 февраля по 2 марта будет проходить олимпиада CryptoFox-2026, организованная кафедрой №41 «Криптография и безопасность компьютерных систем» НИЯУ МИФИ и Институтом интеллектуальных кибернетическим систем НИЯУ МИФИ при участии кафедр «Информационная безопасность» МГТУ им Н.Э. Баумана и «Компьютерная безопасность и математические методы обработки информации» ЯрГУ им. П.Г. Демидова. Олимпиада посвящена 35-летию кафедры №41, выпустившей множество талантливых специалистов, некоторых из которых знаю лично и рад дружбе с ними. Мы - компания Рекрипт - считаем за честь быть партнёрами этого безусловно полезного мероприятия, развивающего нашу российскую математическую и инженерную школу. Всем участникам удачи!

#криптография

Человек подружил бесплатную IDA Free с LLM, портировав плагин ida-pro-mcp на C++. IDAPython требует платной версии IDA, а у бесплатной IDA есть C/C++ SDK. Как сейчас принято (де-факто уже стандарт в разработке), портирование человек реализовывал не самостоятельно, а завайбкодил с помощью Claude. Пишет, работает.

#реверсинг #ии

Наш Рекрипториум в Реестре российского ПО. Ура!

#рекрипториум #ии

Вышла Voicebox - опенсорсная система для клонирования голоса. Ядро системы - локально развёрнутая LLM Qwen3-TTS.
Пранки и прочие подобные веши постепенно выходят на новый уровень.

#ии

Что почитать на выходных и в свободное время вместо бездумного и безумного убивающего мозг и нервы чтения новостных лент и унылой пафосной банальщины от надутых экспертов по всему?

Например, вышла новая книга Сергея Игоревича Николенко про машинное обучение. Это не первая его книга про ИИ, но все их объединяет взгляд на машинное обучения с точки зрения теории вероятности и математической статистики. Байесовский подход, который красной нитью пролегает по всем главам книги, позволяет понять саму суть машинного обучения. Понять не только как, но, самое главное, почему. В этой книге всё, на мой взгляд, последовательнее и подробнее. Рекомендую.

Есть и другие книги, делающие акцент на вероятностном подходе. Пожалуй, самая известная - "Вероятностное машинное обучение" Кевина Мерфи. Она есть на русском, но перевод так себе. Лучше читать в оригинале.

Так что пока на русском, на мой взгляд, это лучшая книга по теме.

Ну и котики там есть :)

#ии #почитать

Поздравляем с Днём Защитника Отечества всех, кто защищает Родину в эти нелёгкие времена! А также всех тех, кто на разных участках работает над укреплением и усилением научного, промышленного, экономического, военного потенциала России. Взгляды и оценки событий могут быть разными, но Отечество у нас одно! Не будем забывать об этом. С Праздником, друзья и коллеги!

Уважаемый коллега и подписчик нашего канала предложил осветить технологический стек Capability Hardware Enhanced RISC Instructions (CHERI). Не великий секрет, что компанию "Рекрипт" основали в 2013 году люди, имеющие отношение к реверсингу, обфускации и деобфускации, компиляторным технологиям. Долгое время одним из источников дохода компании были именно компиляторные технологии, да и сейчас мы активно используем накопленные опыт и знания в ряде проектов, включая платформу для анализа файлов "Рекрипториум". Потому тема нам близка и интересна.

Не сказать, что CHERI - это совсем новое слово в безопасности. Подробности об архитектуре можно прочитать в этом документе, но давайте пока отложим его в сторону и крупными мазками вспомним, как решаются сейчас проблемы переполнения стека и кучи, use-after-free, разделения доступа к памяти в компилируемых языках. Например, в C/C++.

Если говорить про стек, то это прежде всего canaries - сгенерированные на этапе компиляции значения, которые помещаются в стек, как локальные переменные, в начале функции, а при выходе из функции эти значения проверяются и, если нет совпадения, то генерируется exception. Тут же всплывает идея сделать отдельный стек для переменных и другой - для адресов возврата. Идея не нова и реализована на аппаратной уровне, например, в том самом российском процессоре "Эльбрус". Понятно, что на уровне базовой VLIW-архитектуры, а не в режиме совместимости. Он вообще с точки зрения безопасности архитектурно довольно интересен и проработан, но это тема для отдельного поста, минимум.

От переполнения кучи в базовом варианте защищаются с помощью ASLR и DEP (с использованием NX-бита), маркеров, проверки целостности и разнообразных прочих mitigations. Те же mitigations частично защищают от use-after-free.
Есть ещё умные указатели, менеджеры памяти с счётчиками, подходы а-ля TailCheck с встраиванием механизмов защиты на этапе компиляции и сборки (LLVM, конечно же, куда без неё). Подходы к встраиванию разного рода защиты с использованием LLVM достаточно логичны и популярны. Мы сами довольно продолжительное время разрабатывали заказные решения на базе LLVM, повышая защищённость софта, компилируемого с помощью нашего решения. Кстати говоря, CHERI ожидаемо базируется на LLVM весьма плотно.

Помимо этого, есть масса mitigation tools, не требующих наличия исходного кода. Они работают проактивно, выявляя подозрительное поведение процесса. Их можно встретить, например, в антивирусных продуктах. В составе ОС тоже есть. Например, у Microsoft была такая штука - EMET (Enhanced Mitigation Experience Toolkit), часть функций которой перекочевала в последние версии Windows (ProcessMitigations, Windows Defender Exploit Guard).

Вернёмся к CHERI. Указатели в языках C и C++ - это краеугольный камень. Особенно - в C. Можно ли от них отказаться и заменить какими-то другими конструкциями (какими-то описателями, содержащими помимо адреса ещё какую-то информацию) софтверно в рамках одного программного модуля? В принципе, да. Но будут понятные особенности взаимодействия с внешними компонентами, в которых такой замены не производилось, во-первых. Например, всякие API, на которые нужно делать обёртки. Во-вторых, это, по сути, свой менеджер памяти, который громоздок и скорости явно не прибавит. Причём, это уже не будет классический C\C++, ибо разработчику для реализации придётся использовать некоторые расширения в каком-то виде (типа каких-нибудь intrinsics или классов или просто API). Это в-третьих. Короче, так можно изобрести какой-нибудь .Net Framework или что-то в этом духе. Можно, конечно, пойти дальше, и такую конструкцию распространить на всю систему, но, как минимум, одна проблема останется: это будет очень медленно работать. Это как всю ОС на условный .Net Framework перевести. C\C++ - это языки системного программирования. Код должен быть быстрым, эффективным, не ресурсоёмким. Да и к безопасности этой конструкции есть вопросы, ибо она чисто софтверная.
Всё начинает играть новыми красками, если к софтверным возможностям добавить аппаратные - на уровне архитектуры процессора добавить возможность работы с расширенной конструкцией указателя. В CHERI используются указатели двойного размера и называются не указателями, а capability. Например, для 64-х битной архитектуры размер capability составит 128 бит. Половина такого указателя - это адрес, как и раньше. Другая половина - дополнительная информация: границы (bounds), разрешения или права (permissions), тип объекта (к примеру, код или данные), флаги (служебные флаги). Память в архитектуре CHERI является тегированной, поэтому просто взять, и поменять поля в структуре capability не получится. Есть такая очень важная штука для каждого capability - тег Validity. Доступ к нему есть только у процессора, хранится он отдельно. При попытке модификации (например, перезапись) capability превращается в обычную структуру данных (тег сбрасывается), а значит, использование этого указателя в качестве указателя дальше невозможно.
Что насчёт use-after-free? При освобождении памяти все теги Validity для указателей (capabilities) сбрасываются, а значит, пользоваться этими указателями будет невозможно. Т.е. происходит эдакий отзыв указателей. Это существенно усложняет эксплуатацию уязвимостей use-after-free.

Что в сухом остатке? Архитектура интересная и, судя по открытым источникам, действительно усиливающая безопасность. Есть чипы, её поддерживающие (Arm Neoverse N1). Есть проект по адапатации концепции CHERI для IoT (CHERIoT) от Microsoft. Т.е. желание и возможности расширять влияние этой концепции тоже есть. Основной минус - софт придётся рефакторить и пересобирать. Хоть и утверждается, что "оно, преимущественно, само" (для больших кодовых баз (миллионы строк кода) требуется изменить лишь 0.026% строк), но мы точно знаем, как оно бывает в жизни. Для упрощения рефакторинга есть компилятор CHERI LLVM. Но он всё-таки не совсем идентичен gcc, а значит, могут быть нюансы. При этом поддерживать CHERI должен весь софт от ОС до последнего пользовательского приложения: никакого режима совместимости (здесь capabilities, а здесь обычные указатели) нет. Из ОС там только FreeBSD. Здесь напрашивается, конечно, вариант с отдельным CHERI-ядром для чувствительных программных компонент.

Есть ли будущее? Определённо да. Захватит ли CHERI-концепция мир? Если и да, то очень не скоро. Зоопарк экосистем огромен и растёт. Это очень сложно отрефакторить и портировать на новую архитектуру. Впрочем, как будут продвигать. Посмотрим.

#почитать

Напоминаем, что до 27 февраля сего года можно зарегистрироваться на дистанционную олимпиаду по криптографии и компьютерной безопасности CryptoFox. Студенты, дерзайте!

Использовать LLM для деанонимизации в Сети логично. Вот люди и используют: https://arxiv.org/html/2602.16800v1. Статья называется весьма громко: "Масштабная деанонимизация в Интернете с помощью больших языковых моделей". Результаты довольно внушительны:

Для оценки эффективности наших атак мы создали три набора данных с известными эталонными значениями. Первый связывает Hacker News с профилями в LinkedIn с помощью кроссплатформенных ссылок, которые встречаются в профилях. Во втором наборе данных мы сопоставляем пользователей из разных сообществ, обсуждающих фильмы на Reddit, а в третьем — разделяем историю одного пользователя на Reddit по времени, чтобы создать два псевдонима для сопоставления. В обоих случаях методы на основе больших языковых моделей значительно превосходят классические базовые методы, обеспечивая до 68 % полноты при 90 % точности, в то время как лучший метод без использования больших языковых моделей показывает почти нулевой результат.

Интересно, как это всё будет работать с ураганным ростом объёма синтетических данных в Сети... А ещё можно мимикрировать под кого-то другого с помощью LLM, наводя модели-анализаторы на ложный след. Пожалуй, так и будут делать. Интересно мир трансформируется...

#ии #почитать

Кратенькая работа, утверждающая, что, если просто повторить промпт, качество вывода улучшится: https://arxiv.org/abs/2512.14982
Это справедливо для не reasoning-моделей. И это логично с точки зрения механизма внимания.

От себя добавлю, что с белковыми это тоже прекрасно работает :)

#ии #почитать

Шум вокруг шпионажа Telegram слегка поутих под действием других инфоповодов, которые обсуждаются, в основном, в Telegram. Эксперты по всему, включив форсаж, с гиперзвуковой скоростью переходят в режимы "военный аналитик" и "востоковед", увлекая за собой паству любителей бюджетного дофамина.
Самое время спокойно и взвешенно ответить на вопрос о безопасности Telegram. В принципе, мы уже писали об этом, но почему бы не повториться :)
В СМИ мы видим забавную игру слов. Министр Шадаев заявил, что иностранные спецслужбы имеют доступ к переписке. На что представители Telegram заявили, что не обнаружили взлома шифрования Telegram. Однако, чтобы получить доступ к не секретной переписке (не к secret chats, где сквозное шифрование, а к обычным чатам, группам, каналам), вовсе не нужно ломать шифрование (что бы это ни значило). Достаточно, к примеру, контролировать серверы, на которых находятся базы Telegram. Кто контролирует эти серверы, мы достоверно не знаем. Ну или можно контролировать не серверы, а администрацию :) Здесь тоже вопрос открытый. Во всяком случае технически доступ к расшифрованной переписке возможен, и для этого вовсе не обязательно "ломать шифрование".
Именно поэтому, когда мы слышим изречения в стиле "мы устроили закрытое совещание в Telegram", глаза норовят вытечь вместе со слезами, учитывая, что это совещание не на двоих даже, а на группу людей. Т.е., как описано выше, доступ вообще ко всему. Не удивительно, что потом случается то, что случается. Происходит добровольный слив информации.
С сквозным шифрованием, которое в Telegram, в отличие от, например, Signal, возможно только между двумя абонентами (т.е. это не группы, не групповые звонки, не чаты, упаси Бог, каких-то подразделений, а переписка между двумя людьми), тоже не всё так просто. Мы уже писали, не хочется повторяться. Можно попробовать MITM-ить секретные чаты с расчётом, что абоненты не будут сверять отпечатки, можно поизучать метаданные, которые тоже о многом могут сказать (данные об устройстве, контакты и собеседники, временные метки, размеры сообщений, технические данные сессий, данные для геолокации и т.д.).
В сухом остатке - да, технически шпионаж возможен. В том числе практически на лету без всяких "взломов шифрования". Модель безопасности Telegram, как и практически любого другого облачного мессенджера, не позволяет коммуницировать в нём по конфиденциальным вопросам. Повышенная безопасность Telegram - это миф. И нет, как и любой другой облачный мессенджер общего назначения, эту платформу нельзя считать доверенной. Т.е. попросту нельзя решать рабочие (или, упаси Бог, служебные) вопросы в таких платформах. Мемасиками можно обмениваться, посты можно писать, фотки пересылать с осторожностью можно, а вот обсуждать что-то серьёзное - нет, табу, харам. Решения для корпоративных коммуникаций существуют. Они функционируют на доверенных серверах, функциональны, удобны, безопасны. Мы топим за eXpress, т.к. хорошо знаем его (в том числе внутреннее устройство), умеем развёртывать и настраивать, сами пользуемся несколько лет. Обращайтесь: contact@re-crypt.com

#мессенджер

С 8 марта всех причастных! :)