flat assembler
Message board for the users of flat assembler.

flat assembler > Windows > Possible bug when handling "data" section flag

Author
Thread Post new topic Reply to topic
Ben321



Joined: 07 Dec 2017
Posts: 24
Whenever you set the "data" section flag for the "section" statement in FASM, even if it's not for a section named ".data", that section is treated as if it were a ".data" section. I discovered this when I looked at a DLL I compiled with FASM by loading it into OllyDbg.

Now the DLL has an exports section called ".edata" and in OllyDbg this section is labeled as "Data,exports". However when looking at another DLL, one which I made by using NASM for the assembler and GoLink for the linker, in OllyDbg it shows the ".edata" section labeled only as "Exports". Now I wondered why this was, after all both the FASM DLL and the NASM+GoLink DLL have the same flags in the section header for ".edata" (those flags are INITIALIZED_DATA|READ). However the labeling of them (OllyDbg can report what a section is being used for, by looking at variety of different headers) showed that ".edata" section in the the FASM DLL was labeled as having both "data" and "exports", while the ".edata" section in the NASM+GOLINK DLL was labeled as only being for "exports".

Careful examination of the main PE header showed the difference. In the FASM DLL, the BaseOfData field pointed to the ".edata" section. However, in the NASM+GoLink DLL, the BaseOfData field was 0 (as there was no ".data" section in the file).

From my understanding of the official PE specs, the BaseOfData field in the PE header is supposed to point to the ".data" section in files that have that section. Otherwise it's supposed to be 0. The related field, called SizeOfInitializedData, is a bit different. It's supposed to contain the sum of the sizes of all sections for which the section headers contain the INITIALIZED_DATA flag. And your SizeOfInitializedData field is correct. It appears that only your BaseOfData field is wrong here. For any DLL (or EXE file for that matter) that does not contain a ".data" section, the BaseOfData field in the PE header should be 0.
Post 08 Dec 2017, 03:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15872
Location: 162173 Ryugu
The name of the section is arbitrary. You can name it anything (yes really, even a empty string) the loader completely ignores the name. You can also have many sections all named the same with the same flags. The loader won't care, and it is not prohibited by the PE specs. You can name your data section ".text" and your code section ".data" if you want to. The names are just a tradition, not a requirement.
Post 08 Dec 2017, 03:13
View user's profile Send private message Visit poster's website Reply with quote
Ben321



Joined: 07 Dec 2017
Posts: 24
revolution wrote:
The name of the section is arbitrary. You can name it anything (yes really, even a empty string) the loader completely ignores the name. You can also have many sections all named the same with the same flags. The loader won't care, and it is not prohibited by the PE specs. You can name your data section ".text" and your code section ".data" if you want to. The names are just a tradition, not a requirement.


Is it possible then maybe to have more control of FASM's behavior, so that you can tell it not to have BaseOfData point to the exports section .edata? That way it would mimick the behavior of other assemblers and linkers that I've seen. I'm pretty sure that it's not correct PE specs to have BaseOfData point to a section with special purpose (such as the section containing the export table, typically called .edata). I believe that BaseOfData is supposed to only point to a section containing generic data, as is typically found in the .data section.
Post 08 Dec 2017, 05:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15872
Location: 162173 Ryugu
Export data, and import data, do not have to be in a separate section. They are just data actually and can appear anywhere that other data appears. As long as the PE headers correctly point to the data (in whatever section it appears) then everything is okay.

You can use the "data" directive to put values into the PE header:
Code:
data 12 ;PE header offset 12 will point to this data db 'random data' ;blah end data
the manual wrote:
data directive begins the definition of special PE data, it should be followed by one of the data identifiers (export, import, resource or fixups) or by the number of data entry in PE header. The data should be defined in next lines, ended with end data directive. When fixups data definition is chosen, they are generated automatically and no more data needs to be defined there. The same applies to the resource data when the resource identifier is followed by from operator and quoted file name – in such case data is taken from the given resource file.
Post 08 Dec 2017, 05:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6876
Location: Kraków, Poland
Ben321 wrote:
Is it possible then maybe to have more control of FASM's behavior, so that you can tell it not to have BaseOfData point to the exports section .edata?
Please try out fasmg, where everything including the PE formatting is generated through customizable macros. Having more control over the assembler's behavior is exactly on of the advantages of the all-macro approach. The PE.INC can be configured with a couple of settings in PE.Settings namespace, but even for things that currently have no dedicated option, it is usually easy to alter the macros to get them to do what is needed. The BaseOfData field is initialized around the line 473 of PE.INC:
Code:
if DATA_SIZE = 0 & MAGIC <> 0x20B load DATA_BASE from PE:SectionTable.VirtualAddress+SECTION_INDEX*SectionTable.ENTRY_LENGTH store DATA_BASE at PE:OptionalHeader.BaseOfData end if
Funny thing is, initially when I wrote PE.INC for fasmg I made it zero the BaseOfData and family, like many modern linkers do. But then I changed it to be compatible with fasm 1 after it was requested. I should perhaps add another option in "PE.Settings" to allows easily turning this off.
Post 08 Dec 2017, 07:34
View user's profile Send private message Visit poster's website Reply with quote
Ben321



Joined: 07 Dec 2017
Posts: 24
Is it currently possible in just plain fasm (not fasmg) to write custom data to the PE header?
Post 08 Dec 2017, 10:14
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15872
Location: 162173 Ryugu
Ben321 wrote:
Is it currently possible in just plain fasm (not fasmg) to write custom data to the PE header?
Do you mean to manually edit the header? If so, then there is no direct way to do that from within the assembly code. You will need to post process the binary file. Or, another option is to create a raw binary file and do it all manually with macros the way fasmg does it.


Last edited by revolution on 08 Dec 2017, 11:00; edited 1 time in total
Post 08 Dec 2017, 10:59
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6876
Location: Kraków, Poland
Ben321 wrote:
Is it currently possible in just plain fasm (not fasmg) to write custom data to the PE header?
Not in general. Some of the fields can be customized with options given to the FORMAT directive, but fields like BaseOfData are not among them.

It is possible to patch the headers with a second stage of assembly with directives like FILE and STORE, but this would require some sort of batch assembly (or a tool like "make").
Post 08 Dec 2017, 11:00
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
AFAIK, BaseOfData is a completely useless field. Why do you care so much about it? Confused

Sections aren't important except in rare cases (.rsrc is special, maybe .reloc too I forgot). Other than that, sections really don't matter. Most of those fields don't matter either.

What matters in PE are the data directories. Those are the only thing that the loader cares of when doing imports/exports and other special stuff like relocation directory, TLS etc. Make sure the export/import directories are properly set (they are the first two directories, respectively).
Post 08 Dec 2017, 13:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15872
Location: 162173 Ryugu
Furs wrote:
Sections aren't important except in rare cases (.rsrc is special, maybe .reloc too I forgot). Other than that, sections really don't matter. Most of those fields don't matter either.
.rsrc: Not special AFAIK
.reloc: Not special, can be mixed in with normal data sections. No problem.

Indeed the entire program, including data, code, imports, exports, resources, relocation, etc., can all reside in one giant combined section. And you can name it "IHAZALL". Wink Although some AVs may go into major panic mode.
Post 08 Dec 2017, 13:20
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
I'm pretty sure I read .rsrc is special in some MSDN doc (or blog post by MS employee), or rather Microsoft strongly encourage to not mess with it. Unfortunately, can't seem to find it anymore.

Probably it's because many applications scan resources by section and name instead of the resource directory, or something like that.
Post 09 Dec 2017, 00:03
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 2004-2018, Tomasz Grysztar.

Powered by rwasa.