Например, мы находимся на платформе Windows XP, у нас есть программа A на ollydbg, и мы смотрим на инструкцию x. он имеет адрес 0x11111111 (например). Если я возьму программу A и запустил в ollydbg на другом компьютере с той же платформой, команда x будет иметь тот же адрес 0x11111111? Итак, мой вопрос: меняются ли адреса памяти каждый раз, когда запускается программа A? или они изменены на другом компьютере или платформе?адрес памяти
ответ
В зависимости от архитектуры, но вы никогда не должны полагаться на эти адреса. Для практических целей ответ отрицательный.
Чтобы ответить на ваши комментарии, эксплойты должны выяснить, где они находятся. Простой способ это сделать вызов и поп обратный адрес, как это:
call test_eip
test_eip:
pop eax
В этом случае, вы будете иметь указатель команд в eax
. Это полезно для определения, где введенный код.
Конечно, вам нужно будет добраться до точки, где это выполняется, в основном используя эксплойт переполнения буфера.
Википедия - как всегда - обеспечивает отличное объяснение и много ссылок на ухаживают: http://en.wikipedia.org/wiki/Stack_buffer_overflow
На одной и той же версии операционной системы с тем же исполняемый файл, вы, вероятно, но, безусловно, не смотрите те же кодовые адреса , Различные версии ОС, менее вероятно.
Что вы видите, это виртуальный адрес. ЦП содержит специальные регистры, которые могут видеть только операционная система; эти регистры управляют отображением виртуальной памяти в физическую память. Каждый раз, когда ОС переключается на другой процесс, он перепрограммирует эти регистры, чтобы программа считала, что ее память всегда находится в одном месте.
двоичные файлы Windows PE не являются независимыми от положения, это означает, что им необходимо принять фиксированный адрес для выполнения. Microsoft делает это для повышения производительности исполнения (за счет штрафных санкций за загрузку).
Ваш двоичный файл всегда будет выполняться с того места, где он хочет, однако DLL могут быть перемещены, если их предпочтительный адрес уже используется другим кодом.
Перемещение прозрачно для вас, что происходит, так как бинарный загрузчик Windows модифицирует ваш код и исправляет все адреса, чтобы они работали в новом месте.
- 1. Адрес памяти памяти объекта
- 2. Адрес и адрес памяти
- 3. адрес памяти памяти переменной Python
- 4. Насколько возможно, что адрес памяти также имеет другой адрес памяти?
- 5. Что означает адрес памяти?
- 6. адрес памяти literal
- 7. Адрес памяти от указателя
- 8. Биты в адрес памяти
- 9. Адрес памяти из строки
- 10. Естественно выравненные памяти адрес
- 11. Получить адрес памяти функции
- 12. Lambda возвращает адрес памяти
- 13. Первично присвоен адрес памяти?
- 14. NSArray памяти Адрес
- 15. Сохранить адрес памяти указателя
- 16. Как записать адрес памяти?
- 17. Адрес памяти функции (ASM)
- 18. Адрес памяти не загружается
- 19. Как распечатать адрес памяти?
- 20. Адрес памяти переменной
- 21. Выделенный адрес ячейки памяти
- 22. Адрес постоянной памяти
- 23. Адрес памяти в C
- 24. Адрес памяти вектора uint8_t
- 25. Рассчитать адрес памяти C#
- 26. Печать Адрес памяти
- 27. Случайный адрес памяти
- 28. Адрес памяти функции лямбда
- 29. Адрес памяти массива - Java
- 30. Адрес памяти массива
спасибо большое за ответ. Итак, как эксплоит (основанный на переполнении буфера) может запускать шелковый код (не предполагать никакой защиты) в стеке, где начальный адрес шеллкода должен перезаписывать обратный адрес, и пока мы не можем полагаться на них. как это возможно? это то, что я не могу получить. – nore 2010-12-09 23:08:09
Да, но проблема в том, как можно запустить test_esp, если я не перенаправляю обратный адрес на что-то, чтобы его выполнить. я должен сначала узнать адрес. и, например, я не могу «gdb-it» в уязвимой программе на удаленном компьютере. общий вопрос: насколько хорошо известны эксплуатационные инструменты. иметь им постоянную переменную с возвратом addres? Я прошу слишком много, я знаю, но я думаю, что это разрыв, падающий. Мне нужно руководство для этого, но если вы ответите мне, я по достоинству оценю его. ty again – nore 2010-12-09 23:32:41