Что делает kb для 64-битных процессов?

Question

Я недавно ошибся, проанализировав стоп-колл, потому что я не ожидал, что приложение будет 64 бит. Я использовал команду WinDbg kb, чтобы показать столбец и параметры, переданные методам.

На 64-битных параметрах параметры не передаются через стек, а в регистры (RCX, RDX, R8 и R9). Кажется, что WinDbg не выполнил или не полностью выполнил это. Частично я предполагаю, что это почти невозможно, так как значения регистров могли быть изменены тем временем.

Однако помощь WinDbg по-прежнему перечисляет kb как действительную команду под User-Mode, x64 Processor. Поэтому мой вопрос:

Что делает kb дисплей для 64-битных процессов пользовательского режима? Когда/как этот вывод полезен?

Answer 1

Выход «Args to Child», показанный в kb и kv в WinDbg, всегда был очень подозрительным, даже на x86 эти столбцы не обязательно отображают вам аргументы функции.

На x86 «Args to Child» - это просто [EBP + 0x08], [EBP + 0x0C] и [EBP + 0x10] (kv показывает четыре аргумента, таким образом, последний столбец - [EBP + 0x14]). Они будут только аргументы функции, если:

1. Функция использует EBP кадр
2. Функция имеет стек передается аргументы (зависит от вызывающей конвенции)
3. оптимизатор не повторно использовать эти места для чего-то еще

На x64, как вы отметили, первые четыре аргумента функции передаются через регистры. Однако, как часть вызывающего соглашения, вызывающий абонент должен выделять пространство «Дом» (или «Разливать») в стек для каждого из этих аргументов. Это пространство равно всегда выделено, даже если вызываемая функция занимает менее четырех аргументов. Вызванная функция может свободно использовать этот дом пространства так, как он выбирает, он может:

1. Игнорируйте
2. Сохранить энергонезависимые регистры там
3. «Home» регистр передаваемых параметров в стек

Выход kb и kv показывает рабочее пространство на заказ (RCX Home, RDX Home, R8 Home, R9 Home). Чаще всего это пространство будет использоваться для 1 или 2 выше, поэтому оно фактически не имеет ничего общего с переданными в аргументах. Тем не менее, в сборке Debug компилятор немедленно Homes передается в аргументах, чтобы облегчить отладку.

Например, вот пролог функции с двумя аргументами, скомпилированными Debug.Обратите внимание самонаведения аргументов как первые инструкции:

0:000> u DriverEntry 
mov  qword ptr [rsp+10h],rdx 
mov  qword ptr [rsp+8],rcx 
push rdi 
sub  rsp,0C0h 

И тот же код, скомпилированный Release, используя Home Space для энергонезависимого сохранения регистра:

0:000> u DriverEntry 
mov  qword ptr [rsp+8],rbx 
mov  qword ptr [rsp+10h],rdi 
push rbp 
lea  rbp,[rsp-57h] 
sub  rsp,0B0h 

Это означает, что Home Space обычно довольно бесполезно с точки зрения получения аргументов функции. Тем не менее, его все еще можно использовать в качестве средства отладки для восстановления значений энергонезависимого регистра при вводе функции (т. Е. Я могу рассказать вам об уровне RBX или RDI выше, посмотрев на Home Space)

Answer 2

kb показывает список следов стека вместе с тремя параметрами, однако это механизм передачи параметров (вызов), который не делает аргументы отображаемыми достоверными. Вы должны прочитать больше @http://www.codemachine.com/article_x64deepdive.html

dv, и все остальные варианты dv/v и т. Д. Могут показать все значения мусора. только в случае __ этого вызова мы можем использовать rcx в качестве этого указателя, но мы должны разобрать и обеспечить, чтобы указатель не был скопирован где-то еще, а затем повторно использован. Dis-assembly - это путь, если у нас нет параметров homed.