пуша ассемблер

Question

У меня дамп ядра, стек которого поврежден. Я пытаюсь разобрать его и обнаружил, что следующие PLZ помогают мне проанализировать это ..

(gdb) bt
#0  0x55a63c98 in ?? ()
#1  0x00000000 in ?? ()

(gdb) disassemble 0x55a63c90 0x55a63ca8

Dump of assembler code from 0x55a63c90 to 0x55a63ca8:

0x55a63c90:     add    %cl,%dh

0x55a63c92:     cmpsb  %es:(%edi),%ds:(%esi)

0x55a63c93:     push   %ebp

0x55a63c94:     add    %al,(%eax)

0x55a63c96:     add    %al,(%eax)

**0x55a63c98:     pusha**

0x55a63c99:     lret   $0x9

0x55a63c9c:     subb   $0x56,0xd005598(%ebp)

0x55a63ca3:     push   %ebp

0x55a63ca4:     jo     0x55a63cc5

0x55a63ca6:     sahf

0x55a63ca7:     push   %ebp

End of assembler dump.
(gdb) q

Может ли эта инструкция pusha привести к дампу ядра?

Answer 1

Нет ^*, все, что делает pusha - это помещает все регистры общего назначения в стек, включая указатель стека! То, что вызывает дамп ядра, - это инструкция после pusha, lret, которая является длинным возвращением со стеком pop. Адрес возврата - это самое последнее значение, помещаемое в стек, которое в данном случае будет тем, что было в esi: edi (поскольку они являются последними значениями, которые должны быть переданы инструкцией pusha), и это, вероятно, будет указывать на случайное место.

* Если у вас нет свободного места в стеке.

Answer 2

Абсолютно. PUSHA с последующим RET никогда не будет правильным, обратный адрес будет нежелательным. Видя ДОБАВИТЬ AL, [EAX] в вашей разборке - это еще одна мертвая отдача, это разборка для 0.

Другими словами: вы разбираете данные, а не код. Ваша программа взорвалась бомбой, потому что она выполняла данные. Классический способ, которым это происходит, - повреждение фрейма стека переполнением буфера. Когда функция возвращает, она извлекает неверный адрес возврата из поврежденного стека и никогда не приземляется. Отсутствие ошибки в сегменте очень неудачно.

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

Answer 3

проверьте, видите ли выровненный код дизассемблирования:

x/i $eip

Также показывать значения регистров:

i r

Answer 4

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