Не получается запустить бинарные данные в памяти программы

[Unseen]

/del

/del

 

[Roller]

Я так понял что нужно использовать WriteProcessMemory, VirtualAllocEx, OpenProcess.

Вот последовательность действий при внедрении шелла в чужой/свой процесс, и запуска его на исполнение:

1. Если внедряемся в чужой процесс, нужно получить его идентификатор PID. Здесь можно в цикле прокрутить Process32First/Next() или получить PID сразу через NtQuerySystemInformation() с классом(5) "ProcessesAndThreadsInformation". PID не нужен, если запускаем шелл из своего процесса.

2. Получив ID процесса, передаём его в OpenProcess(), возвращающий дескриптор/хэндл процесса жертвы;

3. Handle процесса отправляем в VirtualAllocEx() с атрибутом PAGE_EXECUTE, которая выделит внутри процесса-жертвы память требуемых размеров. Если процесс свой, то зовём VirtualAlloc() без расширения(Ex), и не нужны PID + Handle;

4. В выделенный блок памяти чз WriteProcessMemory() копируем готовый шелл;

5. Теперь, чтобы запустить код на исполнение, зовём CreateRemoteThread(), передавая ей дескриптор процесса и указатель на стартовый адрес потока, где находится уже голова шелла внутри блока памяти, выделенного VirtualAllocEx(). Запустить бинарь из своего процесса можно обычным вызовом call, только код шелла должен тогда обязательно заканчивать ассемблерной инструкцией возврата управления ret;

6. На заключительном этапе необходимо функцией ExitThread() или CloseHandle() прихлопнуть созданный CreateRemoteThread() удаленный поток (иначе получим ошибку), а шелл тем временем отработает по своему коду.

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

Например если нужна инфа о системе, можно запросить адрес структуры окружения потока TEB, база которой всегда лежит в регистре FS на х32, или GS на х64. Внутри TEB прописывается и указатель на РЕВ (Process Environment Block), в полях которой тоже предостаточно инфы, например базы системных либ Kernel32.dll, Ntdll.dll, etc - в них можно найти уже LoadLibrary(), со всеми вытекающими. Хотя всё здесь зависит от того, что именно должен делать шелл.

Спойлер: ASM example

;....
        call  @delta
@delta: pop   rbp           ;// в RBP текущий адрес (который заранее неизвестен)
;....
        mov   rsi,[gs:0]    ;// в RSI указатель на TEB чужого/своего потока
        mov   rdi,[gs:60h]  ;// в RDI указатель на PEB чужого/своего процесса
;....

Спойлер: TEB & PEB

;//--------- Логи из WinDbg --------------
0: kd> !teb
TEB at 000007fffffde000
    ExceptionList:        0000000000000000
    StackBase:            00000000000d0000
    StackLimit:           00000000000c6000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 000007fffffde000
    EnvironmentPointer:   0000000000000000
    ClientId:             0000000000000c30 . 0000000000000d04
    RpcHandle:            0000000000000000
    Tls Storage:          000007fffffde058
    PEB Address:          000007fffffd7000
    LastErrorValue:       0
    LastStatusValue:      c000003a
    Count Owned Locks:    0
    HardErrorMode:        0

0: kd> !peb
PEB at 000007fffffd7000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            No
    ImageBaseAddress:         000000013f060000
    Ldr                       0000000076ead640
    Ldr.Initialized:          Yes
    Ldr.InInitializationOrderModuleList: 0000000000162c90 . 000000000018a570
    Ldr.InLoadOrderModuleList:           0000000000162b80 . 000000000018a550
    Ldr.InMemoryOrderModuleList:         0000000000162b90 . 000000000018a560
            Base  TimeStamp                      Module
       13f060000  4b673665 Feb 02 01:15:33 2010  C:\program files\Debugging Tools for Windows (x64)\kd.exe
        76d80000  57c99b8f Sep 02 20:32:31 2016  C:\Windows\SYSTEM32\ntdll.dll
        76c60000  57c99bd3 Sep 02 20:33:39 2016  C:\Windows\system32\kernel32.dll
     7fefcff0000  57c99bd4 Sep 02 20:33:40 2016  C:\Windows\system32\KERNELBASE.dll
     7fefdfb0000  4a5bdfbe Jul 14 06:30:38 2009  C:\Windows\system32\msvcrt.dll
        70950000  4b67367a Feb 02 01:15:54 2010  C:\program files\Debugging Tools for Windows (x64)\dbgeng.dll
        73190000  4b673670 Feb 02 01:15:44 2010  C:\program files\Debugging Tools for Windows (x64)\dbghelp.dll
     7fefbe10000  4a5be082 Jul 14 06:33:54 2009  C:\Windows\system32\VERSION.dll
     7fefd690000  57c99b2f Sep 02 20:30:55 2016  C:\Windows\system32\ADVAPI32.dll
     7fefd540000  4a5be05e Jul 14 06:33:18 2009  C:\Windows\SYSTEM32\sechost.dll
     7fefd770000  57c99b3a Sep 02 20:31:06 2016  C:\Windows\system32\RPCRT4.dll
        73140000  4b673674 Feb 02 01:15:48 2010  C:\program files\Debugging Tools for Windows (x64)\symsrv.dll

    SubSystemData:     0000000000000000
    ProcessHeap:       0000000000160000
    ProcessParameters: 00000000001620a0

    CurrentDirectory:  'C:\program files\Debugging Tools for Windows (x64)\'
    WindowTitle:       'C:\Users\Admin\Desktop\livekd64.lnk'
    ImageFile:         'C:\program files\Debugging Tools for Windows (x64)\kd.exe'
    CommandLine:       'kd.exe      -z C:\Windows\livekd.dmp'
    Environment:       000000000018a6b0
        ALLUSERSPROFILE=C:\ProgramData
        APPDATA=C:\Users\Admin\AppData\Roaming
;.................