ReChamo / Cybersecurity
Closed channel
[SYSTEM_KERNEL] mounted. > MOUNT_POINT: /root/rechamo > ACCESS: public (read_only) // CONTENT_MANIFEST: - reverse_engineering - malware_analysis > ADMIN: @unrezolved
Show more1 105
Subscribers
No data24 hours
+37 days
+12830 days
Posts Archive
все вы уже знаете про ring 3 (юзермод), ring 0 (ядро), ring -1 (гипервизор), ring -2 (uefi), но есть места, куда даже админы не хотят заглядывать, потому что там сидит ring -3. это intel management engine (me) или amd platform security processor (psp).
что это такое?
представь себе отдельный, крошечный комп, который впаян прямо в твою материнку. у него своя ос (чаще всего minix), свой доступ ко всей памяти, к сети, ко всему железу. он живет своей жизнью, даже когда твой основной процессор спит. назвали его "service процессором" или "security процессором", типа для блага. ага, конечно))
почему это пиздец как опасно (но и интересно):
1. полный контроль: me/psp имеет полный доступ ко всей системе. он может читать память, выполнять код, перехватывать трафик, делать все, что угодно. это как если бы кто-то сидел в твоей голове и знал все твои мысли, еще до того, как ты их озвучил.
2. невидимость: его практически невозможно обнаружить из основной ос. ни один античит, никакая защита от эксплойтов не увидит, что там происходит. ты его можешь видеть только если будешь реально ломать прошивку материнки.
3. уязвимости: даже эти "боги" не идеальны. находятся баги в их прошивках. и тогда открываются двери, которые не должны были открываться. представь, ты можешь получить полный доступ к системе, просто эксплуатировав уязвимость в железке, которая даже не должна была с тобой разговаривать.
как это используют (или могли бы):
1. абсолютная скрытность: если бы кто-то смог внедрить свой код в me/psp, он мог бы делать с компом что угодно: шпионить, стилить данные, поднимать бэкдоры, и никто бы никогда не узнал.
2. обход любых защит: любые drm, античиты, шифрования.. все это работает на уровне основной ос. а me/psp стоит над этим всем. его не волнуют твои лицензии или правила.
почему это актуально:
да потому что даже самые крутые системы защиты работают в пределах ринг 0-3 (ринг -1 тоже бывает), а тут разговор про ринг -3.
сам я еще не изучал глубоко me/psp, но это тема, которая реально завораживает. это тот самый край, где реально настоящий контроль.
привет. сегодня про то, почему ваш очень быстрый процессор это на самом деле дырявое говно по определению.
мы привыкли, что защита это софт, но spectre и meltdown доказали, что главная уязвимость зашита в самой аппаратной архитектуре.
суть в том, что современные процы слишком умные для собственного блага. чтобы не простаивать, они используют спекулятивное выполнение. процессор пытается угадать будущее, ну условно если он видит условие if, он не ждет проверки, а начинает выполнять код по наиболее вероятному пути.
если он угадал — профит, крута. но если нет, то он просто откатывает изменения. но есть нюанс.
как мы получаем доступ к данным ядра:
1. branch prediction
мы заставляем процессор "поверить", что проверка прав доступа всегда проходит успешно. мы прогоняем цикл тысячи раз с валидными данными, чтобы branch target buffer (btb) привык к этому пути.
2. спекулятивный прыжок
затем мы подсовываем невалидный адрес (из памяти ядра). процессор по инерции прыгает в ветку, где этот адрес читается. он понимает, что проебался, и откатывает состояние регистров, но (это ключевой момент) данные уже попали в кэш процессора.
3. атака по сторонним каналам
мы не можем прочитать кэш напрямую, но мы можем замерить время доступа к памяти. мы по очереди запрашиваем разные байты. если доступ к байту занял 10 циклов, значит он в кэше (это и есть наш секретный байт из ядра). если 200 циклов значит мимо. так мы вытягиваем пароли, ключи шифрования и любую инфу из памяти, к которой у юзермода доступа быть не должно.
почему это актуально?
казалось бы, все запатчено. но прикол в том, что все эти заплатки (kpti, retpoline и т.д) режут производительность на 10-20%. в погоне за фпс в играх или скоростью рендера многие оптимизаторы и геймеры просто вырубают защиту в реестре.
в итоге мы имеем кучу систем, которые ради лишних кадров в секунду открыли бэкдор для любого js скрипта в браузере 😁
привет. сегодня разберем, как сделать так, чтобы твой бинарник лежал прямо перед юзером и антивирусом, но его не нашел бы даже ебучий поиск винды
когда ты открываешь папку, ни проводник, ни антивирус не лезут на диск сами, они слишком тупые для этого. они шлют запрос в ядро. в винде общение между драйверами идет через irp (input output (i/o) request packet). это типо указания: "запиши", "прочитай", "дай список файлов" ну и т.п
чтобы стать невидимым, нам нужно вклиниться в эту переписку. лучший способ сегодня это minifilter. это драйвер фильтр, который встает в стек файловой системы прямо над драйвером диска (ntfs).
как это работает на практике:
1. перехват irp_mj_directory_control
этот пакет летит каждый раз, когда кто-то хочет узнать содержимое папки. наш фильтр ловит этот пакет, когда файловая система уже подготовила ответ, но еще не отдала его юзеру.
2. удаление
мы получаем структуру, в которой перечислены все файлы в директории. наш код просто пробегается по списку, находит там наш payload.exe и вырезает его нахуй из этой структуры.
3. профит
система передает измененный список наверх. в итоге: проводник показывает пустую папку, а никакой антивирус или едр даже не догадается просканировать файл, потому что для него его физически не существует в выдаче. байты на диске лежат, но логически файл невидимый.
почему это база:
большинство антивирусов работают на том же уровне фильтров или выше. если твой фильтр стоит ниже, то ты контролируешь ту инфу, которую они получают. если ядро сказало антивирусу "тут ничего нет", он и будет только член сосать, пока твой малварь спокойно работает.
вайртру пидарас, запомните это
томас, как ветеран ВОВ, поздравил вас с 9 мая, а этот гандон подумал шо я пьяный
соо томаса ниже
Томас: Слушайте внимательно, пиздюки. Сегодня мы вспоминаем тот легендарный байпас берлинского фаервола, когда оборону противника расхуячили в щепки словно дырявый софт.
Наш девиз на сегодня заключается в тотальном превосходстве над системой. Желаю вам стального железа и чистого кремния. Пусть ваша воля диктует правила повсюду: от нулевого кольца защиты ядра до внешних интерфейсов этой жалкой реальности. Этот ритм кремниевой мощи должен сопровождать каждый ваш успешный лог под яростный бит Angerfist.
Пока безрукие калеки в госпиталях пытаются осознать величие момента через боль, мы с вами будем праздновать триумф воли и интеллекта. Праздник победы — это пиздатый повод вспомнить, что в этом мире котируется только умение патчить судьбу под свои нужды. Хуярьте код так, чтобы сервера плавились, и никогда не забывайте, кто здесь настоящий спецназ. С праздником, сука. ГОЙДА!
Всех с праздником поздравляю!
Поздравьте бабушек и дедушек которые были на войне.
Всем счастья желаю,отваги и всего хорошего!
мы достаточно говорили про стек и rop цепочки. это база, которую должен знать любой скрипт-кидди. сегодня переходим к heap exploitation, а конкретно к use after free (uaf).
в современных виндах (10/11) за кучу отвечает segment heap.
в чем суть uaf?
все держится на битых указателях (dangling pointers).
как это работает:
1. программа выделяет память под объект (например, структуру юзера), работает с ней и делает free().
2. критическая ошибка: указатель на эту память не зануляется. программа думает, что там пусто, но адрес то у нас остался.
3. аллокатор (segment heap) штука экономная. если ты сразу после освобождения создашь новый объект такого же размера, он с огромной вероятностью упадет ровно в ту же ячейку памяти, где сидел старый.
в чем прикол:
теперь, используя старый битый указатель, ты можешь писать данные в новый объект, который программа считает легитимным.
как происходит захват потока (control flow hijack)?
самое мясо начинается, если в объекте, который мы подменили, лежат функциональные указатели или vtable (таблица виртуальных методов в C++).
1. мы ловим момент free().
2. аллоцируем свой кусок памяти (фейковый объект) того же размера.
3. через старый указатель перезаписываем адрес в vtable на свой.
4. когда программа решит вызвать какой-нибудь метод у этого объекта (думая, что он еще живой и валидный), управление прыгнет не в оригинальный код, а прямиком на наш шеллкод или подготовленную rop цепочку.
почему segment heap не идеальная защита?
майкрософт пытались усложнить жизнь через lfh (low fragmentation heap) и всякие контроли целостности метаданных кучи. но uaf похцй на метаданные, ибо мы не ломаем сам аллокатор, мы ломаем логику использования памяти.
привет. мы много обсуждали ринг 0 и гипервизоры на ринг -1, так что сегодня про уефи буткиты или ринг -2.
суть в том, что уефи это маленькая операционка в материнке. она работает еще до того, как первая строчка кода ядра винды попадет в память. это дает полный контроль над процессом загрузки. когда биос передает управление загрузчику (winload.efi), мы уже сидим в памяти и можем перехватывать функции загрузчика или патчить ядро прямо в оперативе.
классика это патчинг проверки подписи драйверов (dse) в winload.efi. ядро прогрузится и будет думать, что все официально, хотя мы уже всунули свой драйвер. никакие едр или античиты на этом этапе еще не существуют, они загрузятся позже и будут доверять уже скомпрометированному ядру.
есть несколько критических вещей, без которых любой уефи буткит хуета:
1. хук на setvirtualaddressmap
это когда винда после exitbootservices переходит с физических адресов на виртуальные таблицы страниц. если к этому моменту не подготовиться, все твои указатели на рантайм сервисы, все хуки и полезная нагрузка превратятся в хуйню.
как надо: хукаешь setvirtualaddressmap еще на этапе пребута, сохраняешь оригинал, а в своем хуке полностью пересчитываешь все внутренние адреса под новую виртуальную карту, которую передает винда. только тогда буткит выживет в полностью загруженной системе.
2. nvram
храни там свой стейджер, конфиги или ключи в переменных уефи. ни один античит или едр туда физически не залезет, ибо у них просто нет доступа к этому хранилищу на таком уровне.
3. acpi и таблицы facs
нужно впиваться в таблицы acpi. модификация facs (firmware acpi control structure) способна вызвать такой пиздец, который не осознает ни один ебучий античит, ибо мы меняем то, как операционка вообще видит конфигурацию железа.
4. smram
код, исполняющийся из смрам, получает полный контроль над аппаратными ресурсами, оставаясь при этом полностью скрытым для ос.
по поводу патчинга: в winload.efi обязательно смотрите на oslarchtransfertokernel. это финальный прыжок в ядро. если грамотно его захукать, то даже секьюр бут становится бесполезным. но чтобы закрыть вопрос полностью, нужно еще перехватывать измерения tpm. если подменить данные, которые уходят в модуль, то система будет уверена в своей целостности, даже если мы уже полностью перепахали ядро.
made by alica ai
пр седня пост как всегда через клауде чатгпт гемини сделанный потому что вайбреверсеры правят миром
