Thread: VirtualProtectEx fails

  1. #1
    Registered User
    Join Date
    Jun 2011
    Posts
    30

    VirtualProtectEx fails

    Hi,

    I have a question but I already asked it on msdn. Though I find this forum better at answering and since I'm new I didn't know there was a windows session here too. Now that I found it, would it be okay to cross-post?

    I understand it is foolish to ask a question about the question, but I don't want to upset someone or break any rules.

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    You could post a link to the other thread.

  3. #3

  4. #4
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    Well, any ideas? I re-write the troubling functions just to make it easier for aiders to read the code fast/easy

  5. #5
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    So far I'm agreeing with your other poster -- 10000 = not your memory. Plus error 487 = invalid address.

    I've not had much luck trying some other DLLs I had lying around -- they all give 10000. And I'm not sure how Windows handles putting DLL functions into process' memory space, if at all.

  6. #6
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    But how come I get an address when asking for it? Shouldn't I get only zeroes then? I wrote another test class which just had a function called "sum" besides "main". Then I tried to get the address of that function but I just received zeroes. This confuses me very much. When it comes to memory handling and soft/memory breakpoints nothing works. When I try to google it however it seems other people done like me. And PyDBG is designed similar importing the same functions to Python.

    I am grateful for any suggestions on how to take proper control of a process, get access to change it's memory, manipulate it etc.

    At the moment, only hardware breakpoints work for me :/

  7. #7
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    To take the second question first, I had troubles getting the address of a function that I didn't use. This may be an artifact of how MinGW links things (or the way I am making MinGW link things), or more likely the difference between GetModuleHandle and LoadLibrary -- using LoadLibrary instead I could get the address of any function I wanted regardless of whether or not I actually used it. I still get the 10000/487 situation though.

    This may be something to do with the separation between code and data (i.e. function pointers don't have to be the same, or look the same, as "normal" pointers), but I haven't quite found actual information on how function pointers & DLLs work on Windows.

  8. #8
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    LoadLibrary: I get the exact same results as before. another strange thing is that you get 487 while I get 998. Which constant are you using as mbi.Protect?

    One more thing, if you look at my post on msdn, you can see following, which is my MEMORY_BASIC_INFORMATIO structure:

    BaseAddress = 75f6c000
    AllocationBase = 0
    AllocationProtect = 0
    RegionSize = 11e4000
    State = 10000 // MEM_FREE
    Protect = 1 // PAGE_NOACCESS
    Type = 0
    How come the "RegionSize" is so huge?

  9. #9
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    What am I using for mbi.Protect? I have no idea. Whatever was in your code .... I'm getting (for using a different function out of a DLL):
    BaseAddress = 61b41000
    AllocationBase = 0
    AllocationProtect = 0
    RegionSize = 1606f000
    State = 10000
    Protect = 1
    Type = 0

    Even changing the access type in VirtualProtectEx, I still get 487.

    If you read the docs on MSDN, you'll see that a "region" is just all the consecutive memory pages that have the same settings, so the region is going until a non-free page.

  10. #10
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    Very strange indeed...

    I was thinking you might have another value for Protect since you got another error code.

    Ah, thanks, that explains the size of the region. Well, I read MSDN docs once again on memory management but so far I can't find anything there that I've missed or that show it should be different. Thinking how it would be if you allocated memory for the child-process, the one that the debugger runs the debugee in. Could that work?

  11. #11
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    639
    Code:
    PDWORD old_protection; // this is a pointer
    if (!VirtualProtectEx(hProcess, currentpage, size, PAGE_NOACCESS, old_protection)) {
    And the pointer is pointing to...?

    You can't set breakpoints that way. Dlls can load at different addresses in different processes. The address of printf in your debugger program is just that. It's not a universal value valid for every program. It might be, but then again, you might be able to write to a piece of memory after you free it, doesn't mean you always will.

    There isn't a GetProcAddressEx function. To get the address in a remote process, you need the offset of the function in the dll* and the base address of the dll in the target process, add the two together and there you go. Or you can use the Sym* api's which wrap this and other things up for you. Or the IDebugClient and related interfaces which pretty much give you access to everything a debugger needs, including breakpoints.

    * you can use GetProcAddress and GetModuleHandle and subtract the difference for this value
    Last edited by adeyblue; 08-24-2011 at 08:04 PM.

  12. #12
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    The pointer will receive the old protection constant as I understand it, here is what the docs say:

    A pointer to a variable that receives the previous access protection of the first page in the specified region of pages. If this parameter is NULL or does not point to a valid variable, the function fails.
    Hmm, you seem to be on to something here. Just to clear things out:

    1. GetProcAddress - GetModuleHandle = the offset of the function in the dll?

    2. How would I get the base address of the dll in the target function?

    3. What does Sym* mean? Which API / Functions can I use, do you have a specific name on libraries or something?

    Finally, thank you very much! At least now I understand why it fails...

  13. #13
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    Quote Originally Posted by Hear.Me.ROAR View Post
    The pointer will receive the old protection constant as I understand it, here is what the docs say:
    The DWORD that the pointer points to will receive the old protection value. You are pointing to random memory.

    1. GetProcAddress - GetModuleHandle = the offset of the function in the dll?
    2. How would I get the base address of the dll in the target function?
    3. What does Sym* mean? Which API / Functions can I use, do you have a specific name on libraries or something?
    1) Yes
    2) LOAD_DLL_DEBUG_INFO structure (Windows)
    3) Debug Help Library (Windows)
    4) Your 'getThreadContext' function is leaking handles. And there's actually no need to call OpenThread() since you get handles for all the threads in the CREATE_PROCESS and CREATE_THREAD events.

  14. #14
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    _Mike: Thanks, appreciated! Sorry for delayed response, been busy at my work. But I re-read the docs on debugging structures at MSDN and got a lot of ideas at least. Going to find out if they work now.

    Just one question: Why is my "getThreadContext" function leaking handles? Ain't it just changing the value of the global variable "hThread"?
    Last edited by Hear.Me.ROAR; 08-26-2011 at 07:43 PM.

  15. #15
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    639
    Quote Originally Posted by Hear.Me.ROAR View Post
    Just one question: Why is my "getThreadContext" function leaking handles? Ain't it just changing the value of the global variable "hThread"?
    Quote Originally Posted by OpenThread
    http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
    Remarks:
    The handle returned by OpenThread can be used in any function that requires a handle to a thread, such as the wait functions, provided you requested the appropriate access rights. The handle is granted access to the thread object only to the extent it was specified in the dwDesiredAccess parameter.

    When you are finished with the handle, be sure to close it by using the CloseHandle function.
    You don't do that, nor for your unnecessary OpenProcess call neither (look at what the members of PROCESS_INFORMATION are). The handles returned in said structure also need to be closed if you don't need them. Ironically, the only thing you CloseHandle is something you shouldn't.

    Your code doesn't appear to have been copied from anywhere, kudos for that, so you need to pay a bit closer attention to the doc pages to get all the ins and outs and housekeeping you're charged with when you stay in Windows' house.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. fscanf fails on an int
    By Chronoflect in forum C Programming
    Replies: 3
    Last Post: 02-18-2011, 06:00 PM
  2. Why this fails?
    By manav in forum C++ Programming
    Replies: 13
    Last Post: 05-29-2008, 01:11 PM
  3. trying to rea from /dev/tty fails!
    By arunj in forum Linux Programming
    Replies: 4
    Last Post: 10-17-2007, 03:59 AM
  4. wofstream Fails in VC++ 6.0
    By mercury529 in forum C++ Programming
    Replies: 2
    Last Post: 11-22-2005, 11:51 PM
  5. InternetConnect fails
    By jmd15 in forum Windows Programming
    Replies: 5
    Last Post: 09-04-2005, 06:05 PM