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

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

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

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

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

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

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

Уважаемый коллега и подписчик нашего канала предложил осветить технологический стек 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 марта всех причастных! :)

Традиционное в этот день :)

Реверс-инженер Карстен Хан описал свой недавний опыт реверс-инжиниринга с помощью LLM. Это, как мне кажется, классика, с которой сталкиваются все, кто пытается это делать впервые, полагаясь чисто на LLM и, по всей видимости, ожидая какого-то чуда.
Например, цитата:

Вердикты — это самое худшее. Большие языковые модели часто недооценивают важность своих выводов. Это происходит из-за того, что они делают неверные предположения и поспешные выводы. Если у них есть доступ к результатам VirusTotal, они, как правило, при вынесении вердикта полагаются в основном на сканеры. В моей сфере деятельности это нежелательно, потому что мы специально получаем образцы, которые не распознаются сканерами или другими автоматизированными системами. Я мог бы частично исправить ситуацию, запретив большой языковой модели использовать результаты VirusTotal при вынесении вердикта. Но это не решило проблему ошибочных вердиктов в целом.
Требуется опытный аналитик, который будет задавать уточняющие вопросы, выявлять ошибки и направлять работу больших языковых моделей в нужное русло.
На данный момент нельзя доверять большим языковым моделям вынесение вердиктов!

Да, такое встречается практически всегда, когда пытаешься решить задачу нахрапом. В итоге у людей появляется разочарование инструментом. Чем-то напоминает критику молотка, который может попасть по пальцам.
Даже просто грамотный промпт-инжиниринг позволит значительно улучшить качество. Также необходимо использовать другой инструментарий, о чём Карстен тоже говорит.

Качество и скорость анализа значительно повышаются, если в распоряжении исследователя есть подходящие инструменты и описания того, когда и как их использовать. Поэтому со временем имеет смысл создавать навыки для конкретных типов образцов, например специальный навык для анализа JavaScript, в котором будет описано, какие инструменты лучше всего подходят для этой задачи. В противном случае языковая модель будет тратить кучу токенов, пытаясь методом проб и ошибок определить, какие инструменты подходят для каждого образца.

А ещё модели нужен опыт, который можно моделировать с помощью, например, RAG. Либо через fine-tuning.
И, по-хорошему, нужен агентский подход с LLM-агентами (которые, возможно, базируются на других LLM) для решения узкоспециализированных задач.
Нужно уменьшать контекст, расставлять приоритеты эвристикам и инструментам (включая ML), которые нужно постоянно совершенствовать. Тогда результаты автоматизации будут более достойными.

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

Хороший разбор зловреда: https://habr.com/ru/articles/1009074/
Примечательно, но уже не особо удивительно, что файлик подписан EV-сертификатом. Это уже далеко не первый случай, когда вредоносы подписываются не просто Authenticode, а EV Code Signing. Аббревиатура EV означает Extended Validation - расширенная проверка. Мы когда-то в прошлой реальности покупали такой. Расширенная проверка означает проверку существования и функционирования юрлица. Сам сертификат поставляется на USB-токене. Но, тем не менее, практика показывает, что злоумышленники идут на это. Ведь многие средства защиты до сих пор слепо полагаются на наличие подписи Authenticode. Особенно - когда речь идёт о EV. На скриншоте вердикт Рекрипториума для этого файлика.

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

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

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

Много вопросов на очных и онлайн-встречах по поводу статического анализа вредоносов. Кажется, настала пора написать об этом небольшой пост. Статический анализ - это анализ без запуска на исполнение в самом широком смысле этого определения. Многие под статическим анализом понимают что-то типа эвристических движков антивируса или простых моделек ML из тех же антивирусов. На самом деле это гораздо более широкое понятие: в него входит и дизассемблирование, и анализ логики без запуска на исполнение, да и в целом реверс-инжиниринг - это, в основном, статический анализ.
Давайте "понаблюдаем", как анализирует файл (пусть это будет PE-файл) реверс-инженер, у которого стоит одна задача: понять, вредоносный файл или нет. Сначала он смотрит основные свойства файла: тип, платформу, свойства, размеры и имена секций, их энтропию, наличие TLS-коллбэков, наличие подписи Authenticode, импорты, экспорты, оверлей и что там лежит, ресурсы и т.п. Это беглый взгляд даже без дизассемблера и декомпилятора. Чем более намётан глаз реверс-инженера, тем быстрее он даже без дизассемблирования и тщательного изучения классифицирует файл уже по этим признакам. Далее он смотрит глубже: распределение вероятностей встречающихся инструкций и их последовательностей. Хороший реверсер, например, сразу на глазок выделит обфусцированный код. Как он это делает? Опыт. Он знает статистику встречаемости инструкций и их последовательностей. Он много видел как чистых, так и вредоносных файлов. И он без погружения в изучение логики видит, что код подозрителен. То же самое с данными. Что ещё видно сразу? Строки, если они есть. По ним многое понятно без анализа логики. Ещё видно использование критпографии. Это видно либо по вызову импортируемых функций, либо по коду. Наш реверсер просто крутит мышкой код в дизассмеблере и видит подозрительные вещи. Как он это делает? Опыт, набитая рука. Тысячи параметров дают чёткую картину опытному человеку. И чем он опытнее, тем лучше без погружения непосредственно в логику он сможет классифицировать файл. Если он знает, откуда файл к нему попал, то здесь начинает играть роль априорная вероятность. В общем, интуиция, подкреплённая опытом.
Можно ли обучить ИИ делать то же самое? Вполне! Если есть миллионы разных семплов вредоносных и чистых файлов и понимание, как работает Data Science. Нет, публичные датасеты не подходят. Данные надо упорно и постоянно собирать, просеивать, классифицировать, выделять из них признаки. В общем, готовить. Это не быстро и не дёшево. Здесь нужна антивирусная лаборатория. Нет данных - нет ИИ. У нас есть и антивирусная лаборатория, и миллионы семплов, и специалисты Data Science, и, как следствие, Рекрипториум.
Чем мощнее оборудование, на котором работает ИИ, тем более продвинутые модели могут там работать. Это и есть основное ограничение антивирусов. Они созданы для работы на хостах, а значит, ограничены сверху весьма небольшими ресурсами. Значит, эвристики будут простыми и грубыми, а точность сильно пострадает. На подсчёт и формирование больших векторов признаков нет ресурсов. В этом проблема мультисканеров. Особенно хорошо это проявляется на файлах скриптовых языков, но и на бинарях мы это тоже прекрасно видим.
Статический анализ статическому анализу рознь.

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

16 апреля в 17.30 в рамках Недели прикладной кибербезопасности «CyberFox» расскажу о нашем опыте обучения моделей ИИ для анализа файлов. Просто скопирую анонс доклада с сайта:

Говоря об ИИ, имеем в виду данные, или почему данные важнее алгоритмов

Сейчас IT-отрасль испытывает настоящий бум от развития и повсеместного внедрения ИИ. Создатели практически каждого IT-продукта заявляют, что в нём присутствует ИИ. Не обошла эта тенденция и мир ИБ. Однако есть крайне важный вопрос, который витает в воздухе, но редко озвучивается: а где все эти люди берут столько данных, чтобы качественно обучить свои модели ИИ? Как они данные обрабатывают? Или это готовые и уже обученные открытые модели? Или модели ИИ обучаются на открытых датасетах? И насколько качественны открытые датасеты? Я расскажу о нашем опыте сбора датасетов для обучения наших ИИ-классификаторов файлов и почему сбор датасетов - это сложный и технологичный процесс. Расскажу, чем плохи открытые датасеты и почему многие из них годятся разве что для академических исследований, да и то не всегда. Расскажу, зачем нужно разрабатывать и обучать свои модели, когда "всё есть на гитхабе" и есть LLM, которые "всё умеют".

Классный курс по реверсингу от Mandiant FLARE Team . Свеженький. Налетай, а то, вдруг, забанит кто... ;)

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

Инфоцыгане и прочие эксперты по всему любят порой порассуждать про ИИ. Принимают снисходительный вид и начинают объяснять типа простыми словами для не специалистов, как они любят говорить, вворачивая какие-нибудь околонаучные или даже научные термины (обычно ни к селу - ни к городу), дабы продать свою экспертность и показать превосходство над. Вот, к примеру, есть типичный внезапный эксперт по ИИ, который рассуждает в стиле "ИИ не может выдать того, чего не знает и чему не обучался". На разных площадках на полном серьёзе об этом говорит. Новоявленного эксперта вообще не смущает, что он описывает логику обычного справочника. Про "проклятие размерности" эксперт не слышал, он стратегией занимается. Эксперта совершенно не беспокоит, что, вообще говоря, вся эта очень давняя пляска вокруг ИИ - это пляска вокруг и только вокруг обучения способности обобщать и предсказывать результат, близкий к реальному, для тех входов, которые не входили в обучающий набор. На этом всё держится и ради этого всё затевалось.Т.е. модель обучается моделировать распределение вероятности. Тот самый вероятностный подход к машинному обучению, о котором мы говорили. Если говорить о LLM, модель через, по сути, ту же базовую математику обучается моделировать в том числе и рассуждения (reasoning). Это моделирование рассуждений в сочетании агентским подходом вполне позволяет получать в том числе новые научные результаты. Так, например, было получено решение одной из проблем Эрдёша. Есть интересные результаты работы ИИ во многих отраслях: от генетики до IT-сферы. Но до сих пор мы встречаем, например, вот такие слова:

Большие языковые модели — это мощные системы распознавания образов: они изучили статистические закономерности в тексте и очень хорошо их воспроизводят.

Как отмечает нейробиолог Кристоф Кох, такие инструменты, как ChatGPT, Anthropic и Perplexity, могут лишь «пересказывать то, что написали другие». 

Или вот это:

Они вообще не «думают». Это компилятор чужих идей, искусно оформленный так, что мы воспринимаем его как нечто естественное.

Они действительно не думают в нашем понимании. Они моделируют мышление. Это модели, они так и называются. Это работает, это можно совершенствовать. Это хорошо.
Статья, откуда взяты цитаты выше: https://quillette.com/2026/03/27/ai-is-not-about-to-become-sentient-moltbook-openclaw/

Ну и чисто практическая ссылка ;) про анализ кода с помощью Claude Code: https://specterops.io/blog/2026/03/26/leveling-up-secure-code-reviews-with-claude-code/

#ии

Китайцы провели интересное исследование, в результате которого сумели улучшить вывод маленькой модели с 7 миллиардами параметров настолько, что она превзошла гораздо более обьёмные модели (в 4 раза больше параметров). Добились они этого за счёт оригинального механизма памяти. Если совсем кратко, то они в противовес традиционному подходу с RAG предлагают хранить не просто данные, а стратегии вывода - эдакие дорожные карты: не что искать, а как искать. Предлагается хранить не только "хорошие" стратегии, но и плохие - когда вывод некорректен. Таким образом, аккумулируя эти стратегии, модель обучается мыслить всё более и более качественно и корректно.
Почему это очень важно? Потому что какой-нибудь Claude, к сожалению, не лежит в кармане и всегда хочется крутых результатов на локальных моделях с как можно меньшим числом параметров.
Мой глаз зацепился за эту работу, потому что мы у себя в ходе экспериментов и
размышлений в одном из проектов пришли к чему-то подобному.
А вот и сама работа: https://arxiv.org/pdf/2604.04503

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

Неделя прикладной кибербезорасности стартовала в НИЯУ МИФИ сегодня. Кто не успел зарегистрироваться, можно это сделать, написав на почту cryptofox@mephi.ru с темой "Регистрация. Неделя кибербезопасности". В письме нужно указать ФИО, телефон, ВУЗ/место работы.

Интересное использование LLM не для непосредственно нахождения багов, а для генерации тестовых наборов для фаззинга.
Цитата:

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

#фаззинг #ии #почитать #уязвимости