Author Topic: Debugging tricks  (Read 3051 times)

guga

  • Moderator
  • Member
  • *****
  • Posts: 1449
  • Assembly is a state of art.
    • RosAsm
Debugging tricks
« on: June 30, 2014, 12:57:54 PM »
During the development of a newer and safer Exitprocess function i faced some interesting functions related to the Kernel Internals as showed here:
http://masm32.com/board/index.php?topic=3347.0

Now here comes one small trick to set a breakpoint directly on a given windows regardless it is packet, not packet etc...

CreateToolhelp32Snapshot was my point of start. While rebuilding it i found a function called "BaseFormatObjectAttributes" which is not an api, but it is called in many Apis, such as:

DllGetClassObject ---> It is called whenever a app starts to be loaded (from msctf.dll)
RunInputCPL---> It is called whenever a app starts to be loaded (from msctf.dll)
CreateFileMappingW---> It is called whenever a app starts to be loaded (from kernel32.dll)

CreateEvent ---> It is called whenever a app starts to be loaded and also when it is already loaded and you click on a window, for example (From kernel32.dll)
 TF_CheckThreadInputIdle (from msctf.dll)
msctf_TF_CreateCicLoadMutex (from msctf.dll)

and...finally from....
GetWindowThreadProcessId

So...for debugging purposes....There is no more need to check from a specific api to break your app...All you have to do is load it and set a breakpoint in any of those functions (Specifically the last one GetWindowThreadProcessId )

I didn´t tested it yet, neither make some routines for debugging using those apis, but it seems usefull for the purpose. The GetWindowThreadProcessId for example, if you create a dll containing only this Api, and use it as a loader for th debugger, in theory, whenever you click on a specific window, it will break and later retrieve the ProcessID (THreadID, in fact) related to the loaded file.

Once you have the threadID or ProcessID, it can be possible to retrieve (dump) the whole file as it is loaded in memory with all the IAT intact (perhaps).

This is just an idea, i didn´t tested it to check...Maybe later i´ll implement it on RosAsm to allow it to dump to disk the loaded memory of a specific process/object.

For security issues this maybe relevant to know if an unwanted process is being loaded aside with your app (a hooker or a virus) and you maybe be able to kill it before it ruins your work without the help of any antiviruses etc.

Some years ago, René made a small trick to check for the checksum of the PE before it was loaded. So if the file was changed, it was stopped to open and a msgbox is showed, instead. It does not kill any virus, but at least, gave an indication either you file was being altered or not.

So, a similar techynique, maybe be implement in other apps, that can be able to identify if they are "under attack" or not without the needs to paying for antiviruses etc etc....All you have to stop a hook/virus attack maybe already on your OS. So all you have to do is use some apis in your own App to detect for changes during the process it is loaded.


Note:
Btw...When i meant hooker....well....it was not this...
... kind of hooker. :greensml: :greensml: :greensml:
« Last Edit: June 30, 2014, 02:43:57 PM by guga »
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com