121112
.pdf
CODE SQUEEZING
PROS
Сохраняется локальность кода
CONS
Чрезвычайно трудоемко 
Абсолютно не поддается автоматизации
CALL HIJACKING
PROS
Очень просто патчить — всего 4 байта
CONS
"Брейкпойнты" только на начало фукций
Можно смотреть только на параметры функций 
Разные модели передачи параметров
JUMPS!
Запоминаем старый код, поверх него пишем jmp на наш код, в конце нашего кода исполняем старый код и делаем jmp обратно.
PROS
Сравнительно легко патчить
Брейкпойты практически в любом месте
Не портится контекст 
Легко автоматизировать
ПРАКТИЧЕСКИ В ЛЮБОМ МЕСТЕ?
Было:
00402B66 8B CF |
mov |
ecx, edi |
00402B68 E8 D3 E5 FF FF |
call |
sub_401140 |
401140 = 402B68 + FFFFE5D3 + 5
Стало:
00902B66 8B CF |
mov |
ecx, edi |
00902B68 E8 D3 E5 FF FF |
call |
sub_901140 |
ПИШЕМ ХОРОШУЮ ОБЕРТКУ
pusha |
|
pushf |
hook_func |
call |
|
popf |
|
popa |
|
taken_code |
|
jmp |
back |
uchar wrap_start[9] = {0x60, 0x9C,
0xE8, 0x00, 0x00, 0x00, 0x00,
0x9D, 0x61};
uchar wrap_end[5] = {0xE9, 0x00, 0x00, 0x00, 0x00};
ОК, И КУДА ЖЕ ПИСАТЬ НАШ КОД?
Code caves
В конце концов, у нас же целая виртуальная память!
КАКИЕ ТАКИЕ CODE CAVES?
.text:0049F771 |
retn |
.text:0049F771 last_func |
endp |
.text:0049F771 |
align 1000h |
.text:0049F772 |
|
.text:0049F772 _text |
ends |
.text:0049F772 |
|
.idata:004A0000 ; Section 2. (virtual address 000A0000)
PROS
Вообще не нужно думать над выделением памяти
CONS
Зависит от конкретной программы, может не хватить места
КАЗАЛОСЬ БЫ, ПРИ ЧЕМ ЗДЕСЬ DLL
БОЛЬШЕ ИНЪЕКЦИЙ, ХОРОШИХ И РАЗНЫХ
1. .\kernel32.dll
2.AppInit_DLLs
3.Windows Hooks
4.VirtualAllocEx + CreateRemoteThread