We have analysed the basic structure of a Portable Executable, to delve into the structure of executable files. We have seen the basic types and purposes of sections in the executable files. In the post pertaining to sections, we mentioned that the definition and the use of section is variable. We’ll have a practical example of the following. Let’s take a look at traditional/conventional code first:
and the corresponding section table of the Portable Executable in hex:
Now let’s look at a modified version of the code, with the corresponding section table:
As we can see even if the sections are given random names, they are reflected in the executable file and does not seem to cause any problems. There are two things that are to be noticed in this code. This first thing that is established from the two different executables are that the names of the sections are not binding properties. The next obvious question is what then defines the sections? The answer is that the defined sections are not the strictest rules but are more like guidelines. If you remember in the section table, one of the fields in the section data structure is characteristics, which are flags that dictate the behaviour of the section . It is this field that decides the behaviour of the section. Correspondingly, in the assembly code it is the circled part of the following line that decides that behaviour of the section To prove it is so , if the code is read carefully, the data section is defined as executable and the code in the .text section does take a jump to the code in this section and back. This is valid as long as the section has been given the permission to execute binary patterns at offsets in it’s section.
But the main point to note is that since compilers form the executables, the creation of sections and the components and characteristics, such misuse rarely occurs since it involves coding in assembly or modifying the compiler itself.