What is really correct translation algorithm to get an offset in portable executable file from relative virtual address of some byte in the image?

I see next cases:

  1. RVA points into the header part of image
  2. RVA points into a section part presented in file
  3. RVA points into a section part not presented in file (some loadtime initialized data)
  4. RVA points out of image

For the first case it's like RVA is equal to offset in a file. (If all parts of file are mapped to the image. I'm not sure about DOS header.)

Further, mapped section can be biger than section in a file so some RVAs jast have no offset like RVA that points out of image.

And last things that I does not undestand at all. Are the values of fildes SizeOfImage, VirtualSize, VirtualAddress, PointerToRawData, SizeOfRawData already take into consideration file alignment and section alignment?

I saw some realizations of RvaToRaw full of black magic that made a correction for alignments, but without any explanation.

If no more alignment is needed so for case 2 it's

raw = rva - rvaOfSection + SectionRaw
  • @DarthGizka Did you read the thread you linked? I don't ask about some disasm tools and even about Virtual Adress. The scope of my question are only RVA and "raw".
    – SerG
    Feb 15, 2015 at 20:03
  • The link leads to an answer containing a simple overview and a simple explanation, which should drive home the importance of the section table for converting between RVA and file offset. The exact details can get tricky, like the question when exactly Windows starts ignoring the alignment math and simply assumes a 1:1 mapping, for example. Most of the info is in the PE COFF specification, in the ReactOS sources, or here
    – DarthGizka
    Feb 15, 2015 at 21:04


Browse other questions tagged or ask your own question.