Хакер {Hacker}
Канал о кибербезопасности - Защита - Кодинг - Новости - Интервью - Безопасность в сети По всем вопросам @evgenycarter РКН clck.ru/3KoG7p
Больше📈 Аналитический обзор Telegram-канала Хакер {Hacker}
Канал Хакер {Hacker} (@thehaking) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 13 309 подписчиков, занимая 9 471 место в категории Технологии и приложения и 49 272 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 13 309 подписчиков.
Согласно последним данным от 26 июля, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -46, а за последние 24 часа — -2, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 12.03%. В первые 24 часа после публикации контент обычно набирает 4.93% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 1 601 просмотров. В течение первых суток публикация набирает 656 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 7.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как программист, linux, программирование, c++, ядро.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Канал о кибербезопасности
- Защита
- Кодинг
- Новости
- Интервью
- Безопасность в сети
По всем вопросам @evgenycarter
РКН clck.ru/3KoG7p”
Благодаря высокой частоте обновлений (последние данные получены 27 июля, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
Compatible-with-StealthPalace).
🔗 Подробнее https://maorsabag.github.io/posts/adaptix-stealthpalace/sleeping-beauty/
#RedTeam #MalwareDev #EDREvasion #SleepObfuscation #AdaptixC2 #CyberSecurity
📲 Мы в MAX
👉@thehakingpipe_buffer так любят исследователи безопасности Linux
Александр Попов опубликовал интересные результаты экспериментов с объектом ядра Linux pipe_buffer - одной из самых мощных целей при эксплуатации уязвимостей ядра.
Почему он так интересен атакующему? Повреждение отдельных полей pipe_buffer потенциально позволяет:
🔸 реализовать техники вроде Dirty Pipe и изменять файлы только для чтения;
🔸 перехватывать управление в kernel space;
🔸 строить примитивы Arbitrary Address Read/Write;
🔸 использовать техники вроде PageJack.
В ходе экспериментов автор обнаружил несколько любопытных особенностей.
Например, после достижения лимита /proc/sys/fs/pipe-user-pages-soft ядро начинает создавать новые pipe с уменьшенным буфером. Это может неожиданно повлиять на heap spray и размещение объектов в slab-кешах.
Ещё интереснее другое: оказалось, что для получения примитива чтения и записи памяти ядра может быть достаточно повредить только указатель pipe_buffer.page. Причина кроется в механизме кеширования освобождённых страниц через pipe_inode_info.tmp_page.
Есть и неприятный побочный эффект: закрытие повреждённого pipe может вернуть атакованную страницу аллокатору страниц, что приведёт к непредсказуемому повреждению памяти ядра. Практичное решение из PoC - просто не закрывать такой pipe 😁
Отличный материал для тех, кто изучает Linux Kernel Exploitation, устройство slab allocator и внутреннюю механику pipe.
https://a13xp0p0v.github.io/2026/04/20/pipe-buffer-experiments.html
📲 Мы в MAX
👉@thehakingFrameState.
• Когда спекулятивные предположения компилятора о типах нарушаются в рантайме, ожидаемой деоптимизации (lazy deopt) не происходит.
• В результате оптимизированный машинный код продолжает оперировать объектами с совершенно неверным layout'ом памяти.
💥 К чему это приводит:
Обычно для полноценного RCE и побега из песочницы требуется целая цепочка эксплоитов. Longinus уникален тем, что справляется в одиночку:
1. Дает 100% надежный примитив произвольного чтения/записи (arbitrary read/write) внутри песочницы V8 без использования хитрых техник вроде heap spraying.
2. Позволяет "сбежать" из V8 sandbox и писать в память за его пределами, что обеспечивает RCE в процессе рендерера.
В репозитории исследователей даже доступен рабочий PoC эксплоита. Это просто отличный кейс для тех, кто увлекается анализом уязвимостей, малварью и устройством современных браузерных движков.
🔗 Полный технический разбор и детали эксплоита: https://nebusec.ai/research/v8-cve-2026-6307-writeup/?p
📲 Мы в MAX
👉@thehakingadb shell до root.
В чем суть атаки?
Внутри приставки стоит 4-ядерный чип Mediatek MT8696 (Cortex-A55, 1.8 ГГц). Ребята написали эксплойт, который в бесконечном цикле пытается выполнить системный вызов setresuid(0, 0, 0) от имени непривилегированного пользователя shell (uid 2000). В нормальных условиях ядро (здесь используется дефолтный Android GKI) блокирует этот запрос на этапе проверки ns_capable_setid().
Но в дело вступает физика: вплотную к вскрытому чипу разместили EMFI-зонд, который асинхронно «бомбардировал» процессор мощными электромагнитными импульсами. Один удачный импульс физически искажает инструкцию условного перехода прямо в процессоре. В результате ядро проскакивает проверку прав, вызывает функцию commit_creds() и выдает процессу uid = 0. После этого эксплойт успешно поднимает telnetd с рутовым доступом.
🛡 Defense-in-depth в действии
Самое интересное: на этом взлом не заканчивается. Несмотря на получение uid = 0, эшелонированная защита Android отработала отлично. Процесс остался заперт в жестком контексте SELinux (u:r:shell:s0 в режиме Enforcing). Читать память ядра или критичные разделы eMMC все еще нельзя. Для полного захвата устройства (Full Device Compromise) потребуется еще один аппаратный глитч или софтверный эксплойт для обхода SELinux.
Ключевые выводы:
🔹 Аппаратный глитчинг можно успешно проводить прямо на работающей ОС (не уходя в bootloader), даже на современных чипах с частотой 1.8 ГГц.
🔹 Искажения всего одной инструкции достаточно, чтобы полностью сломать программную модель безопасности.
🔹 В качестве бонуса — аналогичным методом исследователям удалось обойти проверку check_syslog_permissions и слить дамп syslog из закрытой области ядра.
🔗 Читать технический разбор в оригинале: https://raelize.com/blog/setresuid-glitching-google-tv-streamer-from-adb-to-root/
📲 Мы в MAX
👉@thehakingSYSHUB (часть шины передачи данных) и принудительно выставить атрибут NoSnoop для всех обращений PSP к памяти. Из-за этого PSP начинает читать и писать данные напрямую в DRAM, игнорируя более актуальные данные, осевшие в кэшах x86.
Это создает «рассинхронизацию» (split memory view):
1. PSP читает из DRAM старые данные.
2. Данные, которые PSP записывает в DRAM, могут быть тихо перезаписаны при сбросе (вытеснении) кэша x86.
Используя этот баг, злонамеренный гипервизор может подделать Guest Context Page - защищенную структуру, в которой хранятся отчеты об аттестации и политики гостевой ОС. Это позволяет активировать режим отладки на боевой виртуальной машине и получить полный доступ на чтение и запись ко всей конфиденциальной памяти CVM. Защита SEV-SNP полностью падает.
💡 Главные факты об атаке:
• Тип: 100% программная (software-only) с вероятностью успеха 100%. Физический доступ к серверу не нужен.
• Уязвимое железо: Серверные процессоры AMD EPYC на архитектурах Zen 4 и Zen 5.
• Влияние на конкурентов: Intel TDX и Arm CCA атаке не подвержены, так как не используют выделенный сопроцессор вроде PSP в качестве корня доверия.
• Семейство XCA: Staleus относится к классу Interconnect Corruption Attacks (как и прошлые атаки Fabricked и BreakFAST), но использует принципиально новый вектор — не перенаправление трафика, а манипуляцию атрибутами кэша.
AMD уже признала проблему и выпустила соответствующий бюллетень безопасности.
🔗 Читать подробнее (Whitepaper & FAQ): https://xca-attacks.github.io/staleus/
📲 Мы в MAX
👉@thehaking