Системное программирование *

Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.

Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.

Сегодня, как и обещала, я продолжу тему планирования легких сущностей, которую уже начала в своем цикле статей. В нем я рассказала о внутреннем устройстве tasklet, workqueue и protothread. Конечно, тема не ограничивается лишь этими примерами: есть еще FreeRTOS с ее coroutine, или GNU Portable threads; или можно отойти от структур и библиотек, применяющихся в ОС, и вспомнить различные green threads, которых становится все больше и больше.

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

Привет, Хабрахабр!

В предыдущей статье я рассказал про vfork() и пообещал рассказать о реализации вызова fork() как с поддержкой MMU, так и без неё (последняя, само собой, со значительными ограничениями). Но прежде, чем перейти к подробностям, будет логичнее начать с устройства виртуальной памяти.

Конечно, многие слышали про MMU, страничные таблицы и TLB. К сожалению, материалы на эту тему обычно рассматривают аппаратную сторону этого механизма, упоминая механизмы ОС только в общих чертах. Я же хочу разобрать конкретную программную реализацию в проекте Embox. Это лишь один из возможных подходов, и он достаточно лёгок для понимания. Кроме того, это не музейный экспонат, и при желании можно залезть “под капот” ОС и попробовать что-нибудь поменять.

^{HCF, n. Mnemonic for ‘Halt and Catch Fire’, any of several undocumented and semi-mythical machine instructions with destructive side-effects <...>
Jargon File}

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

Введение
В этой статье мы попробуем разобраться как работает Return Oriented эксплоит. Тема, в принципе, так себе заезженная, и в инете валяется немало публикаций, но я постараюсь писать так, чтобы эта статья не была их простой компиляцией. По ходу нам придется разбираться с некоторыми системными особенностями Linux и архитектуры x86-64 (все нижеописанные эксперименты были проведены на Ubuntu 14.04). Основной целью будет эксплуатирование тривиальной уязвимости gets с помощью ROP (Return oriented programming).

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

^{Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor
golang.org/doc/asm}

На Хабре да и в Интернете в целом есть довольно много информации про использование языков ассемблера для всевозможных архитектур. Пролистав доступные материалы, я обнаружил, что чаще всего освещаемые в них области использования ассемблера и родственных технологий следующие:

1. Встраиваемые (embedded) системы.
2. Декомпиляция, обратная разработка (reverse engineering), компьютерная безопасность.
3. Высокопроизводительные вычисления (HPC) и оптимизация программ.

И конечно же, в каждой из этих областей существуют специфические требования, а значит свои понятия об инструментах и «свой» ассемблер. Эмбедщики смотрят в код через редактор и дебаггер, реверс-инженеры видят его в декомпиляторах вроде IDA и radare2 и отладчиках ICE, а HPC-спецы — через профилировщики, такие как Intel® VTune™ Amplifier, xperf или perf.
И захотелось мне рассказать об ещё одной области программирования, в которой ассемблеры частые спутники. А именно — об их роли при разработке программных моделей вычислительных систем, в простонародье именуемых симуляторами.

Доброго времени чтения, уважаемые участники habrahabr.ru

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



Попытка описания исходных данных для анализа:

Синими — с подписью вверху «Бытие» — нарисованы гиперболические конусы, отображающие усложнение природы. Ось симметрии конусов — ось «Абстрактность».

Идея в следующем. Чтобы не было разыменования нулевого указателя, нужно, чтобы не было нулевого указателя. Ваш КО. Так сложилось, что однажды я исправил небольшую проблему в ядре Linux, но это была не текущая ветка ядра, а стабильная. В текущей, на тот момент, эту проблему тоже исправили, но по другому.

Привздохнув, произнесла:
«Как же долго я спала!»

Когда-то, впервые встретив Unix, я был очарован логической стройностью и завершенностью системы. Несколько лет после этого я яростно изучал устройство ядра и системные вызовы, читая все что удавалось достать. Понемногу мое увлечение сошло на нет, нашлись более насущные дела и вот, начиная с какого-то времени, я стал обнаруживать то одну то другую фичу про которые я раньше не знал. Процесс естественный, однако слишком часто такие казусы обьединяет одно — отсутствие авторитетного источника документации. Часто ответ находится в виде третьего сверху комментария на stackoverflow, часто приходится сводить вместе два-три источника чтобы получить ответ на именно тот вопрос который задавал. Я хочу привести здесь небольшую коллекцию таких плохо документированных особенностей. Ни одна из них не нова, некоторые даже очень не новы, но на каждую я убил в свое время несколько часов и часто до сих пор не знаю систематического описания.

Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.

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

В пятой части нашей серии статей мы показали, как можно использовать прерывания BIOS'а после перехода в защищенный режим, и в качестве примера определили размер оперативной памяти. Сегодня мы разовьем этот успех и реализуем полноценную поддержку работы с дисками с файловой системой FAT16 и FAT32. Работу с файлами на диске можно разбить на 2 части: работа с файловой системой и работа с диском на уровне чтения/записи секторов. Можно сказать, что для этого нам нужно написать «драйвер» файловой системы и «драйвер» диска.

Здравствуйте, уважаемые читатели Хабра.
С вами снова я и мы продолжаем копаться в различных реализациях UEFI во имя добра. Есть у меня один старый китайский GSM-модем, который на моем Dell Vostro 3360 определяется через раз, а на более старых ноутбуках — нормально. После нескольких экспериментов с подключением его через переходник к основному ПК выяснилось, что ему почему-то не нравится подключение через PCIe Gen2, и хотелось бы переключить порт на Gen1, но в UEFI Setup нужной настройки не оказалось. Печально, но не смертельно, ведь очень часто производители устройств не удаляют оригинальные меню производителя UEFI, а просто скрывают их, либо показывают на их месте свои, поэтому после небольшого реверс-инжиниринга оригинальное меню можно вернуть на место, что у меня и получилось. В этот раз одной IDA Demo уже не обойтись, т.к. DXE-драйверы в большинстве современных UEFI собираются для архитектуры x86-64, поэтому вместо нее будем использовать radare2.
На лавры первооткрывателя не претендую и подобным модификациям сто лет в обед, но постараюсь показать, как сделать подобную модификацию самостоятельно.
Если вам все еще интересно — добро пожаловать под кат.

И снова здравствуйте, уважаемые хабрачитатели.

В рамках борьбы за возможность модификации UEFI на ноутбуках HP пришлось отломать еще одну защиту, на этот раз более современную. Видимо, отдел разработки прошивок в HP догадался, что предыдущая защита была не ахти, и потому они решили радикально её улучшить, поэтому метод обхода защиты DXE-тома из предыдущей статьи перестал работать, и мне опять понадобилось вооружаться дизассемблером, разрабатывать конвертер из TE в PE и отвечать на те же вопросы: где находится цифровая подпись, кто именно ее проверяет и как сделать так, чтобы проверка всегда заканчивалась успехом.

Если вас интересуют ответы и описание процесса их поиска — прошу под кат.

Здравствуйте, уважаемые читатели Хабра.

После долгого перерыва с вами опять я и мы продолжаем копаться во внутренностях UEFI. На этот раз я решил показать несколько техник, которые позволяют упростить реверс и отладку исполняемых компонентов UEFI на примере устаревшего-но-все-еще-популярного PEI-модуля SecureUpdating, который призван защищать прошивку некоторых ноутбуков HP от модификации.

Предыстория такова: однажды вечером мне написал знакомый ремонтник ноутбуков из Беларуси и попросил посмотреть, почему ноутбук с замененным VideoBIOS'ом не хочет стартовать, хотя такой же точно рядом успешно стартует. Ответ оказался на поверхности — не стартующий после модификации ноутбук имел более новую версию UEFI, в которую добрые люди из HP интегрировали защиту от модификации DXE-тома (а там и находится нужный нам VideoBIOS вместе с 80% кода UEFI), чтобы злобные вирусы и не менее злобные пользователи ничего там не сломали ненароком. Тогда проблема решилась переносом PEI-модуля SecureUpdating из старой версии UEFI в новую, но через две недели тот же человек обратился вновь, на этот раз на похожем ноутбуке старая версия модуля работать отказалась, и моя помощь понадобилась вновь.
Если вас заинтересовали мои дальнейшие приключения в мире UEFI PEI-модулей с дизассемблером и пропатченными переходами — добро пожаловать под кат.

Мы публикуем обзор нового сервера HP ProLiant ML350 Gen9 от Евгения KorP Елизарова

В конце 2014 года большая тройка производителей серверов анонсировала новые модели серверов. Компания HP представила больше 10 обновлённых моделей серверов, среди которых был и HP ProLiant ML350 Gen9.



Главными особенностями нового сервера являются:
— поддержка процессоров нового поколения Intel Xeon E5-2600 v3
— поддержка памяти HP SmartMemory DDR4
— обновлённый контроллер HP Smart Array P440ar (SAS 12 Гбит/с)
— обновлённый контроллер HP Dynamic Smart Array, поддерживающий совместную работу с контроллерами HP Flexible Smart Array и Smart SAS HBA.

С удивлением обнаружил, что это ожидаемое многими событие почему-то обошло Хабр стороной. Думаю, что для многих программистов, следящих за этим языком программирования, будет полезно узнать, что тот самый релиз версии Rust 1.0.0 Alpha состоялся 9 января. В этой версии наконец-то стабилизировали ядро языка и большую часть стандартной библиотеки, так что теперь можно начинать писать на Rust'е программы не боясь, что через неделю что-то сломается после обновления компилятора.

От себя могу добавить, что язык действительно интересный и, как минимум, стоит внимания.

Соавтор: Святослав Размыслов SvyatoslavMC.

В рекламных целях мы решили попробовать проверить ядро Linux с помощью нашего статического анализатора кода. Эта задача интересна своей сложностью. Исходные коды Linux чем только не проверялись и проверяются. Поэтому найти хоть что-то новое, весьма сложная задача. Но если получится, то это будет хорошая рекламная заметка о возможностях анализатора PVS-Studio.

Уважаемый читатель,
в своем проекте ты наверняка написал инструмент логирования и с успехом применяешь его для анализа трудно-диагностируемых багов. Но ты всегда сталкивался с ситуацией:

• когда запись в файл — консоль драматически сказывалось на воспроизодимости бага;
• когда мульти(процессорное/поточное) приложение часто обращается к драйверу и ты не можешь сопоставить временные метки и потоки;
• когда баг воспроизводится на стороне кастомера, сеанс teamviewer бесполезен, да к тому же версия с отладочными символами private;
• когда системное приложение падает до того, как система успеет скинуть логирование на диск;
• или когда макрос для логирования выглядит в лучшем случае как

  #define TraceDbg(format, ...) \
      printf( "(p %d, t %d) - (%s,%d) %s(): " format, GetCurrentProcessId(), GetCurrentThreadId(), __FILE__, __LINE__,__FUNCTION__, __VA_ARGS__ );
  

• когда придумываешь очередной способ вывести на экран ipaddr или UUID

В статье я представлю быстрый, надежный и универсальный для отладки с минимальным оверхедом инструмент диагностики, предлагаемой MS для системных приложений — WPP, рассмотренный частично в публикации «EventTrace for Windows. Высокоскоростная передача отладочных сообщений драйвера по сети».

Периодически, как правило во вторую среду месяца, можно услышать истории о том, что Windows после очередного обновления перестает загружаться, показывая синий экран смерти. В большинстве случаев причиной такой ситуации оказывается либо руткит, либо специфичное системное ПО, фривольно обращающееся со внутренними структурами ОС. Винят, конечно, все равно обновление, ведь «до него все работало». С таким отношением не удивительно, что «Майкрософт» не поощряет использование всего, что не документировано. В какой-то момент, а именно с релизом Windows Server 2003, MS заняла более активную позицию в вопросе борьбы с чудо-поделками сторонних разработчиков. Тогда появился механизм защиты целостности ядра — kernel patch protection, более известный как PatchGuard.

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

Четвертая часть перевода D Programming Language Tutorial от Ali Çehreli.