Статья ASM для х86. (4.0) Системные механизмы Windows

CKAP · 30.06.2019

Ну вот подводя некий итог по потокам.. какова их природа?
Что есть поток? То есть скажем Call может породить поток.. или там, все что угодно его порождает? Ну не знаю.. запись в файл.

Marylin · 30.06.2019

CKAP сказал(а):
Что есть поток? То есть скажем Call может породить поток.. или там, все что угодно его порождает?

Нет, call не порождает потоков, а лишь передаёт управление на некоторый участок кода в текущем потоке. Дополнительные потоки создаёт основной поток программы, посредством только функции CreateThread(). Результатом этой функции будет отдельная нить программного кода, которая будет исполняться параллельно (одновременно) с основным потоком программы.

Многопоточные программы хлынули в массы с появлением процессоров с поддержкой Hyper-Threading (Pentium-IV), когда одно ядро представляется в виде двух логических ядер. Эта технология основана на том, что к одному исполнительному ядру Core подходит не один, а два конвейера, которые снабжают ядро инструкциями. Это позволило исполнять одновременно сразу два программных потока, вместо одного.

ООО-ядро четвёртого пенька было настолько удачным, что при полной загрузке конвейера, 70% исполнительных возможностей ядра тупо простаивало, т.е. ядро могло исполнять инструкции намного быстрее, чем они поступали из-вне. Поэтому инженеры добавили второй конвейер, и проц стал Hyper-Threading, или двупоточным.

Ясно, что поскольку ядро у HT на самом деле одно, то это эмуляция многопоточности, т.к. исполнение двух потоков просто чередуется планировщиком на высокой частоте, загружая ядро по самые помидоры. Реальная параллельность возможна только на процессорах с двумя физическими ядрами. Кстати, процессоры INTEL отличаются от AMD тем, что если INTEL говорит "8-ядерный процессор", то это 4-ядерный проц с поддержкой HT. У AMD, 8-ядер означают реальные 8 ядра, без технологии HT (хотя встречаются и исключения).

Таким образом программист получил возможность создавать в своих программах дополнительные потоки, которые на многоядерных процессорах будут исполняться параллельно с основным потоком. Созданный функцией CreateThread() программный поток - это физически отдельная нить программного кода. Как-правило, доп.поток ждёт от основного потока сигнала к действию, для чего применяют объекты синхронизации типа Event (событие) или Semaphore (семафор).

Например в текстовых редакторах основной поток может принимать от пользователя ввод с клавиатуры, а доп.поток будет сохранять этот ввод в файл. Тогда основной поток не будет отвлекаться от пользователя. Когда юзер нажмёт комбинацию Ctrl+S (save) и продолжит печатать дальше, основной поток как и прежде будет обрабатывать ввод, а доп.поток в фоне сохранит данные в файл.

CKAP · 30.06.2019

Marylin сказал(а):
Нет, call не порождает потоков

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

Кому тоже интересно 21:40

Marylin · 01.07.2019

4.1.4.4. Простое многопоточное приложение

Небольшой пример дву/поточного приложения..
Основной поток подаёт сигнал к действию доп.потоку посредством объекта-синхронизации 'Event' (событие). Значит сначала нужно создать этот объект функцией CreateEvent() с таким прототипом:

C-подобный:

HANDLE CreateEvent (
    lpEventAttributes    // (0) - атрибут безопасности 
    bManualReset         // (0) - авто/переключение в предыдущее состояние
    bInitialState        // (0) - начальное состояние объекта (выкл)
    lpName               // (0) - указатель на имя объекта (у нас безымянный).
   );

Эта fn. вернёт дескриптор Handle данного объекта-события.
Включать/выключать событие позволяют функции SetEvent() и ResetEvent() соответственно, но поскольку в аргументах мы задали авто/переключение в предыдущее состояние, нужно будет только включить его по Set. После того-как тред отработает, он сам обратно выключит объект.

Везде, где есть объекты-синхронизации, должна быть функция WaitForSingleObject(), которая будет наблюдать за этим объектом, и в зависимости от его состояния - замораживать или пробуждать доп.поток, для исполнения своего кода. Если нужно наблюдать сразу за несколькими объектами, то вместо Single используем WaitForMultipleObject(). Эти функции удобны тем, что в момент ожидания не занимают процессорное время. Прототип у Single такой:

C-подобный:

DWORD WaitForSingleObject (
    hHandle,              // Handle объекта, за которым нужно наблюдать
    dwMilliseconds        // сколько времени наблюдать. -1 = 0xFFFFFFFF = вечно (INFINITE)
   );

Это - что касается объекта.. Теперь сам поток..
Создаётся он функцией CreateThread() с нижеследующим прототипом (в скобках мои значения):

C-подобный:

HANDLE CreateThread (
    lpThreadAttributes,   // (0) - атрибут безопасности (в дефолте)
    dwStackSize,          // (0) - размер стека для потока (в дефолте)
    lpStartAddress,       // указатель на исполняемую функцию потока
    lpParameter,          // (0) - можно передать потоку 1 аргумент
    dwCreationFlags,      // (0) - после создания, сразу запустить поток на исполнение
    lpThreadId            // (0) - указатель для сохранения Thread-ID (нам TID не нужен)
   );

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

SuspendThread (handle) - усыпить поток;
ResumeThread (handle) - пробудить поток;
ExitThread (0) - выгрузить поток из памяти.

Консольная программа ниже демонстрирует, как применять эти функции на практике. Здесь, в основном потоке пользователю предлагается ввести текст, а доп.поток сохранит этот текст в файл. Командой для начала работы потока является SetEvent(). Дескриптором вывода STDOUT (монитор) является константа(7), а дескриптором ввода STDIN (клавиатура) - константа(3). Их будем подставлять в fn. Read/WriteConsole().

Стандартные функции Win32 для работы с файлами типа CreateFile() - слишком громоздки, поэтому задействуем их аналоги из Win2000, которые для обратной совместимости поддерживаются всеми Kernel32/64.dll. Просмотреть список функций-экспорта из системных библиотек можно как-минимум прямо из TotalCommander, нажав в нём комбинацию Ctrl+Q и перейдя на вкладку Импорт/Экспорт. Для их исследования, я скопировал основные файлы системы в отдельную папку, и теперь могу свободно трассировать их в отладчике (иначе система не даст этого сделать):

Ну и собственно многопоточный код:

C-подобный:

format PE console
include 'win32ax.inc'
.data
fName   db  'backup.txt',0
capt    db   'Type text for save to file',13,10
        db   '--------------------------',13,10,0
cLen    dd   $ - capt
final   db   '--------------------------',13,10
        db   'Save to backup.txt - OK!  ',0
fLen    dd   $ - final
buff    db   512 dup(0)    ; буфер для ввода
rSize   dd   0             ; реальная длина ввода.
tHndl   dd   0             ; хэндлы: - потока  Thread
fHndl   dd   0             ;         - файла   File
eHndl   dd   0             ;         - события Event
;-------
.code
start:
;// Создаём событие и доп.поток
        invoke   CreateEvent,0,0,0,0
        mov      [eHndl],eax
        invoke   CreateThread,0,0,threadFunc,0,0,0
        mov      [tHndl],eax

;// Выводим заголовок программы в консоль
;// и принимаем от юзера ввод
        invoke   WriteConsoleA,7,capt,[cLen],0,0
        invoke   ReadConsoleA,3,buff,512,rSize,0

;// Включаем объект события для доп.потока
        invoke   SetEvent,[eHndl]

;// Выводим финальную мессагу в основном потоке
        invoke   WriteConsoleA,7,final,[fLen],0,0
        invoke   ExitProcess,0

;//vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
;//--- Функция дополнительного потока ----
proc    threadFunc
        invoke   WaitForSingleObject,[eHndl],-1   ; ждём события..
        invoke  _lcreat,fName,0                   ; создать файл R/W
        invoke  _lwrite,eax,buff,[rSize]          ; запись в него из буфера!
        invoke  _lclose,[fHndl]                   ; закрыть файл
        invoke   ExitThread,0                     ;   ..и выгрузить поток.
        ret
endp
.end start

CKAP · 01.07.2019

Годный линк подогнали ребята с Васма

Ссылка скрыта от гостей

Marylin · 02.07.2019

4.2. Вторжение в пространство чужого процесса

Как упоминалось выше, у каждого процесса своё адресное пространство и если мы хотим произвести мод стороннего процесса, сначала должны получить его координаты в памяти. Сделать это проще, чем может показаться на первый взгляд, хотя Microsoft утверждает обратное. Во-первых, нужно получить PID, по которому сможем запросить у системы Handle процесса-жертвы через OpenProcess(). Если удастся выудить PID и Handle, то процесс будет полностью в нашем распоряжении.

Способов нахождения PID довольно много, среди которых пользуются спросом функции: ZwQuerySystemInformation(), EnumProcess() и CreateToolhelp32Snapshot(). Первая – это шагающий экскаватор, который может перемолоть всё на своём пути. Помимо Pid, ZwQuery возвращает ещё кучу информации, причём за один вызов сразу обо всех активных процессах, что требует резерва памяти под выхлоп. Её мы будем использовать для скрытия своей тушки в следующем разделе этой части. Вторая EnumProcess() живёт в сторонней библиотеке Psapi.dll, поэтому пока оставим её в покое.

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

Ссылка скрыта от гостей

. Snapshot – это снимок объектов, доступный только для чтения. В окопах CreateToolhelp32Snapshot() лежит аргумент, в котором нужно указать один из следующих флагов, чтобы уточнить запрос:

C-подобный:

TH32CS_SNAPHEAPLIST = 1      ; снимок куч
TH32CS_SNAPPROCESS  = 2      ; снимок процессов
TH32CS_SNAPTHREAD   = 4      ; снимок тредов
TH32CS_SNAPMODULE   = 8      ; снимок модулей DLL
TH32CS_SNAPALL      = 15     ; всё перечисленное

Из этой коллекции нам нужен флаг(2), что заставит функцию выдать информацию только о процессах. Она вернёт нам Handle на снапшот, который нужно передать в руки родственным функциям Process32First() и Process32Next(). Результатом их работы будет заполненная данными структура PROCESS_ENTRY32 следующего содержания:

C-подобный:

struct  ProcessEntry32          ;// cтруктура для fn. Process32First/Next()
  size           dd  300          ; размер данной структуры (установить до вызова)
  usage          dd  0            ; ссылок на процесс
  processID      dd  0            ; PID процесса (наш клиент)
  defaultHeapID  dd  0            ; ID кучи процесса по-умолчанию
  moduleID       dd  0            ; MID
  threads        dd  0            ; кол-во тредов у процесса
  parentPID      dd  0            ; PID родительского процесса
  priClassBase   dd  0            ; приоритет процесса (см.в Диспетчере задач)
  flags          dd  0            ; ..(резерв)
  processName    db  256 dup(0)   ; ASCII-имя процесса
ends

Третий член этой структуры есть никто-иной как идентификатор процесса PID, и это радует. Только данная структура описывает всего один процесс, значит нужно продолжить сбор информации в цикле, пока Process32Next() не вернёт ошибку. Так мы просканируем все процессы в памяти и сможем вывести некоторые (или все) поля структуры на экран. Код ниже демонстрирует такой алгоритм:

C-подобный:

include 'win32ax.inc'
.data
capt           db  'Task v0.1',0
text           db  'Активные процессы ',13,10
               db  '------------------',13,10
buff           db  2048 dup(0)
frmt           db  'Pid: %04x     Процесс: %s',13,10,0
count          db  '------------------',13,10
               db  'Всего процессов: %d',0
pHndl          dd  0

align   16                      ; выравнивание памяти на 16-байтный параграф
struct  ProcessEntry32    ;//<--- cтруктура для fn. Process32First/Next()
size           dd  300          ; размер данной структуры (установить до вызова)
usage          dd  0            ;
processID      dd  0            ; PID процесса
defaultHeapID  dd  0            ;
moduleID       dd  0            ;
threads        dd  0            ; кол-во тредов в процессе
parentPID      dd  0            ;
priClassBase   dd  0            ;
flags          dd  0            ;
processName    db  256 dup(0)   ; имя процесса
ends
pEntry         ProcessEntry32   ; определяем (#define) укороченное имя структуры
;//------------
.code
start: invoke  CreateToolhelp32Snapshot,2,0       ; аргумент = 2. процессы
       mov     [pHndl],eax                        ; запомнить хэндл снапшота

       xor     ebx,ebx                            ; EBX=0, будет счётчиком найденых
       mov     edi,buff                           ; адресуем буфер через EDI
       invoke  Process32First,[pHndl],pEntry      ; первый пошёл! (он заполнит структуру)
@scan: inc     ebx                                ; счётчик найденых +1
       mov     esi,edi                            ; ESI = указатель на текущий буфер

      cinvoke  wsprintf,esi,frmt,[pEntry.processID],pEntry.processName  ;// сбрасываем инфу в буфер

;// здесь нужно очистить поле с именем в структуре, от предыдущего
       mov     edi,pEntry.processName             ; EDI = указатель на него
       xor     al,al                              ; забивать будем нулями, AL=0
       mov     ecx,256                            ; длина поля в байтах
       rep     stosb                              ; запись из AL в EDI, 256 раз

;// чтобы не затереть предыдущую инфу в буфере,
;// нужно сместить указатель ЗА строку, тогда получим форматированный вывод.
;// т.к. весь буфф был забит нулями, значит нужно искать первый/попавшийся нуль:
       mov     edi,buff                           ; ставим указатель на начало
       xor     al,al                              ; искать будем нуль, AL=0
       mov     ecx,-1                             ; счётчик на макс! ECX=FFFFFFFFh
       repne   scasb                              ; ищем AL в EDI
       dec     edi                                ; коррекция указателя.

;// теперь можно перейти к поиску следующего процесса в памяти
       invoke  Process32Next,[pHndl],pEntry       ; в аргументах хэндл снапшота, и адрес структуры
       or      eax,eax                            ; ошибка???
       jne     @scan                              ; нет - повторить цикл..
       invoke  CloseHandle,[pHndl]                ; иначе: прибьём снапшот

      cinvoke  wsprintf,edi,count,ebx             ; добавим в буфер счётчик найденых

       invoke  MessageBox,0,text,capt,0           ; вывод всей инфы на экран!
       invoke  ExitProcess,0                      ;
.end start

Угу.. значит ToolHelp исправно робит и в награду мы получили валиндый PID каждого из присутствующих в памяти процессов. Теперь настала очередь их дескрипторов. Функция OpenProcess() как-раз этим и занимается. В аргументах она требует PID, по которому возвращает Handle окутанного тайной процесса.

C-подобный:

Handle OpenProcess (
     DWORD dwDesiredAccess,    // флаги доступа, ставим ALL_ACCESS
     BOOL  bInheritHandle,     // флаг наследования, ставим нуль
     DWORD dwProcessId         // PID, чей хэндл нужно получить
    );

Если функция завершается ошибкой, возвращаемое значение NULL, иначе – дескриптор указанного процесса. Например, функция завершается неудачно для процессов Idle и csrss.exe, поскольку их атрибуты доступа не позволяют открывать свои тушки на уровне юзера.

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

C-подобный:

BOOL WriteProcessMemory (
    hProcess,               // Handle процесса, в чью память хотим проникнуть
    lpBaseAddress,          // адрес для записи в его пространстве
    lpBuffer,               // указатель на буфер-источник в своём пространстве
    nSize,                  // кол-во байт для записи
    lpNumberOfBytesWritten  // фактическое кол-во записанных байт
   );

Эта функция BOOL, так-что нуль = ошибка, иначе = ОК!
Судя по её описанию, критическим условием является доступ на запись в регион.
Значит перед тем-как воспользоваться WriteProcessMemory(), нужно функцией VirtualAllocEx() выделить память в пространстве жертвы, задав ей атрибуты R/W. Эта функция возвращает адрес выделенного блока памяти в пространстве жертвы, или нуль в случае ошибки:

C-подобный:

LPVOID VirtualAllocEx (
    hProcess,            // Handle процесса, чью память хотим поиметь
    lpAddress,           // базовый адрес выделения, ставим нуль и fn.сама найдёт свободный участок
    dwSize,              // размер в байтах области выделения
    flAllocationType,    // тип размещения, ставим MEM_COMMIT – выделение (не резервация)
    flProtect            // тип защиты доступа, ставим EXECUTE_READWRITE – исполняемая для шелла.
   );

Теперь потренируемся ‘на кошках’..
Напишем два приложения: одно будет жертвой, а другое – атакующим.
Если наша цель раньше была коммунизм, то сейчас – запись строки в область памяти подопытного процесса Hello.exe. Алгоритм будет такой:

CreateToolhelp32Snapshot() – найти процесс Hello.exe в памяти, и получить его PID;
OpenProcess() – открыть данный процесс по PID и получить его Handle;
VirtualAllocEx() – передав Handle, выделить память в процессе Hello.exe с доступом на запись/исполнение;
WriteProcessMemory() – записать данные в подопытный процесс.

C-подобный:

include 'win32ax.inc'
.data
capt           db  'Attach v0.1',0
frmt           db  'Шелл-код удачно записан в удалённый процесс!',13,10
               db  'Базовый адрес расположения: 0x%08X',0
text           db   128 dup(0)
accessError    db  'Процесс найден, но к нему нет доступа.',0
noProcess      db  'Указанный процесс не найден.',0
name           db  'hello.exe',0    ; имя процесса для поиска (в нижнем регистре)
nameLen        =   ($ - name)-1     ; его длина без учёта нуля
snapHndl       dd   0               ; будет хэндл снапшота
processHndl    dd   0               ; под хэндл процесса

align   16                        ; выравнивание структуры на параграф
struct  ProcessEntry32            ;// cтруктура для fn.Process32First/Next()
  size         dd  300            ;
  usage        dd  0              ;
  processID    dd  0              ;// PID процесса
  HeapID       dd  6 dup(0)       ; резерв
  processName  db  256 dup(0)     ;// имя процесса
ends
pEntry         ProcessEntry32
;//-------
.code
start: invoke  CreateToolhelp32Snapshot,2,0       ; запрашиваем инфу о процессах
       mov     [snapHndl],eax                     ; запомнить хэндл снапшота
       invoke  Process32First,[snapHndl],pEntry   ; начинаем поиск процесса-жертвы

;// здесь нужно перевести имя в структуре, в нижний регистр (прописные),
;// иначе поиск может не дать результата
@scan: mov     edi,pEntry.processName   ; EDI = указатель на него
       mov     ecx,nameLen              ; длина строки в байтах
       push    edi ecx                  ; запомнить для сл.операции!
@01:   or      byte[edi],00100000b      ; взводим бит(5) в имени (символ в ниж.регистр)
       inc     edi                      ; сл.байт в поле 'Имя' структуры
       loop    @01                      ; повторить ECX-раз..

;// сканируем поле с именем на 'hello.exe'
       pop     ecx edi                  ; восстанавливаем указатель и длину имени
       mov     esi,name                 ; ESI = указатель на строку поиска
       repe    cmpsb                    ; сравниваем байты ESI с байтами EDI
       or      ecx,ecx                  ; всю строку проверили?
       je      @ok                      ; если совпало!

       invoke  Process32Next,[snapHndl],pEntry  ; иначе: продолжить поиск процесса
       or      eax,eax                          ; ошибка???
       jne     @scan                            ; нет - повторить цикл..
       invoke  MessageBox,0,noProcess,0,0       ; все процессы проверили - нету Hello.exe
       jmp     @exit                            ; на выход!

;// нашли процесс!
;// берём его PID из структуры и получаем Handle
@ok:   mov     eax,[pEntry.processID]
       invoke  OpenProcess,PROCESS_ALL_ACCESS,0,eax    ; ставим доступ ALL
       or      eax,eax                                 ; ошибка???
       jnz     @next                                   ; если нет..
@err:  invoke  MessageBox,0,accessError,0,0            ; иначе: нет доступа!
       jmp     @exit                                   ; и на выход.

;// теперь у нас есть PID и Handle процесса 'hello.exe'
;// выделяем в нём память размером в страницу и атрибутами Ex/R/W
@next: mov     [processHndl],eax
       invoke  VirtualAllocEx,eax,0,1000h,MEM_COMMIT,PAGE_EXECUTE_READWRITE
       or      eax,eax                                 ;
       jz      @err                                    ; если ошибка, уходим выше.
       push    eax                                     ; запомнить выделенную базу
      cinvoke  wsprintf,text,frmt,eax                  ; преобразовать её в текст

;// Осталось записать в процесс шелл-код (пока просто строку)
       pop     eax                                     ; снимаем базу
       invoke  WriteProcessMemory,[processHndl],eax,name,nameLen,0
       or      eax,eax                                 ;
       jz      @err                                    ; если ошибка, уходим выше.

;// Значит запись в сторонний процесс прошла успешно
       invoke  MessageBox,0,text,capt,0                ; вывод инфы на экран!

@exit: invoke  CloseHandle,[snapHndl]      ; прибиваем снапшот
       invoke  ExitProcess,0
.end start

Тут непонятно одно – куда смотрят аверы, т.к. на

Ссылка скрыта от гостей

не один из них даже не хрюкнул. Расположившись в чужом пространстве, можно остановить поток жертвы по SuspendThread() и вместо него самим выполнять любые задачи, тем-самым уничтожив против себя все улики – мол это не мой процесс, и вообще моя хата с краю. Во-вторых, можно перехватывать все адресованные жертве пакеты хоть на уровне сокетов, хоть на уровне Web-приложений (например проникнув в Хром). Вообщем поле деятельности настолько обширно, что становится грустно, ведь это-же могут проделать и с нами.

zigun · 05.07.2019

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

Marylin · 05.07.2019

zigun сказал(а):
т.е. в этом процессе должна быть уязвимость переполнения

..всё-правильно.
Программа должна записать шелл в чужое пространство, и запустить его функцией CreateRemoteThread(). Беспрепятственное выделение памяти в пространстве жертвы с доступом на R/W и исполнение - это уже уязвимость, и жертва от этого никак не застрахована.

Microsoft разрекламировала фишку под названием DEP 'Data-Execute-Protect' (защита от исполнения в секции-данных), но по-большому счёту она была введена только для защиты от переполнения стека, и просто делает стек неисполняемым. Если-уж ввели DEP, тогда нужно было убрать такие функции как VirtualProtectEx() и VirtualAllocEx(), которые с лёгкостью переназначают атрибуты регионов памяти. Но у Microsoft всё через пятую точку..

CKAP · 05.07.2019

Я закончил, жадно хочу есче знаний

Остались не понятны эти манипуляции %04x, 0x%08X и тд.. но это к синтаксису я так понимаю. Де переменные де метки уже ясно.
invoke это макрос который живет тут win32ax.inc, а вот всякие OpenProcess это.. мм.. это тоже из win32ax.inc или это winAPI ?

Marylin · 05.07.2019

CKAP сказал(а):
Остались не понятны эти манипуляции %04x, 0x%08X

это спецификаторы для функции wsprintf(), которая сохраняет в буфер переданные ей аргументы в различных представлениях. Список наиболее часто применяемых спецификаторов выглядит так:

C-подобный:

   %f - плавающая точка fpu,
   %o - OCT восьмеричное число,
   %u - DEC беззнаковое целое,
   %d - DEC знаковое целое,
   %x - hex в нижнем регистре  5fe10ab8,
   %X - HEX в верхнем регистре 5FE10AB8,
   %s - строка (аргумент должен быть адресом строки).

//-- Ограничение разрядов в числе на примере 5fe10ab8 --
   %04x - четыре младших разрядов = 0ab8
   %08X - восьми/разрядное число  = 5FE10AB8
 
//-- В одной строке может быть несколько спецификаторов --
//-- причём началом спецификатора является знак процента (%),
//-- и до него может быть строка, например:
.data
frmt     db  'HEX = %08x, DEC = %u',0
buff     db  64 dup(0)
;------
.code
start:   mov     eax,0x5fe10ab8
        cinvoke  wsprintf, buff, frmt, eax, eax    ; 2-аргумента EAX (не считая первых/двух)
         invoke  MessageBox,0,buff,0,0

//-- Результат на экране --
         HEX = 5fe10ab8, DEC = 1608583864

Макрос invoke превращает стандартный вызов API-функций в приглядный вид. В ассемблере нет инструкции invoke, а есть только call, аргументы которому передаются через стек. Если посмотреть в отладчике, то бокс мессаги имеет в нём такой вид, который является фактическим вызовом функции в ассемблере:

C-подобный:

push  0           ; аргумент(4) - стиль окна,
push  caption     ; аргумент(3) - заголовок окна,
push  text        ; аргумент(2) - указатель на строку,
push  0           ; аргумент(1) - окно не модальное (вызывается не другим окном),
call  MessageBox  ; вызов Win32-API

Но в исходнике такой формат неудобен, и проще выстроить все аргументы в одной строке, что собственно и делает макрос invoke.

Чтобы изучить компилятор, можно полазить по фасмовским папкам и просмотреть содержимое его файлов. Как-правило там только инклуды с текстовым содержимым, поэтому можно использовать просмотрщик Тотала по Ctrl+Q. По функциональному назначению они выстроены так:

fasm\include - макросы, для технических нужд компилятора;
fasm\include\api - перечень API-функций из системных библиотек;
fasm\include\equates - список структур для API-функций;
fasm\include\pcount - число параметров/аргументов у API-функций;
fasm\tools - готовые к компиляции исходники, для создания доп.утилит.

Из этого списка, лично я часто обращаюсь к содержимому папки equates, чтобы найти формат той-или-иной структуры. Их там много, и открывать каждую порой напрягает. Поэтому я написал батник в который подставляю маску для поиска, и он мне выдаёт полный путь, где прописана данная структура. Основой батника является консольная команда findstr, способная рекурсивно обходить все папки и файлы, в поисках указанной строки:

Bash:

@echo off
echo.
echo  Поиск по маске "WSADATA" начался.
echo  Это займёт пару минут. Пожалуйста ждите...
echo.
echo  Слово найдено в следующих файлах:
echo  ---------------------------------
findstr /s /i /m "\<wsadata\>" *.*
echo  ---------------------------------
echo  Поиск окончен!!!
pause

Чтобы консоль отображала кирилицу, нужно сохранить этот сценарий как *.bat, в кодировке OEM-866. Сама маска указывается в аргументах findstr. Теперь ложим батник в корневую папку фасма и запускаем его на исполнение.

OpenProcess() и прочие - это виндовые функции Win32-API, которые экспортируют для нас системные библиотеки типа Ntdll.dll, Kernel32.dll, User32.dll и т.д. Какой из библиотек принадлежит конкретная функция можно узнать из директории fasm\include\api. Чтобы не искать вручную, можно как-раз воспользоваться этим батником, изменив маску "\<wsadata\>" на маску "\<CreateProcess\>".

CKAP · 05.07.2019

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

Marylin · 05.07.2019

CKAP сказал(а):
штудирую Масм

ассемблер - и в Африке ассемблер, а зоопарк его компиляторов отличается только синтаксисом. Например у MASM и TASM он на 99% схож, а разраб FASM'а попытался убрать из их синтаксиса всё лишнее, например ту-же директиву offset.

Классическим ассемблером для х86 является TASM, только под винду на нём не прогают. MASM выделяет на фоне других шикарной коллекцией инклуд и макросов на все случаи жизни (он так и называется Macro-Asm). Зато исходник на фасме получается более читабельным, да и сам компилятор более шустрый и простой из-за своего IDE.

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

Marylin · 08.07.2019

4.3. Перехват API-функций

Win-API или Application Programming Interface предоставляет программистам готовые функций для решения широкого круга задач. Все имеющиеся в системе API отсортированы по назначению и хранятся в соответствующих библиотеках DLL. На английский манер библиотеки называются Library, а в роли консперативной их квартиры выступает системная директория %Windir%\System32\.. Внутри либ, функции расположены вплотную друг-к-другу и каждая из них имеет свою точку-входа. Для осуществления наших замыслов, на данном этапе понадобится

Ссылка скрыта от гостей

– хакерское оружие ближнего боя, способное творить чудеса. Вот как он отображает содержимое библиотек на примере Kernel32.dll:

При вызове функций из наших программ система проделывает огромную работу прежде чем вернём нам результат, и в силу некоторых обстоятельств этот результат может быть не только положительным, но и отрицательным. Например передали мы функции неверный аргумент – встречаем ошибку. Большинство (если не все) API возвращают информацию о проделанной работе, в регистре EAX. Обработчики некоторых функций могут выполнятся в пределах юзерского пространства, однако львиная их доля бурится в ядро по такой схеме:

Здесь видно, что вся нагрузка выпадает на долю библиотеки Ntdll.dll, которая через ассемблерную инструкцию SYSENTER переходит из юзерского пространства, в кернел. Если мы вызываем API для создания всяких побрекушек типа иконки или курсоры, то подключать к этому делу ядро совсем не обязательно, и можно сделать это локально, в пределах юзерского пространства (пунктирные линии на схеме). Однако если API создаёт объекты ядра типа файл/устройство и прочее (см.утилиту WinObj), то оська должна зарегистрировать эти объекты у себя. Переход из юзера в ядро занимает много времени, поэтому практичней создавать все ядерные объекты на начальном этапе программы, а не внутри полезного кода. Тогда наша программа пробуксует один раз при старте, а дальше - будет работать как часы.

4.3.0. Получаем адрес точки-входа в функцию

Таким образом, чтобы перехватить некоторую функцию Win32-API, нам нужно получить Entry-Point перехватываемой функции внутри данной библиотеки. Сделать это можно несколькими способами в зависимости от того, кто будет осуществлять перехват. Например если это шелл-код, то на него накладывается куча ограничений, в числе которых отказ от прямого использования системных сервисов. Shell должен делать всё самостоятельно, рассчитывая только на себя. Причиной тому – компиляция его в виде бинарного файла с базой нуль. Попав в тело жертвы, посредством вычисления т.н. ‘дельта-смещения’, шелл получает базу той области памяти в пространстве жертвы, куда его катапультировала программа-матка. Запомнив эту базу в регистре EBP (base-pointer), шелл должен будет опираться только на него, осуществляя исключительно косвенные переходы, типа EBP+4.

Эти сложные механизмы мы оставим на закуску, а пока вычислим адрес точки-входа легальными путями, для чего система имеет твикс-парочку GetModuleHandle() и GetProcAddress(). Первая возвращает в EAX базу указанной библиотеки в памяти, а вторая – адрес функции внутри этой библиотеки. После того-как в наших руках окажется точка-входа, мы можем вставить туда свой JMP, что позволит получить управление при вызовы системой данной функции. Это собственно и есть один из способов перехвата API, который назвали ‘сплайсинг’ от буржуйского Splicing. Код выглядит так:

C-подобный:

include 'win32ax.inc'
.data
capt     db   'Win32-API',0
text     db    128 dup(0)
frmt     db   '%08X = База User32.dll в памяти',13,10
         db   '%08X = Точка входа в MessageBox()',0

libName  db   'user32.dll',0
fName    db   'MessageBoxA',0
;-------
.code
start:   invoke  GetModuleHandle,libName        ;// EAX = база DLL в памяти
         mov     ebx,eax                        ;// (запомнить в EBX)
         invoke  GetProcAddress,eax,fName       ;// EAX = база функции внутри DLL
        cinvoke  wsprintf,text,frmt,ebx,eax     ;// (числа в символы)

         invoke  MessageBox,0,text,capt,0
         invoke  ExitProcess, 0
.end start

Попробуем сверить результаты с выхлопами HIEW’a и отладчика WinDbg..
Значит запускаем Hiew и открыв в нём User32.dll пару раз жмём Enter. Клавиша Enter переключает режимы отображения в Hiew на Text/Hex/Decode – нам нужен любой режим, кроме Text. В каждом из режимов своя строка-меню и соответственно свои опции. Теперь в режиме Hex жмём на F8 и получаем содержимое РЕ-заголовка, с технической информацией о дисковом образе файла. Меню F8 открывает вход в закрома библиотеки, где можно ознакомится со-списком импорта(F7) , или экспорта(F9) – выбираем экспорт и мотаем список, пока не уткнёмся в функцию MessageBoxA().

Первый стоблец в окне – это ‘ординал функции’, т.е. её порядковый номер внутри библиотеки. Hiew предлагает нам отсортивать список клавишами F2-3-4 по трём критериям – ординалам, адресу или имени. После выбора функции по Enter, мы попадаем в аккурат на дизассемблерный код выбранной функции.

Чтобы проделать аналогичную операцию в WinDbg, достаточно открыть скомпилированную программу ‘HelloWorld’ комбинацией клавиш Ctrl+E, и дать запрос на дизассемблирование функции командой ‘u MessageBoxA’ (unassemble). У меня получилось так:

4.3.1. Подготовительные операции

Поскольку мы хотим произвести запись в часть нашего пространства где тусуются системные библиотеки (адрес выше 0х70000000), для начала посмотрим, доступен-ли вообще данный регион для записи, для чего затребуем карту MemoryMap в отладчике OllyDbg.

Упс.. система выставила им/всем атрибуты ‘только-чтение’, что и неудивительно – должна-же она предпринимать хоть какие-то попытки, пусть и сугубо ламерские. В наших штанинах есть функция VirtualProtect(), которая сможет переназначить доступ, добавив к ‘R’ буковку ‘W’. Этикет программистов предписывает после записи восстанавливать предыдущие атрибуты, и если мы входим в их сообщество, должны придерживаться этих правил. VirtualProtect() служит для переназначения атрибутов страниц текущего процесса, она-же с окончанием(Ex) манипулирует с защитой страниц чужих процессов. Вот её прототип:

C-подобный:

VirtualProtect (
    lpvAddress,         // адрес защищаемого блока
    dwSize,             // размер защищаемого блока
    fdwNewProtect,      // новые флаги защиты
    fdwOldProtect  );   // переменная, в которую записываются старые флаги

Константы флагов защиты
-----------------------------------
#define PAGE_NOACCESS          0x01     // страница без атрибутов (зарезервирована)
#define PAGE_READONLY          0x02
#define PAGE_READWRITE         0x04
#define PAGE_WRITECOPY         0x08
#define PAGE_EXECUTE           0x10
#define PAGE_EXECUTE_READ      0x20
#define PAGE_EXECUTE_READWRITE 0x40
#define PAGE_EXECUTE_WRITECOPY 0x80
#define PAGE_GUARD             0x100    // сторожевая страница стека
#define PAGE_NOCACHE           0x200    // страницу нельзя выгружать в файл-подкачки.

Если функция терпит неудачу, то возвращаемое значение EAX=0.
Аргументы lpvAddress и dwSize служат для указания диапазона адресов защищаемой памяти. Поскольку функция работает только с 4К-байтными страницами, то и начальный адрес должен быть выровнен на границу 0х1000 байт. Для выравнивания границ адресов как-нельзя лучше подходит ассемблерная инструкция AND. Вторым операндом она требует маску, по которой сбрасывает в двоичном числе те биты, которые в маске установлены в нуль.

Например из предыдущего скрина мы уже знаем, что адрес MessageBox() в библиотеке User32.dll равен 0x7E3A07EA, и чтобы выровнить его на 4К-байтную границу, нужно сбросить три/младших разряда в нуль. Значит нужна маска FFFFF000, что равнозначно числу -1000h. Тогда получим адрес 0х7E3A0000, в диапазоне которого и будет находится точка-входа в MessageBox().

4.3.2. Перехват API методом сплайсинга, в своём пространстве.

Будем считать, что пусть и не до блеска, но чуть заточили своё оружие, и теперь можно осуществить практический перехват системной API. В конечном итоге алгорит будет такой:

GetProcAddress() – найти адрес точки-входа в перехватываемую функцию;
Инструкция AND – выровнить этот адрес на 4К-байтную границу;
VirtualProtect() – переназначить атрибуты данного региона памяти, с доступом на запись;
Инструкция REP MOVSB – сохранить первые 5-байт из точки-входа в функцию, в свой буфер;
Инструкция REP STOSB – записать на их место, JMP-переход на свою/фиктивную функцию.

Суть перехвата API в том, чтобы при вызове функции системой, изменить ход событий в свою пользу, вставив в начало обработчика свой дальний переход JMP far. Её опкодом является всего 1-байт со-значением EАh и если добавить к нему 4-байтный адрес нашей процедуры, то в сумме получим как-раз 5 байт, которые можем вставить в пролог оригинальной функции Win-API.

В демонстрационном примере, я буду перехватывать тот-же MessageBox(). Моя подставная функция будет просто расшифровывать выводимую на экран строку, после чего вернёт управление опять оригинальной функции, чтобы она вывела её на экран. Замечу, что метод шифрования тут не важен, главное понять сам принцип перехвата системных функций:

C-подобный:

include  'win32ax.inc'
.data
capt       db  'Splicing',0
text       db  'Пример перехвата API-функций',13,10
           db  'Эта строка была дешифрована!',0
mesLen      =   $-text
libName    db  'user32.dll',0
fName      db  'MessageBoxA',0
oldByte    db   7 dup(0)               ;// под оригинальные 7-байт функции
ePoint     dd   0                      ;// под оригинальный адрес MessageBox()
oldFlags   dd   0                      ;// прежние флаги защиты для VirtualProtect()
;-------
.code
start:
;// Получаем адрес функции
         invoke  GetModuleHandle,libName
         invoke  GetProcAddress,eax,fName
         mov     [ePoint],eax              ;// запомнить

;// Выравниваем адрес на 4К страницу,
;// и выставляем этой странице атрибуты R/W
         and     eax,-1000h
         invoke  VirtualProtect,eax,1000h,PAGE_READWRITE,oldFlags

;// Копируем оригинальные 7-байт из функции, в свой буфер
         mov     esi,[ePoint]
         mov     edi,oldByte
         mov     ecx,7
         push    esi                 ;// запомнить точку-входа в функцию..
         rep     movsb

;// Перехват API-функции!
;// вставляем на место 7-ми байт, переход на свою процедуру
         pop     edi                 ;// точка-входа в функцию..
         mov     al,0xEA             ;// опкод инструкции 'JMP_FAR'
         stosb                       ;// вставить первым байтом! (EDI сам сдвинулся)
         mov     eax,@crypt          ;// EAX = адрес нашей функции
         stosd                       ;// вставить как DWORD!
         mov     ax,cs               ;// АХ = селектор сегмента-кода
         stosw                       ;// вставить как WORD! Итого 7-байт.

         invoke  MessageBox,0,text,capt,0
         invoke  ExitProcess, 0

;//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
;//-- Подставная функция MessageBox() ------
;//-- дешифрует указанную строку в секции-данных
@crypt:  push    esi edi ecx         ;// запомнить модифицируемые регистры
         mov     ecx,mesLen          ;// длина строки,
         mov     esi,text            ;// ..и её адрес
@001:    xor     byte[esi],7Eh       ;// дешифруем байтики ключом 0х7Е
         inc     esi                 ;// сл.байт..
         loop    @001                ;// повторить ЕСХ-раз!

;// Восстанавливаем перехваченную функцию!
         mov     esi,oldByte         ;// источник = оригинальные 7-байт
         mov     edi,[ePoint]        ;// приёмник = точка-входа в функцию
         mov     ecx,7               ;// длина участка кода
         rep     movsb               ;// скопировать из ESI в EDI.

         pop     ecx edi esi         ;// восстанавливаем регистры
         push    [ePoint]            ;// засылаем в стек точку-входа в MessageBox()
         ret                         ;// передаём на неё управление!
.end start

Теперь запускаем это приложение и видим такую форточку..
Вместо указанной строки получили абракадабру, а это означает, что наш код исправно сработал, и функция MessageBox() перехвачена! Если-бы мы увидели что-то другое, тогда нужно было-бы искать ошибки в отладчике. Как говорят в народе: - ‘Если отладка это поиск ошибок, то программирование – их создание’:

Такое окно предстало нашему взору потому, что функция @crypt в нашем коде не расшифровывает строку, а наоборот шифрует её по XOR с ключом 0x7Eh. Учитывая тот факт, что операция XOR обратима (т.е. повторный XOR таким-же ключом восстанавливает прежнее значение), сейчас мы должны зашифровать данную строку, тогда программа исправно её дешифрует и мы увидим долгожданный текст.

4.3.3. Ручное шифрование строк в HIEW’e

Шифрование позволяет скрыть от любопытных глаз все строки, которые исследователь может обнаружить в отладчике. Посмотрим, как выглядит секция-данных программы выше.

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

На данном этапе, нам нужно проксорить эту строку ключом 7Eh в образе программы на диске. Такое шифрование назвали офф-лайн шифрованием, а в качестве инструмента в самый цвет подходит хек-редактор HIEW. Откроем в нём свою прожку, после чего нажмём такую последовательность клавиш: Enter -> F8 -> F6 -> (.data) -> Enter. Так мы уткнёмся в начало секции данных, но к сожалению Hiew не понимает кириллицу и придётся ориентироваться на терминальный нуль строки, которым она заканчивается:

Теперь у нас есть начало строки и можно приступить непосредственно к шифрованию. Обязательным условием является одинаковый ключ ксора 0х7Е, иначе дешифрация потерпит крах. Шифровать будем весь выделенный блок, включая терминальный нуль, т.к. процедура дешифрации учитывает и его. Значит установив стрелками указатель на начало блока с байтом CFh, жмём последовательность F3 (edit) -> F8 (xor) и в поле ‘Hex’ вводим значение ключа 7Е. Теперь подтверждаем намерения по Enter, и той-же клавишей F8 шифруем весь блок. Каждый зашифрованный байт выделяется жёлтым цветом. По окончании, применяем изменения клавишей F9 (update) и получаем такую картину:

Если после всех телодвижений теперь запустить нашу прожку, то функция @crypt в программе начнёт дешифрацию текста тем-же ключом, которым мы и шифровали. В результате текст начнёт мутировать в оригинальную строку, которую и сбоксит в окошко оригинальная MessageBox(). За процессом дешифровки можно понаблюдать в отладчике:

Здесь мы рассмотрели только один метод перехвата API, хотя есть и другие – например модификация секции-импорта. Но для этого метода нужно подробно изучить формат и структуру заголовка РЕ-файла, чем мы займёмся как-нибудь в другой раз.

Сергей Попов · 08.07.2019

Marylin сказал(а):
4.3. Перехват API-функций

Комментарии не индексируются поисковиками. Ваши комментарии тянут на полноценную статью. Было бы здорово, если бы Вы прислушались к моему мнению, и начали публиковать подобные комментарии отдельными статьями. Это даст море целевого трафика на Ваши статьи.

Marylin · 08.07.2019

WebWare Team сказал(а):
и начали публиковать подобные комментарии отдельными статьями.

спасибо, учту на будущее..

CKAP · 10.07.2019

Короче, не чего не смог найти в сети по импорту и экспорту либов. Ну как бы по названиям понятно о чем речь но картина в целом не ясна.

>В реальном софте строки несут в себе большую смысловую нагрузку, по которым можно выстроить общую картину работы программы

Вот как её выстраивать, мм.. назовем условно дорожной картой. Ну скажем есть exe, он по любому грузит в себя либ кернел, юзер в .data , что то я так понимаю инициализирует перед Энтри Поинт.. геты я вижу всякие курсора, иконок..

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

Благодарю.

Marylin · 11.07.2019

CKAP сказал(а):
Короче, не чего не смог найти в сети по импорту и экспорту либов.

Классикой являются следующие доки, которые должны быть у каждого разработчика:

Джеффри Рихтер - Windows для профессионалов (издание 4)
Марк Руссинович - Внутреннее устройство Windows (издание 6)
Эндрю Танненбаум - Современные операционные системы (издание 4)

CKAP сказал(а):
Вот как её выстраивать, мм.. назовем условно дорожной картой.

думаю это придёт с опытом, поэтому нужно больше практиковаться

CKAP сказал(а):
что бы видеть что с чем общается.

Есть признанный

Ссылка скрыта от гостей

в котором имеются перекрёстные ссылки, т.е. он связывает стрелками переходы. Попробуйте использовать его, хотя лично я им редко пользуюсь, т.к. этот-же функционал есть и у HIEW'a. Но это дело вкуса..

EdmonDantesDuma · 14.07.2019

Спасибо Вам за труд. Очень познавательно, доходчиво и интересно. Очень будем ждать продолжения. Спасибо.

SearcherSlava · 14.07.2019

Marylin сказал(а):
Классикой являются следующие доки, которые должны быть у каждого разработчика:

Джеффри Рихтер - Windows для профессионалов (издание 4)

Марк Руссинович - Внутреннее устройство Windows (издание 6)

Эндрю Танненбаум - Современные операционные системы (издание 4)

думаю это придёт с опытом, поэтому нужно больше практиковаться

Есть признанный
Ссылка скрыта от гостей
в котором имеются перекрёстные ссылки, т.е. он связывает стрелками переходы. Попробуйте использовать его, хотя лично я им редко пользуюсь, т.к. этот-же функционал есть и у HIEW'a. Но это дело вкуса..

Здрав будь!

Можно & нужно почитать по IDA-PRO:

Chris Eagle.THE IDA PRO BOOK. The Unofficial Guide to the World’s Most Popular Disassembler. 1 & 2nd Edition
Chris Eagle. Reverse Engineering with Ida Pro
Pearce W. Reverse Engineering Code with IDA Pro
Brdarevic Omega. Hacker Tools Crack With Disassembling
Wong Reginald. Mastering Reverse Engineering
Dennis Yurichev. Reverse Engineering for Beginners
Крис Касперски. Техника отладки программ без исходных текстов
Крис Касперски. Образ мышления - дизассемблер IDA PRO
Крис Касперски. Фундаментальные основы хакерства. Искусство дизассемблирования
Крис Касперски. Искусство дизассемблирования
Крис Касперски. Тонкости дизассемблирования
Крис Касперски. Техника и философия хакерских атак. Записки мыщ'а
Pirogov Vlad. Disassembling Code IDA Pro and SoftICE
Пирогов В.Ю. Ассемблер и дизассемблирование

Hardreversengineer · 21.08.2019

Marylin сказал(а):
4.1.4.4. Простое многопоточное приложение

У меня код из примера не работает. Запускается и сразу исчезает (проверено на разных ПК), я прописал invoke Sleep,1000 перед Invoke Exitprocess, окно остаётся, сообщение не прописывается (пустое консольное окно), создаётся файл backup спустя доли секунды(при чём до слипа не создавался), он тоже пустой. Как поправлять ?

Все сервисы Codeby

Поиск

Поиск

Статья ASM для х86. (4.0) Системные механизмы Windows

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

zigun

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

Marylin

Mod.Assembler

Сергей Попов

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

EdmonDantesDuma

SearcherSlava

Hardreversengineer