1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

BitBlt

Discussion in 'Win32' started by abraham2119, Aug 31, 2010.

  1. abraham2119

    abraham2119 New Member

    Joined:
    Aug 31, 2010
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    0
    Hello,

    I have a program that loads a DLL into a remote process and hooks the "BitBlt" function. Now the problem's as follows; I'm attempting to get the coordinates of where a certain device context is copied into on the on-screen one, but all my logs of the invocations to the "BitBlt" function show that both, the source and the destination coordinates are the same. It seems as if the targeted application double buffers each device context (which I find quite strange, to be honest), but assumedly, the process should then at some point copy it onto the "absolute" HDC (relative to the window's client area). I've truncated the logs to show only the HDCs I'm interested in (which is identified by a certain width and height):
    Code:
    [BEGIN PAINT]
    
    [ HDC[1140922105] -> HDC[251729776] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[251729776] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[268506992] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[268506992] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[285284208] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[285284208] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[302061424] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[302061424] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[318838640] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[318838640] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[335615856] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[335615856] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[352393072] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[352393072] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[369170288] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    [ HDC[369170288] -> HDC[1140922105] ]src: 0, 0        dest: 0, 0        width: 93, 30 (or 93, 30)
    
    [ HDC[1140922105] -> HDC[-1996417122] ]src: 0, 0        dest: 0, 0        width: 790, 429 (or 790, 429)
    
    [END PAINT] 
    
    As you can see, it's quite strange. The program copies the HDC into another one and then copies it back into it. Then, the last log entry is it copying the assumed off-screen device context to the on-screen one.

    And yes, I'm invalidating the complete window area so a full repaint is necessary.

    I've also checked for calls to "SelectClipRgn", but none are outputted in the selected window (they are however in another window created by the process, but I'm not interested in that one).

    Here is the function import list in alphabetical order:

    I've basically checked any other pixel transfer method used on that list and they aren't the one to copy the HDCs I'm targetting.

    Any ideas would be appreciated.
     

Share This Page