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

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
4
  • 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, 2016 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, 2016 at 7:53
  • 1
    see also "Use hardware temporary breakpoints" in Debugging Options.
    – Igor Skochinsky ♦
    Apr 26, 2016 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, 2017 at 8:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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