/ALIGN:8 does not work on x64 Windows7

[Devils Child]

Hey,

i'm trying to achieve smaller executable sizes using /ALIGN:8
but all i get is an application error (0xc0000018), when the executable is run.
this example runs fine under Windows 7 x86, but not under 64 bit windows 7

you'd say i have to use at lease 512 align, but i've seen handcrafted PE stubs with no align at all, yet working.
so how do i manage this? do i have to write the PE header myself, or is there any other option to remove the align?

any ideas?


code:

Code Select Expand

.386
.model flat, stdcall
option casemap :none

include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

.code
start:
invoke ExitProcess, 0
end start

compiled with that commandline:

Code Select Expand

\masm32\bin\ml /c /coff /nologo test.asm
\masm32\bin\Link /SUBSYSTEM:WINDOWS /MERGE:.rdata=.text /ALIGN:8 test.obj > nul


any ideas?

[hutch--]

You can do it but its not a valid PE executable, stick to the 512 byte alignment and its safe. hand crafted stubs can get smaller but they are not actually executing as programs. For the little it worthy you can write a 2 byte COM file. INT 19h.

[Antariy]

Hey,

i'm trying to achieve smaller executable sizes using /ALIGN:8
...
compiled with that commandline:

Code Select Expand

\masm32\bin\ml /c /coff /nologo test.asm
\masm32\bin\Link /SUBSYSTEM:WINDOWS /MERGE:.rdata=.text /ALIGN:8 test.obj > nul


any ideas?

Try to specify /FIXED:NO and/or /FILEALIGN:8 switch to the linker.
I.e.:

Code Select Expand


\masm32\bin\Link /SUBSYSTEM:WINDOWS /MERGE:.rdata=.text /ALIGN:8 /FIXED:NO /FILEALIGN:8 test.obj > nul


/FILEALIGN will not work with old linkers, only with new (like from MSVC8/10 installation).

Try to specify 16  or 32 or 64 alignments.

[Devils Child]

@Antariy: this produces the same error. even for higher align/filealign such as 64 bytes...

i also tried using the visual c++ 2010 linker like this:

Code Select Expand

"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link"  /MERGE:.rdata=.text /ALIGN:8 /FIXED:NO /FILEALIGN:8 test.obj

but it sais that mspdb100.dll could not be found. should i use the vc++ linker? should i use any other linker than the masm32 linker? if so, which, and if not, how do i use the current linker correctly?

thanks.

[Antariy]

@Antariy: this produces the same error. even for higher align/filealign such as 64 bytes...

i also tried using the visual c++ 2010 linker like this:

Code Select Expand

"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link"  /MERGE:.rdata=.text /ALIGN:8 /FIXED:NO /FILEALIGN:8 test.obj

but it sais that mspdb100.dll could not be found. should i use the vc++ linker? should i use any other linker than the masm32 linker? if so, which, and if not, how do i use the current linker correctly?

thanks.

This maybe some security issue - x64 Windows disallows many things which 32 bit Windows NT allows.
Actually I have no way to test all of this - not on x64 Windows.

The strange thing is: it looks like loader cannot resolve mapping of the image:

Exception C0000018H have description:

{Conflicting Address Range}
The specified address range conflicts with the address space.

Used this tool: http://www.masm32.com/board/index.php?action=dlattach;topic=14448.0;id=7828 to get description. NTSTATUS code mode.

[Devils Child]

yes, i get the same error using this tool.

here is my asm file and my binary: http://xload.dev-ch.de/bc54dc6662f34912/test-masm-smallfile.zip
it should work with win32.

could get detected as xcrypt by avira antivir, tho it's nothing more then one function call to ExitProcess.

anything else which could solve the problem?

[BogdanOntanu]

One problem with using non standard PE layouts is that AV heuristics will automatically flag your executable as suspicious and/or even as malware no matter if it does or does not perform bad actions.

Normal applications are done in C/C++ or higher (C#, Java) those days. ASM is rare and IF used then one must try to be as "standard" as possible. Any attempt to play "smart" tricks will flag you.

And NO there is nothing you can do about this because it is an efficiency/political  decision of AV's managers. That is because 99% of in the wild tricky PE files are malware and it is very easy to single them out exactly because they try to play "smart" :D :D :D

In order to "solve" this problem play nice and do not try to use smaller alignment and overlapping structures and tricks on the PE layout (even if they are somehow "valid" by the "standards") ANy trick you use rises a flag... too many flags is bad :D

Doing an application in ASM is already a flag, small is another flag, no real code inside (just ExitProcess) is another flag... using non standard PE layout is a terminal flag :D :D :D

Even my own assembler written in ASM is sometimes flanged by the AV company where I work ... hence you get the idea

[Devils Child]

the av thing is not my point. it is only detected if smaller than 700 bytes, and only by avira antivir.

i'm still looking for a way to change the align.

[donkey]

One problem with using non standard PE layouts is that AV heuristics will automatically flag your executable as suspicious and/or even as malware no matter if it does or does not perform bad actions.

Normal applications are done in C/C++ or higher (C#, Java) those days. ASM is rare and IF used then one must try to be as "standard" as possible. Any attempt to play "smart" tricks will flag you.

And NO there is nothing you can do about this because it is an efficiency/political  decision of AV's managers. That is because 99% of in the wild tricky PE files are malware and it is very easy to single them out exactly because they try to play "smart" :D :D :D

In order to "solve" this problem play nice and do not try to use smaller alignment and overlapping structures and tricks on the PE layout (even if they are somehow "valid" by the "standards") ANy trick you use rises a flag... too many flags is bad :D

Doing an application in ASM is already a flag, small is another flag, no real code inside (just ExitProcess) is another flag... using non standard PE layout is a terminal flag :D :D :D

Even my own assembler written in ASM is sometimes flanged by the AV company where I work ... hence you get the idea

Do I ever agree with you here Bogdan, for years now I have seen attempt after attempt to knock off 2 or 3 hundred bytes in a machine that routinely carries at least 2 Gig of memory only to have the apps fail from Windows version to Windows version or trigger every AV scanner on the planet. It is a useless waste of time and effort that could be spent building better applications, today smaller is rarely better and at times its a lot worse. I'm not in favor of bloat ware but a couple of hundred bytes is not worth the effort. I remember when XP was released and so many asm apps failed, saving pushing one or two registers or invalid PE formats resulted in many more hours of coding than the microsecond or two that they saved in total execution time.

Edgar

[hutch--]

I still laugh at this stuff, for years a few folks have been trying to re-invent the 32 bit PE specifications to no avail, Microsoft publish these specs and write their operating system executable loaders according to the specs so when you differ from the PE specifications you get predictably bad results. It is a serious mistake to tweak something to fit one OS version only to wonder why it does not work on another. We have all seen it before, the changes from win9x ANSI APIs to UNICODE WinNT, 2000, XP and later broke a lot of code that was written that way.

There is nothing wrong with Win7 64 bit, it loads correct specification 32 bit PE files with no problems, its EXACTLY the reason why you don't write non-standard PE files that make it crash on Win7 64 bit.

[Antariy]

the av thing is not my point. it is only detected if smaller than 700 bytes, and only by avira antivir.

i'm still looking for a way to change the align.

I guess it is security issue. Windows NT (at least 32 bit) actually supports anything sane file/memory alignment - it is part of loader's ideology. Drivers itself are standard PE files, though all of them (of aware devs) uses small alignment ~16 bytes. Maybe for non-native mode images MS make it is refused in x64 systems to use small alignments.

[Antariy]

Smaller alignment is a *correct* file format for Windows NT. x64 systems refuse this for security reasons, for sure.
As well as many other changes in the format is a still *correct* format. PE spec is very flexible, this is reason that it changed so small with a PE+ spec.

As about uncorrect formats... PB/Win 7 produces wrong format of sections headers - sections are overlapped. Though, this is not maked something wrong just by ideology of the loader.

There is example of the two overlapped sections in a program produced by PB/Win 7. It is exactly the bug, since sometimes sections are properly managed. But most of times they are overlapped.

Code Select Expand


02  .data    Virtual Address         00006000
Virtual Size            00000580
Raw Data Offset         00004600   <---
Raw Data Size           00000400   <--- 4600 + 400 = next section should start at 4A00 ...
Relocation Offset       00000000
Relocation Count        0000
Line Number Offset      00000000
Line Number Count       0000
Characteristics         C0000040
Initialized Data
Readable
Writeable

03  .link    Virtual Address         00007000
Virtual Size            00000A64
Raw Data Offset         00004800 <--- ... but it starts at 4800 instead - overlapped sections
Raw Data Size           00000C00
Relocation Offset       00000000
Relocation Count        0000
Line Number Offset      00000000
Line Number Count       0000
Characteristics         C0000040
Initialized Data
Readable
Writeable


Overlapped sections is a wrong file format. Though, where is the complainings?.. :bg

[Antariy]

Overlapped sections is a wrong file format. Though, where is the complainings?.. :bg

To not be unfounded, there is example - sources ((C) - Hutch) and exe compiled with PB/Win 7.
Files attached in the archive.

Sections data overlapping in the headers:

Code Select Expand


02  .data    Virtual Address         00003000
Virtual Size            0000053C
Raw Data Offset         00002200 <--- 2200 + ...
Raw Data Size           00000400  <--- ... + 400 = ...
Relocation Offset       00000000
Relocation Count        0000
Line Number Offset      00000000
Line Number Count       0000
Characteristics         C0000040
Initialized Data
Readable
Writeable

03  .link    Virtual Address         00004000
Virtual Size            0000046A
Raw Data Offset         00002400 <--- ... = 2400 :D
Raw Data Size           00000600
Relocation Offset       00000000
Relocation Count        0000
Line Number Offset      00000000
Line Number Count       0000
Characteristics         C0000040
Initialized Data
Readable
Writeable



PB/Win 9 have no this issue (as far as tested code compiled is not have it).

[Antariy]

I remember when XP was released and so many asm apps failed, saving pushing one or two registers or invalid PE formats resulted in many more hours of coding than the microsecond or two that they saved in total execution time.

That's perfectly right, of course. Though for small "funny stuff" projects it is worth for efforts.

Besides of all, on NT failed very many apps written on HLL for 9x - BTW many parts of it is the insane alignment. Simple example - game Machines (Acclaim) - sections alignment 64 KB :bg
Though, it is still working on todays machines, only required a small fix.

[hutch--]

 :bg

An "executable" that will run on Win(this) but won't run on Win(that) is USELESS. Thats why you write executable files that conform to the manufacturers specification in terms of MZ and PE headers. Do it the wrong way and you end up with USELESS code.  :P