Index
> Windows > Correct Win64 support?Goto page 1, 2 Next |
| Author |
|
|
LocoDelAssembly 10 Dec 2006, 04:29
Melissa, the documentation says
Quote: 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. If you know the number of .pdata section then you can define it. (I don't know if fasm do it already automatically). PS: And wellcome to the board  |
|||
10 Dec 2006, 04:29 |
|
|
LocoDelAssembly 10 Dec 2006, 04:58
For those like me that didn't know the existence of this new section, this one serves for exception handling proposes and replaces the stack based one.
Here an explanation http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx And here http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx the PE spec that shows the structure of this new section |
|||
|
10 Dec 2006, 04:58 |
|
|
Myria 10 Dec 2006, 05:32
In order to generate the .pdata section, you have to output information about every assembly function in your program. You have to describe the layout of your stack frame, including which nonvolatile registers went there. You must also follow a strict set of guidelines regarding function prolog and epilog code.
All this is mandatory, otherwise exception handling breaks. Even functions that don't have an exception handler must have metadata, because a __try block in an outer function may cover an inner function. An executable without such markup on all non-leaf functions is not a valid Win64 executable. |
|||
|
10 Dec 2006, 05:32 |
|
|
r22 10 Dec 2006, 06:08
interesting, I wonder if Vista 64 checks for this and as a result doesn't allow fasm compiled 64bit programs to run on it?
|
|||
|
10 Dec 2006, 06:08 |
|
|
Tomasz Grysztar 10 Dec 2006, 09:24
Well, in context of mentioned "data" directive - it's not the fasm that doesn't generate this section, it's the programmer.
 As this is the mechanism that manages the exception handling, I also guess the skilled assembly programmer should be able to define that structure in a way to bend those mechanisms to his own purposes.
In assembly language code doesn't have to reside in functions, and the functions may be in fact just a programmer's mind constructs. Also "__try" constructs wouldn't make much sense in the assembly... And the idea that stack frame should be only modified by function prologues... that's so incompatible... Do they want to allow only programs written in C-like languages to run? Silly thing. However I've never heard before that executables that don't define exception handling structures are not the valid one. Any reference? Well, apart from assembler itself, fasmw distribution does now also have some standard Win64 headers, including the "proc" macro. vid proposed to build into "proc" macro the support for generating the unwind information. This is a good idea, since if you use "proc" macro, you (in most cases) agree this way to use the default prologue/epilogue, and thus the unwind info can be generated automatically. But that would only be a modification of a macro, not the assembler itself - and this is the only possibly way to automate. |
|||
|
10 Dec 2006, 09:24 |
|
|
MazeGen 10 Dec 2006, 17:57
Myria wrote: An executable without such markup on all non-leaf functions is not a valid Win64 executable. What do you mean by "not a valid executable"? I doesn't work for you? I can run such an executable without any problems under winxp x64 and it works well. Only when an exception occurs, the application is silently killed with no warnings or messages. |
|||
|
10 Dec 2006, 17:57 |
|
|
LocoDelAssembly 10 Dec 2006, 21:05
Quote: Only when an exception occurs, the application is silently killed with no warnings or messages. I checked it with a "mov [0], rax" and no warning appeared as you say, THAT'S TERRIBLE!! Maybe fasm should add the .pdata section initializing it with some defaults values that guaranties that the exception will be handled by Windows (like in Win32 apps when you don't destroy [FS:0]) |
|||
|
10 Dec 2006, 21:05 |
|
|
vid 10 Dec 2006, 23:29
why should it do it? It should do it only when you want FASM to do it
|
|||
|
10 Dec 2006, 23:29 |
|
|
Myria 11 Dec 2006, 02:33
What's needed is commands in fasm (or any other assembler) to tell it what it needs to know in order to build the .pdata section. It's still manual but at least the programmer isn't having to calculate the raw table data themselves.
|
|||
|
11 Dec 2006, 02:33 |
|
|
LocoDelAssembly 11 Dec 2006, 03:23
vid wrote: why should it do it? It should do it only when you want FASM to do it Because if Myria is right then it's mandatory and fasm should add some default info when you don't specify custom data. Or fasm should stop including a default stub telling "This program cannot run in DOS mode." because you didn't specified a stub? You see, fasm already adds default things, so why it should be different? |
|||
|
11 Dec 2006, 03:23 |
|
|
Myria 11 Dec 2006, 06:04
The only way I can think of to have a default is to call AddVectoredExceptionHandler or RtlInstallFunctionTableCallback at the entry point of the program to put in a default handler.
|
|||
|
11 Dec 2006, 06:04 |
|
|
vid 11 Dec 2006, 11:36
Loco: stub is formatting thing. Having extra section is different. What would you do if you don't want any pdata info for some reason?
|
|||
|
11 Dec 2006, 11:36 |
|
|
MazeGen 11 Dec 2006, 12:12
LocoDelAssembly wrote:
Yeah, I really don't know why windows couldn't pop up a simple message box 
I'm curious whether vista x64 works same - weird - way in this case. |
|||
|
11 Dec 2006, 12:12 |
|
|
LocoDelAssembly 11 Dec 2006, 15:25
Quote:
Maybe the same reason as when you overwrite [FS:0] with garbage on Win32 apps. vid, well I don't have a more strong argument right now  So for now I only suggest that the ".end" macro of the not done yet WIN64AX.INC/WIN64AXP.INC add a default .pdata section using the entry point as the unique function (only if this is really mandatory and/or helps to show the message box provided by Windows when an unhandled exception ocurrs).
BTW, how can I add such section with current fasm? |
|||
|
11 Dec 2006, 15:25 |
|
|
vid 11 Dec 2006, 16:31
loco: since "proc" macros doesn't supported that, you have to do manually. I tried to make tomasz write such macros, but it seems he is as lazy about this as me
one of arguments was that FASM would be first assembler to have this done properly. something like: Code: proc excpt name arg1, arg2 to build unwind info I agree about .end |
|||
|
11 Dec 2006, 16:31 |
|
|
LocoDelAssembly 12 Dec 2006, 00:37
MazeGen, I have news, I got a warning message now.
Here templete example modified to produce the run-time error dialog Code: section '.code' code readable executable start: mov [0], rax sub rsp,8*6 ; reserve stack for API use and make stack dqword aligned And here the one that silently dies Code: section '.code' code readable executable start: sub rsp,8*6 ; reserve stack for API use and make stack dqword aligned mov [0], rax Code: ; #define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // Exception Directory section '.pdata' data readable data 3 dd rva start dd rva start dd 0 ; while I don't know how to produce this unwind info I use NULL (which probably is wrong and I must study this more of couse) end data But not success... Just I hope that one good defined entry it is enough [edit] Tryed using dq instead of dd and removing rva. My last attempt: Code: ; #define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // Exception Directory section '.pdata' data readable data 3 dq start dq endOfCode dq start end data |
|||
|
12 Dec 2006, 00:37 |
|
|
Myria 17 Dec 2006, 21:00
It terminates without warning because it believes that it just detected an exploit. Messing with exception handlers is a classic trick for exploiting bugs in Windows programs. It can't display a dialog box, because there is a risk that doing so will end up executing shellcode.
|
|||
|
17 Dec 2006, 21:00 |
|
|
MazeGen 18 Dec 2006, 08:13
LocoDelAssembly, interesting, thanks.
|
|||
|
18 Dec 2006, 08:13 |
|
|
LocoDelAssembly 23 Aug 2009, 22:29
Since there was some proc64 development recently I must bump this thread.
Any plans to support this? Is it still an issue or now Windows drops some error dialog? |
|||
|
23 Aug 2009, 22:29 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|