Рассказ об уровне взаимодействия с хост-контроллерами растянулся на две статьи и всё равно оставил за кадром некоторые детали — которые, как я надеюсь, заинтересованный читатель может восполнить непосредственно из исходников. Уровень поддержки каналов куда проще и в основном занят тем, что преобразует вызовы API для вышележащих уровней в нужную последовательность действий, включая блокировки, с нужным хост-контроллером.

Открытие канала

Функция USBOpenPipe из API, названная usb_open_pipe в коде pipe.inc, открывает новый канал по указанным характеристикам канала и «родительскому» каналу, где записаны характеристики устройства. Для этого она:

• выделяет пару структур *hci_pipe+usb_pipe, описывающих канал и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocPipe;
• выделяет пару структур *hci_gtd+usb_gtd, описывающих пустой дескриптор передачи и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocTD;
• заполняет указатели: в структуре канала копирует указатель на структуру контроллера и указатель на данные устройства, общие для всех каналов, из «родительского» канала; между структурой канала и структурой пустого дескриптора заполняет указатели туда-обратно; структуру пустого дескриптора делает единственным элементом двусвязного списка каналов;
• инициализирует мьютекс, который будет охранять все операции с этим каналом. Хотя вся обработка событий от USB-контроллеров происходит в потоке USB, про обращения к API нельзя сказать того же: чтение приложением файла с USB-флешки инициирует постановку передачи — и даже не одной — в очередь в контексте потока приложения. Чтобы новая передача не мешала USB-потоку обрабатывать завершение старой передачи, и нужен этот мьютекс;
• захватывает мьютекс набора каналов устройства и убеждается, что устройство ещё не отключено;
• вызывает контроллеро-специфичную инициализацию usb_hardware_func.InitPipe, охраняемую мьютексом, глобальным для контроллера;
• добавляет новый канал в набор каналов устройства и отпускает мьютекс набора каналов;
• при ошибке на одном из этапов откатывает все предыдущие этапы. Поскольку откатить контроллеро-специфичную инициализацию сложнее всего, она сделана на последнем этапе, после которого ошибок быть не может.

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

Здесь в игру вступает планировщик scheduler.inc. Он как раз и выбирает один из списков каналов прерываний, а также убеждается, что для нового канала «достаточно места». Я напомню, что в каждом фрейме FullSpeed-шины под периодические передачи нельзя использовать более 90% времени, а в каждом микрофрейме HighSpeed-шины — более 80% времени.

Здесь я должна отметить, что если вы зачем-то пишете реализацию USB, которая должна работать в ваших условиях, на планировщике можно серьёзно сэкономить. Вам придётся в том или ином виде реализовать всё остальное, что описано в этой серии статей, но при отсутствии большой нагрузки можно вместо полного дерева обойтись всего одним списком каналов прерываний, обрабатываемым каждый фрейм/микрофрейм. Чуть более экономная схема, не слишком усложняющая реализацию, — один список каналов для каждого интервала обработки 1, 2, 4, 8, 16, 32 фреймов. Пока не нужно одновременно обрабатывать более одного устройства с большим трафиком на один хост-контроллер, такой подход ничем не уступает полноценному планировщику. Простая схема «сломается» в некоторых специфичных конфигурациях с двумя или более изохронными каналами FullSpeed-устройств или тремя или более изохронными каналами HighSpeed-устройств, но, быть может, никто и не будет запускать вашу реализацию в столь специфичных условиях?

Если же вы пишете реализацию USB, которая должна работать везде и всегда, планировщик вам тоже придётся написать.

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

Если кто-то из читателей ещё не знает, то, хотя большинство разработчиков KolibriOS русскоговорящие и живут в СНГ, у нас есть также несколько зарубежных разработчиков. Причём один из них, бельгиец Jeffrey Amelynck, нам больше известный под «ником» hidnplayr, участвует в проекте с 2003 года (ещё до того, как KolibriOS отделилась от MenuetOS — уже целых 10 лет!). С первых дней в проекте он решил заниматься поддержкой сети и сетевыми программами, потому что на тот момент в MenuetOS с сетью было очень туго, если не сказать «вообще никак».


На фото — hidnplayr, с помощью собственноручно написанного FTP-client, подключается из-под KolibriOS к своему FTP-аккаунту на FTP-сервере KolibriOS. На заднем плане — файловый менеджер KFM для KolibriOS, написанный одним из основателей KolibriOS Mario_Z

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

Запуск подсистемы USB

Подготовка: USB-контроллеры в списке PCI-устройств

Подсистема USB запускается вызовом usb_init из init.inc в ходе загрузки системы.

К моменту запуска USB уже подготовлен список найденных PCI-устройств pcidev_list. USB-контроллеры опознаются среди всех PCI-устройств по коду класса, подкласса и интерфейса:

Тип	Класс	Подкласс	Интерфейс
UHCI	0Ch	03h	00h
OHCI	0Ch	03h	10h
EHCI	0Ch	03h	20h
XHCI	0Ch	03h	30h

usb_init проходит по списку PCI-устройств несколько раз, каждый раз выделяя USB-контроллеры.

Отключение контроля BIOS

Некоторые BIOS умеют обрабатывать USB-мыши, USB-клавиатуры и USB-флешки, предоставляя данные для операционных систем, не знающих про USB. Данные от мышей и клавиатур преобразуются в формат PS/2 и тем или иным способом доводятся до операционной системы так же, как если бы в системе существовала настоящая PS/2-мышь и/или клавиатура. USB-флешка представляется жёстким диском с точки зрения int 13h — такая поддержка встречается куда чаще поддержки мышей, ибо необходима для загрузки с флешек.
Операционная система может использовать любой режим процессора и самостоятельно обрабатывать любые прерывания. Чтобы BIOS в таких условиях всё же могла получать управление с предсказуемым окружением, ещё в районе 486-х (начиная со специальной версии i386SL, если точно) Intel придумала специальный режим процессора System Management Mode (SMM), в котором и работает BIOS, прерывая операционную систему. В SMM невозможно попасть средствами самого процессора; процессор попадает в этот режим, когда железо материнской платы подаёт специальный сигнал System Management Interrupt (SMI). USB-контроллеры, встроенные в чипсет, как правило, могут генерировать SMI вместо прерывания в зависимости от настроек.

Перевод статьи Дэвида Альберта — Understanding C by learning assembly.

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

Уровни абстракции — отличные инструменты для создания вещей, но иногда они могут стать преградой на пути обучения. Цель этого поста — убедить вас, что для твердого понимания C нужно также хорошо понимать ассемблерный код, который генерирует компилятор. Я сделаю это на примере дизассемблирования и разбора простой программы на С с помощью GDB, а затем мы используем GDB и приобретенные знания ассемблера для изучения того, как устроены статические локальные переменные в С.

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

Прерывания и потоки

Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару cli/sti без собственно спинлока, на многопроцессорных внутри cli/sti остаётся обычный спинлок. Кроме того, контроллер прерываний во время обработки одного прерывания блокирует остальные с тем же или более низким приоритетом.

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

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

Всем доброго времени суток! Я студентка-второкурсница технического ВУЗа. Пару месяцев назад пришла пора выбирать себе тему курсового проекта. Темы типа калькулятора меня не устраивали. Поэтому я поинтересовалась, есть ли что-нибудь более интересное, и получила утвердительный ответ. «Подмена обработчика системного вызова» — вот моя тема.

Введение

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

Зачем?

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

Здравствуй Хабр!

Одно из направлений моей компании — продажа технологических решений в области виртуализации. По долгу службы, приходится делать пилотные проекты или устраивать тестовые стенды. Недавно, компания Citrix выпустила новый продукт под название XenClient XT, который по сути является клиентским гипервизором первого уровня, то есть работает на чистом железе. Основной идеей клиентского гипервизора является создание виртуальных машин на собственном ноутбуке. Где и как это применимо — опустим.

Все современные процессоры Intel и AMD поддерживают технологию аппаратной виртулизации.
И так, в моем распоряжении был ноутбук с H77 чипсетом и Intel Core i7-3820QM процессором. Согласно спецификации от производителя, мой процессор поддерживал Intel Virtualization Technology (VT-x) и Intel Virtualization Technology for Directed I/O (VT-d) технологии. Если первая имеется почти на всех новых ноутбуках, то вторая технология встречается только на топовых моделях. Но она дает много преимуществ, как например прямой проброс GDU в виртуальную среду, соответственно клиентская машина получает полную поддержку 3D. Но давайте не будем углубляться в технологии, отличные от тематики данной статьи.

В моем биосе была возможность включения VT-x, но вот управление технологией VT-d не было предусмотрено изначально.

Архитектура USB содержит несколько уровней. На самом низком уровне специально обученное железо, называемое хост-контроллером (host controller), общается с USB-устройством специальными сигналами. Сигналы кодируют биты, биты складываются в пакеты, пакеты образуют транзакции, транзакции составляют передачи (transfers).

Я рассказываю о программной поддержке USB, поэтому уровни ниже передач почти неинтересны: за них отвечает хост-контроллер. Зато важно, какой интерфейс представляет хост-контроллер софту. Сейчас распространены три интерфейса, и постепенно распространяется четвёртый:

Аббр.	Название интерфейса	Версия	Код поддержки контроллера в KolibriOS
UHCI	Universal Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/uhci.inc
OHCI	Open Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/ohci.inc
EHCI	Enhanced Host Controller Interface	USB 2.0	kernel/trunk/bus/usb/ehci.inc
XHCI	eXtensible Host Controller Interface (новый)	USB 3.0	В KolibriOS ещё не поддерживается

На этом же уровне взаимодействия с контроллерами находятся файлы kernel/trunk/bus/usb/hccommon.inc, где реализованы некоторые функции, общие для всех контроллеров, и kernel/trunk/bus/usb/init.inc, который запускает всю подсистему. Впрочем, не торопитесь пока лезть в код — во-первых, я ещё не рассказала про то, чего же ожидают от него более высокие уровни, а во-вторых, после демонстрации общей схемы я вернусь к отдельным компонентам с подробностями.

Страница KeygenMe на crackmes.de
You have to find a valid serial.

The only protection is the serial ...!

This is a kind of headache… :D

Good luck
Difficulty: 5 — Professional problem to solve
Platform: Windows
Language: Borland Delphi

KolibriOS — открытая операционная система, основанная на MenuetOS (форк произошел в 2004 году), требующая всего 8 МБ ОЗУ для запуска и разрабатываемая русской командой разработчиков исключительно на языке ассемблера. Её дистрибутив занимает одну 1.44 МБ-дискету и, тем не менее, включает в себя текстовый редактор, программу для просмотра изображений, браузер, набор из 30+ игр, различные тесты, системные и прикладные утилиты. Полностью поддерживается FAT12/16/32, в режиме чтения — NTFS, ISO9660 и Ext2/3/4. Написаны драйверы для популярных звуковых, сетевых и графических карт.

В этом году администраторы проекта подали заявку участие в Google Summer of Code 2013, но их предложение было отвергнуто. Причем Google написали, что им нравится проект, но из-за ограниченного бюджета они не могут принять всех из 416 претендентов. Поскольку список нововведений KolibriOS, которые планировалось реализовать на GSoC '13, довольно обширный, и уже внесен в некотором смысле в планы разработки, было решено организовать свой SOC. Поскольку проект некоммерческий, а на донейтной основе маленькому проекту пока что сложно быстро собирать финансирование, разработчики выбрали Kickstarter. Кампания была запущена 3 дня назад, из £5,000 пока что собрано свыше 20%. Сбор средств закончится 31 мая.

Вы можете скачать KolibriOS и решить, стоит ли поддерживать проект, на этой странице: kolibrios.org/ru/download.htm
Адрес Kickstarter-кампании: www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013

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

Итак, что такое планировщик? Планировщик — это часть ОС, реализующая многозадачность. Число процессоров, обычно, намного меньше числа выполняемых задач. Поэтому на каждый процессор приходится несколько задач. В силу своей последовательной природы процессор не может выполнять эти задачи одновременно — и он поочерёдно переключается с одной задачи на другую.

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

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

Данная статья написана в форме поста для блога. Если она окажется вам интересной, то будет продолжение.

Последние четыре месяца посвящаю свободное от работы время написанию игрушечной ОС для x86_64. Исходный код лежит здесь.

Общая задумка (пока весьма далёкая от реализации) следующая: единое 64-битное адресное пространство с вечно живущими нитями (как у Phantom OS); виртуальная машина, обеспечивающая безопасность исполнения кода. На данный момент реализованы:

1. загрузка ядра при помощи multiboot-загрузчика (GRUB);
2. текстовый VGA-режим (16-цветов, kprintf);
3. простой интерфейс настройки отображения страниц;
4. возможность обработки прерываний на C;
5. идентификация топологии процессоров (сокеты, ядра, потоки) и их запуск;
6. работающий прототип вытесняющего SMP-планировщика с поддержкой приоритетов;

Пропустим описание multiboot-загрузки и работы с VGA-режимом (об этом не писал, разве что, ленивый). Про отображение страниц тоже не хочу писать, боюсь это будет скучно (может, в другой раз). Давайте лучше поговорим об обработке прерываний.

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

Я же, воодушевлённый статьёй про скрытые возможности кастомизации процесса explorer.exe, тоже решил сделать что-нибудь забавное.
Пусть сегодня моя секундная стрелка часов в Windows идёт в обратную сторону! Не самый, конечно, полезный в хозяйстве мод, но в академических и рекреационных целях вполне сгодится :)

Часовую и минутную стрелки я оставил в правильном направлении. Иногда всё же приходится полгядывать на часы в трее — пусть они показывают время с точностью хотя бы до минуты...

Однажды, в 2009 году, вышла Windows 7. В то время я сидел на Висте, которая притормаживала на моем стареньком компьютере, и я решил пересесть на семерку сразу после ее выхода.

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



Сразу же полез в настройки, чтобы отключить это безобразие, и с удивлением обнаружил, что группировка не отключается. Наиболее близкий к желаемому вариант, Never combine, кнопки все же группирует.



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

Под катом:

• Подробная демонстрация того, как можно самостоятельно подправить принцип работы такого системного процесса, как explorer, под себя, используя отладчик OllyDbg.
• Готовое решение описанной выше проблемы.

Пару лет назад я писал об использовании базы PAF (Postcode Address File) британской Королевской почты (Royal Mail) для приведения почтовых адресов, вводимых пользователями, к стандартному виду. Поскольку PAF — основная интеллектуальная собственность Royal Mail, то заполучить её не так-то просто: годовая подписка стоит от £400 в зависимости от полноты базы и от частоты апдейтов. Спустя неделю-другую после оформления подписки по почте приходит солидная красная коробочка с CD-диском:


На диске — EXE-файл, который запрашивает «серийный номер» и распаковывает базу (набор CSV-файлов) на диск. Серийный номер присылают отдельно, чтобы злоумышленник, перехвативший посылку, не смог бы воспользоваться базой. (Вот выдумают же — текстовый файл с серийным номером!) Номер у каждого клиента свой, чтобы в случае «утечки» было ясно, к кому предъявлять претензии. Впрочем, организовать «утечку» самих данных серийный номер никак не мешает, и на WikiLeaks в 2009 г. появилась база Postzon (одна из составляющих PAF). В комментариях к ней отмечено, что "данная база составлена на средства налогоплатильщиков, и активисты, в их числе газета The Guardian и сэр Тим Бернерс-Ли, уже давно пытаются убедить Royal Mail открыть свободный доступ к PAF; но до сих пор эти попытки не увенчались успехом". Впрочем, через год после появления Postzon на WikiLeaks аналогичная по содержанию база появилась в открытом доступе от имени британской картографической службы Ordnance Survey и под названием OS Code-Point Open — таким образом и Royal Mail сохранила лицо, не уступив требованиям активистов, и утёкшие данные официально получили статус общедоступных. Тем не менее, полностью PAF до сих пор необщедоступна. (Пока я готовил эту статью, Postzon и с WikiLeaks куда-то пропала; но гугл всё помнит.)

Спустя год после получения PAF мне понадобилось в неё снова заглянуть, но листочек с серийным номером, присланный отдельно от диска, за год успел куда-то затеряться. Тут мне и стало интересно — насколько сложно будет обойти проверку серийного номера в продукте таком солидном и так яростно защищаемом от «освободителей информации»? Через полчаса данные были у меня на винте, а сама программа-распаковщик мне показалась неплохим демонстрационным примером для начинающих реверс-инженеров. Никакая IDA не потребуется — только бесплатные и быстроустанавливаемые инструменты.

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

В университете на одном профильном предмете начали изучать стенд на основе микроконтроллера МК-51, дисплея HD44780, клавиатуры. Все это дело программируется через COM порт с помощью ассемблера. На тот момент я изучат микроконтроллеры семейства AVR (а именно Atmega8), поэтому появилось желание научиться инициализировать и выводить на экран какую-нибудь информацию с помощью ассемблера без применения библиотек. После продолжительных поисков нашел только то, как дисплей запрограммировать на языке C с помощью библиотек, в которых не совсем понятно, что происходит. Поэтому было принято решение написать код самому, с использованием ассемблерных команд. Дисплей 0802, две строки.

Первые части игры Age of Empires уже давно стали своего рода классикой. У этой игры до сих пор есть немало поклонников. В 2007 году вышло официальное коллекционное издание игры, которое включает первую и вторую части с дополнениями. Причём во всех странах, кроме США, оно вышло на одном DVD вместо четырёх CD. Тогда я уже немного занимался реверс-инжинирингом этой игры и знал, что оригинальные версии исполняемых файлов не захотят работать с одним общим диском, поскольку в код каждой части и их дополнений зашита проверка метки соответствующего диска. Очевидно, что у одного DVD не может быть сразу четыре разных метки, и после покупки русского DVD издания я ожидал увидеть перекомпилированные разработчиками версии файлов с изменённым кодом проверки наличия диска или вовсе без него. Но всё оказалось намного интереснее.

Продолжаем наше исследование игры «Сапёр» от Microsoft.

Данная статья является продолжением первой статьи.

О чем будет идти речь:
1) Взлом, основанный на переполнении буфера
2) Взлом игровых мин
3) Исследование архитектуры игры.

I

Откроем игру, следом за ней CE( Cheat Engine ). Присоединяемся к процессу игры:

Intro

Холодным зимним вечером, начитавшись статей об исследовании различного ПО и насмотревшись различного рода видео про взломы игр и прочее, у меня вдруг тоже возникло желание повозиться под дебагерром с чем-нибудь интересным. Крякингом я занимаюсь сравнительно давно, поэтому практический опыт имеется. Поначалу я, как и многие, просто искал различные CrackME в сети и взламывал их с целью обучения, затем перешел на взломы платных приложений(поиск/подбор ключей) и написание различного рода KeyGen`ов. В данный момент «набиваю руку» и пытаюсь оттачивать мастерство взлома.
Ну да ладно, это лирическое отступление от сути. Теперь определимся с некоторыми деталями.

В данной статье главным объектом внимания для нас будет компьютерная игра «Сапер».
Исследование и последующая отладка приложения происходят под Windows 7 x64 (реализация игры «Сапер» отличается в различных версиях OS Windows).