пятница, 30 декабря 2011 г.

Мысли вслух

Подумалось недавно, как много Microsoft делает для обеспечения безопасности своих ОС: куча защитных механизмов против эксплойтов( aslr/dep/safeseh/function pointer obfuscation/sehop/stack cookies и т.д. ), uac, встроенная в ядро система защиты от патчей ( patch guard ) призванная бороться в том числе и с руткитами, скоро появится безопасная загрузка через UEFI, призванная бороться с буткитами(в win8), цикл SDL, призванный делать код безопасным еще на этапе написания, тулзы повышающие безопасность устаревших ОС семейства windows (EMET),  средство удаления вредоносных программ и даже бесплатный антивирус (Microsoft Security Essentials).

Эффективны ли эти меры? Безусловно да, безопасность ОС со временем развивается и улучшается, для того, чтобы обойти все защитные механизмы, малварь должна быть все изощреннее и изощреннее, уровень малварописателей также обязан повышаться. Таким образом, несмотря на то, что практически каждый защитный механизм обходится, в целом, картина имеет положительную динамику. Порог вхождения для малварописателей также с течением времени повышается.

Придет ли момент, когда малварь в принципе исчезнет? Тут можно только гадать. Но в принципе, с течением времени могут появиться механизмы защиты, не обходимые принципиально(как пример, можно взять какой-нибудь патч гвард сидящий на уровне гипервизора, и контролирующий не только изменение кодосекций и системных структур, но и остальные лазейки), или требующие для обхода затрат, превосходящих прибыль малварописателей, т.е. экономически не выгодных.

Пока все выглядит как вечная война щита и меча, кончится ли она когда нибудь? Поживем, увидим.

p.s. Всех с Наступающим!

четверг, 15 декабря 2011 г.

Подарок для отладчико-писателей

Те, кто писал отладчики знают, что существуют определенные трудности с отрисовкой элементов GUI. Сложности были и с выводом в видеопамять на видеокартах, где эта видеопамять фрагментирована, и с копанием в недокументированных структурах драйвера дисплея. Ни о каких стандартах и речи не шло. Но все течет, все меняется, развивается как software, так и hardware. И с появлением UEFI появился и стандарт GOP (Graphic Output Protocol).

GOP дает возможность устанавливать видео режимы и писать из/в фреймбуфер графического контроллера, предоставляя следующие интерфейсы:

QueryMode Returns information for an available graphics mode that the graphics device and the set of active video output devices supports.
SetMode Set the video device into the specified mode and clears the visible portions of the output display to black.
Blt Software abstraction to draw on the video device’s frame buffer.

Так что с использованием GOP можно наваять практически любой GUI для того же отладчика уровня ядра, если конечно вы являетесь счастливым обладателем платы с UEFI( как я например :) ).

Пример того, как выглядит графика выведенная через GOP(собственно весь интерфейс UEFI выведен через него):

пятница, 9 декабря 2011 г.

BURNMEMORY

Есть любопытная опция для загрузчика ОС: http://msdn.microsoft.com/en-us/library/windows/hardware/ff556246%28v=vs.85%29.aspx

На этапе загрузки ядра она обрабатывается следующим образом: получается число страниц, нужное для представления указанного в опциях количества MB, затем эти страницы включаются в список BadPageList, напомню, списков всего 8:

typedef enum _MMLISTS
{
    ZeroedPageList,
    FreePageList,
    StandbyPageList,
    ModifiedPageList,
    ModifiedNoWritePageList,
    BadPageList,
    ActiveAndValid,
    TransitionPage
} MMLISTS;

Также, данная память не учитывается в MmNumberOfPhysicalPages, то есть невидима для системы.

Но вот практический смысл данной опции для меня как-то ускользает.
Кто-нибудь знает, зачем нужна опция BURNMEMORY ?