Win7 64-bit and 32-bit debuggers.

[Ficko]

Hi guys!

I recently installed a "Win7 64-bit" and now I unable to use any of my favorite debugger. :'(

I wonder that someone had simile experience and have some advise. ::)

If I load an executable into the debugger "Olly,Windbg,Immunity" the "winmain" looks like this:

Code Select Expand


CPU Disasm
Address   Hex dump             Command
01291000  -/E9 FBEF8670        JMP 71B00000
01291005   |E3 E8              JECXZ SHORT 01290FEF
01291007   |9B                 WAIT
01291008   |0A00               OR AL,BYTE PTR DS:[EAX]
0129100A   |0085 C0742360      ADD BYTE PTR SS:[EBP+602374C0],AL
01291010   |8925 44622901      MOV DWORD PTR DS:[1296244],ESP
01291016   |68 57102901        PUSH OFFSET 01291057
0129101B   |FF15 00502901      CALL DWORD PTR DS:[1295000]
01291021   |E9 EA000000        JMP 01291110
01291026   |8B25 44622901      MOV ESP,DWORD PTR DS:[1296244]
0129102C   |61                 POPAD
0129102D   |E8 990A0000        CALL 01291ACB
01291032   |C9                 LEAVE


it should look like this:

Code Select Expand


CPU Disasm
Address   Hex dump              Command
00401000  /.  55                PUSH EBP
00401001  |.  89E5              MOV EBP,ESP
00401003  |.  9B                WAIT
00401004  |.  DBE3              FINIT
00401006  |.  E8 9B0A0000       CALL 00401AA6
0040100B  |.  85C0              TEST EAX,EAX
0040100D  |.  74 23             JE SHORT 00401032
0040100F  |.  60                PUSHAD
00401010  |.  8925 44624000     MOV DWORD PTR DS:[406244],ESP
00401016  |.  68 57104000       PUSH 00401057                           
0040101B  |.  FF15 00504000     CALL DWORD PTR DS:[<&KERNEL32.SetUnhandl
00401021  |.  E9 EA000000       JMP 00401110
00401026  |>  8B25 44624000     MOV ESP,DWORD PTR DS:[406244]
0040102C  |.  61                POPAD
0040102D  |.  E8 990A0000       CALL 00401ACB
00401032  |>  C9                LEAVE


You can see that the memory index is totally screwed up "01291000" instead of "00401000" and the firs 5 bites are changed to a jump into the kernel. :dazzled:
Needles to say that the program does not run properly in the debugging environment.

Any clue whats wrong?! :'(

I used a VISTA-64 before with no problem what so ever.

[theunknownguy]

Hi guys!

I recently installed a "Win7 64-bit" and now I unable to use any of my favorite debugger. :'(

I wonder that someone had simile experience and have some advise. ::)

If I load an executable into the debugger "Olly,Windbg,Immunity" the "winmain" looks like this:

Code Select Expand


CPU Disasm
Address   Hex dump             Command
01291000  -/E9 FBEF8670        JMP 71B00000
01291005   |E3 E8              JECXZ SHORT 01290FEF
01291007   |9B                 WAIT
01291008   |0A00               OR AL,BYTE PTR DS:[EAX]
0129100A   |0085 C0742360      ADD BYTE PTR SS:[EBP+602374C0],AL
01291010   |8925 44622901      MOV DWORD PTR DS:[1296244],ESP
01291016   |68 57102901        PUSH OFFSET 01291057
0129101B   |FF15 00502901      CALL DWORD PTR DS:[1295000]
01291021   |E9 EA000000        JMP 01291110
01291026   |8B25 44622901      MOV ESP,DWORD PTR DS:[1296244]
0129102C   |61                 POPAD
0129102D   |E8 990A0000        CALL 01291ACB
01291032   |C9                 LEAVE


it should look like this:

Code Select Expand


CPU Disasm
Address   Hex dump              Command
00401000  /.  55                PUSH EBP
00401001  |.  89E5              MOV EBP,ESP
00401003  |.  9B                WAIT
00401004  |.  DBE3              FINIT
00401006  |.  E8 9B0A0000       CALL 00401AA6
0040100B  |.  85C0              TEST EAX,EAX
0040100D  |.  74 23             JE SHORT 00401032
0040100F  |.  60                PUSHAD
00401010  |.  8925 44624000     MOV DWORD PTR DS:[406244],ESP
00401016  |.  68 57104000       PUSH 00401057                           
0040101B  |.  FF15 00504000     CALL DWORD PTR DS:[<&KERNEL32.SetUnhandl
00401021  |.  E9 EA000000       JMP 00401110
00401026  |>  8B25 44624000     MOV ESP,DWORD PTR DS:[406244]
0040102C  |.  61                POPAD
0040102D  |.  E8 990A0000       CALL 00401ACB
00401032  |>  C9                LEAVE


You can see that the memory index is totally screwed up "01291000" instead of "00401000" and the firs 5 bites are changed to a jump into the kernel. :dazzled:
Needles to say that the program does not run properly in the debugging environment.

Any clue whats wrong?! :'(

I used a VISTA-64 before with no problem what so ever.

Ollydbg or Inmmunity have no support for x64 for what i know... So probably start using IDA. Ollydbg 2.0 its being developed and i think it have x64 support.

PS: I am not sure of this, but i used to try remote debug into a VISTA-64 and doesnt work too (also try Win7-64)

[Ficko]

Thaks for the reply "theunknownguy"!

Ollydbg or Inmmunity have no support for x64 for what i know...

I know that I am not trying to debug 64-bit application. :lol

32-bit applications are running under "SysWOW64" and under VISTA-64 it was not a problem to debug 32-bit applications.
Even Olly 1.0 was able to do it with a plugin. "stealt64"

Now even "windbg" from MS is spinning.
"windbg" is designed to debug 32 and 64 - bit applications as well.

So I am thinking this has to do with some kind of "privileges" or simile. ::)

[theunknownguy]

Thaks for the reply "theunknownguy"!

Ollydbg or Inmmunity have no support for x64 for what i know...

I know that I am not trying to debug 64-bit application. :lol

32-bit applications are running under "SysWOW64" and under VISTA-64 it was not a problem to debug 32-bit applications.
Even Olly 1.0 was able to do it with a plugin. "stealt64"

Now even "windbg" from MS is spinning.
"windbg" is designed to debug 32 and 64 - bit applications as well.

So I am thinking this has to do with some kind of "privileges" or simile. ::)

Can you paste a big portion of the code that you see when trying to debug please. (Better an screenshot of ollydbg)  :toothy

[Ficko]

Can you paste a big portion of the code that you see

I did in my original post above.
It shows how it looks like on the Win7-64 and on a XP32 machine.

You can see that the disassembly is the same except the first 5 bytes -  JMP 71B00000 - and the thoroughly screed up offset.

"01291005" = "00401005"

No executable can start on "01xxxxxx" sofar I know. ::)

[theunknownguy]

Can you paste a big portion of the code that you see

I did in my original post above.
It shows how it looks like on the Win7-64 and on a XP32 machine.

You can see that the disassembly is the same except the first 5 bytes -  JMP 71B00000 - and the thoroughly screed up offset.

"01291005" = "00401005"

No executable can start on "01xxxxxx" sofar I know. ::)

I doubt alot that a privilege setting would cause the override of the first 5 bytes + the screw of RVAs...

Honestly its not too much info for knowing the problem. Ill recommend to check on google best friend if some one had your error too.

[sinsi]

I have found with windbg that you need to actually jump to your start proc for it to make sense i.e. use 'g 401000' to get it to the internal breakpoint then 'g 401000' again to get it to load dlls and get ready.

[Ficko]

Thanks sinsi.

I can't set a break point on "00401000".  :(

Unable to insert breakpoint 0 at 00000000`00401000, Win32 error 0n299

Everything is very strange and I do not have a clue.

[Ficko]

Just for info if somebody run into this strange behavior in the future.

"COMODO" Internet Security is the culprit.

It is modifying executables on the fly to implement a unique partial "sanbox".

This thing may be very useful for regular computer users but makes programmers the life unbearable.
The phenomena pointed out here is just one of the 10 almost unexplainable strange manifestation your computer can show by using the above software.

You sometimes think have catched the most hideous Trojan man ever invented.

Just a warning. :toothy

[brethren]

i've seen this happen with zonealarm :tdown

[Alloy]

"COMODO" Internet Security is the culprit.

It is modifying executables on the fly to implement a unique partial "sanbox".

Cool, I thought the sandbox schemes weren't being used that much anymore. I'll give it a test run.  :bg