PE: add code at the end of the .txt section
As I understand it in the PE
file, Virtual Size shows how much space it allocates for the partition at boot time, and Raw Size shows how large the partition is on the disk.
I came across this executable which did the following:
It subtracted the virtual size ( offset 0x8
) from the raw data size ( offset 0x10
) and made sure there was some space (e.g. 100 bytes). When offset 0x14
from the title of the text section, it found an offset in the file for the section itself. He added a virtual size to that, I'm where the section ends in the file. it copied some shellcode (which eventually jumped to the original entry point of the executable to make sure the original executable was running) to the end of the text section of the binary.
Now I'm a little confused here, if the virtual size shows the exact space that will be allocated for the executable, wouldn't the code at the end of the section .txt
overwrite some other data of the executable and make it crash? thank.
source to share
This is a great question and illustrates a very important point (or you can tell quirk) about how the Windows boot loader calculates memory sizes.
The PE / COFF specification does describe VirtualSize as "Total size of a partition when loaded into memory". This is technically true if you think that the total amount of REAL data contains the partition, but it is not the total amount of Windows memory allocated to the partition. You will find that VirtualSize is often LESS than the amount Windows allocates for the in-memory partition because VirtualSize must be UP to the nearest memory alignment value (given in the PE image).
In other words, VirtualSize does not represent the enclosed size of the partition, but SizeOfRawData is the size of the data in the image file, but is rounded to the nearest file alignment value. It is for this reason that VirtualSize is the best representation of the true "raw" size of data in memory or on disk. The PE / COFF specification does not make this distinction. Why one is rounded in an image file and not the other probably has its ancient roots in backward compatibility.
This is why your shellcode uses VirtualSize to find the "real" end of the data, even if it's in the image file. Unsurprisingly, you can calculate SizeOfRawData by rounding VirtualSize to the file alignment value, at least in well-formed PE files.
The shellcode just used VirtualSize to find the end of the REAL code. Between them and the bytes, SizeOfRawData are just unused zeros, making it a prime place to add new code without affecting file size or breaking addressing offsets in the PE file.
So the Windows bootloader essentially takes a VirtualSize value and rounds it to the memory alignment value to get the actual size of the memory allocation (and even that can be rounded to the nearest page with minimum 4k memory). Then up to the SizeOfRawData bytes are copied from the file to the beginning of the memory section. If it is less than the size of the section in memory, the remainder is filled with zero.
source to share
Uhmmm, this hack code seems to be crafted to hide the malicious code between sections.
Moving on to your question, you are right. VirtualSize is the space actually allocated in memory and RawSize is the space used on disk to store partition data. What you missed (from MS PECOFF spec):
VirtualSize
: The total size of the partition when loaded into memory. If this value is greater thanSizeOfRawData
, the section has a value of zero. This field is only valid for executable images and must be set to zero for object files.
This means that if a SizeOfRawData
is a VirtualSize
positive result , we have some space available on the disk actually filled with 0 .
If there is enough space to store the malicious code and then add the beginning of a section of text on disk with VirtualSize
, you might end up with a start 0 filled area that can be used to copy the code.
The rest is history ...
source to share