Printable View
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.
You could post a link to the other thread.
tabstop: I see, here it is then: VirtualProtectEx fails, throws different error codes for different memory protection constants
Well, any ideas? I re-write the troubling functions just to make it easier for aiders to read the code fast/easy :)
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.
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 :/
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.
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:
How come the "RegionSize" is so huge?Quote:
BaseAddress = 75f6c000
AllocationBase = 0
AllocationProtect = 0
RegionSize = 11e4000
State = 10000 // MEM_FREE
Protect = 1 // PAGE_NOACCESS
Type = 0
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.
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?
And the pointer is pointing to...?Code:PDWORD old_protection; // this is a pointer
if (!VirtualProtectEx(hProcess, currentpage, size, PAGE_NOACCESS, old_protection)) {
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
The pointer will receive the old protection constant as I understand it, here is what the docs say:
Hmm, you seem to be on to something here. Just to clear things out:Quote:
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.
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...
The DWORD that the pointer points to will receive the old protection value. You are pointing to random memory.Quote:
Originally Posted by Hear.Me.ROAR
1) YesQuote:
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?
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.
_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"?
Quote:
Originally Posted by Hear.Me.ROAR
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.Quote:
Originally Posted by OpenThread
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.
Current stand: I can, thanks to your guidance change the access and set a memory breakpoint, using the LOAD_DLL_DEBUG_EVENT exception to get a valid address space. However, I can't seem to get the name of the loaded DLL. Is it possible to cast the unicode value lpImageName in LOAD_DLL_DEBUG_INFO to a string somehow?
Is the problem that you're getting NULL, or that you're getting Unicode?
Unicode, though I think I found a way to get the name through the handle on msdn (link).
I assume that approach could be used by passing the dll-handle, can't blame them for making it easy on their developers though...
I'm feeling okey about the debugging library at the moment and feel I should create a disassembler to make it easier for a potential user to put breakpoints. The first step, before disassembling, should be reading the entire file in hex-values, right?