ВА (виртуальный адрес) и RVA (относительный виртуальный адрес)

Большинство процесса Windows (* .exe) загружаются в (пользовательский режим) адрес памяти 0x00400000, вот что мы называем «виртуальный адрес» (VA) - потому что они видны только для каждого процесса и будет преобразован в различные физические адреса ОС (видимым на уровне ядра / драйвера).

Например, возможный адрес физической памяти (видимый CPU):

0x00300000 on physical memory has process A's main
0x00500000 on physical memory has process B's main

и ОС может иметь таблицу сопоставления:

process A's 0x00400000 (VA) = physical address 0x00300000
process B's 0x00400000 (VA) = physical address 0x00500000

, затем, когда вы пытаетесь прочитать 0x004000000 в процессе A, вы получите контент который расположен на 0x00300000 физической памяти.

Относительно RVA, это просто предназначено для облегчения перемещения. При загрузке перемещенных модулей (например, DLL) система постарается сдвинуть его через пространство процесса памяти. Таким образом, в макете файлов он ставит «относительный» адрес, чтобы помочь вычислению.

Например, DLL C может иметь этот адрес:

 RVA 0x00001000 DLL C's main entry

при нагрузке в процесс A при базовом адресе 0x10000000, основной вход C становится

 VA = 0x10000000 + 0x00001000 = 0x10001000
 (if process A's VA 0x10000000 mapped to physical address was 0x30000000, then 
  C's main entry will be 0x30001000 for physical address).

, когда его загружаются в процесс B при базовом адресе 0x32000000, главная запись C

 VA = 0x32000000 + 0x00001000 = 0x32001000
 (if process B's VA 0x32000000 mapped to physical address was 0x50000000, then 
  C's main entry will be 0x50001000 for physical address).

Обычно RVA в файлах изображений относительно обработки базового адреса при нагрузке в память, но некоторая RVA может быть относительно адреса «раздела» в начальном адресе в изображениях или объектах (вы должны проверить спецификацию формата PE для деталей ). Неважно, что RVA относительно «какая-то» базы VA.

Для суммирования

1. Адрес физической памяти - это то, что CPU видит
2. Virtual Addreess (VA) относительно физического адреса, на процесс (управляется ОС)
3. RVA относится к VA (файловая база или раздел База), на файл (управляется линкером и погрузчиком)

(редактирование), касающиеся нового вопроса Claw:

значение RVA метода / переменной не всегда его смещение от начала файла. Они обычно относительны к некоторым VA, что может быть базовым адресом по умолчанию по умолчанию или раздел Base VA - вот почему я говорю, что вы должны проверить спецификацию формата .

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

Что касается ваших догадок, они очень близки к правильным ответам:

1. Обычно мы не будем обсуждать «RVA» перед разделами, но заголовок PE все равно будет загружен до конца заголовков секции. Зазор между заголовком раздела и корпусом секции (если таковая имеется) не будет загружена. Вы можете изучить это отладчиками. Тофоре, когда между разделами есть разрыв между разделами, они могут быть не загружены.

2. Как я уже сказал, RVA - это просто «относительно некоторого VA», независимо от того, что VA есть (хотя при разговоре о PE, VA обычно относится к базу нагрузки). Когда вы читаете спецификацию Формата Thet PE, вы можете найти некоторую «RVA», которое относительно некоторого специального адреса, такого как адрес для начала ресурсов. Список PEView RVA от 0x1000 заключается в том, что этот раздел начинается с 0x1000. Почему 0x1000? Поскольку линкер слева от 0x1000 байтов для заголовка PE, поэтому RVA начинается с 0x1000.

3. То, что вы пропустили, - это концепция «раздела» в стадии погрузки PE. PE может содержать несколько «разделов», каждая секция отображается на новый запуск VA. Например, это сброшено из Win7 Kernel32.dll:

    # Name Virtsize RVA Phangsize Offset
   1 .text 000C44C1 00001000 000C4600 00000800
   2 .DATA 00000FEC 000C6000 00000E00 000C4E00
   3 .rsrc 00000520 000C7000 00000600 000C5C00
   4 .Reloc 0000B098 000C8000 0000B200 000C6200
    

   Существует невидимый «0 заголовок RVA = 0000, размер = 1000», который заставил .Text начать на RVA 1000. Разделы должны быть непрерывными при нагрузке в память (I.E., VA), поэтому их RVA является непрерывным. Однако, поскольку память выделяется страницами, она будет несколько размеров страницы (4096 = 0x1000 байтов). Вот почему раздел № 2 начинается при 1000 + C5000 = C6000 (C5000 поставляется из C44C1).

   Для того, чтобы обеспечить сопоставление памяти, эти разделы все еще должны быть выровнены некоторыми размерами (размер выравнивания файлов - решить по линкеру. В моем примере выше это 0x200 = 512 байт), который контролирует поле Physsize. Смещение означает «компенсирование для начала файла PE PE PE».

   Итак, заголовки занимают 0x800 байтов файла (и 0x1000 при сопоставлении к памяти), что является смещением раздела № 1. Затем, выравнивая свои данные (байты C44C1), мы получаем Physsize C4600. C4600 + 800 = C4E00, который именно смещение второго сечения.

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

(редактировать) Позвольте мне снова сделать новое простое резюме.

1. Файлы «Формат RVA» в DLL / EXE (PE) обычно относится к «адресу базы нагрузки в памяти» (но не всегда - вы должны прочитать спецификацию)
2. Формат PE содержит «раздел» Структура сопоставления для отображения содержания физического файла в память.Таким образом, RVA на самом деле не относится к смещению файла.
3. Чтобы рассчитать RVA некоторых байтов, вы должны найти его смещение в разделе и добавить секционную базу.