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


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.

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.