shERis
June 15th, 2007, 04:33
BUG in GPA !
There is a great bug in GPA, but I don´t know how to solve this problem. (I posted it long time before, but there is no solution.)
If you have a command GPA "Any_Proc","COMCTL32.DLL", you´ll get a wrong (non existing) address of this "Any_Proc".
Why
?
I tried the following:
1. I loaded notepad.exe in Olly (could be another app using COMCTL32.DLL)
2. I made a little script:
========================
gpa "CreateToolbar","COMCTL32.DLL"
mov addr,$RESULT
gn addr
msg $RESULT
========================
and loaded it
3. I singlestepped the script and
4. gn addr fails to get the name of CreateToolbar, it results 0!
Furthermore I tried the following:
1. I loaded notepad.exe in a first instance of Olly (could be another app using COMCTL32.DLL)
2. I made a little script:
========================
gpa "CreateToolbar","COMCTL32.DLL"
mov addr,$RESULT
gn addr
msg $RESULT
========================
and loaded it
3. I started another instance of Olly, attached first instance of Olly and run it
4. I set a BP on CALL near kernel32.LoadLibraryA in GPA command in ODbgScript-section in second instance of Olly and run the second instance
5. I singlestepped the script in first instance of Olly with S
6. Olly stopps in second instance at that CALL LoadLibraryA as wanted
7. Wonder
I found the following:
In second instance of Olly there are all plugins in shown memory, in first instance not.
In first instance there is COMCTL32 in a high memory space. But in second instance of Olly there is at the same place a DLL called COMCTL_1. And there is at another memory place COMCTL32!!! At this address there is nothing in first instance of Olly! GPA now examines the address of CreateToolbar in COMCTL32 in second instance in a lower space and gives it to $RESULT. But in first instance of Olly this address is invalid!!!
GPA results the proc addresses of the named proc in OllyDbg process and NOT in the app process !!!
All other commands seem to be executed in app process.
Does anybody know how to get proc addresses in another loaded process (it is the loaded app process, here in the example notepad.exe) ?
1st instance of Olly debugs app (notepad.exe).
2nd instance of Olly debugs Olly of 1st instance.
ODbgScript is loaded by Olly - it´s loaded in both instances! But only in 2nd instance you can debug ODbgScript and set a BP on CALL kernel32.LoadLibraryA in ODbgScript code.
When you run a script with GPA then 2nd Olly breaks at LoadLibraryA.
But when you look at memory map window in both Olly´s, you´ll find the following (address could vary for you):
1st instance:
71950000 COMCTL32
2nd instance:
71950000 COMCTL_1
77310000 COMCTL32
When you execute GPA, then it results addresses of COMCTL32 in 2nd instance, it doesn´t matter in what instance of Olly you do. You´ll always get 77310000. But this is wrong!
It seems that Olly (1st instance) loads COMCTL32 twice in its process. One for the app and one for Olly itself.
But the right version of COMCTL32 is renamed to COMCTL_1, which has the same address. Therefore you´ll always get the wrong address of 2nd COMCTL32, which does not exist in app process.
So it is necessary to get proc address in app process and not in Olly process.
This ugly behaviour is only with COMCTL32.DLL. All other libs are at the same memory location in 1st and 2nd instance of Olly, therefore reading app process or Olly process doesn´t matter. But GPA always should result app process !!!
I played a little bit with OllyDbg and found the following:
When Olly is loaded, COMCTL32 from windows system32 directory is loaded into memory. It is shown as COMCTL32 in memory map window.
When Olly begins to run, it loads COMCTL32 from windows WinSxS\x86_Microsoft.Windows.Common-Controls..... directory using kernel32.LoadLibraryW/kernel32.LoadLibraryExW/ntdll.LdrLoadDll. With ntdll.RtlDosApplyFileIsolationRedirection_Ustr the WinSxS path is added to filename.
COMCTL32 therefore is loaded twice. The both versions are not identical. (Process Explorer shows it very well.)
To make a difference between the two instances windows changes the owner name to COMCTL_1 of the second COMCTL32.
I don´t know why Olly does this and this is our problem.
I think there should be a simple possibility to get the proc addresses of the loaded modules in the debugged process using
VAL_HPROCESS (HANDLE) Handle of debugged process
VAL_PROCESSID Process ID of debugged process
information of Plugingetvalue(int type).
Sysinternals Process Explorer shows it in a very effective way.
But I am no windows programmer.
Please help me and Epsylon3 if you know the necessary code to get the right proc address. Any ideas are welcome.
shERis
There is a great bug in GPA, but I don´t know how to solve this problem. (I posted it long time before, but there is no solution.)
If you have a command GPA "Any_Proc","COMCTL32.DLL", you´ll get a wrong (non existing) address of this "Any_Proc".

Why

I tried the following:
1. I loaded notepad.exe in Olly (could be another app using COMCTL32.DLL)
2. I made a little script:
========================
gpa "CreateToolbar","COMCTL32.DLL"
mov addr,$RESULT
gn addr
msg $RESULT
========================
and loaded it
3. I singlestepped the script and
4. gn addr fails to get the name of CreateToolbar, it results 0!

Furthermore I tried the following:
1. I loaded notepad.exe in a first instance of Olly (could be another app using COMCTL32.DLL)
2. I made a little script:
========================
gpa "CreateToolbar","COMCTL32.DLL"
mov addr,$RESULT
gn addr
msg $RESULT
========================
and loaded it
3. I started another instance of Olly, attached first instance of Olly and run it
4. I set a BP on CALL near kernel32.LoadLibraryA in GPA command in ODbgScript-section in second instance of Olly and run the second instance
5. I singlestepped the script in first instance of Olly with S
6. Olly stopps in second instance at that CALL LoadLibraryA as wanted
7. Wonder

I found the following:
In second instance of Olly there are all plugins in shown memory, in first instance not.
In first instance there is COMCTL32 in a high memory space. But in second instance of Olly there is at the same place a DLL called COMCTL_1. And there is at another memory place COMCTL32!!! At this address there is nothing in first instance of Olly! GPA now examines the address of CreateToolbar in COMCTL32 in second instance in a lower space and gives it to $RESULT. But in first instance of Olly this address is invalid!!!
GPA results the proc addresses of the named proc in OllyDbg process and NOT in the app process !!!
All other commands seem to be executed in app process.
Does anybody know how to get proc addresses in another loaded process (it is the loaded app process, here in the example notepad.exe) ?
1st instance of Olly debugs app (notepad.exe).
2nd instance of Olly debugs Olly of 1st instance.
ODbgScript is loaded by Olly - it´s loaded in both instances! But only in 2nd instance you can debug ODbgScript and set a BP on CALL kernel32.LoadLibraryA in ODbgScript code.
When you run a script with GPA then 2nd Olly breaks at LoadLibraryA.
But when you look at memory map window in both Olly´s, you´ll find the following (address could vary for you):
1st instance:
71950000 COMCTL32
2nd instance:
71950000 COMCTL_1
77310000 COMCTL32
When you execute GPA, then it results addresses of COMCTL32 in 2nd instance, it doesn´t matter in what instance of Olly you do. You´ll always get 77310000. But this is wrong!
It seems that Olly (1st instance) loads COMCTL32 twice in its process. One for the app and one for Olly itself.
But the right version of COMCTL32 is renamed to COMCTL_1, which has the same address. Therefore you´ll always get the wrong address of 2nd COMCTL32, which does not exist in app process.
So it is necessary to get proc address in app process and not in Olly process.
This ugly behaviour is only with COMCTL32.DLL. All other libs are at the same memory location in 1st and 2nd instance of Olly, therefore reading app process or Olly process doesn´t matter. But GPA always should result app process !!!
I played a little bit with OllyDbg and found the following:
When Olly is loaded, COMCTL32 from windows system32 directory is loaded into memory. It is shown as COMCTL32 in memory map window.
When Olly begins to run, it loads COMCTL32 from windows WinSxS\x86_Microsoft.Windows.Common-Controls..... directory using kernel32.LoadLibraryW/kernel32.LoadLibraryExW/ntdll.LdrLoadDll. With ntdll.RtlDosApplyFileIsolationRedirection_Ustr the WinSxS path is added to filename.
COMCTL32 therefore is loaded twice. The both versions are not identical. (Process Explorer shows it very well.)
To make a difference between the two instances windows changes the owner name to COMCTL_1 of the second COMCTL32.
I don´t know why Olly does this and this is our problem.
I think there should be a simple possibility to get the proc addresses of the loaded modules in the debugged process using
VAL_HPROCESS (HANDLE) Handle of debugged process
VAL_PROCESSID Process ID of debugged process
information of Plugingetvalue(int type).
Sysinternals Process Explorer shows it in a very effective way.
But I am no windows programmer.
Please help me and Epsylon3 if you know the necessary code to get the right proc address. Any ideas are welcome.
shERis