I am new to assembly language and try to get the memory base of the .rdata section because I would like to compare a string from there with a current string that's on the stack. I am using x64dbg.
Example: At a specific call I see the (relative) memory address from some data that is stored in .rdata, let's say it is 0x001C0000 and .rdata starts at 0x001A0000 and ends at 0x001F0000. In x64dbg I can get the .rdata memory base by typing mem.base(0x001C0000) which returns 0x001A0000 but how can I do it in x86 assembly language? What I am trying to do is access data from .rdata but I don't know the offset from the memory base. How can I do that?
Use "dumpbin.exe". Here is how: suppose your file is "foo.exe", do:
dumpbin.exe /all foo.exe >foo.txt
Then, open foo.txt and look for "SECTION HEADER #1" and check the name (for example ".text"). Then, look for "SECTION HEADER #2", #3, etc..
One of these will be named ".rdata". Just under the name, you have the field "virtual address". That's what you want.
Related
i got two PE files having same sections named as ".data". These name contains different bytes when we see in hex dump. This sections is having 00 bytes in contents. What is this file type can be?
https://www.curlybrace.com/archive/PE%20File%20Structure.pdf
You can get all the details about section names here [PE file Structure]
And then decide yourself if the file is malicious or not.
Happy Overflowing :D
Normal compilers shouldn't produce two sections with identical names, so the likely explanation is that the binary was modified post-compilation. Such obvious modifications are typical (but not conclusive) of malware. Without further information, it's not possible to say much else.
How to find starting offset of resource section in PE file ?
BOOL IsResource(PIMAGE_SECTION_HEADER Input){
}
First you should take a look at the following PE file specification by Microsoft: Microsoft PE and COFF Specification
The information you are looking for is stored in the optional header at offset 112 and is interpreted as IMAGE_DATA_DIRECTORY. Take a look at page 23.
This will give you the RVA (relative virtual address) and the size of the section. Interpretation of this section is explained in section 5.9. beginning at page 89.
The RVA is the address of the table relative to the base address of
the image when the table is loaded.
I am analyzing PE structure.
some article in MSDN(http://msdn.microsoft.com/en-us/magazine/bb985997.aspx) says
"IMAGE_DIRECTORY_ENTRY_IMPORT" points to the imports(an array of IMAGE_IMPORT_DESCRIPTOR structures).
I checked the actual value with 010 Editor PE template.
however the value seemed to be encoded somehow and I don't know how to interpret.
pictures below clearly explains this situation problem.
some advice would be appreciated...!
I looked through the template, and it would appear that the "FOA" comments are generated by passing an RVA to the "RVA2FOA" function, which looks like it's converting the RVA to a file offset.
That makes sense, the file offset is something you often want to know (especially in a HEX editor, where you have to navigate by file offset), and FOA looks like it can be short for File Offset Something-or-other.
When looking at PE files in a hex editor, I often encountered some bytes between the section table and the first section, which doesn't really make sense to me. As far as I am concerned, there should be a 00-byte padding in order to fit the alignment. However, here is a screenshot which demonstrates the opposite:
As it turned out the highlighted block is pretty much the Bound Import Table. But I am still confused. Why is this table not located in a section? Is this always the case or is it just the specification of a certain compiler/linker? I did not find any documentation on this specific issue. Everything one can find on this topic basically says:
DOS MZ Header
DOS Stub
PE Header
Section Table
Section 1
Section 2
Section 3
... and so on
Before I encountered this issue I was not even aware of the fact, that there can be things outside of the sections (besides the ones i listed above, of course).
[EDIT]
Proof of concept (Since Mox did not believe me):
Data directories such as the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT can exist outside of sections. Another example of a data directory existing outside of any known section would be the IMAGE_DIRECTORY_ENTRY_CERTIFICATE data directory which is the data directory used to store the certificate information when an executable is signed.
Data directories can point to data outside of a section, with-in a section, or they can point to the entire section. The IMAGE_DIRECTORY_ENTRY_RESOURCE data directory points to the entire ".rsrc" section. Certain data directories point to known sections and these are documented in the PE format specification by Microsoft.
Items like the bound import table can be written wherever the linker wants to put them in the raw image. It just overwrites the zero bytes with the table and makes the pointer correct in the data directory. You could probably even overwrite the middle of the DOS header or stub with the import table and it would work as long as the pointer in the directory was correct.
As far as I can see with LordPe, the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry of iexplore.exe is empty.
both 32bit and 64bit versions of IEXPLORE.EXE don't have IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entries.
Here a snaphot of LordPE, showing the 64bit version of IEXPLORE.EXE on a Windows 7 machine and (in green) the missing IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry:
It looks like you don't look at the right directory entry.
I need to read the ".pdata" section of a x64 PE file.
I've seen that the structures in the ".pdata" section differ from one platform to another
http://msdn.microsoft.com/en-us/library/aa448751.aspx
It also says the same thing in the PE specifications document.
But I dont understand what it is for the regular windows (XP/Vista/Win7 etc.)
Does anybody what it is?
The .pdata section is an array of RUNTIME_FUNCTION. It gives you a code range (first two members) and an RVA to the corresponding UNWIND_INFO.
From there you get info like exception handler RVA, size of prolog, etc.