Оригинальный DVD-ROM: eXeL@B DVD !
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
выпущен 2 сентября!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

АРХИВ ФОРУМА eXeL@B
https://exelab.ru/f/

   

infern0 об Armadillo 3.70 b2 Target: Armadillo 3.70 beta 2


infern0 об Armadillo 3.70 b2 Target: Armadillo 3.70 beta 2

Что нового. В первую очередь обламывается NRec - cannot find jcc resolve proc. Смотрим в код
в раоне GetThreadContext и видим такую херню:

.text1:0048904C mov ecx, [ebp+nano_type]
.text1:00489052 mov edx, [ebp+tbl_2_index]
.text1:00489058 mov eax, ds:tbl_1[ecx*4]
.text1:0048905F xor eax, ds:tbl_2[edx*4]
.text1:00489066 mov ecx, [ebp+tbl_2_index_2]
.text1:0048906C xor eax, ds:tbl_2[ecx*4]
.text1:00489073 mov [ebp+jcc_proc], eax
.text1:00489079 mov edx, [ebp+context.EFlags]
.text1:0048907F and edx, 0FD7h
.text1:00489085 push edx
.text1:00489086 mov eax, [ebp+nano_type]
.text1:0048908C movsx ecx, ds:byte_4B2730[eax]
.text1:00489093 call ds:decodeProcArray[ecx*4]
.text1:0048909A add esp, 4
.text1:0048909D mov [ebp+crypted_Eflags], eax
.text1:004890A3 mov edx, [ebp+context.Ecx]
.text1:004890A9 push edx
.text1:004890AA mov eax, [ebp+crypted_Eflags]
.text1:004890B0 push eax
.text1:004890B1 call [ebp+jcc_proc] ; 47d5ef buildCryptedJccProcTable
.text1:004890B7 add esp, 8
.text1:004890BA push eax
.text1:004890BB mov ecx, [ebp+nano_type]
.text1:004890C1 movsx edx, ds:byte_4B2730[ecx]
.text1:004890C8 call ds:encodeProcArray[edx*4]
.text1:004890CF add esp, 4
.text1:004890D2 mov [ebp+var_147C], eax
.text1:004890D8 mov eax, [ebp+var_147C]
.text1:004890DE and eax, 1
.text1:004890E1 test eax, eax
.text1:004890E3 jz loc_489197
.text1:004890E9 jmp short loc_48910F
[/CODE]

Отсюда видно что вызов процедуры проверки jccCheck производится косвенно,
причем адрес выбирается путем расчетов по двум таблицам. Я написал простую прогу перебирающую
все возможные варианты (код вычисления tbl_2_index и tbl_1_index_2 исходя из nano_type чуть выше)
и по полученным адресам вышел на такую функцию:

[CODE]
.text1:004742FA buildCryptedJccProcTable proc near ; CODE XREF: sub_4742F0+3p
.text1:004742FA push ebp
.text1:004742FB mov ebp, esp
.text1:004742FD mov eax, offset type_00_proc
.text1:00474302 xor eax, ds:tbl_2
.text1:00474308 xor eax, ds:dword_4AE260
.text1:0047430E mov ds:tbl_1, eax
.text1:00474313 mov ecx, offset type_01_proc
.text1:00474318 xor ecx, ds:tbl_2
.text1:0047431E xor ecx, ds:dword_4AE260

и так далее для всех 255 функций. Очень неприятно и то что перед вызовом процедуры проверки
перехода содержимое eflags тоже шифруется. Также внутри каждой функции оно расшифровывается
назад и результат проверки опять шифруется. И в конце концов он расшифровывается назад (4890c8)
и принимается решение о выполнении или пропуске перехода. Короче все это очень сильно похоже
на попытку противостоять автоматическому определению типа перехода.

В остальном изменений не произошло. Слегка подправленный NRec успешно расшифровывает все
таблицы. Пока не решена проблема с типами переходов, ну думаю выходных мне хватит. И потом
возможно стоит подождать выхода релиза версии 3.70 - на нем заодно окончательно и оттестируюсь.

05.08.2004
infern0 / TSRh team

MozgC [TSRh] :: печально... Но я думаю ты справишься =)))
А то я уже обленился NRec’ом пользоваться, без него опять будет по суткам уходить на арму с наномитами =(






   
Оригинальный DVD-ROM: eXeL@B DVD !


Вы находитесь на EXELAB.rU
Проект ReactOS