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:
.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:
\masm32\bin\ml /c /coff /nologo test.asm
\masm32\bin\Link /SUBSYSTEM:WINDOWS /MERGE:.rdata=.text /ALIGN:8 test.obj > nul
any ideas?
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.
Quote from: Devils Child on February 12, 2011, 11:42:20 AM
Hey,
i'm trying to achieve smaller executable sizes using /ALIGN:8
...
compiled with that commandline:
\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.:
\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.
@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:"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.
Quote from: Devils Child on February 12, 2011, 02:01:36 PM
@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:"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:
Quote
{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.
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?
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
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.
Quote from: BogdanOntanu on February 12, 2011, 04:49:43 PM
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
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.
Quote from: Devils Child on February 12, 2011, 05:15:44 PM
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.
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.
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
Quote from: Antariy on February 13, 2011, 03:17:43 AM
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:
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).
Quote from: donkey on February 12, 2011, 09:13:02 PM
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.
: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
You guys are right. I should be more hapyy seeing it working on all OS, insead of being smaller.
i guess 1kb will be good.
thanks guys :) this really seems to be a nice community!
Did you try Pelle's linker Polink?
\masm32\bin\polink.exe
Erol - which polink switches may be used to make a smaller EXE ?
(other than merging sections)
i prefer a smaller file, but i don't want to upset AV programs, either - lol
Quote from: hutch-- on February 13, 2011, 04:21:15 AM
: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
Very good and useful program compiled with compiler producing wrong file format (http://www.masm32.com/board/index.php?topic=16077.msg132868#msg132868) is
USELESS :bg
PB9 is OK, though.
Hi Dave,
Polink and link share the same command-line options. It always worth to try Polink in my opinion.
POLINK works fine and is always very up to date specification wise.
Quote from: dedndave on February 13, 2011, 02:51:27 PM
i prefer a smaller file, but i don't want to upset AV programs, either - lol
EDIT: post pointed was successfully removed by adherers of other linkers :green2
So, Dave, now only you and some other peoples know what was said in it :lol
No,
patching other people's binaries is against the rules of the forum. Then we get QUACKERS, inverse engineering and other cockroaches who want to add to this stuff.