flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > [DONE] Align import binding addresses in IMPORT??.INC

Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17474
Location: In your JS exploiting you and your system
revolution
Both the IMPORT32.INC and IMPORT64.INC files currently do not try to align binding call addresses. The best alignment guaranteed is to even addresses.

This can be fixed by inserting align at around line 26:
Code:
macro import name,[label,string]
 { common
    if defined name#.referred
          align 4 ;<<<----- use '4' for 32-bit and '8' for 64-bit
     name#.lookup:
   forward
;...    


Last edited by revolution on 12 Sep 2010, 18:10; edited 1 time in total
Post 31 Jul 2010, 04:13
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
http://board.flatassembler.net/topic.php?p=107831#107831

I don't have the tools at hand not a 64-bit setup so, was the bug mentioned there fixed?
Post 31 Jul 2010, 06:22
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17474
Location: In your JS exploiting you and your system
revolution
LocoDelAssembly wrote:
I don't have the tools at hand not a 64-bit setup so, was the bug mentioned there fixed?
If you are asking about the alignment penalty, then, no, it appears to be still the same. Neither IMPORT??.INC file contains any alignment directives.
Post 31 Jul 2010, 06:42
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
The PROCs without locals nor params problem which leave RSP unaligned on entry. A quick look to PROC64.INC tells me that "PUSH RBP" is avoided on such situation which could potentially keep RSP MOD 16 = 8, but maybe something else compensates that (but I can't test here).
Post 31 Jul 2010, 06:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17474
Location: In your JS exploiting you and your system
revolution
If one is concerned about "polluting" the data area with extraneous nops then we can use this instead:
Code:
times (-rva $) and 3 db 0 ;<<<----- use '3' for 32-bit and '7' for 64-bit    
Post 31 Jul 2010, 08:36
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: 17474
Location: In your JS exploiting you and your system
revolution
BUMP
Post 12 Sep 2010, 09:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
There is this wider problem with import macros - they are left almost unchanged since the very early fasm versions for Win32. Well, that may also speak in their favor, as they had to be not so bad at all if they managed to be useful through all this time - however initially I thought that some better variants would appear when some knowledgeable user realizes he needs more that this simplest solution. For instance, one could put the import addresses table into some other section (marking the table with "data 12") and mark the import section as "discardable" then. Also, in another variant, one might create "jump gates" for imported functions to make the call instructions shorter (but then you'd have to use "stdcall" instead of "invoke" to call them). And with the new abilities of fasm's preprocessor this certainly could be done at a small cost.
On the other hand, I'm afraid that even the new project of Windows headers maintained by community would be reluctant to change the usage of import macros, as they became de facto standard for fasm during all those years...
Post 12 Sep 2010, 12:49
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: 17474
Location: In your JS exploiting you and your system
revolution
Does your response above mean that you are not keen to change them? My suggestion won't break any existing code.

I found in the past that messing with import tables and moving them around among sections has a tendency to trigger the paranoid AVs. In general. the tiny gain one might get with using various data sections is more than offset by the loss of triggering AVs and panicking users.

[edit] BTW: There have been a number of import macro suggestions placed in this board. They never catch on though because whenever someone posts code here they have to use the "official" macros else no one else can assemble the code.
Post 12 Sep 2010, 12:56
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Does your response above mean that you are not keen to change them? My suggestion won't break any existing code.

No, it is not about that. I just hoped to trigger some discussion about those macros and possible improvements. As for alignment, I can of course do it without breaking anything, but this does not solve the wider problems the import macros have, in my opinion.

revolution wrote:
I found in the past that messing with import tables and moving them around among sections has a tendency to trigger the paranoid AVs. In general. the tiny gain one might get with using various data sections is more than offset by the loss of triggering AVs and panicking users.
Sometimes the effect may be the opposite. Since there exists some malware that was created with fasm, some AVs were looking for the "footprints" of standard fasm's way of creating programs. Changing them to some non-standard (in fasm's context) then helped to avoid the false alarm.


Last edited by Tomasz Grysztar on 12 Sep 2010, 13:13; edited 1 time in total
Post 12 Sep 2010, 13:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7755
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
[edit] BTW: There have been a number of import macro suggestions placed in this board. They never catch on though because whenever someone posts code here they have to use the "official" macros else no one else can assemble the code.
And that's what I'm talking about - even changing the official ones would now cause problems, because everyone is already used to assume those macros are there as if they were part of fasm's language. Well, in some sense they are.
On the other hand, I've seen sometimes programs distributed with a set of includes full of someone's own macro inventions for even the basic things - so that sometimes still happens.
Post 12 Sep 2010, 13:05
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:  


< 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.