x64dbg предыдущая инструкция

[CheckerChin]

Всем привет. Подскажите пожалуйста, может кто знает, как в x64dbg вернуться на прошлую инструкцию до RIP, на котором происходит краш?
Есть прожка, которую периодически крашит, потому что выполнение передаётся на неизвестную область. Нашёл это значение в стэке, но когда именно туда переходит я не могу понять.
То есть там какая-то бага, которая крашит в 20% случаев. В остальных всё норм. Функция рекурсивная, её отлаживать заебёшься и не факт, что будет запуск с крашем.
Вообщем вопрос в том, как посмотреть предыдущую инструкцию, до перехода на краш. Судя по тому, что адрес нашёлся в стэке, то это какой-то ret.
Только проблема в том, что при ручном отлаживании оно не выполняется так, как выглядит стэк при краше.
Грешил на переполнение буффера где-то, но буфферов на стэке в программе не выделяется (разве что переменные под числа).
Когда бага происходит, то просто исключение, что выполнение кода где-то не там, ну и RIP стоит на этом месте. А как оно туда попало не могу понять.

 

[человек]

windbg
analyze -v

 

[handersen]

вернуться на прошлую инструкцию

Это можно сделать с помощью трассировки, при этом нужно использовать "шаг со входом", чтобы проблемная инструкция записалась в историю.

 

[CheckerChin]

windbg
analyze -v

Не очень помогло или я не понял, что дальше делать с этим. Вся эта информация мне и так известна.

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 000000000128b412 <тут всегда разный адрес>
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000008
   Parameter[1]: 000000000128b412
Attempt to execute non-executable address 000000000128b412

FAULTING_THREAD:  000028a0

PROCESS_NAME:  123.exe

EXECUTE_ADDRESS: 128b412

FAILED_INSTRUCTION_ADDRESS:
+0
00000000`0128b412 ??              ???

ERROR_CODE: (NTSTATUS) 0xc0000005 -                      0x%p                               0x%p.                      %s.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  0000000000000008

EXCEPTION_PARAMETER2:  000000000128b412

IP_ON_HEAP:  000001dfd9080000 <в дизасме смотрел, там нули>
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\ntrebase.log for module which may
contain the address if it were loaded.

IP_IN_FREE_BLOCK: 128b412

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

FRAME_ONE_INVALID: 1

Это можно сделать с помощью трассировки, при этом нужно использовать "шаг со входом", чтобы проблемная инструкция записалась в историю.

А её можно как-то автоматизировать? Функция большая, с разными вызовами других функций. Так еще и рекурсивная, думаю 1 проход с заходом по всё может много времени занять.
UPD:
с трассировкой вроде разобрался, надо пробовать

 

[handersen]

А её можно как-то автоматизировать?

В книге Вскрытие покажет! Практический анализ вредоносного ПО, со страницы 219, что-то по этой теме. Может еще Process Monitor-ом Руссиновича прогу посмотреть, куда она там лезет и при каких условиях падает?
По работе с x64dbg на Stack Exchange может полезное найтись.

 

[Kapibara]

бери виндебаг и не еби себе и другим мозги

 

[CheckerChin]

бери виндебаг и не еби себе и другим мозги

То что выше советовали не помогло. Виндбг особо ничего полезного не вывел
А трассировка в x64dbg слишком много времени занимает, так еще и судя по всему ограничена в кол-во шагов. (учитывая, что бага не каждый раз выскакивает, то очень много времени тратится).
Виндбг сейчас ковыряю, пока безуспешно

 

[человек]

windbg нужно уметь пользоваться
гуглите и учитесь

а других учить времени и желания ни у кого нет

 

[Whisper]

Ага виндбг это быстренько и просто =)