На пятничном семинаре учебного проекта лаборатории МФТИ-Интел один из студентов задал мне примерно такой вопрос: а почему 64-битный вариант архитектуры процессоров Intel называется x64, а 32-битный — x86? Я начал объяснять, что не всё так просто. Захотелось нарисовать более полную картину. Ведь на самом деле это не x64, и даже не x86.

С каждым новом поколением процессоры Intel вбирают в себя все больше технологий и функций. Некоторые из них у всех на слуху (кто, например, не знает про гипертрединг?), о существовании других большинство неспециалистов даже не догадываются. Откроем всем хорошо известную базу знаний по продуктам Intel Automated Relational Knowledge Base (ARK) и выберем там какой-нибудь процессор. Мы увидим здоровенный список функций и технологий — что скрывается за их таинственными маркетинговыми наименованиями? Предлагаем углубиться в вопрос, обращая особое внимание на мало известные технологии — наверняка, там найдется много интересного.

Недавно, когда я изучал досовые бут-секторы, я обнаружил довольно загадочную вещь. DOS распознает, является ли бут-сектор загрузочным, по нескольким критерям, и один из них (странно, да?) — есть ли в первых двух байтах jump-инструкция, которая указывает, соответственно, куда-нибудь за BPB. В модуле MSDISK.INC из MS-DOS 3.21 OAK как раз и происходят такие проверки. Модуль проверяет, начинается ли BPB с прыжка, при этом за верную jump-инструкцию он принимает опкоды EBh (short JMP), E9h (JMP), или 69h. Стоп. 69? Это же IMUL!
Не-а, не IMUL. Комментарий в коде утверждает, что это «direct jump»:

   cmp   byte ptr cs:[DiskSector],069H  ; Is it a direct jump?
   je    Check_Signature                ; don't need to find a NOP
   cmp   byte ptr cs:[DiskSector],0E9H  ; DOS 2.0 jump?
   je    Check_Signature                ; no need for NOP
   cmp   byte ptr cs:[DiskSector],0EBH  ; How about a short jump.
   jne   BadDisk

Хорошо, вот только про 69h в документации 8086 ничего не сказано! Да, в 8186 и далее — это опкод IMUL, но то, что 8086 умеет IMUL — крайне маловероятно. Тем более, комментарий ясно указывает, что это прыжок.

Может быть, на процессорах 8086 69h ведёт себя как прыжок? Вопрос хороший, вот только информации по этому поводу почти нет.

Привет, %username%!
Декодирование IA-32 кода — задача архисложная. Чтобы в этом убедиться, можете обратиться к Intel Software Development Manual или к статьям, ранее написанным на хабре: Префиксы в системе команд IA-32, Правильно ли работает ваш дизассемблер?. Давайте посмотрим, как с этой задачей борется функционально точный полноплатформенный симулятор Wind River Simics, позволяющий создать высокопроизводительное виртуальное окружение, в котором любая электронная система, начиная с одной платы и заканчивая целыми многопроцессорными, многоядерными и даже многомашинными системами, может быть определена, разработана и запущена.
Большинство библиотек для декодирования IA-32 инструкций генерируют или используют таблицы соответствия между кодами операций и инструкциями. Пример использования данного подхода описан в статье Дизассемблер своими руками. Однако декодирование префиксов и аргументов обычно написано руками: libopcodes, metasm, beaengine, distorm. Данный подход обладает существенным недостатком — добавление поддержки новых наборов команд потребует большого количества ручной работы.
Существуют и другие способы создания декодеров, например с помощью языка GDSL. Данный подход является универсальным и позволяет создавать декодеры для любых архитектур.
Simics же использует совершенно другой не менее универсальный подход для работы с IA-32 инструкциями, названный раздельным декодированием. Также Simics имеет возможность использования внешних декодеров, но об этом немного позже.

Сегодня я хочу рассказать об одной интересной сложности декодирования/дизассемблирования IA-32 инструкций.

Перед прочтением этой статьи рекомендую обратиться в статье «Префиксы в системе команд IA-32», описывающей общую структуру IA-32 команды и существующие префиксы. В этой статье я подробнее расскажу про обязательные префиксы (англ. mandatory prefixes) и некоторые нюансы, связанные с ними.

Сегодня я хочу рассказать вам о префиксах в системе команд Intel IA-32 в 32- и 64-битных вариантах (также именуемых как x86 и x86_64). Но для начала напомню вкратце общую структуру IA-32 инструкции:

• Префиксы. Могут отсутствовать. Может присутствовать сразу несколько.
• Опкод. Может состоять из одного, двух или трех байтов.
• Mod_R/M байт. Используется для адресации операндов. Может отсутствовать в кодировке, если инструкция не имеет явных операндов.
• SIB (Scale Index Base) байт. Второй байт, использующийся для адресации операндов в памяти. Может отсутствовать.
• Байт смещения адреса (англ. displacement). 1, 2, 4 или ни одного байта.
• Константа (англ. immediate). 1, 2, 4 или ни одного байта.

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

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

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

Объем статьи получился неожиданно большим, поэтому я разбил ее на три части:

• В первой части будут рассмотрены возможности интегрированного в IDE Delphi отладчика, даны рекомендации по наиболее оптимальному его использованию и общие советы по конфигурации среды. Материал данного раздела предназначен как начинающим разработчикам, так и более подготовленным специалистам.
• Во второй части статьи будет рассмотрена изнаночная сторона работы отладчика на примере его исходного кода, подробно рассмотрены механизмы, используемые им при отладке приложения, показаны варианты модификаций памяти приложения, производимые отладчиком во время работы.
• В третьей части статьи будет рассмотрено практическое использование отладчика на примере обхода защиты приложения, использующего некоторый набор антиотладочных трюков.

Собственно, приступим.

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

Сразу-же оговорюсь, в противостоянии приложение/отладчик, всегда победит последний :)
Но, только в том случае, если им будет пользоваться грамотный специалист, а с такими спецами бороться практически бесполезно (ну, если вы конечно не обладаете как минимум такой же квалификацией).

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

Вот что-то такое мы и рассмотрим, только в очень упрощенной форме.

Класс CSharpCodeProvider позволяет программе на C# компилировать код на C#. Обычный вопрос – «зачем». Обычные ответы:

1. исполнение кода, данного пользователями, как на ideone.com,
2. «ну мало ли зачем» и
3. «а это уже отдельный вопрос»

Сегодня мы используем этот класс для удобного воспроизведения гонки двух процессов.

Перефразируя известную поговорку: «не делает багов тот, кто ничего не кодирует». Каждый разработчик умеет и любит делать баги, но не любит потом их исправлять. Ошибки в коде в одном случае приводят просто к некорректной обработке данных программой, а в другом — к исключениям (вылетам, падениям, крашам). В этом посте я расскажу о том, как можно автоматизировать сбор данных о краше программы, чтобы сильно облегчить себе жизнь при разборе и устранении ошибок.

В первой части статьи были рассмотрены некоторые нюансы работы с интегрированным отладчиком Delphi — не все конечно, но наиболее необходимые разработчику. Теперь задача выглядит несколько иначе: рассмотрим его работу изнутри на примере его исходного кода. Для того чтобы не сильно утомлять вас описанием API функций и не разжевывать все этапы отладки, описывать его работу я буду на примере класса TFWDebugerCore. Часть не особо важных моментов я опущу, при желании вы их сможете уточнить просмотрев код данного класса.

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

Если же вы ранее никогда не сталкивались с самостоятельной реализацией отладчика, но заинтересованы в ней, то как минимум вы должны начать с данной ссылки: Debugging and Error Handling
По ней вы сможете узнать об основных аспектах отладки, как-то структурной обработке исключений, работой с отладочной информацией, минидампами. Работой с образом исполняемого файла, заголовками, секциями, картой памяти процесса, что такое RVA и VA и прочее-прочее.
Но это только если захотите разобраться во всей этой кухне.

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

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

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

Большинство проектов, использующих коптеры, опираются на ручное дистанционное управление, полностью автономных систем пока нет. Но для индустриального использования это необходимо; человеческий фактор — причина большинства аварий. Ниже рассказ пойдёт про то, как мы делали свою систему стабилизации с помощью ПИД, позволяющую свести к минимуму участие человека в процессе работы дрона.

^{Один из тестовых полётов нашего коптера}

Технологический процесс с проектными нормами 32 нм.
Два ядра ARMv7 с тактовой частотой 1,3 ГГц
Оперативная память – 1 Гбайт.

Технологический процесс с проектными нормами 150 нм.
Одно ядро PowerPC с тактовой частотой 200 МГц.
Оперативная память – 256 Мбайт.

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

В связи с известными событиями в новостях появились сообщения о том, что США запретили поставки микроэлектроники для российских спутников и военной техники.
Такое развитие событий может негативно повлиять на состояние российской аэрокосмической и оборонной промышленности, ведь ежегодный импорт электроники для космической промышленности составляет два миллиарда долларов, и это чипы, критически важные для работоспособности спутников. Некоторые чиновники (смотрите статью по ссылке) уже начали предаваться панике и разговаривать о покупке электроники в Китае, который якобы наладил у себя производство всего необходимого. Я же хочу немного рассказать о том, какие микросхемы разрабатываются и производятся для космической отрасли в России.

Первую часть вы можете прочитать здесь.


Специалисты команды полета STS-107 Лорел Б. Кларк, Рик Д. Хасбэнд и Калпана Чаула отдыхают в своих спальных местах на средней палубе. Source: NASA / WikiMedia Commons

Шоу начинается

«Отключение электроэнергии оставило бы в рабочем состоянии только самые основные модули управления судном, поддержки жизнедеятельности и коммуникации.»
— Из Приложения D.13 отчета Комиссии по расследованию катастрофы шаттла «Колумбия»

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

Каждая новая спецификация OpenMP вводит очень полезные и необходимые дополнения к уже существующему функционалу. Например, в версии 3.0 были добавлены так ожидаемые задачи (tasks), позволившие решать ещё больший спектр задач по распараллеливанию приложений. В 3.1 целый ряд улучшений по работе с задачами и редукциями.

Но по сравнению с тем, что нам теперь даёт стандарт 4.0, предыдущие нововведения кажутся какими-то мелкими. Последняя версия расширила типы поддерживаемого параллелизма, чего раньше никогда не замечалось.

Есть несколько важных аспектов, которые нужно обязательно учитывать при создании приложения, производящего какие-либо вычисления, а точнее — операции с числами с плавающей точкой. Что мы ждём и планируем получить от таких приложений (в большинстве случаев, научных)? В первую очередь, нас интересует точность вычислений – полученный результат должен быть наиболее близок к «правильному». Другая сторона медали – стабильность результатов и портируемость приложения. Нам важно иметь возможность получать одинаковый, неизменно повторяющийся от запуска к запуску результат, причём на разных машинах/архитектурах. Ну и последний, но не менее значимый пункт – производительность. Насколько быстро при всём этом будет выполняться наше приложение, и когда мы получим результаты наших вычислений?

В компиляторе компании Intel есть набор опций, отвечающих за контроль оптимизаций вычислений над числами с плавающей точкой. Рассмотрим преинтереснейший ключик –fp-model, который, судя по описанию в документации, управляет семантикой вычислений над числами с плавающей точкой. Кстати, стоит отметить, что похожие ключи есть и в других компиляторах, не только Интеловском, об этом мы тоже поговорим. По сути, с помощью данного ключика мы и сможем контролировать баланс между производительностью и точностью вычислений. Возможные значения, которые могут быть указаны в опции –fp-model: precise, fast[=1|2], strict, source, [no-]except (Linux*) or except[-] (Windows*). Давайте разберёмся, что они дают при компиляции нашего кода.

Для некоторых мне известны возможные решения. Некоторые изредка встречаются на собеседованиях, реже чем об обедающих философах. Интересно было ознакомиться, как развлекаются в МассТехе.

Миф #1

Все LINQ запросы должны начинаться с ключевого слова 'var'. По сути основная цель ключевого слова 'var' — начать LINQ запрос!

Ключевое слово var и LINQ — это самостоятельные концепции. Ключевое слово var позволяет компилятору вывести тип локальной переменной на основании начального присваивания(неявная типизация). К примеру, следующий код:

var s = "Hello"; 

точный эквивалент для:

string s = "Hello"; 

потому что компилятор выводит тип переменной s как string.

В данной статье я хотел бы рассказать о некоторых особенностях представления объектов в памяти в .Net, оптимизациях, проводимых компиляторах, и продолжить традицию товарища mynameco, написавшего эту статью

Этот пост не ориентирован на кулхацкеров, поэтому если вы знаете, что using компилируется с конструкцией вызова Dispose для энумератора, что для работы оператора foreach не обязательно использовать интерфейсы, а достаточно иметь метод GetEnumerator, возвращающий энумератор корректной сигнатуры, что сам Enumerator — изменяемая (мутабельная) структура, что может стать причиной неожиданного бага… То просьба не заходить и не читать, сэкономьте свое время, не надо оставлять посты вроде «КГ\АМ», «боян», и «Капитаны отаке». Остальных прошу под кат.