Выполнение работы. Цель работы: Изучение оболочки Visual Studio

 

Цель работы: Изучение оболочки Visual Studio

 

 

Рисунок 1. Создание проекта на рабочем столе.

 

 

Рисунок 2. Создание приложения для Windows

 

 

Рисунок 3. Запущенный проект.

Введение

В данной лабораторной работе я познакомлюсь с отладчиком. По причине невозможности работать в бинарных OC, таких как WinNT, React OS я выбрал свободные аналоги из репозиториев GitHub. А именно NASM, и в данной лабораторной работе буду использовать отладчик OllyDbg

 

Программное обеспечение

MacBook Air середина 2011 OS X Yosemite 10.10.5

Microsoft Office 2016 Mac beta version.

Консольные пакеты

sudo(права root)

nasm(свободное ПО)

bash(эмулятор терминала)

nano(редактирование)

screenme(c ключем -all)

 

Цели работы

Изучить правила описания простых типов данных и основные моменты работы с отладчиком TD.

Рабочие задания

1. Наберите исходный текст программы согласно варианту. Получив загрузочный модуль, запустите его в Турбо отладчике (TD). В окне DUMP просмотреть сегмент данных, найти все переменные, заданные в вашем варианте и объяснить местоположение и занимаемый объем этой переменной. Вы ответственны не только за описание переменной в сегменте данных, но и за каждый байт памяти.

 

 

Выполнение работы

В данной лабораторной работе я познакомлюсь с отладчиком LinICE,это известный порт SoftICE для линукс. Это сторонний отладчик и не поставляется в комплекте с операционными системами. Работать я буду с предустановленным x.org сервером под OS X, и собранным и исходников LinICE. Данное программное обеспечение использует нативную трассировку, что позволяет отлаживать любые проекты обходя возможные защитные механизмы, подобные DEBUG_PROCESS в операционных системах в WinNT.

После сбора из исходников запустим отладчик с помощью команды показанной на рисунке №1

Рисунок №1

После старта данного программного обеспечения мы увидим окно показанное на рисунке №2

Рисунок №2

Как описано в лабораторной работе №1, при использовании NASM создаются Unix исполняемые пакеты. Основываясь на этом скомпилированный проект помжет быть запущен на любой Unix подобной системе с процессорами Intel. Также данная лабораторная работа предпологает доскональное исследование исходников искомой программы, местоположение в памяти, занимаемый объем и подобное. LinIce а имеено основная часть его исходного кода предназначена для ядра 2.4 версии. Модифицированные версии данной программы для других ярер распологаются в закрытых репозиториях kali-linux.

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

Запускаем LinIce с ключем TARGET = -DSMP -DIO_APIC. Вытягиваем все зависимости как показано на рисунке №3

Рисунок №3

После этого уходим с иксов и стартуем наш отладчик в консольном режиме.Забыл сказать перед этим запускаем нашу программу, которую нужно будет найти с помощью отладчика. С пмощью команды proc вылавливаем нужную программу как показано на рисунке №4

Рисунок №5

Далее зная id процесса, снова стартуем LinIce и вылавливаем данный процесс как показано на рисунке №6

Рисунок №6

Далее организуем точку входа в программу, загрузив файл в редактор с помощью опции macho/image подгоняем курсор к "entrypoint:", давим <F4> (edit) и, изменяем первый байт на CCh, сохраняем изменения по <F2> (save) и выходим. При повторном запуске откроется LinIce потревоженный исключением CCh, после которого EIP укажет на конец CCh, как показано на рисунке №7

Рисунок №7

Курсор указывает на инструкцию "in eax,dx" (EDh), представляющую собой "осколок" от пропатченной команды "xor ebp,ebp" (31h EDh). Теперь (по идее) мы должны восстановить оригинальный байт, заменив CCh на 31h, уменьшить регистр EIP на единицу и продолжать трассировку в обычном режиме.

linice это, конечно, порт, но… только очень сырой и модифицировать память он _не_ умеет, даже если предварительно открыть кодовый сегмент на запись. Ни "E" (редактирование), ни "F" (заполнение), ни "M" (копирование памяти) _не_ работают!!! Зато работает запись в стек и нам, этого вполне достаточно. Совершая единичный акт трассировки возвращением EIP на место, то есть на следующую машинную команду.

Рисунок №8

Смотрим на вершину стека указывая 10h максимально возможный размер машинной команды на архитектуре x86, как показано на рисунке №9

Рисунок №9

После этого изучам стек. Так как он изменился, после пропатчивания 1го байта, теперь есть возможность просматривать дамп в интерактивном режиме. После этого продолжаем трассировку в обычном режиме. Программный assembler код можно пробросить в tarball архив, для более корректного изучения в обычном текстовом редакторе.

Также можно просмотреть с помощью команды exp именна портируемые программный код ядром. Это действие выполняется как показано на рисунке №8

Рисунок №10

В заключение посмотрим системные вызовы программы, как показано на рисунке №11

Рисунок №11

 

Контрольные вопросы

1. Как размещаются в памяти байты?

2. Как размещаются в памяти слова, двойные слова?

3. С какого байта адресуются слова, двойные слова?

4. Как размещается в памяти полный адрес переменной?

5. Какие операторы используются в команде ассемблера, если размеры регистров и переменных не одинаковы?

 

Ответы на вопросы

Заключение

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

 

Список литературы

1. wikiTaxi // Assembler NASM

2. wikiTaxi // Основные команды NASM

3. wikiTaxi // Ядро Darwin

4. wikiTaxi // Компиляция пакетов