flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > safe invoke macro

Author
Thread Post new topic Reply to topic
skykrnl



Joined: 17 Nov 2008
Posts: 21
skykrnl
Code:
macro ccall proc,[arg]
{
common
       local   ..next
      push    edi
 mov     edi, esp
    ccall   proc,arg
    cmp     edi, esp
    jz      ..next
      int3
..next:
 pop     edi
}

macro stdcall proc, [arg]
{
common
  local   ..next
      push    edi
 mov     edi, esp
    stdcall proc,arg
    cmp     edi, esp
    jz      ..next
      int3
..next:
 pop     edi
}

macro cinvoke proc,[arg]
{
common
   ccall   [proc], arg
}

macro invoke proc, [arg]
{
common
   stdcall [proc], arg
}
    
Post 28 Nov 2008, 12:17
View user's profile Send private message Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1607
Location: Ukraine
shoorick
it would be not bad to make this safe int3 inserting conditional, depending on presence of DEBUG_VERSION or so
Post 28 Nov 2008, 12:24
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: 17458
Location: In your JS exploiting you and your system
revolution
shoorick wrote:
it would be not bad to make this safe int3 inserting conditional, depending on presence of DEBUG_VERSION or so
Since macros can be nested then one could simply use a conditional to include these macros.
Code:
match any,DEBUG_ME {include 'my_safe_calls.inc'}    
Post 28 Nov 2008, 13:10
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
shoorick,

What's the point of having extra wrapper for every function call without added functionality?

skykrnl,

If function returns, it's too late to check for stack balance (it supposedly ret using address put on stack with call, at least for common case). Test for ccall macro correctly adjusting esp? Wink
Post 28 Nov 2008, 15:00
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

If function returns, it's too late to check for stack balance (it supposedly ret using address put on stack with call, at least for common case)

Why? It will return successfully even if the retn operand didn't match with the total size of the arguments.*

About ccall yeah, it is wrong, the only case in which int3 will not be executed is when the proc is parameterless...

*I'm assuming here that stack imbalance is the only violation expected, EDI preservation is assumed.

[edit]I'm wrong about ccall, I forgot that it adjusts the stack automatically after return Embarassed[/edit]


Last edited by LocoDelAssembly on 28 Nov 2008, 17:30; edited 1 time in total
Post 28 Nov 2008, 16:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17458
Location: In your JS exploiting you and your system
revolution
LocoDelAssembly wrote:
*I'm assuming here that stack imbalance is the only violation expected, EDI preservation is assumed.
How about:
Code:
macro ccall proc,[arg]
{
common
        local   ..next,..ohshit
        push    edi esi ebx ebp
        mov     edi, esp
        mov     esi, esp
        mov     ebx, esp
        mov     ebp, esp
        not     ebx
        not     ebp
        ccall   proc,arg
        not     ebx
        not     ebp
        cmp     edi, esp
        jnz     ..ohshit
        cmp     esi, esp
        jnz     ..ohshit
        cmp     ebx, esp
        jnz     ..ohshit
        cmp     ebp, esp
        jz      ..next
..ohshit:
        int3
..next:
        pop     ebp ebx esi edi
}    
Post 28 Nov 2008, 16:46
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
If you can't even assume that it will at least respect register preservation then I think that using a global variable to store ESP would be better. Razz

I suppose that the intent of these macros is to guard the code against a calling convention mismatch, not a half stack protection as I had in mind in my first post (thinking of it in that way makes sense to the way in which the macros are implemented).
Post 28 Nov 2008, 17:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17458
Location: In your JS exploiting you and your system
revolution
LocoDelAssembly wrote:
If you can't even assume that it will at least respect register preservation then I think that using a global variable to store ESP would be better. Razz
Globals are a killer for multi-threading. Just say no to globals.
Post 29 Nov 2008, 01:35
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
Quote:

Globals are a killer for multi-threading. Just say no to globals.

Use access synchronization then (or use TLS).
Post 29 Nov 2008, 02:03
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
LocoDelAssembly,

Access syncronization? I.e. block thread 1 in ccall/stdcall func1 each time ccall/stdcall func1 successfully acquired sync. object in thread 2 (I assume per-function synchronization object), which then was preempted before sync. object was released? TLS seems much better.
Post 29 Nov 2008, 07:20
View user's profile Send private message 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.