ember wrote:I used the 1.10 version but it doesn't work for me.
When i start doing the "step over" (F8) it behaives totally differently than in the video and if I continue with the F8.
This is "before and after" I press F8, if I continue to press F8 program complains that he can't find the address.
http://i50.tinypic.com/x1x3c1.jpg
Also I am not pressing "step into" by accident.
Also the api doesn't work in win7
The API used by the debugged program works fine in Windows 7. It would be bad if there wasn't backward compatibility for 32 bits programs.
From what I can tell there doesn't seem to be a module mapped in the address space on address 0x71b00000
You can check if there's a module loaded in that address space by pressing alt-M or pressing on the M icon.
I will look at this myself in a Windows 7 64 bit environment when I can.
I had a closer look at the example program. Something is fishy about the program entry point. Control of the program is being diverted to something else.
The entry point of the debugged program should look like below. It should not start with a jump.
I think a DLL is being globally injected and the DLL overwrites the original entry point of any program you run.
You can check this by loading other executable files in the debugger and look if the entry point has a jump.
Since I don't see the the name of the module responsible for overwriting the OEP, I suspect a hidden DLL module is loaded.
OllyDbg 1.10 doesn't detect hidden modules, but OllyDbg 2.01 has the ability to detect hidden modules. Look and see if there's a difference.
I think you might have a virus.
- Code: Select all
CPU Disasm
Address Hex dump Command Comments
00401000 /. 6A 00 PUSH 0 ; /ModuleName = NULL
00401002 |. E8 64020000 CALL <JMP.&KERNEL32.GetModuleHandleA> ; \KERNEL32.GetModuleHandleA




