Thursday, March 4, 2010

x64 dumps

64 битный windows радует
Первое впечатление - как можно что-то понять по дампу если все передается в регистрах?
fffff980`0091f953 4c8bcb           mov     r9,rbx
fffff980`0091f956 4d8bc6 mov r8,r14
fffff980`0091f959 4c8bb42498010000 mov r14,[rsp+0x198]
fffff980`0091f961 498bd6 mov rdx,r14
fffff980`0091f964 498bcc mov rcx,r12
fffff980`0091f967 e84490feff call Ntfs!NtfsOpenFile (fffff980009089b0)
fffff980`0091f96c 8bd8 mov ebx,eax

Второе еще смешнее. Раньше я всегда искал фрейм функции используя команду scan:

0: kd> s -d esp L100 адрес_возврата_из_функции

Например, так:


Как можно видеть на изображении, эту команду довольно удобно использовать для получения доступа к параметрам функции.
Но! К моему удивлению, под x64 та же команда

0: kd> s -q rsp L1000 адрес_возврата_из_функции

не вернула ровным счетом ничего. Мистика.
Какое-то время я был в замешательстве, пока ситуацию не прояснила немного команда kv:



Если посмотреть на первую колонку Child-SP, то можно заметить прекрасное явление: вначале стек растет как ему и положено в сторону уменьшения адресов от fffff980`0f0e0c20 до fffff980`0f0dfa50, но потом случается Странная Вещь. Стек продолжает расти в сторону уменьшения адресов, но уже начиная с адреса fffff980`10349d60!

Если присмотреться, то можно заметить, чем же вызвано такое странное поведение системы. Оказывается, что драйвер ntfs.sys вызвал функцию ядра KeExpandKernelStackAndCalloutEx, которая, собственно и сотворило сие магическое действо:
"The KeExpandKernelStackAndCalloutEx routine calls a routine and guarantees that a specified amount of stack space is available for this call." (с) MSDN

Интересно что эта функция меняет значения стека Init, Current и Base на новый сегмент, т.е. в нашем случае они стали начинаться на fffff9801034###:
0: kd> !thread -1
THREAD fffffa80015874e0 Cid 03f8.0abc Teb: 000007fffff90000 Win32Thread: 0000000000000000 RUNNING on processor 0
IRP List:
fffffa80023dc010: (0006,03a0) Flags: 00000884 Mdl: 00000000
Unable to read Impersonation Information at 0
Owning Process fffffa8001cda040 Image: svchost.exe
Wait Start TickCount 66603034 Ticks: 261 (0:00:00:04.078)
Context Switch Count 10716
UserTime 00:00:00.0109
KernelTime 00:00:18.0546
Start Address 0x0000000076edc6c0
Win32 Start Address 0x000007fef7a75530
Stack Init fffff98010349db0 Current fffff98010348910
Base fffff9801034a000 Limit fffff98010344000 Call 0


Вот такие вот модные тенденции

No comments: