• XSS.stack #1 – первый литературный журнал от юзеров форума

Помогите с RunPE (Process Hollowing) x32->x64

Отслеживать
weaver сказал(а):
Попался реп на днях, мб кому интересно будет

Nim implementation of Process Hollowing using syscalls (PoC)

GitHub - snovvcrash/NimHollow: Nim implementation of Process Hollowing using syscalls (PoC)

Nim implementation of Process Hollowing using syscalls (PoC) - GitHub - snovvcrash/NimHollow: Nim implementation of Process Hollowing using syscalls (PoC)
github.com
Бро, к сожалению, этот реп ничего (кроме способа инжекта) с тредом общего не имеет. Whispers насколько я знаю доступен только для х64, плюс яп - Nim.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
Так NT-статусы везде нормальные?
Прошу прощения, всё-таки один NT статус ненормальный. В цикле записи секций.
C++: 
dwRet64 = X64Call(MyNtWriteVirtualMemory, 5, (DWORD64)pInfo.hProcess, (DWORD64)((LPBYTE)mem + SectionHeader->VirtualAddress), (DWORD64)((LPBYTE)lpImage + SectionHeader->PointerToRawData), (DWORD64)SectionHeader->SizeOfRawData, (DWORD64)NULL);
 
IPirateS6 сказал(а):
Прошу прощения, всё-таки один NT статус ненормальный. В цикле записи секций.
C++: 
dwRet64 = X64Call(MyNtWriteVirtualMemory, 5, (DWORD64)pInfo.hProcess, (DWORD64)((LPBYTE)mem + SectionHeader->VirtualAddress), (DWORD64)((LPBYTE)lpImage + SectionHeader->PointerToRawData), (DWORD64)SectionHeader->SizeOfRawData, (DWORD64)NULL);
Такой статус показывает:
1640781598200.png
 
Пожалуйста, обратите внимание, что пользователь заблокирован
IPirateS6 сказал(а):
В цикле записи секций.
Какая именно секция? Ну на вскидку, если какая-то из секций данных содержит только нули, то в PE-файле может и не быть Raw-данных для оптимизации, в этом случае SizeOfRawData нулевой скорее всего и указатель на них тоже. В общем проверь, что и куда ты пишешь.
 
DildoFagins сказал(а):
Какая именно секция? Ну на вскидку, если какая-то из секций данных содержит только нули, то в PE-файле может и не быть Raw-данных для оптимизации, в этом случае SizeOfRawData нулевой скорее всего и указатель на них тоже. В общем проверь, что и куда ты пишешь.
DildoFagins сказал(а):
Какая именно секция?
Все)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Это надо дебажить, а не угадывать. Что вообще и куда пишется, какие инструкции выполняются.
Не писал ни разу RunPE x64, в 32 битном надо чтобы imagebase совпадал у обоих процессов. Хз как в таком случае, мб надо что-то еще, там релоки править или что.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
Это надо дебажить, а не угадывать. Что вообще и куда пишется, какие инструкции выполняются.
Не писал ни разу RunPE x64, в 32 битном надо чтобы imagebase совпадал у обоих процессов. Хз как в таком случае, мб надо что-то еще, там релоки править или что.
В случае с RunPE всю работу делает виндовый загрузчик, тут дело явно не в этом.
IPirateS6, ты в коде работаешь с x86 указателями, может в этом проблема? Тоже навскидку.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
Не писал ни разу RunPE x64, в 32 битном надо чтобы imagebase совпадал у обоих процессов
Не обязательно, но нужно ImageBase поменять в двух PEB'ах: 32-битном и 64-битном.

IPirateS6 сказал(а):
Все)
Выведи все указатели с именами секций, откуда куда пишешь. Обычно такой статус вылазит, когда один из указателей (откуда или куда) неверный.
 
DildoFagins сказал(а):
Не обязательно, но нужно ImageBase поменять в двух PEB'ах: 32-битном и 64-битном.


Выведи все указатели с именами секций, откуда куда пишешь. Обычно такой статус вылазит, когда один из указателей (откуда или куда) неверный.
Изменив часть кода с записью секций на этот у меня получилось избежать данной ошибки. Но ситуация всё та же.
C++: 
PIMAGE_SECTION_HEADER pSectionHeader = IMAGE_FIRST_SECTION(inhNtHeader64);
            for (int section = 0; section < inhNtHeader64->FileHeader.NumberOfSections; section++) {
                dwRet64 = X64Call(MyNtWriteVirtualMemory, 5, (DWORD64)pInfo.hProcess, DWORD64(DWORD64(mem) + pSectionHeader[section].VirtualAddress), DWORD64(DWORD64(lpImage) + pSectionHeader[section].PointerToRawData), (DWORD64)pSectionHeader[section].SizeOfRawData, (DWORD64)NULL);
            }
 
Пожалуйста, обратите внимание, что пользователь заблокирован
winhost сказал(а):
В случае с RunPE всю работу делает виндовый загрузчик, тут дело явно не в этом.

DildoFagins сказал(а):
Не обязательно, но нужно ImageBase поменять
Или я чето путаю, давно уже не писал Runpe. Но как оно будет работать, допустим у жертвы imagebase 0x01000000 у малварки 0х00400000. Как делаем - выделяем память и копируем по адресу 0х00400000, потому что иначе малварь не будет работать (имею ввиду без правки релоков).
 
IPirateS6 сказал(а):
Изменив часть кода с записью секций на этот у меня получилось избежать данной ошибки. Но ситуация всё та же.
C++: 
PIMAGE_SECTION_HEADER pSectionHeader = IMAGE_FIRST_SECTION(inhNtHeader64);
            for (int section = 0; section < inhNtHeader64->FileHeader.NumberOfSections; section++) {
                dwRet64 = X64Call(MyNtWriteVirtualMemory, 5, (DWORD64)pInfo.hProcess, DWORD64(DWORD64(mem) + pSectionHeader[section].VirtualAddress), DWORD64(DWORD64(lpImage) + pSectionHeader[section].PointerToRawData), (DWORD64)pSectionHeader[section].SizeOfRawData, (DWORD64)NULL);
            }
В процес хакере кстати говоря после всех изменений начал отображаться бинарь.
1640787862200.png
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
Или я чето путаю, давно уже не писал Runpe. Но как оно будет работать, допустим у жертвы imagebase 0x01000000 у малварки 0х00400000. Как делаем - выделяем память и копируем по адресу 0х00400000, потому что иначе малварь не будет работать (имею ввиду без правки релоков).
Если я правильно тебя понял, решается правкой NT заголовка бинарника, который мы грузим в память и последующей загрузкой по нужному ImageBase.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
winhost сказал(а):
решается правкой NT заголовка бинарника, который мы грузим в память и последующей загрузкой по нужному ImageBase.
мб и так, не помню уже, RunPE сейчас не особо актуален, как метод.

IPirateS6 сказал(а):
начал отображаться бинарь.
будет ли корректно работать 32 битный бинарь, который загружен по адресу , превышающему 32 битное число ? мб грузить все же по его ImageBase ?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
мб и так, не помню уже, RunPE сейчас не особо актуален, как метод.


будет ли корректно работать 32 битный бинарь, который загружен по адресу , превышающему 32 битное число ? мб грузить все же по его ImageBase ?
Как сказал ТС, он в качестве модуля делает, поэтому смею предположить, что вся эта магия будет происходить из системного процесса, поэтому все будет гуд.
IPirateS6 размеры указателей на x86 и x64 отличаются, пошамань с ними, мне кажется, проблема в этом.
 
Quake3 сказал(а):
будет ли корректно работать 32 битный бинарь,
Я инжекчу 64 битный бинарь в 64 битный svchost. Инжект идёт из-под 32 битного(WoW64) dllhost.exe
winhost сказал(а):
размеры указателей на x86 и x64 отличаются, пошамань с ними, мне кажется, проблема в этом.
А где я использовал х86 указатель? В коде я использовал DWORD64. И в sizeof передавал DWORD64 вместо PVOID.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх