Фича №2
Вы решили писать программы для windows mobile, ставите себе студию, sdk, образы эмулятора. Доходите до установки Virtual PC, без которого эмулятор не сможет ходить в сеть и соединиться по DMA с «activesync». И тут оба-на! Virtual PC нельзя установить на home, покупайте professional, потому что его интегрировали в professional как windows xp mode.

Думаю, что есть какие-то еще такие скрытые фишки home версий, присылайте мне если знаете. Народ должен знать своих героев.

#include "stdafx.h"
#include
#include
#include 

#define DECLARE_UNICODE_STRING_BY_WSTRING(strName, stdWstring) \
	UNICODE_STRING strName = {(USHORT)stdWstring.size() * 2, (USHORT)stdWstring.size() * 2, (PWSTR)stdWstring.c_str()}

std::wstring GetPath()
{
	return L"C:\\windows\\system32";
}

int _tmain(int argc, _TCHAR* argv[])
{

	DECLARE_UNICODE_STRING_BY_WSTRING(moduleName, GetPath());
	return 0; //здесь moduleName.Buffer указывает на пустую строку
}

Как же так получается, что строка становится пустой. Видно это только из ассемблера:

.text:00411558                 call    GetPath(void)
...
.text:00411581                 call    ds:std::basic_string::c_str(void)
...
.text:0041158E                 mov     [ebp+moduleNameUs.Buffer], eax
...
.text:004115A0                 call    ds:std::basic_string::~basic_string

Вызывается деструктор!
А связано это с тем, что область видимости экземпляра std::wstring, который вернула GetPath(), это:

{(USHORT)stdWstring.size() * 2, (USHORT)stdWstring.size() * 2, (PWSTR)stdWstring.c_str()}

То есть сразу же после, того как moduleName.Buffer будет присвоено значение, будет вызыван деструктор. И сделано это будет до строки return 0; А макрос это скрывает! И создается впечатление что объект будет уничтожен на выходе из функции.

Before calling any support routine that requires access to a caller-supplied executive spin lock, a driver must call KeInitializeSpinLock to initialize the corresponding executive spin lock. Support routines that require an initialized executive spin lock include the following:

KeAcquireSpinLock and, subsequently, KeReleaseSpinLock
KeAcquireSpinLockAtDpcLevel and, subsequently, KeReleaseSpinLockFromDpcLevel
KeAcquireInStackQueuedSpinLock and, subsequently, KeReleaseInStackQueuedSpinLock
KeAcquireInStackQueuedSpinLockAtDpcLevel and, subsequently, KeReleaseInStackQueuedSpinLockFromDpcLevel

Но не пишется о том, что будет если вы используете разные функции на одном и том же спинлоке. Как показал опыт, ничего не будет, ровно до того момента пока не будет захвачен спинлок и начнется ожидание.
Например, ОС инициализирует спинлок через KeInitializeSpinLock, и дальше использует пару KeAcquireSpinLock/KeReleaseSpinLock для работы с ним. Тут вы своим кодом начинаете пытаться лочить его через KeAcquireInStackQueuedSpinLock/KeReleaseInStackQueuedSpinLock. И вот если лок был уже захвачен через KeAcquireSpinLock, KeAcquireInStackQueuedSpinLock рухнет, потому что KeAcquireSpinLock хранит в SPIN_LOCK просто DWORD равный 0 или 1. А KeAcquireInStackQueuedSpinLock хранит там указатель на очередь. Спинлок один и тот же данные абсолютно разные. Соответственно, в спинлоке, залоченом через KeAcquireSpinLock хранится число 1, а KeAcquireInStackQueuedSpinLock попытается прочитать по указателю = 1.

В моем случае все оказалось еще веселее, в одних версии ОС для этого спинлока использовались KeAcquireSpinLock/KeReleaseSpinLock, а в других KeAcquireInStackQueuedSpinLock/KeReleaseInStackQueuedSpinLock. Баг получился плавающим.

Вывод: при использовании чужих спинлоков обязательно проверьте какими функциями пользуется ОС.

if (LastThread &&
    (Process->Flags & PS_PROCESS_FLAGS_BREAK_ON_TERMINATION)) {
    if (KD_DEBUGGER_ENABLED) {
        PspCatchCriticalBreak ("Critical process 0x%p (%s) exited\n",
                               Process,
                               Process->ImageFileName);
    } else {
        KeBugCheckEx (CRITICAL_PROCESS_DIED,
                      (ULONG_PTR)Process,
                      0,
                      0,
                      0);
    }
}

Вот такой код в PspExitThread(). Если у процесса стоит флаг PS_PROCESS_FLAGS_BREAK_ON_TERMINATION, то система героически уйдет в BSOD.

Какой из этого следует вывод: любой процесс можно сделать критическим для системы. То есть запросто можно какой-то notepad.exe сделать критическим. Более того, не нужно лезть для этого в EPROCESS. Есть NtSetInformationProcess() с типом ProcessBreakOnTermination, и похоже что это можно даже сделать из ring-3!

Так что убивая процесс, стоит проверить, а не поставил ли он себе такой флаг

Итак технологии.
DEP
Если у приложения отключен DEP, EMET может его софтварно включить. Через SetProcessDEPPolicy(). То есть малварь при желании тоже может вызвать SetProcessDEPPolicy, и вернуть все как было.

ASLR
Во-первых эта фича работает только начиная с висты, что уже наводит на мысли. Во-вторых ASLR возможен только для образов с флагом IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE в OptionalHeader.DllCharacteristics. То есть форсить особенно не выйдет изначально. Что тогда оно делает? Оно смотрит какие модули в процессе имеют IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE. Размапливает такие модули (NtUnmapViewOfSection), выделяет блок памяти на котором раньше находился модуль, и снова мапит. То есть старый адрес уже занят, и системе приходится ремапить модуль на другие адреса.

SEHOP
Здесь ничего особенного, дописывают всем потокам, которые запущенны на момент срабатывания EMET, свое исключение в Teb.ExceptionList. Так что бы при раскрутке исключения проверить осталось ли оно на месте, или нет. Для того, чтобы сделать проверку вешают свой VEH обработчик. Все хорошо, только новые потоки не контролируются. А на момент срабатывания EMET, создан только главный поток.

EAF
По описанию, создается впечатление, что оно каким-то образом отслеживает попытки доступа к элементам EAT. Но на самом деле все проще. EMET берет указатель на поле IMAGE_DATA_DIRECTORY.VirtualAddress у kernel32.dll и у ntdll.dll и ставит на эти адреса хардварный брейкпоинт (т.е. через отладочные регистры). А чтобы ловить исключения он еще ставит свой VEH обработчик, где собственно принимает решение убивать или не надо. Кроме того, для того чтобы его брейкпоинты не сняли, он с перодичностью 100 мс, переустанавливает брейкпоинты. Вот так чудо защита… Шелкоду нужно очистить отладочные регистры, а потом просто уложиться в 100 мс

HSA
Защита от Heap Spraying. Метод состоит в том, чтобы забить под себя стандартные адреса куда выпрыгивает эксплоит. То есть те блоки, где при Heap Spraying будет лежать шелкод, уже будут заняты, и шелкод выполняться не сможет. Для этого имеется список таких адресов:
0x0a040a04
0x0a0a0a0a
0x0b0b0b0b
0x0c0c0c0c
0x0d0d0d0d
0x0e0e0e0e
0x04040404
0x05050505
0x06060606
0x07070707
0x08080808
0x09090909
0x14141414
Обход со стороны малвареписателей простой: использовать другие адреса .

NPA
Защита от попытки выделить память по адресу 1, т.е. нулевая страница. Защита сводится к тому, что EMET сам вызывает NtAllocateVirtualMemory по этому адресу. Снова метод «первонаха». Ничто не мешает освободить эту память и выделить под себя снова.

BUR

Суть проста – к базовым адресам выделяемых сегментов (кучи, стека, и прочих) прибавляется случайное число размером в 8 бит

Это неправда. Они просто выделяют рандомное количество(от 0 до 255, отсюда и бред про 8 бит) блоков памяти размером 0×10000 для того, чтобы heap имел псевдорандомный адрес. Опять же, за счет того, что стандартные адреса уже заняты, heap выделят в другом месте. Но он все равно будет выравнен под размер страницы.

Вывод
Нефиговые такие memory leak’и делает этот EMET. А чего вы хотели за такие деньги? Бесплатная халтура.

Изначально, у lisyok@mail.ru нет информации о том, что buldog@mail.ru – это Гарик Харламов. А buldog@mail.ru не знает что lisyok@mail.ru – это Дмитрий Сорокин. Если lisyok напишет просто письмо buldog’у, но buldog не ответит, то так они ничего и не узнают друг о друге.

Другое дело, если отправить письмо с запросом подтверждения о прочтении. Если buldog разрешит отправить отчет о прочтении, lisyok получит письмо вида:

Ваше письмо от Дмитрий Сорокин
Тема asdasd
Отправленное Fri, 07 Oct 2011 19:36:03
Было прочитано Fri, 07 Oct 2011 20:36:34
Получателем Гарик Харламов


Зачет! Человек просто подтвердил, что он согласен выслать подтверждение о прочтении, но он не говорил, что хочет заодно отправить информацию о том, как его зовут. И теперь lisyok знает, buldog@mail.ru – это Гарик Харламов.

На самом деле все фреймворки для написания GUI – проблемные. Я полностью согласен с фразами о том, что какой фреймворк не выбери, написание кода GUI будет не добавлением, а сращиванием. Обязательно придется переделывать код так, чтобы он вписывался в GUI, а не делать GUI на основе существующего кода. Поэтому надеяться на то, что какой-то фреймворк будет лучше для моего проекта – бесполезно. И заявления о том, что какой-то фреймворк лучше подходит для каких-то задач, скорее миф чем правда.

Для подтверждения своих слов вот результат исследования фреймворков используемых в современных приложениях:

Я выбирал приложения где GUI – это не просто форма, две кнопки, один прогресс и список, и нужно лишь напрячь дизайнера, чтобы он это красиво оформил. Я выбирал приложения, где нужно отображать достаточно много данных, где действительно требовалась большая работа по юзабилити, где есть сложные взаимодействия элементов. Ну и где проект уже существует много лет.

Как вы видите, на любом фреймворке можно написать сложный GUI, и на любом фреймворке можно продолжать его расширять. И как видите, некоторые компании не пугает факт того, что свой делать фреймворк – это долго и сложно. Пишут.

На что же влияет выбор фреймворка?
1) Конечно же фреймворк влияет на внешний вид.

MFC, ATL, WTL и их потомки

Комментировать особо нечего. Если сильно постараться, то можно получить конфету похожую на интерфейс windows 7 (Nod), но в целом получается «классика».

QT

Белое, но не пушистое, модное направление.

HtmlLayout и производные

Совсем новое направление, но люди используют. И получается, имхо очень даже прилично.

Экзотика

А GTK-то может быть вполне приятным глазу.

Астру cerulean studios «пилили», насколько я помню, почти 3 года. Все это время они, похоже, изобретали свой кросплатформенный фреймворк с панелями и виджетами на основе GDI+. Поражаюсь как они смогли так долго не выпускать новых версий и не помереть…

2) Фреймворк влияет на сложность поиска людей
Вот вбили вы себе в голову к примеру, что надо писать GUI только на WxWidgets. Даете объяление, находите какого человека, который думает что знает как писать на wxWidgets. Он начинает делать GUI. GUI растет, кода все больше, а потом этот человек берет и уходит. А за то время, пока вы писали GUI, ситуация изменилась, и желающих писать на wxWidgets больше не осталось. Все ушли на WPF, к примеру. Или еще есть любители wxWidgets, но неспособные разгрестись в сложном GUI, который был создан первым человеком, а профессионалов нет. И что дальше? Переписывать заново?

Поэтому стоит сделать запрос вида «резюме с++ ИМЯ_ФРЕЙМВОРКА» в гугл чтобы оценить сложность поиска человека. На момент написания статьи гугл выдавал вот такое:
MFC – 120000 результатов
WTL – 17600
ATL – 46700
QT – 112000
Htmlayout – 113 (sic!)
GTK – 7600
wxWidgets – 17500
У вас все еще есть вопросы?
Конечно же, эта статистика гугла не говорит о том, что ATL-программиста ровно в 3 раза легче найти, чем WTL-программиста. Но какая-то корреляция здесь есть: ATL-программистов все же проще будет найти, чем человека для GTK или WTL.

Для полноты картины:
C# WPF – 1280000 результатов! Мухи не ошибаются

3) Фреймворк влияет на разработку
И вот только в-третьих стоит начинать думать, о том грабли какого фреймворка, вас ударят менее сильно. Фреймворки навязывают размер приложения, одинаковый/изменчивый внешний вид под разными ОС и темами рабочего стола, сложность создания кастомных контролов, способ создания MUI и хранения ресурсов, степень корявости UI-дизайнера, шаблоны проектирования, но это уже холиварная тема…

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

Как это сделать

how do you do – как вы это делаете?
alright – всегда правой.

Понадобятся довольно прямые руки и понимание как стыковать ассемблер с си. Но до того как начать декомпиляцию предстоит еще 4 этапа.

Этап №1. Создание базы
Нельзя реассемблировать просто так любую базу иды. Нужна девственная, а не та в которой проводится реверсинг. Иначе это будет весьма веселое занятие, как в статье у Касперски. Наша цель получить компилируемый ассемблер, а не ассемблер похожий на тот, что в IDA (с примененными на нем энумами, структурами, коментами). Поэтому создаем базу с ноля.

Перед тем как создавать базу, я рекомендую изменить в файле ida.cfg настройку

ASCII_PREFIX            = "a"

на

ASCII_PREFIX            = "ga"

Это префикс, который ида проставляет строкам. Если использовать просто «a», то строка «%d%d» получает имя aDD, что является ассемблерной инструкцией. Оно нам надо?

В окне «Load new file»:

Все. Теперь можно грузить.

Этап №2. Подготовка базы к генерации ассемблера
База создалась, но анализ не начался, потому что отключен. Так и должно быть.
Перед тем как отпустить анализ, нужно удалить в окне Type Libraries (shift-F11) все библиотеки типов. Иначе затянет кучу структур и энумов, которые нам при реассембировании будут только проблемы создавать. Отпускаем автоанализ и ждем завершения.

Теперь:
Раскрываем все hidden функции. Иначе в ассемблер попадет текст:

[00000005 BYTES: COLLAPSED FUNCTION RegisterClassA(x). PRESS KEYPAD "+" TO EXPAND]

А не сам код.

Удаляем align’ы. Если ида случайно промаркирует данные кодом, то она запросто может вставить там align директивы, тем самым просто отбросит изначальные данные. И константные указатели в ассемблере начнут указывать в никуда.
Все align директивы нужно удалить. Вот в помощь IDC скрипт:

auto ea,f;
for (ea=0x400000;ea<"ваш адрес";ea++)
{
if (isAlign(GetFlags(ea)))
   MakeUnkn(ea,DOUNK_EXPAND);
}

Обязательно нужно отключить деманглинг, иначе MASM потом будет возмущаться.

Импорт. Это проблема с которой сталкиваешься, когда уже казалось бы все проблемы этапа №3 решены. А приходится все начинать заново. Все потому, что ida проставляет импортируемым функциям имена из секции импорта. Она понятия не имеет какие там нужны имена функций, чтобы импорты смог потом подхватить линкер. В двух словах на примере:
Чтобы линкер подхватил импорт win api, например функцию CreateWindowExA импорт должен выглядеть вот так:

extrn __imp__CreateWindowExA@48:dword

А ида генерит вот так:

extrn __imp_CreateWindowExA:dword

или так:

extrn CreateWindowExA:dword

а если импорт встречается дважды, то еще и вот так:

extrn __imp_CreateWindowExA_0:dword

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

	for (ea_t ea=НАЧАЛО СЕКЦИИ ИМПОРТА;ea<КОНЕЦ СЕКЦИИ ИМПОРТА;ea+=4)
	{
		int purgedBytes=0;
		if (netnode_supval(ea,0xf,&purgedBytes,sizeof(purgedBytes),'A')!=-1)
		{

			if (purgedBytes)
				purgedBytes--; // это не хак, там действительно всегда на 1 байт больше

			char name[250]={0};
			get_true_name(BADADDR,ea,name,sizeof(name));

			char * pname=name;
			if (!strncmp(name,"__imp_",6))
				pname+=6;

			char newName[250]={0};
			sprintf(newName,"__imp__%s@%d",pname,purgedBytes);
			set_name(ea,newName);
		}

	}

Этот код вычитывает размер «purged bytes» для каждой из функции и заменяет имя импорта на правильное. В моем случае exe файл использовал только библиотеки windows. Соответственно там везде был stdcall, и фокус проканал. Для повторяющися импортов, где в имени был суффикс «_0″, пришлось руками удалить дубликат в сгенеренном ассемблере.

В самом конце обязательно нужно проверить, чтобы не было кода в данных. Чтобы не было приколов типа как с align’ами.

Все, можно генерить ассемблер.

Этап №3. Работа напильником, приведение ассемблера в компиляберный вид
Ассемблер, который генерирует IDA раньше был заточен под TASM, сейчас слава богу есть выбор, и «Generic for Intel 80×86″ это почти MASM. Поэтому напильником теперь пользоваться приходится гораздо меньше.
Что придется изменить перед тем как пытаться собрать через ML:

Могут быть еще какие-то мелкие проблемы несовместимости синтаксиса иды и MASM. Но не думаю, что будут какие-то особые сложности.
Наконец можно пробовать скомпилировать.

Я все также собираю командой: ML.EXE /coff /Fl /Sf /I. /Zi /c /Cp /Zp1 /Zm /Ta
Потому что мне нужен obj, который я буду потом линковать к моим сишным сорцам. В моем случае перечисленных выше действий оказалось достаточно. Мой asm файл, размером 32 мб, скомпилился в красивый obj.

Этап №4. Сборка в Visual studio
Я создавал пустой проект типа «windows application» и добавлял туда конечный asm файл. Дальше прописывал для asm файла custom build tool и командную строку для ML. В настройках линкера я отключал DEP и ASLR, и указывал имя start в поле Entry Point. Этого достаточно, чтобы собрался EXE файл. Таким образом будет получен бинарь который прямо с энтрипоинта двинет в функцию start, которая была точкой входа первоначального EXE. Благодаря этому оригинальный runtime init отработает как надо и (о чудо!) программа запустится.

Что придется доделать
TLS колбэки. В новособранном EXE их нет, придется самостоятельно вызывать их перед запуском рантайма.

Как выносить код из ассемблера
Предположим нашел функцию, которую готов переписать как сишный код, или даже уже ее переписал, но непонятно как теперь ее правильно убрать из ассемблера, так чтобы сохранилась работоспособность. Я делал следующим образом:
1) написал свою функцию в си
2) написал wrapper над своей функцией, чтобы соблюсти конвенцию вызова и сохранить все регистры не измененными. Да, оказывается мало просто call перенаправить, нужно еще и окружение не испортить, чтобы по возвращению из вашей функции код смог продолжить выполнение.
пример враппера, который я использовал для перенаправления fastcall в stdcall:

extern "C" __declspec(naked) int * jMyCFunc(Object *object)
{
	static void * result;
	__asm pushad
	__asm push eax
	__asm call MyCFunc
	__asm mov result, eax
	__asm popad
	__asm mov eax, result
	__asm ret
}

3) создавал extern декларацию в ассемблере

extern _jMyCFunc : proc

4) удалял оригинальную функцию в ассемблере и заменял все call sub_XXXX на call _jMyCFunc

Но работает если ваш текущий каталог это c:\build вот так:
matlab -r myscript

Не подходит, сборка многозадачная, текущий каталог пляшет как угодно. Выход обнаружился после долгого и нудного ковыряния в доках матлаба:
matlab -r "cd c:\build, run('c:\build\myscript.m')"
cd c:\build нужно, чтобы matlab не выдал сообщение, что текущий каталог не там же, где .m файл.

Проблема №2: Как заставить сборку дождаться окончания работы скрипта?
Если просто запускать bin\matlab.exe, то управление вернется в сборку сразу же. А матлаб пойдет работать сам по себе. Это связано с тем, что bin\matlab.exe – это просто промежуточный бинарь, который проверяет среду и переключается потом на bin\win32\matlab.exe или bin\win64\matlab.exe. А вот эти matlab.exe уже настоящие. Если запускать именно их, то сборка будет ждать пока не завершится процесс.

Проблема №3: Как заставить матлаб закрыться после выполнения скрипта?
Да, вот такой прикол: матлаб запускается, запускает скрипт и висит дальше, ждет пока его закроют. Еще копаемся в командах матлаба и рожаем:
matlab -r "cd c:\build, run('c:\build\myscript.m'), quit"

Проблема №4: Как заставить матлаб закрыться после ошибки выполнения скрипта?
И еще более веселая проблема. Если во время выполнения скрипта происходит ошибка, то матлаб остается висеть ожидая ввода. Тут уже без «звонка другу» не обошлось:
matlab -r "cd c:\build, try, run('c:\build\myscript.m'); end; quit"

Слава тебе господи, что я на нем не программирую…