flat assembler
Message board for the users of flat assembler.

Index > Examples and Tutorials > 64 bit ScanMap

Author
Thread Post new topic Reply to topic
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
I've implemented the 64 bit version of this snipped and I'll probably stick with it, if for no other reason it make code more manageable. At least the way I'm doing it anyway.

Once I'm sure it functions as expected, especially for procedures that need post default processing, I'll document code a lot better.
Code:
  ScanMap:      push     r9                     ; lParam
                push     r8                     ; wParam
                push    rdx                     ; Msg
                push    rcx                     ; hWnd

                push    rsi
                mov     rsi, rax                ; Pointer to windows message map

                lodsd
                push    rbx
                mov     rbx, rax                ; Pointer to windows default procedure
                lodsd
                mov     rcx, rax                ; Number of messages in map

           @@:  lodsd                           ; Get application defined message number
                cmp     edx, eax
                lodsd                           ; Pointer to application defined handler
                jz     .Handle
                loopnz  @B

           @@:  or      rbx, rbx
                pop     rbx
                pop     rsi
                jnz    .Subed

                pop     rcx
                pop     rdx
                pop      r8
                pop      r9
                jmp     [ DefWindowProc ]

       .Subed:  mov     rcx, rbx
                pop     rbx                     ; lpPrevWndFunc
                pop     rsi
                pop     rdx                     ; hWnd
                pop      r8                     ; Msg
                pop      r9                     ; wParam
                pop     rax
                sub     rsp, 48
                mov     [ rsp + 32 ], rax      ; wParam
                jmp     [ CallWindowProc ]

      .Handle:  call    rax
                jc      @B                      ; Do default processing if specified

                add     rsp, 48                 ; Waste everything on stack
                xor     rax, rax
                ret
    

As I haven't created any sub or super classed windows, that part of the app hasn't been tested yet. Although not extensively for the rest, but short sessions of program hasn't crashed it yet.


Description:
Download
Filename: PEView.ASM
Filesize: 6.38 KB
Downloaded: 199 Time(s)

Post 29 Jun 2013, 19:40
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: 16904
Location: In your JS exploiting you and your system
revolution
I would expect you need to use lodsq so that RAX is giving a true 64-bit address?

BTW: This example is incomplete. Can you please post a fully working test app to show it working.
Post 29 Jun 2013, 20:59
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2800
Location: dank orb
bitRAKE
The example ran well on Win7. Sometimes in sub-/super- classing it's beneficial to execute the default handler first, and then work with that result.
Post 29 Jun 2013, 21:21
View user's profile Send private message Visit poster's website Reply with quote
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
revolution wrote:
BTW: This example is incomplete. Can you please post a fully working test app to show it working.
Did the attached ASM file not work for you? If so, please tell what architecture specifics your using as it has worked for bitRake and it's being developed probably on a similar machine. Windows 7 Home Premium (Service Pak 1).

In the next day or so, I'll have an example of a subclassed EDIT control, which will be in part a way of testing the beginning of my library routines called I2A & A2I. This will be multifunctional INTEGER to ASCIIZ and vis versa respectively.
Post 30 Jun 2013, 03:11
View user's profile Send private message Visit poster's website Reply with quote
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
bitRake wrote:
Sometimes in sub-/super- classing it's beneficial to execute the default handler first, and then work with that result.
I do remember seeing some examples of this in WIN32 API BIBLE and will make a call to kernel handler at the beginning of my app defined handler. Can't remember exactly right now which messages required this.
Post 30 Jun 2013, 03:14
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 688
Location: Adelaide
sinsi
You should be using full 64-bit addresses, what happens if the exe is loaded higher than the 4GB limit?
Post 30 Jun 2013, 03:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16904
Location: In your JS exploiting you and your system
revolution
TightCoderEx wrote:
Did the attached ASM file not work for you?
I downloaded again and is now complete. I must have had a broken download earlier. Sorry for the false alarm. But you still need to allow for 64-bit addresses in V2.
Post 30 Jun 2013, 03:53
View user's profile Send private message Visit poster's website Reply with quote
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
revolution wrote:
But you still need to allow for 64-bit addresses in V2.

In my 32 bit version I've even used 16 bit loads, which definitely would pose a problem with sub/super classed windows. In Win7, so far DLL entry points are within the 32 bit boundary, so I think I'm safe with what I'm doing.

sinsi wrote:
what happens if the exe is loaded higher than the 4GB limit
In Ubuntu 13.04 this app would crash and burn, specifically because stack is mapped into highest part of virtual memory, above 4G boundary.

Am I correct in assuming that as long as no one changes PE data, sections will start @ 40000H on 4k boundaries and top of stack will be @ 70000H? Did M$ do this to eliminate a lot of REX qualifiers and would have made porting XP to 64 bit a lot less work.

Please understand, any responses I give that seem to be dismissal are not intended to be so, it's just I don't take Win32 or 64 very seriously. It is only because I've had to replace my Linux box with one that only has EUFI. My ultimate goad is to create a library of routines that will be conducive to my OS and to that end all of these bits of information become criteria by which I base my kernel and subsequent abstract layers to my system.

Thanks gentlemen for you input, it does help in my ultimate design criteria, even though it won't be for Windows or Linux, but I do need to use something in initial development. With any luck I'll be able to use FASM in my OS.
Post 30 Jun 2013, 05:00
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: 16904
Location: In your JS exploiting you and your system
revolution
TightCoderEx wrote:
In Win7, so far DLL entry points are within the 32 bit boundary, so I think I'm safe with what I'm doing.
But such behaviour is not guaranteed by the Win64 design. Sure, it works today, but what about tomorrow when MS send everyone a new update with a rewritten loader? Or what about Win8, or whatever the next version will be called, it might break there because of different characteristics.

Since you already acknowledged that this is not for optimisation (which is fine) then I can't see the advantage of writing code that is known to be against the spec. It only takes a moments to fix and get it right for all future applications. But having known mis-performing code and hoping for the best in the future seems to me like a bomb waiting to go off.
Post 30 Jun 2013, 06:03
View user's profile Send private message Visit poster's website Reply with quote
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
revolution wrote:
But such behaviour is not guaranteed by the Win64 design. Sure, it works today, but what about tomorrow when MS send everyone a new update with a rewritten loader? Or what about Win8, or whatever the next version will be called, it might break there because of different characteristics.

Since you already acknowledged that this is not for optimisation (which is fine) then I can't see the advantage of writing code that is known to be against the spec. It only takes a moments to fix and get it right for all future applications. But having known mis-performing code and hoping for the best in the future seems to me like a bomb waiting to go off.

Agreed and even though I don't plan on doing anything serious at this point in time for W7 or 8, but if it does happen why complicate the matter by having fragments of broken code.
Post 30 Jun 2013, 13:26
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-2019, Tomasz Grysztar.

Powered by rwasa.