flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Error 200 - BUG with FASM's "format MZ"

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
revolution wrote:
So what about the next version of windows, can you say with certainty that it won't check the MZ header (probably "for security reasons"). You have potential for incompatibility


Not my fault. After all, I didn't ask for deleting the code enhancing the header, just adding an option, so your $40-bytes headers are 100% safe Cool ... about breaking compatibility by "next version of windows" , that's what all previous versions already did ... so no breaking news pending Laughing , and, finally, this forum is full of complaints about virii in FASM itself or the examples, so even Tomasz is unable to brew a 100% safe executable, and, not sure who is then, if anyone at all Laughing
Post 11 Jul 2008, 12:34
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
revolution wrote:
DOS386 wrote:
Tomasz Grysztar wrote:
The fact that it works doesn't mean it is correct.


Please point me to documentation saying that it's wrong.
Hehe, look up dude, I posted the MZ header format above. What other evidence do you need?


Code:
     USHORT e_csum;          // Checksum 
    


I've not yet seen a MZ executable having a "checksum" different from 0, so either:

- all coincidence
- unique "checksum" algo always returning 0 (but still very useful Idea )
or
- the "MZ header format" posted by you (where did you get it from ?) can't be taken too seriously Laughing
Post 11 Jul 2008, 12:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
Not my fault. After all, ...
yes it is, you are deliberately ignoring the spec.
DOS386 wrote:
... I didn't ask for deleting the code enhancing the header, just adding an option, so your $40-bytes headers are 100% safe Cool ...
I'm not suggesting you are calling for all headers to be changed.
DOS386 wrote:
... about breaking compatibility by "next version of windows" , that's what all previous versions already did ... so no breaking news pending Laughing ...
This is hardly the same thing.
DOS386 wrote:
... , and, finally, this forum is full of complaints about virii in FASM itself or the examples, so even Tomasz is unable to brew a 100% safe executable, and, not sure who is then, if anyone at all Laughing
That is not fair, the fasm codes are 100% safe. Just because some AV companies choose the mark it as bad is no reason to justify your deliberate breaking of the spec for an as yet unproven 10Gib --> 1MiB file reduction.
Post 11 Jul 2008, 12:43
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
- the "MZ header format" posted by you (where did you get it from ?) can't be taken too seriously Laughing
I don't mind being shown to be wrong, but you must prove it. I won't simply accept you saying it is wrong with no supporting evidence.
Post 11 Jul 2008, 12:45
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
revolution wrote:
you are deliberately ignoring the spec


I've not yet seen the spec saying that the MZ header must be at least $40 bytes in size, otherwise the PE header is not guaranteed to be found.

> I don't mind being shown to be wrong

Same for me.

> but you must prove it. I won't simply accept you saying it is wrong with no supporting evidence.

How many executables having the "checksum" set to 0 do you want to see ? What sources / compilers / linkers / developers do you accept at all ?
Post 11 Jul 2008, 12:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
How many executables having the "checksum" set to 0 do you want to see ? What sources / compilers / linkers / developers do you accept at all ?
You are not arguing the proper point. Just because many other apps in the past have broken the checksum (and thus forcing all loaders to ignore it) is not proof that the spec I posted is wrong. The spec is what is supposed to be there, not a reflection of what is happening in the mainstream If you put a proper checksum the the e_csum field then you can be sure it won't break anything.
Post 11 Jul 2008, 13:02
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
revolution wrote:
You are not arguing the proper point. Just because many other apps in the past have broken the checksum (and thus forcing all loaders to ignore it) is not proof that the spec I posted is wrong. The spec is what is supposed to be there


1st, it's a C struct, not a spec, and, 2nd, it shows up what you can store there ... not what is absolutely obligatory ... 3rd, your "spec" doesn't say anything about the valid sizes / minimal size of header (some linkers bloat it even to $0200 bytes instead of just $40), 4th, it doesn't say what to store at $3C if there is no "new" or "next level" executable, thus, FASM's format MZ, creating a $20 bytes header if possible, already does violate your "spec" but storing random garbage at $3C (beyond file size or "negative" possible), and, finally, the "spec" is 24 years old, the original DOS MZ header "spec" got extended by the "new" field when the first NE drafts came up, and nobody bothered to release a precise spec since, and one simply found out that most of the fields are useless garbage, "OEM" is garbage, "checksum" is garbage, all expect "MZ" and stuff at $3C is garbage for PE loaders, and all beyond $20 is garbage for DOS ... as well as nobody ever specified how the MZ file size has to be aligned - linkers align to $0200 bytes, FASM not at all - because nobody ever cared, again Razz
Post 11 Jul 2008, 13:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
That is more like it, now you are arguing the proper point Wink

Yeah, I posted a C structure, but only for clarity, a full spec would be much larger and obviously contain explanations for the fields.

Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there. If you have another good reason for doing it then please show that, I am still curious as to why you want to put code there Confused Specs get updated periodically, some time in the past it was extended to 0x40 bytes to accommodate PE files, so when you make a PE file it would seem a good idea to follow the spec to avoid any possible future nasty bugs that can come back to bite you when you least expect it.

But still you have not shown any evidence to support your two claims: 1) the 10GiB to 1MiB reduction, and 2) that the "spec" I posted is incorrect.
Post 11 Jul 2008, 13:35
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there.

It's not that he is putting code into headers - on the contrary, he has smaller MZ header, and code after it, and PE offset even later (outside the MZ header boundaries!). If he did put code INSIDE the MZ header, fasm wouldn't touch it. fasm only expands the headers that are too small to fit the PE offset correctly in.
Post 11 Jul 2008, 13:48
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
I was thinking of the final PE file that DOS386 is suggesting, it is intended to put code into the extended MZ header.
Post 11 Jul 2008, 13:52
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
FASM's format MZ, creating a $20 bytes header if possible, already does violate your "spec" but storing random garbage at $3C (beyond file size or "negative" possible), and, finally, the "spec" is 24 years old, the original DOS MZ header "spec" got extended by the "new" field when the first NE drafts came up, and nobody bothered to release a precise spec since, and one simply found out that most of the fields are useless garbage, "OEM" is garbage, "checksum" is garbage, all expect "MZ" and stuff at $3C is garbage for PE loaders, and all beyond $20 is garbage for DOS ...

These fields are not "garbage", since MZ header defines its own size (e_cparhdr field in the structure posted by revolution). If some field doesn't fit into our defined size, it's simply undefined - that's a standard procedure with many kinds of headers (PE also).
Post 11 Jul 2008, 13:55
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
revolution wrote:
posted a C structure, but only for clarity, a full spec would be much larger and obviously contain explanations for the fields


But that's exactly what I'd like to see ... specs stating things like "required" ... "optional" ... "must be set to 0 if not used" ... "after this point unused fields can be dropped" ...

Quote:
Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there. If you have another good reason for doing it then please show that, I am still curious as to why you want to put code there


Some people ("tiny-PE"-guru's) mix code + PE header and put it even below $20 ...

Quote:
specs get updated periodically, some time in the past it was extended to 0x40 bytes to accommodate PE files


IIRC wrong ... the $3C field got invented for NE 24 years ago and then just reused for LE/LX and PE ... no updated specs at all Sad

Quote:
still you have not shown any evidence to support your two claims: 1) the 10GiB to 1MiB reduction


Look dude, 10 GiB is very much garbage to even read, so don't expect an optimized (<10GiB) Vista today, sorry for letting you wait Sad

> that the "spec" I posted is incorrect.

It's obvious that:
- It's old
- It's obsolete
- It's lousy (too many thing left open)
- PE header does get found even if the MZ header hogs $20 bytes only

Who can say "it's valid to set the MZ header size to $20 and place the position of PE at $3C" or "it's NOT valid to set the MZ header size to $20 and place the position of PE at $3C, random failure can occur then" ?

Me NOT, it's not my spec Sad It's up to you to prove that the requirement exists, there is no possibility to prove that something doesn't exist ... I just haven't seen it yet, and since "it works" , it should be safe to assume that such a requirement doesn't exist.

Quote:

Immediately after setting the PE flag, the initialization code must flush
the processor's instruction prefetch queue by executing a JMP instruction.
The 80386 fetches and decodes instructions and addresses before they are
used; however, after a change into protected mode, the prefetched
instruction information (which pertains to real-address mode) is no longer
valid. A JMP forces the processor to discard the invalid information.


Who said that the MZ header must be $40 bytes at least ?
Post 11 Jul 2008, 14:04
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
Who can say "it's valid to set the MZ header size to $20 and place the position of PE at $3C" or "it's NOT valid to set the MZ header size to $20 and place the position of PE at $3C, random failure can occur then" ?

Since PE position is part of MZ header, the statement that it's OK to set the MZ header size to 20h, and still place the PE offset field at position 3Ch, simply defies logic. You don't even have to use any kind of docs to see how ridiculous such statement is.
Post 11 Jul 2008, 14:09
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Tomasz Grysztar wrote:
If some field doesn't fit into our defined size, it's simply undefined


It's very doubtful whether the the field at $3C is part of the MZ header ... they just dropped it to some idle area Idea it's irrelevant how big the MZ header and the full MZ EXE are - they could have placed the PE just after the MZ EXE, like DGJPP does with it's COFF, heh NO, they invented the $3C-hack instead allowing the MZ and PE areas to overlap Laughing

> since MZ header defines its own size (e_cparhdr field in the structure

But wrongly ... M$-linker puts $90,$03 there -> $0490 bytes MZ EXE size, while the PE header sits far below this value ... just doesn't break anything Neutral

Anyway, there are 1'000'000 ways how to "fix" this for me (to get my $20 bytes MZ header) ... if this gets / already got rejected Confused

What about the $0200-bug ? Will this get fixed at least ?

> that's a standard procedure with many kinds of headers (PE also)

But nobody cares about code in the PE header, PE header in MZ header, header size > file size, ..., ... Laughing

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 11 Jul 2008, 14:19
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Tomasz Grysztar wrote:
simply defies logic. You don't even have to use any kind of docs to see how ridiculous such statement is


Considering how "correct" the MZ and PE header and EXE handling always used to be Laughing

I'm leaving now (for today, not leaving FASM totally) ... got 33 answers within 3 hours after this topic was dead for 4 months Laughing
Post 11 Jul 2008, 14:27
View user's profile Send private message Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Quote:
I find the dollar ($) character to be very ugly. The 0x format is much clearer IMO. I don't care whether C programmers use it, I also like it and I won't let the I-hate-C brain-washers sway me into using a format that I think is ugly.
Still off-topic, I agree with that also. I do use the -h format with smaller numbers however, but for readability 0x- is still much more clear than a cryptic '$'. It all depends on what you're used to, I guess (did older FASM versions or DOS asmers use '$' ???)
Post 12 Jul 2008, 21:30
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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 © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.