Assembler *

Все началось с глупой ошибки. В тексте программы вместо оператора x=20; где x – целая переменная со знаком и размером в байт, случайно написали x=200;

И компилятор, что называется не моргнув глазом, сформировал команду записи в переменную x константы 0C8H, что вообще-то соответствовало оператору x=-56; Выяснилось, что за долгие годы эксплуатации этого компилятора ни одна собака ни один пользователь (включая и нас самих) никогда не писал подобных ляпов и поэтому ошибка в компиляторе оставалась незамеченной. А виноваты оказались команды сужения данных.

Это стандартизированные методы реализации и вызова функций.

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

Стек (от англ. Stack) - специально отведённое место в памяти для хранения временных данных. Он подчиняется следующим правилам

Эта история началась когда удобный для меня инструмент VSCode из за одного плагина на борту стал не совсем удобен. А именно, «natizyskunk.sftp» плагин, который позволяет подключится по протоколу (S)FTP к серверу, и вносить изменения на сервер, просто сохранив файл. Всё нечего, если бы настройки подключения к серверам не хранились в корне отдельно взятого проекта. Когда у тебя с десяток проектов, ещё можно потерпеть, но более 70 проектов и они все на разных серверах, то перенос и добавление в каждый из проектов актуальной настройки, например пароль, который периодически меняется, заставляет как минимум раздражённо искать подходящую настройку и с комбинацией клавиш Ctrl+C, Ctrl+V, менять устаревшие настройки или добавлять новые. В дальнейшем оказалось, что коллеги пользуются другими идентичными плагинами с названиями «liximomo.sftp», «doujinya.sftp-revived».

Я уже плакался по поводу исключения в x86-64 команд двоично-десятичной арифметики DAA/DAS и плакался по поводу отмены команды проверки целочисленного переполнения INTO. Теперь настала очередь плакаться по поводу выброшенной команды BOUND. Как говорится, леди и джентльмены, подставляйте свои жилетки и декольте. Начинаю плач.

Отечественный процессор 1967ВН028 от фирмы Milandr предназначен в первую очередь для решения вычислительных задач и поэтому на его борту есть всего два способа обмена данными с внешним миром. Один из них - работа с LVDS LINK портами (разобран в прошлых статьях) и второй это внешняя параллельная шина.

Часто возникает путаница с тем, что же понимается в компьютерных науках под «атомарностью». Как правило, атомарность – это свойство процесса, означающее, что он совершается за один шаг или операцию. Но в языке C++  атомарность определяется гораздо более специфичным образом. На самом деле, при использовании std::atomic  с классами и типами еще не гарантируется, что весь код будет подлинно атомарным. Хотя, атомарные типы и входят в состав языка C++, сами атомарные операции должны поддерживаться на уровне того аппаратного обеспечения, на котором работает программа. Эта статья – простое руководство, помогающее понять, что же представляет собой атомарность в C++.

Хай Хабр! Это серия статей по написанию моей ОС с нуля. Я лютый фанат ретропрограммирования, поэтому я мгновенно забуду про существование EDК. Просьба не писать комменты по типу "BIOS давно устарела где UEFI?". Пишу это просто чтобы было, что почитать вечером и порелаксить. Спасибо.

Хай Хабр! Это серия статей по написанию моей ОС с нуля. Я лютый фанат ретропрограммирования, поэтому я мгновенно забуду про существование EDК. Просьба не писать комменты по типу "BIOS давно устарела где UEFI?". Пишу это просто чтобы было, что почитать вечером и порелаксить. Спасибо.

Данная статья в большей степени является не руководством и не мануалом, а просто моими заметками. Идея этой статьи собрать множество особенностей и знаний в одно целое, надеюсь, она кому-то пригодится =)

Я уже упоминал, каким неприятным сюрпризом оказалось исключение команды INTO из системы команд x86-64, когда я переводил компилятор на эти команды. Давайте разберемся, нужна ли сейчас команда, которая отвечала за контроль целочисленного переполнения еще со времен процессора 8086.

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

Исследование и изменение исполняемого кода в процессе работы программы – что может быть интересней? Intel Pin – фреймворк для динамической бинарной инструментации (Dynamic Binary Instrumentation, DBI) исполняемого кода. Этот фреймворк обладает широкими возможностями по анализу и модификации кода. Мне было очень интересно посмотреть вживую на доступные в нем функции по анализу отдельных инструкций. И наконец подвернулась такая возможность.

В статье будет рассмотрено получение адреса перехода для инструкции jmp, перехват вызова функции, находящейся за таблицей инкрементальной линковки (Incremental Linking Table, ILT) – и все это средствами Pin.

Привет, Хабр! В свободное от работы время по вечерам мне нравится воплощать в жизнь свои сумасшедшие идеи. В один из таких вечеров родилась мысль реализовать компилятор кода в машину Тьюринга. Осознав всю тщетность бытия сложность реализации, было принято решение начать с чего-то более простого – симулятора простенького процессора со своим собственным ассемблером, в котором команды выполнялись бы с помощью различных состояний машины Тьюринга, а данные хранились бы на одной ленте. В конечном итоге удалось осуществить практически первоначальную задумку, а именно получить одну единственную машину Тьюринга, способную выполнять скомпилированную из NASM подобного ассемблера программу без какого-либо внешнего взаимодействия.

Среди бесчисленных режимов адресации архитектуры х86 существует один такой…
Впрочем, почему «бесчисленных» режимов? Если разобраться, то их немного. Со времен первого процессора 8086 адресация укладывалась в байт, который имел аббревиатуру MODRM, где «MOD» - это собственно режим адресации (т.е. mode), «R» - регистр и «M» - очевидно, память (memory).
Если не рассматривать дальнейшее совершенствование системы адресации с помощью SIB-байта, то, поскольку под MODE в MODRM-байте выделено всего два бита, получается, что возможны всего-навсего четыре режима адресации.

А вы знали, что бывает такая атака на компилятор через бэкдор, защититься от которой невозможно? В этом посте я покажу вам, как реализовать такую атаку менее чем в 100 строках кода. Кен Томпсон, создатель операционной системы Unix, рассказывал о такой атаке еще в 1984 году в своей лекции по поводу присуждения Премии Тьюринга. Такая атака по-настоящему опасна и сегодня, причем, не известно решений, которые обеспечивали бы полную неуязвимость от нее. Вирус  XcodeGhost, открытый в 2015 году, проводит атаку через бэкдор по методу, предложенному именно Томпсоном. Я покажу здесь атаку Томпсона на языке   C++, но этот пример легко адаптировать для любого другого языка. Дочитав эту статью, вы крепко задумаетесь, а осталось ли у вас вообще какое-то доверие компилятору.

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

Как-то мне пришла в голову мысль о том, насколько же быстрее современные процессоры по сравнению с ранними экземплярами. Да, можно размышлять об этом эмпирически - зная тактовую частоту и особенности микроархитектуры (как устроен конвейер, сколько есть ALU, и т.д.), можно прикинуть производительность Intel 4004. Пусть и не в FLOPS'ах, ибо нативная поддержка чисел с плавающей запятой появилась позже. Но это будет весьма грубая прикидка, так как у этого процессора есть несколько интересных черт: разрядность только 4 бита (а не 64, как у большинства современных машин), очень скудный набор инструкций (нет даже AND'a и XOR'a!) и ограничения переферии (в частности памяти не так уж и много).

Поэтому я решил исследовать вопрос на практике. В качестве бенчмарка выбор пал на вычисления числа π. В конце-то концов, даже ENIAC в дремучем 1949 году справился с этой задачей! [2]

Сразу хочу сказать, что это только демонстрация возможностей procmon для определения проблемных мест в программном обеспечении. 1С83 была выбрана для опытов из-за неочевидности способа поиска точки входа в процедуру проверки наличия установленных эмуляторов ключа. Она выполняется через различное время после старта порядка 3~10 мин, и вызывает появление окна «нарушение целостности системы» с последующим закрытием приложения. Я призываю всех использовать только лицензионное программное обеспечение. Рассматривать эту статью, как описание возможности взлома, нет смысла. Хотя бы потому, что 1С83 давно взломана и без меня. Любой 1с-ник за секунду вам скажет, как ее запустить без ключа.

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

Итак, ставим фильтр по имени процесса 1с.