Início / unix / Perguntas / 760684
Accepted
Ole Tange
Asked: 2023-11-05 20:38:40 +0800 CST

Por que 'H'/72/0x48 é o segundo byte mais comum em executáveis?

  • 772

Eu corri isso:

cat /usr/bin/* |
  perl -ne 'map {$a{$_}++} split//; END{print map { "$a{$_}\t$_\n" } keys %a}' |
  grep --text . | sort -n | plotpipe --log y {1}

e consegui isso:

número de ocorrências de valor de byte

(Mesmo com um log do eixo y, ainda parece exponencial! Há mais de 100x entre o topo e o fundo)

Olhando para os números:

:
31919597        ^H
32983719        ^B
33943030        ^O
39130281        \213
39893389        $
52237360        \211
53229196        ^A
76884442        \377
100776756       H
746405320       ^@

Não é de surpreender que ^@ (NUL) seja o byte mais comum em executáveis. \377 (255) e ^A (1) também fazem sentido intuitivamente para mim.

Mas o que faz com que 'H' (72) seja o segundo byte mais comum em executáveis ​​- muito mais comum que 255 e 1?

x86

1 respostas

  1. Best Answer

    (Se a pontuação desta resposta for 72, não vote positivamente!)

    Esse seria o prefixo de tamanho de operando de 64 bits das instruções do código de máquina AMD64.

    Você notará que isso só acontece em executáveis ​​AMD64.

    Se você comparar /bin/*em http://ftp.debian.org/debian/pool/main/c/coreutils/coreutils_9.1-1_arm64.deb , http://ftp.debian.org/debian/pool/main/ c/coreutils/coreutils_9.1-1_amd64.deb e http://ftp.debian.org/debian/pool/main/c/coreutils/coreutils_9.1-1_i386.deb , você verá:

    $ for f (coreutils_9.1-1_*.deb) bsdtar xOf $f da\* | bsdtar xO ./bin/\* | xxd -p -c1 | sort | uniq -c | sort -rn | head -n 5 | grep -H --label="${${f:r}##*_}" .
amd64: 692417 00
amd64: 145689 ff
amd64:  81911 48
amd64:  48006 89
amd64:  45331 0f
arm64:1409826 00
arm64:  70391 ff
arm64:  67915 03
arm64:  49380 20
arm64:  41655 40
i386: 515346 00
i386: 171643 ff
i386:  78361 0e
i386:  69317 24
i386:  50497 83

    0x48 (72, 'H') está apenas entre os 3 primeiros no AMD64.

    Em lsmeu sistema Debian amd64:

    $ xxd -p -c1 =ls | sort | uniq -c | sort -rn | head -n 5
  39187 00
   7827 ff
   5565 48
   4181 20
   3393 0f

    Se desmontarmos o código desse executável, encontraremos muitos bytes 0x48 nas instruções:

    $ objdump -d =ls | grep -cw 48
5353

    A maioria deles na primeira posição:

    $ objdump -d =ls | grep -wm10 48
    4000:       48 83 ec 08             sub    $0x8,%rsp
    4004:       48 8b 05 ad ff 01 00    mov    0x1ffad(%rip),%rax        # 23fb8 <__gmon_start__@Base>
    400b:       48 85 c0                test   %rax,%rax
    4012:       48 83 c4 08             add    $0x8,%rsp
    44b6:       68 48 00 00 00          push   $0x48
    4751:       48 89 f3                mov    %rsi,%rbx
    4754:       48 83 ec 68             sub    $0x68,%rsp
    4758:       48 8b 3e                mov    (%rsi),%rdi
    475b:       64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
    4764:       48 89 44 24 58          mov    %rax,0x58(%rsp)

    $ objdump -d =ls | grep -Pc '^\s*[\da-f]+:\s+48'
5113

    De acordo com http://ref.x86asm.net/geek.html#x48 , esse 0x48 é o prefixo do código de operação de tamanho de operando de 64 bits REX.W que especifica que a operação deve ser feita em operandos de 64 bits em vez de qualquer padrão que deveria ser.

    $ objdump -d =ls | pcregrep -o1 -o2 '^\s*[\da-f]+:\s+(48 .. ).*?\t(\S+)' | sort | uniq -c  | sort -rn | head
   1512 48 89 mov
   1040 48 8b mov
    630 48 8d lea
    372 48 85 test
    326 48 83 add
    198 48 39 cmp
    158 48 83 sub
     79 48 01 add
     72 48 83 cmp
     69 48 c7 movq

    Todas as instruções são executadas em operandos de 64 bits.

    • 72

relate perguntas