опять SMM

"Пpидумали SMM (System Management Mode) пpоклятые буpжуины, мучаемые

идеей-фикс энеpгосбеpежения и ноутбуками. Чтобы сию хитpую идею pеализовать,

ввели новый pежим pаботы (SMM) и сво| собственное адpесное пpостpанство

(по большому сч|ту - с обычным не пеpесекающееся, но чипсетом в него

маппиpуемое). Пpи наступление SMI (System Management Interrupt, что

может пpоисходить как пpогpаммно, так и аппаpатно) пpоц сохpаняет сво|

текущее слстояние в SMM-memory (полностью или частично - зависит от

pеализации), сбpасывается в Real Mode и выполняет заданную пpогpамму

в SMM-памяти, после завеpшения коей возвpащается в пpеpванное место

посpедством RSM/RES3/RES4/etc (отсюда "pастут уши" столь любимых тутошним

наpодом LOADALL/STOREALL ..."



1. Где можно на русском по подробнее и есть ли у кого "дополнительные" мысли

2. Как выполнить BIST в этом режиме



поправка.

1. Как-нибудь выполнить BIST

2. Правда что на него уходит 150 мс?

 

да хотьбы на англицком

 

Наконец наметилось собственное созревание знаний в этом направлении, поэтому начинаю ворошить залежавшиеся темы и подымать их на свет Божий Сижу вот, перечитываю ветку заново, так сказать, несколько поумнев в деле SMM и с новыми соображениями... рекомендую

http://www.wasm.ru/forum/index.php?action=vthread&forum=3&topic=8842&page=2

RAR`ы тамошние скачал и опробовал на ICH6+I915P - работают, блин! Но, для меня лично, давно было непонятно, как вернуть "из тени" область ОЗУ обработчика SMI (т.н.SMRAM), а оказалось - не там искал!!! Все дело в СЕВЕРНОМ МОСТЕ, оказывается ребята, ведь ОН "ответственный за память". Intel дает скачать серьезные доки по чипам, что все и проясняет собственно...

Полезный и краткий ликбез + факты

http://www.istc.kiev.ua/~santana/bios/biosp.html

Хе-хе-хе! А вот кое кто уже опомнился и называют SMM + SMI - уязвимостью для атак

http://security.compulenta.ru/263730/

Кто хотел на ангиЦком читать про SMM - вот прямая ссылка, коих по процам хоть завались вообще то:

http://www.cs.purdue.edu/homes/cs503/docs/intel_vol3.pdf

- ЧИТАТЬ гл. 11.4 до полного всасывания мозгом Ж, потом качать PDF`ники по мостам машины(северный-переключение SMRAM из тени и его сдампливание понятно, как получается..., южный - фичи конкретно SMI, уставки для её генерации АППАРАТУРОЙ...)

 

Круто, это то что я искал, спасибо.

 

Такие люди, как этот француз -- автор той статьи про "уязвимость в SMM", вызывают сначала удивление, а затем усмешку и отвращение. То, что обработчик SMI может делать с системой что угодно -- это общеизвестный факт, про это даже Гук упоминал в своей книжке. Для этого этот режим и создавался. И вот появляется этот лягушатник и рождает мировую сенсацию -- "Смотрите!! Обработчик СМИ может вывести ринг3 код на ринг0!!! Для этого надо... всего лишь доступа к I/O и PCI space!!!". Страус картавый бл%$ь, имея доступ к портам и pci conf, можно прыгнуть в ноль и без всякого смм, хоть бл$%ь с помощью DMA, хоть с чем угодно, и сделать это гораздо проще, нежели учитывать десятки чипсетов, кучу процов и тп для СММ.

Удивляюсь, как только Земля таких долб#$бов носит.

 

Вообще как говорит мануал интел в процах (до пней4) режим SMM это четвертый режим работы проца.



Хрен его знает что в нем хорошего - поскольку 16битная дешифрация кода, а доступ к 4Гб сильно напоминает UNREAL модес.



А вот 'shadows' RAM- залезть было-бы прикольно.. Хотя пускать в шэдоувз это личное дело чипсетов... Коих ТЬМА...

 

_BC_

За примерами выдуманых сенсаций далеко ходить не надо, достаточно просто зайти на http://kaspersky.ru/.

В нашей стране таких долб#$бов тоже хватает

 

Возмущение понятно, но что дальше?

Рано ли, поздно ли НО! Но, почти периодично, то тут, то сям, на форумах встречаем вопросы и темы ведущие непосвященных и даже многих пытливых в тупик. На стенке тупика лишь некто может прочитать "SMI", затем развернуться и идти восвояси...

А между тем, приподняв завесу такой "псевдотаинственности" (а все вообщем то, обоюдоострое, даже сама жизнь, так чего бояться?) можно получить ответ: почему и кто(код) пищит спикером, когда, скажем пальцем принудительно остановить кулер; кто пробуждает "ПОЛНОСТЬЮ выключенную" машинуж; кто меряет температуру, питание, кулеры; кто финально(код) выключает питание машины или присыплает её ...

Не думаю, что все настолько НЕстандартно, хотябы в пределах производителя...На сегодня я уже понял и знаю как "пронюхать" Intel`а (Огромное спасибо _BC_!!!), и раскопал у себя на старушке VIA куда и как стучать, чтобы SMI за "вымя взять". А вот доков по мостам SIS, AMD, NFORCE кажись совсем нет в инете? Или я неправ?

 

"Придите и возьмите!" (С) не помню чей Всё это можно узнать, расковыряв прошивку от какой-нибудь ASUSовской материнки (на них это лучше всего развито). У асуса даже программный интерфейс есть с обработчиком СМИ, почти int 21h, только не int и не 21h ) Правда реализация не их, но некоторая заслуга ASUSа всё же там есть.

 

_BC_ ну ASUS мне как то по жизни не встречается, в основном GIGABYTE, Intel, VIA... Но если уж говорить о сути вещей, не лучше ли именно искать доки на мосты/конкрентные к ним прошивки и тамошние методы "затенения" SMRAM? Собственно как ты и делал?

А по докам на мосты, что выше писал, не подскажешь ли где "выловить"? Любопытно попробовать обобщить/унифицитовать хотя бы некоторые поколения/типаж машин в смысле вывода из тени SMRAM.

 

Открытие SMRAM -- это наипервейшая, простая и базовая операция. Самый быстрый способ узнать, как это сделать на конкретной системе -- разобрать код установки SMI handler'a в BIOS'е с этой системы. Код этот легко локализуется по характерным константам -- SMBASE'ы, msr'ы (для амд), большинство манипуляций с сегментом A000h, начиная от инициализации знакогенератора и вплоть до рисования в видеопамяти, приходятся на video bios, так что ложных срабатываний в основном BIOS'е будет мало. Наличие документации необязательно, но весьма помогает. Различия в установке у разных северных мостов в пределах одного вендора нечасты, тому пример интеловский 9Dh.

Но выставление обработчика сродни корпусу сис.блока -- всё самое интересное внутри, а один корпус сам по себе не функционален.

 

тут имеется в виду именно взять код прошивки, затем распаковать по аналогии с тем, как это делается при старте и затем копаться в коде, так верняк будет?

У VIA, надеюсь, стабильно будет 63h (два младших бита )

 

Кстати распаковка бивеса в AWARD-BIOS в SHADOWS RAM происходит в секции

Award

Decompression Bios ??



Хм.. а они чето одинаковые... по крайней мере для Socket7 систем на базе VIA и INTEL..



Как и Boot Block...

 

На мой взгляд AWARD сохраняет стабильность, в смысле "центровые вещи" как бы должны быть одни и теже, а вот там где игра с чипсетиной, так эти то конкретные вкрапления и различны и характерны для тюнинга и настроек железяк. А какой софтиной ты пользуешься для распаковки? Чёнить из тулзов с www.rom.by? Правда он в дауне несколько недель...

 

А какой софтиной ты пользуешься для распаковки?



Far.exe & lha.exe. Мона и WinRar'om..

В теле лежат еще сигнатуры. Ищуться lh5 и вытаскиваються с пом. hiew'а.



Таки у тебя есть технология попадания в шедоуз, о VaStaNi? Как в него заливают?



Через порты спецефичные для каждого чипсета?

 

Вообще то твой метод, мне кажется мутноват, хотя ручками и сознательно зная что, где, как тоже можно. Вот, пожалуй, хорошая отечественная инфа

http://www.oszone.net/2240/

Как в него? А ты читал все в этой ветке? Перечитай снова... посмотри asm код, доки читани и все сложится.

 

Как в него

а вот так - сколько 64кб дырок в адресном пространстве писюка? штуки две а то и три.



А так очень мило - воткнуть биос ничего не втыткая. Вещь.. Абсолютно никому ненужная.

Только единицам. фанатикам дзена, и истиным его патриотам.

 

Т.е. ты хош менять содержимое копии BIOS в ОЗУ, после того как туда он свою копию прописал?

 

Кстати даташиты по VIA чипам мне прислали с сайта этово корпорейшена.. проверяя полузаброшеный почтовый ящиг (с мусором) я с удивлением обнаружил че-то такое.

 

_BC_



Я так понимаю, эта тема -- продолжение старой.



Поэтому хотел бы задать пару ламерских вопросов по перехвату и эмуляции портов при помощи SMM.



1) Возможно ли организовать перехват портов PCI (CFCh и CF8h) ?



Тогда появилась бы возможность фильтровать информацию о конфигурационном пространстве PCI устройств, получаемую программами, даже в случае, если они непосредственно работают с портами CFCh и CF8h.



Это я вот к чему спрашиваю:



Цитата:<ol type=1>"Ну а если же твой комп позволяет ловить IDE, тогда можно написать эмулятор sforc'a (для себя). Сначала погонять цд на предмет получения времени чтения, собрать статистику. Затем отлавливать I/O, проходящий ч/з порты IDE и при определенных обстоятельствах вставлять соотв. задержки (прямо в SMM)."</ol>



Просто в случае с СФ эмуляцию можно будет переложить на плечи спец софта (например, RMPS + Alcohol120% или DaemonTools). Нужно лишь добиться, чтобы драйвера защиты не рискнули работать с IDE-контроллером напрямую. А этого можно достичь, если изменять получаемую драйвером защиты информацию об идентификационных PCI-регистрах контроллера (DeviceID/ClassCode).



Подробности о подмене идентификационных регистров некоторых IDE-контроллеров можно глянуть тут.



2) (вытекает из первого)Возможно при помощи SMM-метода организовать "почти реальные" виртуальные устройства ? (например, виртуальный IDE-контроллер, который бы для любого софта/драйверов выглядел бы реалнее некуда. )

Или блокировать (прятать) некоторые PCI-устройства ?(что-то типа SMM-найтмара )



Прекрасно понимаю, что вопросы скорее риторические.

Но все равно с нетерпение жду Ваших комментариев.



Заранее спасибо!



PS:



Маленкое дополнение к предыдущим вопросам:

Цитата:<ol type=1>Сам SMI handler защитить -- не проблема. Угнать SMRAM подальше, поставить D_LCK -- и всё. А вот регистры, управляющие SMI...

Описание этой защиты ... -- пока под секретом.</ol>

Кстати, если эти управляющие регистры расположены в конфигурационном пространстве PCI, то их содержимое тоже можно фильтровать и при необходимости подсунуть заинтересованным программам/драйверам ложную информацию. Такой вот вариант защиты. Главное, чтобы этой идеей не воспользовались биосописатели.



PPS:



Возможно в будущем разработчики защит кроме идентификационных PCI-регистров также будут проверять и PCI-адрес устройств(bus/device/function)



Поэтому при помощи модификации SMM можно было бы так же [виртуально] менять адреса PCI-устройств на шине.



PPPS:



По поводу размещения модифицирующего кода в случае NT/XP.

В этом случае, естественно, способ с autoexec.bat не прокатит.

Куда тогда запихнуть код (до загрузки ОС)?

Возможные варианты:

(по мотивам обсуждения на клокерсах)

<ol type=1><li> Дополнить биос PCI-ных карточек. Можно даже написать универсальный модификатор -- главное, чтобы свободного объема флэшки хватило.

<li> Модифицировать NTDETECT.COM.

<li> Использовать особую перезагрузку при помощи INT19.com.

<li> Написать драйвер и присвоить ему высочайший приоритет запуска.</ol>

Наверняка существуют еще какие-то способы.