![]() |
Writing small debugger
I'm trying to write a small "debugger" for one specific app. For starters i want to get to EP but i dont know how to do that. Here is how i tried to do so, but when i sompare used memory of app how Olly loaded and how i loaded it, Ollys child process has occupied more memory.
Code:
if DWORD(CreateProcess('1.exe',nil,nil,nil,FALSE,DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS,nil,nil,si,pi)) = 0 then begin |
I've read this tut from ICZlion. He made a simple debugger like what you need as an example. The codes are in MASM32 but it will guide you with Win32 Debug APIs as sure.
http://win32assembly.online.fr/tut28.html http://win32assembly.online.fr/tut29.html http://win32assembly.online.fr/tut30.html Regards O M I D |
A man named "Nico Bendlin" who had translate iczlion's masm code to delphi code. You can search for get it.
|
That is the ugliest piece of code I've ever seen. First off, you don't want to return EXCEPTION_NOT_HANDLED right away. That first exception is the built in system breakpoint, and you have to return DBG_CONTINUE to it.
Secondly, any patching of EP's has to be done during that initial system breakpoint (all debuggers get an auto breakpoint (int 3) by the system, at EP, to let them set up). Here is C++ code that does things the correct way. Code:
// We only do anything if the user selected a file.Also, you have to remember that if you ever use GetThreadContext or SetThreadContext calls in your debugger, DO NOT USE the stored hThread from the creation of the process. You have to get which thread is actually being run. Which means every time a DEBUG_CREATE_THREAD occurs, you need to have a list (I used a vector) to keep track of each new thread handle, so you can support multiple threads. Of course I know you are trying to just make a simple debugger for now though. -Lunar |
Thanks for the info. Maybe trapflag will be usefull for getting to OEP.
|
Well inside the first int3 handler you can put a 0xCC (int3) on your OEP, but usually since it's packed of course it won't work right. In that case you can either single step (might take a while) or you can use BPM's to break on access. Like I said, for either of these you will need to do a GetThreadContext/SetThreadContext pair, and for apps that might be multithreaded, you have to make sure you kept track of thread creation so you set the context of the correct thread. (See above post near bottom)
It does add complexity unfortunately, but it's the only way to make the debugger more robust and reliable on real applications. Examples: setting the single step flag in a thread Code:
Code:
#include <map>storing thread handles when they are created we do this since a debug event only gives us ThreadID's. It's a pain to get hThread from ThreadID, but we can track it ourselves with an "array" (map) Code:
case CREATE_THREAD_DEBUG_EVENT:Code:
case EXIT_THREAD_DEBUG_EVENT:getting the current thread when a debug exception occurs Code:
WaitForDebugEvent(&DebugEv, INFINITE); -Lunar |
ow, ow, i didnt even see your post when i wrote my reply. Well, i trust you its ugliest. I dont like it either. Partly becouse it is really ugly and partly becouse i'm not sure what i'm writing there. I didnt read anything other than Help files when writing that.
Well, some things you said here i read from Icz Tutorials and tried them myself. As for threads, i dont really need to update it (unless its changed O_o) becouse this specific program has only 1 thread while i need to debug it. Later i'll just detach. Thanks alot for these snippets :) Hvala komšija :) |
Oh, and i forgot. When does first BREAKPOINT occur? You said system sets one on EP and thats what i understood from Icz tutorials. I tried getting to EP that way, but seems that i'm in Kernel when i get first BP O_o EIP is 7fxxxxxx. I didnt do any debugging before that. Those are first lines when i try to get there. I thought this might be ret before going to EP and tried to trace with trapflag but its like i stand in same place. I dont move from that EIP. I'll fix it somehow...
|
Yes, I believe that first breakpoint will end you up in the system, but now you can go and write that 0xCC to the EP of the program, and then do a DBG_CONTINUE. Now the second 0xCC that comes thru will be that one that you set.
-Lunar |
Oh. Cool. I'll try it out now. I thought getting to OEP would be least problem. I had problems with VirtualProtect too but solved it...
|
Here is an example program with MASM source that should make thing quite a bit easier after looking over.
Un-FSG 2.0 http://giaubertin.free.fr/pages/Coding/cod_tool.html from redirector http://www.rif.fr.fm/ Good luck :) |
Well i finished mine before yousent me this like but i found other things to look at there ;) Not to learn how to rebuild imports... :)
|
| All times are GMT +8. The time now is 09:00. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX