книги хакеры / журнал хакер / 131_Optimized

ПРОЦЕССЫ, СКРЫТЫЕ УТИЛИТОЙ HIDETOOLZ

скрытыепутемисключенияструктурыEPROCESS издвусвязанного списка. ДляудобстваперечисленияхэндловвсетаблицыхэндловобъединенывдвусвязныйсписокHandleTableList. Проблема заключаетсялишьвтом, какегонайти, ибонеттакихсистемных функций, которыемоглибызаполучитьэтотсамыйвожделенный список. НачинаетсясписоксHandleTableListHead, поэтомудляее поисканеобходимознать, чтоHandleTableListHead — этоглобальная переменнаяядра, следовательно, онанаходитсяводнойизсекций егоPE-файла, аостальныеэлементыHandleTableList находятсяв динамическивыделяемойпамятиивсегдабудутзаегопределами. Изэтогоследует, чтонамнужнополучитьуказательнаHandleTable любогопроцесса, идвигатьсяпосвязанномуспискудотехпор, пока егоэлементнеокажетсявнутриPE-файлаядра. Этотэлементибудет HandleTableListHead. Сложно? Тольконапервыйвзгляд. Смотрим код:

ПоискHandleTableListHead

HandleTable = *(PHANDLE_TABLE *)((ULONG) PsGetCurrentProcess() + HandleTableOffset);

HandleTableList = (PLIST_ENTRY)((ULONG)HandleTable +

HandleTableListOffset);

for (PLIST_ENTRY CurrentHandleTable = HandleTableList-> Flink;

CurrentHandleTable != HandleTableList;

CurrentHandleTable = CurrTable->Flink)

{

if ((ULONG)CurrentHandleTable > KernelBase && (ULONG) CurrentHandleTable < KernelBase + KernelSize)

{

return CurrentHandleTable;

}

}

ЗдесьвCurrentHandleTable ибудетсодержатьсяадресискомой HandleTableListHead. Далеемыможемпройтисьпотаблицамхэндлов ипостроитьпонимсписокзапущенныхпроцессов.

ЗАКЛЮЧЕНИЕ

Япопыталсясобратьикраткоописатьотносительноизвестныеине оченьспособывыявленияскрытыхпроцессоввWindows. Каквидишь, найтискрытыйпроцессдостаточнолегко, ииногдабываетдостаточноскомбинироватьнескольковышеописанныхспособов. Удачного компилированияидапребудетстобойСила! z

Еще одно преимущество для мобильных компьютеров: Windows 7 продлевает время работы от батарейки. «Семерка» — это отнюдь не только приятные внешние изменения, но еще и огромное количество усовершенствований внутри системы, которые скрыты от пользователей. Windows 7 обеспечивает еще большую эффективность за счет уменьшения (а во многих случаях ликвидации) фоновой активности в системе. В тех случаях, когда такая деятельность не может быть исключена (например, для таймеров на USB-стеке), система использует специальный меха-

низм — Windows 7 Timer Coalescing.

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

периода времени, мощность, необходимая для входа и выхода в режим низкого энергопотребления, может быть больше, чем полученная от пребывания в idle-режиме выгода. Технология Timer Coalescing позволяет максимально эффективно использовать режимы работы новых процессоров и таким образом увеличивает продолжительность работы ноутбука от батарейки. Кроме того, Windows 7 откладывает некритические фоновые процессы, когда ноутбук работает от аккумулятора, что позволяет увеличить срок службы батареи портативного компьютера.

Вмоейстатьезапрошлыймесяцмыобсудили некоторыесервисыГугла, ноодинизнихя сознательнооставилдляотдельногорас-

смотрения. Google App Engine (GAE) — одна изперспективнейшихмасштабируемых «облачных» технологий. Онпредставляет собойкрутойхостинг, которыйавтоматически увеличиваетсвою«скорость» взависимости отколичестваюзеров. Еслисегодняунас100 юзеров, тохостингработает. Еслизавтрапридетеще1 миллионсверху, тоГуглавтоматическиподкинетсерверов, ивсенашехозяйство будетработатьтакжестабильно. Крометого, вGAE реализованацелаякучадополнительныхAPI поработесбазойданных, memcache, почтой, джаббером… ивсеэто— совершенно бесплатно(правда, снекоторымимелкими ограничениями).

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

НАЧАЛО ОПЕРАЦИИ

СпециальнодляразработкисайтовподGAE созданпакетSDK, которыйпозволяетписать итестироватьприложениеусебянакомпе. Инсталяхуэтойштукиможноскачатьсhttp:// code.google.com иливзятьснашегоDVD.

Архитектураснифераследующая:

•админкадляпросмотралогов, котораянаходитсяпоадресу/admin/ савторизациейчерез Гугл-акки;

•логер, которыйнавсезапросыпослелогированияданныхоюзере, будетперенаправлять егонадругойсайт.

РОУТИНГ

ГлавныйфайлприсозданиисайтоввGoogle App Engine — app.yaml, онопределяетвсе настройкиприложения. Этотекстовыйфайлс синтаксисомYAML, которыйсодержитобщие настройкионазванииприложения, еговерсии, исредеисполнения:

application: spirt40 version: 2

runtime: python api_version: 1

Длянасособеннополезенпункт«версия». Когда, кпримеру, мыбудемзаливатьновый релизприложения, еенужноинкрементировать. Гуглавтоматическисохранитстарыеи новыеверсиифайловипредоставитсвоим

покорнымслугам(тоесть, нам:)) удобнейшую системупопереключениюналюбуюверсиюив любоймомент.

Последнимпунктомвфайлеapp.yaml будет handlers, которыйустанавливает, какнужно реагироватьнаопределенныеURL. Унасон будеттакой:

handlers:

-url: /favicon\.ico upload: /

static_files: favicon.ico

-url: /.*

script: index.py

Впервомпунктевпараметреurl регуляркой обозначаем, чтоеслибраузерзапрашивает favicon.ico, тоотдаемстатическийфайлскорневойпапки. Этоправиломожнобылопропустить, нобраузерыданнуюиконкучастозапрашивают автоматически, иотсутствиееегрозитнам такимжеавтоматическимзасорениемлогов. Во второмпунктенастроеквсеостальныезапросы мынаправляемнаindex.py.

ХЕЛЛО, ВОРЛД

СкриптынаGAE дляработысWEB используют CGI, окотороммыужеговорилиприсоздании сплойтпака, поэтомудавайперейдемсразук программингу. Начнемсвыводатекста. Для этогосохранимфайлindex.py соследующим содержанием:

print 'Content-Type: text/plain' print ''

print 'Hello, ][akep!'

Можемпосмотретьнанашепервоеприложениевбраузере. Длястартатестовогосервера запустискриптdev_appserver.py спапкойсо скриптамивкачествепараметра. ВWindows это будетвыглядетьтак:

C:\>"C:\Program Files\Google\ google_appengine\dev_appserver.py" d:\snifer

CODING

ЛОГОТИПGAE

СРАВНЕНИЕ GAE C AMAZON

info

Каквсегда— все представленотолько дляознакомления. Тестируйснифер лишьвобучающих целях!

dvd

•Всеисходникис полнымикомментариямисмотрина диске.

•Такженадиске ищидемо-видео поиспользованию снифера.

from google.appengine.ext import db

class Sniffer(db.Model): ip = db.StringProperty()

request_uri = db.StringProperty() ua = db.StringProperty()

referer = db.StringProperty() date = db.DateTimeProperty(

auto_now_add=True)

Здесьмывидим, чтополятаблицыприописаниипредставляютсобойпростыесвойстваобъекта, которыммыприсваиваемсоответствующиеклассы. Длятекстовогополяисполь-

зуемdb.StringProperty(), длядаты— db.DateTimeProperty().

Заметим, чтоприописанииполямыможемпередавать дополнительныепараметры. Так, например, вполесдатой передаемпараметрauto_now_add=True, чемзаставляем БДавтоматическизаписыватьтекущуюдатувэтополепри созданиизаписи.

Теперь, когдавфайлindex.py мыдобавилиописаниебазы, ееможноиспользовать. Длязаписиданныхнужносоздать наосновеэтогоклассаобъектизаполнитьполя. ДлясниферанастраницуMainPage добавимстрочки:

snif = Sniffer()

snif.ip = self.request.remote_addr

snif.request_uri = self.request.uri snif.ua = self.request.user_agent snif.referer = self.request.referer snif.put()

Информациюдлязаполненияполеймыберемизself. request. ИменноэтиммысохраняемIP пользователя, адрес покоторомуонпришел, юзер-агентиреферер. Вызовметодаsnif.put() сохраняетданныевбазу.

ВклассеAdminPage намнужночтениелогаизбазы. Делаетсяэтоещепроще, чемзапись:

log = Sniffer.all().order("-date")

Тутмывыбираемвсеэлементы, сортируемподатевобратномпорядкеисохраняемрезультатвпеременнуюlog.

ТЕМПЛЕЙТЫ

ДляклассаMainPage выводHTML ненужен, достаточнопослеполученияданныхдальшеперенаправитьпользователя ужезнакомымredirect’ом, например, настраницуГугла.

ОднакоклассAdminPage требуетвыводстатистики, поэто- мудляформированияHTML-выводамызаюзаемшабло- низатор. Носначаласформируемданныедлянеговвиде словаря. Думаю, спискалоговиимениюзерадостаточно:

template_values = { 'user': user, 'log': log,

}

GAE используетшаблонизатортакойже, каки вDjango, инаходитсяонвмодулеtemplates. Внемсамаяглавнаяфункцияrender, которая принимаетпутькшаблонуипеременныедля передачившаблон, арезультат— сформированныйHTML — возвращаетсяпростой строкой:

self.response.out.write(

template.render('template/admin. html', template_values)

)

Теперьсоздадимфайлtemplate/admin.html и сохранимегосвоттакимсодержанием:

<html>

<body>

<h1>Hello, {{ user }}</h1> <ul>

{% for item in log %} <li><ul>

<li>{{ item.ip }}</li>

<li>{{ item.request_uri }}</li> <li>{{ item.ua }}</li>

<li>{{ item.referer }}</li> <li>{{ item.date }}</li> </ul></li>

{% endfor %} <ul> </body> </html>

Каквидишь, самшаблон— простойHTML с некоторымивставками. Строкой{{ user }} мы выводимпереданнуювшаблонпеременную. Такжеможноиспользоватьуправляющие конструкции, ионипомещаютсяв{% %}. В нашемслучаемыиспользуемfor дляперебора построчновсехлогов— {% for item in log %} {% endfor %}. Всамомтелецикламывыводим

переменнуюitem, котораяпредставляетсобой однустрокуизлога. Длявыводанаэкранполей изэтойстрочки, чтобыполучитьдоступксвойствам, используем«.». Кпримеру, {{ item.ip }} выведетайпишник.

DEPLOY

Кажетсяневероятным, новоттаклегкои почтинезаметномысоздалисниферна платформеGoogle App Engine. Осталось лишьзадеплоитьего— тоесть, запуститьна сервере. Дляэтогосначалазарегистрируемся наhttps://appengine.google.com, изменимв файлеapp.yaml параметрapplication натот,

чтонамдалиприрегистрации. Изапустим загрузчик: appcfg.py update d:/snifer.

Готовоеприложениесниферанаходитсяпо адресуhttp://spirt40.appspot.com, такчто можешьиспользоватьеговсвоих«научных» целях. Вотивсе, надеюсь, моеймаленькой статьихватит, чтобызаинтересоватьтебяи сподобитьнауглубленноеизучениеииспользованиеплатформыGAE. Удачи! z

ВЗРОСЛЫЕ

ИГРЫ

ВЭЛЕКТРОННОЙ ПЕСОЧНИЦЕ

ПЕСОЧНИЦА

Чтотакое«песочница» дляайтишника? В первуюочередь, этословодолжнобытьдоболи знакомо SEO-оптимизаторам. Например, одну из значительных проблем для оптимизаторов представляет Google Sandbox. Это одно из самых серьезных препятствий, которое необходимо преодолеть новому сайту, прежде чем попасть в результаты поиска Google. Песочница Google не позволяет новым сайтам искусственным путем улучшать свои позиции. Далеко не каждая поисковая система имеет подобную фильтрацию. Сайты, оказавшиеся в песочнице, могут пробыть там от двух недель до года. В течение этого периода новые сайты успеют занять высокие позиции в других поисковых систе-

мах, но не в Google. Однако мы поговорим о другой «песочнице» — программной. Существующая концепция создания программной «песочницы» включает в себя такие «несложные» пункты: эмуляция железа и операционной системы, запуск вероятно «зловредного приложения», отслеживание его действий и их последующий анализ. Имеющиеся на данный момент решения по большей части сводятся к перехвату системных функций и анализу выполнения подозрительного кода. И надо сказать, что эта система очень даже неплохо работает.

Ноповышеннаябезопасностьисполнениякода в«песочнице» зачастуюсвязанасбольшой нагрузкойнасистему— именнопоэтомунеко-

торыевиды«песочниц» используюттолькодля неотлаженногоилиподозрительногокода. Википедия утверждает, что «песочницы» в природе часто встречаются в виде апплетов, которые исполняются в виртуальной машине или интерпретаторе, позволяя запускать Java-код с любых веб-сайтов без угрозы операционной системе, а также так называемых «тюрем», которые позволяют вводить ограничения ресурсов для пользователей и процессов некоторых ОС. Наиболее популярны виртуальные машины, полностью эмулирующие «стандартный» компьютер

(например, VirtualBox или VMvare и др).

Помимо ограничения вредоносного и непроверенного ПО, «песочницы» также используются в процессе разработки для запуска

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

Единственный минус всего сказанного в том, что своими силами соорудить подобную «песочницу» довольно проблематично, потому что она потребует знания архитектуры системы, прямого вмешательства в ядро и перехвата основных системных вызовов. Мы же поговорим о том, как можно, немного поднапрягшись, соорудить средствами C# вполне приемлемую реализацию «сандбокса», которая позволит существенным образом повысить безопасность твоей системы. И для этого не понадобятся специфичные знания системного программиста!

С ЧЕМ РАБОТАЕМ?

Уверен, что ты знаешь: система безопасности в .NET Framework представлена пространством имен System.Security. Она содержит все необходимые нам программные инструменты. При разработке систем, подобных «песочнице», нужно иметь в виду, что имеющиеся на вооружении методы можно разбить на две подгруппы

—методы обеспечения безопасности на основе ролей Windows и методы, ограничивающие поведение управляемого кода.

В чем разница между ними? Если говорить просто и примитивно

—безопасность на основе ролей на порядок ниже, чем прямое ограничение вмешательства кода в систему. Хотя бы потому, что в Windows, несмотря на имеющиеся роли пользователей, все сидят под правами администратора (правильно, а чего мелочиться?). Этот фактор очень часто приводит к запуску малвари и руткитов на компе. С учетом того, что код будет запускаться на машине именно с правами админа, на мой взгляд, гораздо эффективнее разграничивать способы воздействия кода на систему. Об этом и поговорим.

Основой для создания «песочницы» должны являться так называемые зоны безопасности. CLR определяет пять таких зон: «Мой компьютер», Интранет, доверенная зона, Интернет, недоверенная зона и «отсутствие зоны». Это распределение является наиболее

важным для обеспечения безопасности — зоны определяют ее основой уровень. Программная реализация зональной безопасности представлена в классе ZoneIdentityPermission. Включи этот класс в код и можешь смело ограничивать его исполнение:

public class Secured

{

[ZoneIdentityPermission(SecurityAction. LinkDemand, Zone=SecurityZone.MyComputer)]

public static void SaySomething(String Input)

{

MessageBox.Show(Input);

}

}

Нет необходимости перечислять и рассказывать о многочисленных атрибутах и методах, предоставленных программисту в .NET. Позволю себе рассказать только о нескольких наиболее интересных. Основным атрибутом, используемым в программной реализа-

ции «песочницы», может служить [SecurityPermissionAttribute]

— он позволяет назначить практически любую логику поведе-

ния кода. Очень важный атрибут — [PermissionSetAttribute].

К примеру, его можно использовать для постановки запрета открытия/чтения какого-либо файла: [System.Security. Permissions.FileIOPermission(SecurityAction.Deny,All=«C:\\ Windows\\file.dll»)].

ПространствоименSystem.Security включаеттакжеатрибутAllowParti allyTrustedCallersAttribute, которыйпозволяет«частичнодоверенному коду» вызыватьваши«строгие» сборки(«strongly named assembly»).

Вместестем, егоиспользованиеимеетдвесторонымедали— еслиты добавишьэтотатрибутк«строгой» сборке, тоэтодастшанснедовереномукодупоставитьподугрозувсюконцепциюбезопасности. Аеслиты недобавишьэтотатрибут, код, вероятно, ивовсенесможетвызывать «строгие» сборки.

Оченьудобендляиспользованиявпроектируемой«песочнице» класс SecurityManager; нижеследующийкоднагляднопоказываетегоиспользование:

{

string pluginFolder = AppDomain. CurrentDomain.

BaseDirectory;

string plugInPath = Path.Combine (pluginFolder,

"plugin.exe");

PermissionSet ps = new PermissionSet (PermissionState.None); ps.AddPermission

(new SecurityPermission (SecurityPermissionFlag.Execution)); ps.AddPermission

(new FileIOPermission (FileIOPermissionAccess.PathDiscovery |

FileIOPermissionAccess.Read, plugInPath)); AppDomainSetup setup = AppDomain.CurrentDomain.SetupInformation; AppDomain sandbox = AppDomain.CreateDomain ("Sandbox", null, setup, ps); sandbox.ExecuteAssembly (plugInPath); AppDomain.Unload (sandbox);

}

}

APPDOMAIN — ЭТИМ ВСЕ СКАЗАНО

ВС#, восновномпространствеименSystem, естьочень интересный, номалоиспользуемыйвповседневных прикладных целях класс — AppDomain. Это своеобразный логический контейнер набора сборок.

Смысл моей статьи в том, чтобы показать, что домен приложения, в котором исполняется твоя программа, определяет доступ к ресурсам и сервисам машины. И этот доступ можно жестко задать самому. Домен приложения является своего рода контейнером, который определяет набор атрибутов безопасности, предоставленных программе.

При загрузке CLR (общеязыковая среда исполнения платформы .NET) создает домен приложения или AppDomain. Основная задача домена приложения — обеспечить изоляцию выполнения кода. Как результат — объекты, созданные одним AppDomain, не видят другие домены приложения, то есть код одного AppDomain не может напрямую ссылаться на объект, созданный в другом AppDomain. Домены приложения можно защищать по отдельности — при создании домену приложения можно назначить набор разрешений, определяющий максимальные права сборок, работающих в AppDomain. Это позволяет загружать код и быть уверенным, что он не испортит важные структуры данных, используемые самим доменом. Кроме того, домены приложения можно конфигурировать по отдельности. Короче говоря, C# и

.NET предоставляет нам возможность контролировать не только само приложение, но и доступ кода с разграничениями безопасности на основе ролей (столь любимой Microsoft). А скомбинировав изложенные выше способы, можно легко создать вполне сильную реализацию «песочницы», которая добром послужит тебе в укреплении безопасности системы.

ЧТО ДЕЛАТЬ С НЕУПРАВЛЯЕМЫМ КОДОМ?

С управляемым кодом, написанным на языках .NETплатформы, мы вроде разобрались. Напоследок опреде-

ОСНОВНАЯ ЗАДАЧА ДОМЕНА ПРИЛОЖЕНИЯ — ОБЕСПЕЧИТЬ ИЗОЛЯЦИЮ ВЫПОЛНЕНИЯ КОДА.

лимся с неуправляемым кодом — можно ли его использовать в разработке «песочниц» наподобие нашей? Можно, но неуправляемый код требует особого подхода. Поэтому ответ на вопрос: «Можно ли да на 100 % контролировать…» скорее будет отрицательным. Все, что ты сможешь сделать — позволить или запретить выполнение неуправляемого кода в программе. И это можно считать большим, но вполне объяснимым недостатком .NET Framework — уж больно разные подсистемы Windows. По факту архитектура .NET Framework дает программисту два варианта обеспечения безопасности в системах, использующих как управляемый, так и неуправляемый код. Первый — использовать функции Win32 API для

В Windows 7, наконец-то,

реализовали настоящую систему резервного копирования данных. Не точки восстановления, а настоящий бэкап! Нет необходимости устанавливать для этого какие-то сомнительные сред-