So for system32 binaries, dumpbin will report:
...
6178 entry point (0000000140006178)
...
SECTION HEADER #1
.text name
63E6 virtual size
1000 virtual address (0000000140001000 to 00000001400073E5)
6400 size of raw data
400 file pointer to raw data (00000400 to 000067FF)
But the entry point at RVA 6178 maps to file offset 6178-1000+400 = 5578h (21,880), but the file opened in a hex editor only goes up to 4A00h (18,944).
Also, the file size is reported as 38,400 bytes by the shell.
So it seems that the .text section is encrypted or some other magic for system binaries. Anyone know what's going on?
As far as I can see, the Entry point is not pointing to the .text section. This is not unusual for encrypted binaries. Using CFF Explorer or other tools like PeStudio, PE Explorer, etc, you might take a look at the mapping of the Entry Point and the pointed Section.
Related
I am using IDA Pro to disassemble a Windows DLL file. At one point I have a line of code saying
mov esi, dword_xxxxxxxx
I need to know what the dword is, but double-clicking it brings me to the .data page and everything is in question marks.
How do I get the plain text that is supposed to be there?
If you see question marks in IDA, this means that there's no physical data at this location on the file (on your disk drive).
Sections in PE files have a physical size (given by the SizeOfRawData field of the section header). This physical size (on disk) might be different from the size of the section once it is mapped onto the process memory by the Windows' loader (this size is given by the VirtualSize field of the section header).
So, if the VirtualSize field is bigger than the SizeOfRawData field, a part of the section has no physical existence and it exists only in memory (once the file is mapped onto the process address space).
On most case, at program entry point, you can assume this memory is filled with 0 (but some parts of the memory might be written by the windows loader).
To get the locations where the data is being written, read or loaded you can use cross-references (xref). Here's an example :
Click on the name of the data from which you want the xref :
Then press 'x', you'll be shown all known (to ida) location where the data is used :
The second column indicates how the data is used:
r means it is read
w means it is written
o means it is loaded as a pointer
Suppose I have a PE file(E.G. Notepad.exe). Suppose when the file is saved in hard-disk, the .text section of notepad.exe is at 0xabcdefgh offset.
So, how can I calculate/predict the offset of .text section when the same executable (notepad.exe) will be loaded into memory at the time of its execution, assuming ASLR is not enabled?
Thanks in Advance.
PE files are not position independent. Instead, they have a preferred load address, and if the OS is unable (because the address space is already used, or because ASLR is in effect) to load it in this address, it has to relocate it. See here:
http://en.wikipedia.org/wiki/Portable_Executable#Relocations
So, if ASLR (Address Space Layout Randomization) is not enabled, it should load at the offset specified by the preferred load address specified in the header. This may not be the case for DLLs, but for executables it should be.
You can get more info on the file format here:
http://www.wotsit.org/list.asp?fc=5
I'm currently looking through a PE file's section table, both from the raw data on the disk, and through a couple of PE analysers. I'm a little confused over how some addresses are being interpreted.
For example. From the raw PE image on disk, I see this:
.text virtualSize: 0x1A0F71 virtualAddress: 0x1000 rawSize: 0x1A1000
However, when using some PE analysers (LordPE, pedump.me), I see this:
.text virtualSize: 0x114d41 virtualAddress: 0x1000 rawSize: 0x114e00
I'm not sure how these values are being interpreted. It is something to do with alignment, and the image's base address?
Any input would be appreciated.
Thanks
Maybe this would help you to solve the problem:
This requires psychic debugging, the size of a section isn't affected by RVA. The crystal ball says that you are actually looking at two different files. And your PE dumper utilities are 32-bit programs that you run on a 64-bit operating system.
You have to understand the File System Redirector. A 32-bit process will be redirected from c:\windows\system32 to c:\windows\syswow64 and from c:\program files to c:\program files (x86). So your PE dumper utilities could well be opening the 32-bit version of an executable instead. And yes, the .text section will be substantially smaller.
Copy the file to a directory that's not affected by redirection, like your Documents folder.
I have just been reading about the offsets of instructions which they are in a file on the disk, the RVA and the VA once they are loaded into the memory. I also read that if a PE file were loaded into the memory exactly as it were in the disk, the RVA would be same as the file offsets(and that it would be very unusual for that to happen).
My doubt is - under normal circumstances, what are these RVA's relative to? The start of that particular PE data structure?
Edit: by PE data structure I mean - PE header, DOS header, DOS stub, PE file header, Image optional header, Section table and Data directories.
RVA is the address relative to the image base address, after having been loaded into memory.
The MS PE/COFF specification says:
Relative virtual address. In an image file, the address of an item after it is loaded into memory, with the base address of the image file subtracted from it. The RVA of an item almost always differs from its position within the file on disk (file pointer).
The above is the complete list of MS-DOS header fields, but I don't know which of them are mandatory and which are optional, does anyone know?
If you're trying to create PE Image, e_magic(Magic number) and elfanew(File address of new exe header) are the only mandatory fields that you have to fill in. elfanew should point to the PE IMAGE_NT_HEADER structure.
Well back in 2006 someone wanted to create the world most tiny PE. For this he wrote a small PE Fuzzer. With the smallest codebase posible.
return 42;
He managed to get the following sizes of PE's
you are too busy to read the entire page, here is a summary of the results:
Smallest possible PE file: 97 bytes
Smallest possible PE file on Windows 2000: 133 bytes
Smallest PE file that downloads a file over WebDAV and executes it: 133 bytes
You can check his work here:
http://www.phreedom.org/research/tinype/
He also states the required header values. These are:
e_magic
e_lfanew
Machine
NumberOfSections
SizeOfOptionalHeader
Characteristics
OptionalHeader:
Magic
AddressOfEntryPoint
ImageBase
SectionAlignment
FileAlignment
MajorSubsystemVersion
SizeOfImage
SizeOfHeaders
Subsystem
SizeOfStackCommit
SizeOfHeapReserve
For MS-DOS, all of the headers are mandatory.
For Win9x and above, e_lfanew must be the offset from the start of the image to the start of the IMAGE_NT_HEADERS, and e_magic must be IMAGE_DOS_SIGNATURE ('MZ').