0

I am debugging a 32-bit program on a 64-bit MS Windows 7 using IDA Pro 6.8 as seen in the image below:IDAproScreenshot

The instruction highlighted in the trace window (upper-left part of screen-shot) is supposed to MOV a word from some memory address in the .text segment (at the address given by the EDX register), into the EBX register.

EDX = 0x013D4021 and the bytes stored at this address are 50 53 51 52, shown in the HexView of IDA in the lower half of the screen-shot above.

Therefore, after executing the highlighted instruction mov ebx, [edx] I was expecting that EBX = 0x52515350.

However, as you can see in the Result column of the trace window this is not true because EBX = 0x525153CC.

Can anyone explain why the least significant byte in EBX is equal to CC instead of 50? Is it a bug in IDA or is it caused by the OS?

NOTE: I tried the same program with IDA Pro 6.9 and encountered the same behavior.

UPDATE: If you also have this issue and still want to debug the program, use hardware breakpoints. Hardware breakpoints do not modify the code like in the example above. IDA Pro allows enabling hardware breakpoints: hex-rays.com/products/ida/support/idadoc/1407.shtml

1

CC is a single-byte encoding of int 3, which is the standard way of breaking to the debugger. In particular, debuggers often use it for break points and for single-stepping: they simply replace the first instruction byte with CC and wait for the interrupt. Then they write back the original instruction byte.

The hexdump of the memory area around [edx] definitely looks like code, and the bytes loaded into ebx look like push opcodes. So it seems reasonable to suppose that either IDA is playing around with int 3 or someone else does... If your target program is aliasing memory then this could explain the whole confusion.

  • 1
    Especially, as you can see in your screenshot how edx has the address of sub_13D4021. I bet you have a breakpoint on that subroutine, and when you step over your mov ebx, [edx], IDA sets the breakpoint (storing 0xcc at that memory location), executes one instruction so the breakpoint gets loaded into ebx, and restores the memory after the single step. – Guntram Blohm Apr 24 '16 at 18:57
  • 1
    Note to people who also have this issue and still want to debug the program: Use hardware breakpoints, they do not modify the code like in the example above. IDA Pro allows enabling hardware breakpoints: hex-rays.com/products/ida/support/idadoc/1407.shtml – Benny Apr 26 '16 at 7:53
  • 1
    see also "Use hardware temporary breakpoints" in Debugging Options. – Igor Skochinsky Apr 26 '16 at 13:57
  • CC and CD are often used for debugging. When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete? – phuclv Jan 4 '17 at 8:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.