Любой инструмент (ы) для знания структуры (сегментов) запущенного процесса в Windows?

Question

Мне всегда было любопытно

1. Как именно процесс выглядит в памяти?
2. Каковы различные сегменты (части) в нем?
3. Как точно будут связаны программа (на диске) и процесс (в памяти)?

Мой предыдущий вопрос: дополнительная информация о разметке памяти исполняемой программы (процесса)

В своем квесте я наконец нашел ответ. Я нашел эту отличную статью, которая очистила большинство моих запросов: http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html

В приведенной выше статье автор показывает, как получить различные сегменты процесса (LINUX), и сравнивает его с соответствующим файлом ELF. Я цитирую этот раздел здесь:

Обидно видеть реальную планировку сегмент процесса? Мы можем использовать / proc // файл карт для его выявления. PID процесса, который мы хочу наблюдать. Прежде чем двигаться дальше, мы есть небольшая проблема здесь. Наш тест программа работает так быстро, что заканчивается прежде чем мы сможем даже свалить связанные / proc запись. Я использую GDB, чтобы решить это. Вы можете использовать другой трюк, такой как вставка sleep () перед вызовом возврата ().

в консоли (или в эмуляторе терминала) например, xterm) do:

$ gdb test
(gdb) b main
Breakpoint 1 at 0x8048376
(gdb) r
Breakpoint 1, 0x08048376 in main ()

Держи прямо здесь, открой другую консоль и узнать PID программы "тестовое задание". Если вы хотите быстрый путь, Тип:

$ cat /proc/`pgrep test`/maps

Вы увидите вывод, как показано ниже (вы может получить другой вывод):

[1]  0039d000-003b2000 r-xp 00000000 16:41 1080084  /lib/ld-2.3.3.so
[2]  003b2000-003b3000 r--p 00014000 16:41 1080084  /lib/ld-2.3.3.so
[3]  003b3000-003b4000 rw-p 00015000 16:41 1080084  /lib/ld-2.3.3.so
[4]  003b6000-004cb000 r-xp 00000000 16:41 1080085  /lib/tls/libc-2.3.3.so
[5]  004cb000-004cd000 r--p 00115000 16:41 1080085  /lib/tls/libc-2.3.3.so
[6]  004cd000-004cf000 rw-p 00117000 16:41 1080085  /lib/tls/libc-2.3.3.so
[7]  004cf000-004d1000 rw-p 004cf000 00:00 0
[8]  08048000-08049000 r-xp 00000000 16:06 66970    /tmp/test
[9]  08049000-0804a000 rw-p 00000000 16:06 66970    /tmp/test
[10] b7fec000-b7fed000 rw-p b7fec000 00:00 0
[11] bffeb000-c0000000 rw-p bffeb000 00:00 0
[12] ffffe000-fffff000 ---p 00000000 00:00 0

Примечание: я добавляю число в каждой строке в качестве ссылки.

Вернуться к GDB, введите:

(gdb) q

Итак, в итоге мы видим 12 сегментов (также называемых областью виртуальной памяти - VMA).

Но я хочу знать о формате Windows Process & PE.

1. Есть ли инструмент (ы) для получения макета (сегментов) запущенного процесса в Windows?
2. Есть ли другие полезные ресурсы для получения дополнительной информации по этому предмету?

EDIT:

Есть ли хорошие статьи, в которых показано соответствие между PE-файлом sections & VA segments?

Answer 1

Sysinternals VMMap также является отличным инструментом для визуализации пространства процесса VA:

_{(источник: microsoft.com )}

Answer 2

Запустите "! Address" в WinDbg в запущенном процессе. Вы увидите каждый сегмент виртуальной памяти в процессе с некоторой классификацией - образ, файл отображения памяти, стек, куча, PEB, TEB и т. Д.

Windows Internals всегда является хорошим справочным материалом для подобных вещей.

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

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
----------------------------------------------------------------------------------------------------------------------
*        0`00000000        0`00be0000        0`00be0000             MEM_FREE    PAGE_NOACCESS                      Free 
*        0`00be0000        0`00bf0000        0`00010000 MEM_MAPPED  MEM_COMMIT  PAGE_READWRITE                     MemoryMappedFile "PageFile"
*        0`00bf0000        0`00bf7000        0`00007000 MEM_MAPPED  MEM_COMMIT  PAGE_READONLY                      MemoryMappedFile "PageFile"
*        0`00bf7000        0`00c00000        0`00009000             MEM_FREE    PAGE_NOACCESS                      Free 
*        0`00c00000        0`00c03000        0`00003000 MEM_MAPPED  MEM_COMMIT  PAGE_READONLY                      MemoryMappedFile "PageFile"
*        0`00c03000        0`00c10000        0`0000d000             MEM_FREE    PAGE_NOACCESS                      Free 
*        0`00c10000        0`00c12000        0`00002000 MEM_MAPPED  MEM_COMMIT  PAGE_READONLY                      MemoryMappedFile "PageFile"
*        0`00c12000        0`00c20000        0`0000e000             MEM_FREE    PAGE_NOACCESS                      Free 
*        0`00c20000        0`00c21000        0`00001000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unclassified> 
*        0`00c21000        0`00c30000        0`0000f000             MEM_FREE    PAGE_NOACCESS                      Free 
*        0`00c30000        0`00c97000        0`00067000 MEM_MAPPED  MEM_COMMIT  PAGE_READONLY                      MemoryMappedFile "\Device\HarddiskVolume2\Windows\System32\locale.nls"

Answer 3

Другой просмотрщик виртуальной памяти - VMValidator . Визуальные данные макета памяти, а также данные на страницах памяти и абзацах памяти.

Что касается компоновки PE-файлов, я рекомендую книгу Expert .Net 2.0 IL Assembler , глава 4. Он в основном нацелен на управляемый (.Net) PE-файл, а не на собственный, но действительно описывает, как все это выложено.

Тогда, если вы хотите увидеть некоторый исходный код (C ++), который читает PE-файл, вам следует взглянуть на PE File Format DLL . Существует также графический интерфейс, который показывает вам, как использовать DLL. Лицензия на источник является открытым исходным кодом и не ограничена GPL.

РЕДАКТИРОВАТЬ: Другая рекомендация книги будет Внутри Microsoft Windows 2000 (3-е издание) Дэвида А. Соломона и Марка Е. Руссиновича (парни, написавшие VMMap, упоминали в другом ответе). В этой книге есть разделы об управлении памятью, начиная с макета таблицы страниц и заканчивая более масштабным управлением памятью в макроуровне, и еще одна глава, посвященная различным вопросам, связанным с процессами, потоками и связанными структурами данных.

Что касается разметки PE и размещения виртуальных адресов, DLL загружается в область памяти, которая находится на границе абзаца (64 КБ для x86), выделенной VirtualAlloc (). Защита памяти различных страниц (4K на x86, 8K на x64) внутри этого устанавливается в соответствии с описанием каждого раздела в файле PE (только чтение, чтение / выполнение, чтение / запись) и т. Д. Таким образом, зная PE расположение файлов полезно, поэтому я упомянул об этом.

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