I have a binary file and in the optional header I have the address of the entry point 0x00011046 but when I put the file inside HEX editor this address doesn't exist, more than that 0x000097f0.

I suppose that this is kind of RVA but I don't know how can I find the real address.
enter image description here

I have the section headers:
enter image description here

I am not sure but the .textbss is 0x10000, I tried to do 0x11000 - 0x11046 = 0x1046 and search for this in the file but it doesn't look like the entry point.

  • 1
    Why has this question been downvoted? Even if the question has not been asked precisely, for me it was clear what the OP wanted to know. Upticked.
    – josh
    Oct 13, 2020 at 13:01

2 Answers 2


In PE file, AddressOfEntryPoint is a relative address to the image base, so you will have 0x11046 - 0x10000 = 0x1046 value in Optional Header. For more information, see PE format and search for "AddressOfEntryPoint".

The reason you see 0x00011046 being displayed as the entry point (in CFF Explorer I suppose) is that when the file is loaded into memory, this will be the EP address in a process virtual memory - not the offset within PE file itself. The same will hold if you load the file into IDA or radare2, for example - EP will be displayed at 0x00011046.

Note: another quick way to find the place where EP value is stored, other than searching for 0x1046 in hex editor is just reading the Offset column value displayed - in this case it equals 0x120.

In general, you would have to read the value at offset 0x3C (IMAGE_DOS_HEADER.e_lfanew) and add 0x28 to it (AddressOfEntryPoint offset relative to PE header).


From your question it is not quite clear what you want to achieve: I assume you need the address in memory where you can find the "Address of Entry Point", as well as the file offset where the code at "Address of Entry Point" is stored.

  1. Let us look at your screenshots for the file offset of "Address of Entry Point"

In your screenshot you find in the "Meaning" column that the "AddressOfEntryPoint" is contained somewhere in the .text section.

In your screenshot of the section headers you find the start of the .text section at the "Virtual Address" 0x11000. Likewise you find the start of the .text section in the file at the "Raw Address" of 0x400. The difference is 0x11000 - 0x400 = 0x10C00, meaning the hex value of the RVA is by 0x10C00 higher than the same position in the file.

Now you have to subtract the value of 0x10C00 from the "AddressOfEntryPoint" to find the corresponding file offset. This should in your case result in 0x11046 - 0x10C00 = 0x446. This should be the file offset where to find the code residing at "AddressOfEntryPoint". The value of "AddressOfEntryPoint" itself (0x11046) can be found at file offset (the "Offset" entry) 0x120, as pointed out also by @bart1e.

  1. RVA where to find e.g. in Ida the "AddressOfEntryPoint

Take the vaue of "ImageBase" and add to it the "Address of entry point" (as also pointed out by @bart1e), in your case:

0x00400000 + 0x00011046 = 0x411046.

This address will e.g. Ida show you as "start" point after having loaded it. However if you are running the debugger, the situation changes as the "ImageBase" usually will be changed by the NT loader to some random number (called ASLR). You can find this randomized start address in several ways, e.g. by letting Ida run the binary and "stop on process entry start" (Debugger options..) and subtracting your "Address of entry point" from the start address shown by Ida.

Remark: For investigation of a binary, it is often useful to avoid this ASLR. You can try to achieve this for instance in CFF Explorer by selecting in the "Optional Header" window the entry "Dll Characteristics" (a little down in the invisible part of your screenshot), click on "Click here", and then, in the opening dialog un-select the checkbox "DLL can move". The NT loader will now try to avoid ASLR and load the binary at the "ImageStart" address. However, in case of another module is to be loaded at tha same base address i.e. having an address collision, the NT loader will move it to somewhere else anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.