Рекурсивная сборка Вызов, хотя нет рекурсии в исходном коде

Question

У меня есть фрагмент кода из дампа, который я хочу понять. Что беспокоит меня больше всего, являются (по-видимому) рекурсивные вызовы, такие как

bd604: bd605 e8 Ь и далее и далее и далее вызов + 0xb5

Что они делают? Я не использую рекурсию в исходной функции.

Спасибо @ schnaader

, кажется, как будто звонки делают CLD и перейти к EAX

EDIT: полный DMP моей функции

00bd550 <SendData>: 
SendData(): 
    bd550: 55      push %ebp 
    bd551: 57      push %edi 
    bd552: 56      push %esi 
    bd553: 53      push %ebx 
    bd554: 83 ec 20    sub $0x20,%esp 
    bd557: 8b 35 74 a2 06 00  mov 0x6a274,%esi 
    bd55d: 8b 1d ac a2 06 00  mov 0x6a2ac,%ebx 
    bd563: dd 44 24 40    fldl 0x40(%esp,1) 
    bd567: 66 c7 44 24 0e 00 00 movw $0x0,0xe(%esp,1) 
    bd56e: 83 eb 18    sub $0x18,%ebx 
    bd571: 85 f6     test %esi,%esi 
    bd573: dd 5c 24 18    fstpl 0x18(%esp,1) 
    bd577: dd 44 24 48    fldl 0x48(%esp,1) 
    bd57b: dd 5c 24 10    fstpl 0x10(%esp,1) 
    bd57f: 0f 85 b2 00 00 00  jne bd637 <SendData+0xe7> 
    bd585: 8b 7c 24 38    mov 0x38(%esp,1),%edi 
    bd589: 89 dd     mov %ebx,%ebp 
    bd58b: c1 fd 02    sar $0x2,%ebp 
    bd58e: 85 ff     test %edi,%edi 
    bd590: 0f 8e 99 00 00 00  jle bd62f <SendData+0xdf> 
    bd596: 8d 76 00    lea 0x0(%esi),%esi 
    bd599: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi 
    bd5a0: 0f b7 74 24 0e   movzwl 0xe(%esp,1),%esi 
    bd5a5: 39 ef     cmp %ebp,%edi 
    bd5a7: 89 e8     mov %ebp,%eax 
    bd5a9: 0f 4e c7    cmovle %edi,%eax 
    bd5ac: dd 44 24 18    fldl 0x18(%esp,1) 
    bd5b0: 89 c5     mov %eax,%ebp 
    bd5b2: 8d 1c ad 00 00 00 00 lea 0x0(,%ebp,4),%ebx 
    bd5b9: 29 ef     sub %ebp,%edi 
    bd5bb: 01 c6     add %eax,%esi 
    bd5bd: a1 a8 a2 06 00   mov 0x6a2a8,%eax 
    bd5c2: 8d 56 ff    lea 0xffffffff(%esi),%edx 
    bd5c5: dd 58 08    fstpl 0x8(%eax) 
    bd5c8: 66 89 50 06    mov %dx,0x6(%eax) 
    bd5cc: 0f b7 54 24 0e   movzwl 0xe(%esp,1),%edx 
    bd5d1: 66 89 50 04    mov %dx,0x4(%eax) 
    bd5d5: 8b 54 24 3c    mov 0x3c(%esp,1),%edx 
    bd5d9: 89 10     mov %edx,(%eax) 
    bd5db: dd 44 24 10    fldl 0x10(%esp,1) 
    bd5df: dd 58 10    fstpl 0x10(%eax) 
    bd5e2: 8b 54 24 34    mov 0x34(%esp,1),%edx 
    bd5e6: 0f bf 44 24 0e   movswl 0xe(%esp,1),%eax 
    bd5eb: 89 5c 24 08    mov %ebx,0x8(%esp,1) 
    bd5ef: 83 c3 18    add $0x18,%ebx 
    bd5f2: 8d 04 82    lea (%edx,%eax,4),%eax 
    bd5f5: 89 44 24 04    mov %eax,0x4(%esp,1) 
    bd5f9: a1 a8 a2 06 00   mov 0x6a2a8,%eax 
    bd5fe: 83 c0 18    add $0x18,%eax 
    bd601: 89 04 24    mov %eax,(%esp,1) 
    bd604: e8 fc ff ff ff   call bd605 <SendData+0xb5> 
    bd609: a1 a8 a2 06 00   mov 0x6a2a8,%eax 
    bd60e: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp,1) 
    bd615: 00 
    bd616: 89 5c 24 04    mov %ebx,0x4(%esp,1) 
    bd61a: 89 04 24    mov %eax,(%esp,1) 
    bd61d: e8 fc ff ff ff   call bd61e <SendData+0xce> 
    bd622: 85 ff     test %edi,%edi 
    bd624: 66 89 74 24 0e   mov %si,0xe(%esp,1) 
    bd629: 0f 8f 71 ff ff ff  jg  bd5a0 <SendData+0x50> 
    bd62f: 83 c4 20    add $0x20,%esp 
    bd632: 5b      pop %ebx 
    bd633: 5e      pop %esi 
    bd634: 5f      pop %edi 
    bd635: 5d      pop %ebp 
    bd636: c3      ret 
    bd637: dd 44 24 18    fldl 0x18(%esp,1) 
    bd63b: dd 1c 24    fstpl (%esp,1) 
    bd63e: e8 fc ff ff ff   call bd63f <SendData+0xef> 
    bd643: 85 c0     test %eax,%eax 
    bd645: 74 e8     je  bd62f <SendData+0xdf> 
    bd647: e9 39 ff ff ff   jmp bd585 <SendData+0x35> 
    bd64c: 8d 74 26 00    lea 0x0(%esi,1),%esi 

Answer 1

Возможно, вы получили этот дамп от разборки объектного файла (.o). Как упоминалось, here on OSDev последовательность e8 fc ff ff ff соответствует вызову функции перед фазой связывания, до того, как известен конечный адрес (в исполняемом файле) функции, которую вы вызываете. На этом этапе информация о назначении этого вызова сохраняется в таблице перемещений объектного файла, ожидая, пока компоновщик не сможет сместить исполняемый файл вместе.

Чтобы избежать этой проблемы, вы должны проанализировать дамп окончательного исполняемого файла, а не одного из объектных файлов. Здесь задание компоновщика будет выполнено, и операнды CALL будут соответствовать их реальным местам назначения.

Answer 2

Использование GRDB (реальный mode debugger), это означает «вызов -1», поэтому байт на bd603 определит, какая команда будет выполнена. Например, если этот байт является FF, следующей командой будет «jmp ax», который может быть рекурсивным.

В любом случае, это скорее похоже на анти-отладочный/самомодифицирующийся код, чем на самом деле смысл.