Can you explain why IDA-Pro is confused with the following simple x86 instruction?

.text:0000000000001885   jnz     loc_1AD0
.text:000000000000188B loc_188B:
.text:000000000000188B   mov     byte ptr [var+9], 1
.text:000000000000188B some_func endp ; sp-analysis failed
.text:000000000000188B ; ---------------------------------------------------
.text:0000000000001890                 db 4Ch
.text:0000000000001891 ; ---------------------------------------------------
.text:0000000000001891 _debug_info_seg_0:
.text:0000000000001891   mov     eax, esp
.text:0000000000001893   cmp     rbx, 20h

This confusion forces me to manually redefine the incorrect data as code, and then to redefine the subroutine in order to fix the miscalculated endp position.

.text:0000000000001885   jnz     loc_1AD0
.text:000000000000188B loc_188B: 
.text:000000000000188B   mov     byte ptr [r14+9], 1
.text:0000000000001890   mov     rax, r12              <<<FIXED!>>>
.text:0000000000001893   cmp     rbx, 20h
.text:0000000000001897   jb      loc_1A80e

The issue happens several times with other simple x86-x64 instructions. Any idea why? and how to automatically correct those?


IDA's autoanalyzer considers user-defined names to be strong indicators of code or data item starts. Since you have the _debug_info_seg_0 symbol in the middle of the would-be instruction, IDA stopped disassembly instead of removing the symbol. You could write a script to remove such hindering symbols and recreate the instructions.

  • I do have symbols for my binary. _debug_info_seg_0 is not a real symbol. IDA incorrectly create this fake symbol. – Tal Jun 21 '17 at 6:55
  • file a bug report then? I doubt IDA pulled the symbol out of thin air. – Igor Skochinsky Jun 21 '17 at 7:36
  • Thanks Igor. you were right. There is a .debug_info segment with those labels. This section is not listed inside IDA sections tab (why?). when I remove this section from the binary (objcopy --remove-section) IDA is no longer confused. – Tal Jun 21 '17 at 8:30

In short, distinguish code from data is a undecidable problem. Concretely, your question is a special case of this question where you can find answers with detail explanation.

  • I understand some patterns might be undecidable. But not in this simple case. We have here an invalid opcode "db 4Ch" vs. "mov rax, r12", in a middle of a block of code. – Tal Jun 21 '17 at 7:01
  • Ahh, I feel ashamed. But I can learn from your question and the answer of Igor. – Ta Thanh Dinh Jun 21 '17 at 9:00

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.