Неожиданное поведение JMP в Shellcode, когда следующая (пропущенная) инструкция является определением переменной

Я мог бы скомпилировать ваш код с nasm после замены // на ;, однако я не пытался его выполнить.

nasm -f elf64 a.s -o a

Тогда я мог бы посмотреть на код с помощью:

objdump -d a

И часть кода, о котором вы спрашиваете, выглядит так (т.е. jmp)

  12:   48 89 cb                mov    %rcx,%rbx
  15:   eb 07                   jmp    1e <gg>

0000000000000017 <p2>:
  17:   2f                      (bad)  
  18:   62                      (bad)  
  19:   69                      .byte 0x69
  1a:   6e                      outsb  %ds:(%rsi),(%dx)
  1b:   2f                      (bad)  
  1c:   73 68                   jae    86 <gg+0x68>

000000000000001e <gg>:
  1e:   48 31 c0                xor    %rax,%rax

Однако у следующего есть несколько проблем:

    mov [rdi+7], byte al ;null terminating using 0x00 from rax
    mov [rdi+8], rdi
    mov [rdi+16],rax

1. Вы пытаетесь выполнить ЗАПИСЬ в ТОЛЬКО ДЛЯ ЧТЕНИЯ память. Код не может быть изменен

2. Mov rdi / rax не может быть выровнен

3. Если этот код будет успешным, он перезапишет ваш код на gg:.

Также было бы неплохо поставить по выравниванию непосредственно перед gg: Примерно так:

p2: "..."
align   16
gg:
   xor rax,rax

Итак, поскольку код предназначен только для чтения, вы должны вручную ввести туда нули.

p2: db "..."
    db 0
    db 0, 0, 0, 0, 0, 0, 0, 0
    db 0, 0, 0, 0, 0, 0, 0, 0

Если вы знаете, что он выровнен, dq тоже подойдет.

Однако обратите внимание, что вы также не выравниваете p2, поэтому вы не можете быть уверены (т.е. если ваш код изменится, выравнивание, скорее всего, тоже изменится). Вероятно, вы захотите сделать:

    align 16
p2: db "..."
    db 0
    dq 0
    dq 0

И последнее замечание: [rel p2] был довольно ограничен. Насколько мне известно, относительное смещение в этих инструкциях было ограничено -127 и +128. На моем 64-битном процессоре, однако, используется 32-битное смещение. Возможно, вы столкнулись с такой проблемой, в зависимости от вашего ассемблера, где он решил, что это слишком далеко. В вашем случае одно из решений - поместить инструкцию lea перед jmp над данными. И я бы предположил, что компилятор должен выдать ошибку, если смещение переполняется. Другая возможность заключается в том, что каким-то образом что-то оптимизируется, и jmp не обновляется должным образом.

Кстати, следующее не оптимизировано:

    xor rax,rax
    mov rsi,rax
    mov rdi,rsi
    mov rdx,rdi
    mov r8,rdx

Использование xor для всех регистров или повторное использование rax каждый раз вместо переключения будет работать лучше (более вероятно, что будет работать параллельно). Прямо сейчас вы привязываете все инструкции к предыдущей (т.е. прежде, чем вы сможете скопировать rsi в rdi, вам нужно скопировать rax в rsi. Наличие mov rdi,rax удалит эту зависимость.) Я думаю, что вы не увидите никакой разницы в этом случае, но это нужно иметь в виду для хорошей оптимизации.

С выравниванием и добавлением нулей в код я получаю:

0000000000000000 <_start>:
   0:   48 31 c0                xor    %rax,%rax
   3:   48 89 c6                mov    %rax,%rsi
   6:   48 89 f7                mov    %rsi,%rdi
   9:   48 89 fa                mov    %rdi,%rdx
   c:   49 89 d0                mov    %rdx,%r8
   f:   4c 89 c1                mov    %r8,%rcx
  12:   48 89 cb                mov    %rcx,%rbx
  15:   eb 29                   jmp    40 <gg>
  17:   90                      nop
  18:   90                      nop
  19:   90                      nop
  1a:   90                      nop
  1b:   90                      nop
  1c:   90                      nop
  1d:   90                      nop
  1e:   90                      nop
  1f:   90                      nop

0000000000000020 <p2>:
  20:   2f                      (bad)  
  21:   62                      (bad)  
  22:   69 6e 2f 73 68 00 00    imul   $0x6873,0x2f(%rsi),%ebp
        ...
  35:   00 00                   add    %al,(%rax)
  37:   00 90 90 90 90 90       add    %dl,-0x6f6f6f70(%rax)
  3d:   90                      nop
  3e:   90                      nop
  3f:   90                      nop

0000000000000040 <gg>:
  40:   48 31 c0                xor    %rax,%rax
  43:   48 8d 3d d6 ff ff ff    lea    -0x2a(%rip),%rdi        # 20 <p2>
  4a:   48 8d 77 08             lea    0x8(%rdi),%rsi
  4e:   48 8d 57 10             lea    0x10(%rdi),%rdx
  52:   b0 3b                   mov    $0x3b,%al
  54:   0f 05                   syscall

Обратите внимание, что при дизассемблировании, если ваши данные представляют собой инструкцию, они могут в конечном итоге использовать байты из вашего действительного кода и, таким образом, не показать вам то, что вы в противном случае ожидали бы. то есть он может не найти метку назначения. Но здесь у нас все хорошо.