Início / coding / Perguntas / 79552514
Accepted
pts
Asked: 2025-04-03 17:23:44 +0800 CST

Como detectar se meu código x86 está sendo executado no modo de 16 bits ou 32 bits sem modificar FLAGS ou regs?

  • 772

Meu código x86 pré-compilado pode estar sendo executado em 16 bits (modo real ou modo protegido de 16 bits) ou 32 bits (modo protegido i386). Como posso detectá-lo a partir do código em tempo de execução?

Consegui chegar a esta fonte NASM:

bits 16
cpu 386

pushf
test ax, strict word 0  ; In 32-bit mode this is `test eax, ...', +2 bytes.
jmp short found_16
; Fall through to found_32.

found_32:
bits 32
popf
int 32  ; Or whatever code.

found_16:
bits 16
popf
int 16  ; Or whatever code.

No entanto, não gosto, porque ele usa a pilha. Existe uma solução que não modifique nenhum registrador de uso geral, registrador de segmento ou flags, não use a pilha e funcione em um 8086 (somente modo de 16 bits) e em um 386 (ambos os modos)?

Tentei lea esi, [dword esi+0]no modo de 32 bits, mas isso não é possível no modo de 16 bits.

Observe que estou ciente de que para a maioria dos programas o modo é decidido em tempo de compilação (como parte da arquitetura e plataforma), e eles não precisam ser capazes de detectar o modo em tempo de execução. Também para programas iniciados normalmente, o sistema operacional escolherá o modo correto com base no cabeçalho do arquivo, portanto, quase não há perigo de executar acidentalmente um arquivo de programa completo no modo errado. No entanto, alguns trechos de programa, como o shellcode de exploração, podem se beneficiar da detecção em tempo de execução de todos os tipos (incluindo a arquitetura e o sistema operacional). Também tenho alguns outros casos de uso obscuros em mente.

assembly

3 respostas

  1. Se você estiver satisfeito com as mudanças temporárias que esiforam desfeitas, algo como isto pode funcionar:

        bits 16
    lea si, [si + 0xa6]
    jmp short found16
    nop
found32:
    bits 32
    lea esi, [esi + 0x6ff21500]
    int 32
    nop dword [eax + 1] ; padding for better disasm
found16:
    bits 16
    lea si, [si - 0xa6]
    int 16

    No modo de 16 bits que decodifica para:

    00000000  8DB4A600          lea si,[si+0xa6]
00000004  EB0D              jmp short 0x13
00000006  90                nop
00000007  8DB60015          lea si,[bp+0x1500]
0000000B  F26F              repne outsw
0000000D  CD20              int 0x20
0000000F  0F1F4001          nop word [bx+si+0x1]
00000013  8DB45AFF          lea si,[si-0xa6]
00000017  CD10              int 0x10

    E em 32 bits:

    00000000  8DB4A600EB0D90    lea esi,[esi-0x6ff21500]
00000007  8DB60015F26F      lea esi,[esi+0x6ff21500]
0000000D  CD20              int 0x20
    • 7
  2. Best Answer

    Percebi que posso melhorar minha solução anterior.

    JMP NEAR, o opcode 0xE9 pega um deslocamento imediato de 16 bits de dois bytes no modo de 16 bits e um deslocamento de 32 bits de quatro bytes no modo de 32 bits. Além disso, esse deslocamento é relativo ao início da próxima instrução. Então, se os 16 bits superiores do deslocamento de 32 bits forem zero, isso significa que o alvo do salto no modo de 16 bits está dois bytes abaixo do alvo do salto no modo de 32 bits. Isso é espaço suficiente para um salto curto para o destino real de 16 bits.

    Exemplo de NASM:

            bits 16
        jmp near found_16
        dw 0x0
found_16:
        bits 16
        jmp short main_16       ; must be exactly 2 bytes
found_32:       
        bits 32
        ;; up to 127 total bytes of code can go here
        ;; jump elsewhere if you need more space
        int 32
        hlt
main_16:
        bits 16
        ;; unlimited space here
        int 16
        hlt

    Saída de ndisasm -b16 foo.bin:

    00000000  E90200            jmp 0x5
00000003  0000              add [bx+si],al  ; not executed
00000005  EB03              jmp short 0xa
00000007  CD20              int 0x20        ; not executed
00000009  F4                hlt             ; not executed
0000000A  CD10              int 0x10
0000000C  F4                hlt

    Saída de ndisasm -b32 foo.bin:

    00000000  E902000000        jmp 0x7
00000005  EB03              jmp short 0xa   ; not executed
00000007  CD20              int 0x20
00000009  F4                hlt
0000000A  CD10              int 0x10        ; not executed
0000000C  F4                hlt             ; not executed

    Minha solução anterior, incluída para referência, era usar 0x0001como os 16 bits superiores do deslocamento, de modo que no modo de 32 bits, o alvo do salto seja 64K+2 bytes adiante. Isso requer ter pelo menos 64K+ de espaço de código disponível.

        bits 16
    jmp near do_16
next_insn_16:   
    dw 0x1
next_insn_32:   
do_16:
    int 16
    ;; The space between next_insn_32 and do_32
    ;; should equal 0x10000 + (do_16 - next_insn_16)
    db (0x10000 + (do_16 - next_insn_16) - ($ - next_insn_32)) dup 0x90
do_32:
    bits 32
    int 32

    Saída de ndisasm -b16 foo.bin:

    00000000  E90200            jmp 0x5
00000003  0100              add [bx+si],ax
00000005  CD10              int 0x10
00000007  90                nop
; ...

    Saída de ndisasm -b32 foo.bin:

    00000000  E902000100        jmp 0x10007
00000005  CD10              int 0x10
00000007  90                nop
; ...
00010006  90                nop
00010007  CD20              int 0x20
    • 6

  3. É muito incomum querer isso e querer preservar o estado arquitetônico original, incluindo FLAGS. Seu testmétodo de detecção de diferença de comprimento de instrução é o que eu usaria. Ou mov reg, imm16/32se você quiser preservar FLAGs, mas pode destruir sua escolha de registro.

    Se sua CPU suportar NOPs longos ( 0F 1F modrm), você pode usar isso em vez do opcode test eax, imm32/ imm16para evitar afetar até mesmo FLAGS. O suporte a NOPs longos está presente pelo menos desde o P6 (Pentium Pro / Pentium II), mas talvez não no P5 Pentium ou anterior; se você se importa com compatibilidade com hardware retro, você deve verificar novamente ou apenas evitar isso e usar a resposta do Jester.

    bits 32
nop dword [eax + 0x02EB0000]   ; 02 is the branch displacement for 16-bit mode
found32:
 int 32
found16:
 int 16

    Decodificado no modo de 16 bits:

    $ ndisasm -b16 polyglot
00000000  0F1F800000        nop word [bx+si+0x0]
00000005  EB02              jmp short 0x9
00000007  CD20              int 0x20
00000009  CD10              int 0x10

    Decodificado no modo de 32 bits:

    $ ndisasm -b32 polyglot
00000000  0F1F800000EB02    nop dword [eax+0x2eb0000]
00000007  CD20              int 0x20
00000009  CD10              int 0x10

    Mesmo código com o deslocamento do ramo calculado pelo montador

    Então você pode colocar até 127 bytes entre nop/ jmp shorte o found16:rótulo.

    bits 32
; nop dword [eax + 0x02EB0000]
 db 0x0f, 0x1f, 0x80, 0, 0  ; nop word/dword opcode, ModRM, and 2 bytes of displacement
 db 0xEB  ; jmp short opcode
 db found16 - ($+1)   ; relative to the end of the insn, but $ is the start of the line
found32:
 bits 32
 int 32
found16:
 bits 16
 int 16

    Semi-relacionado: https://codegolf.stackexchange.com/questions/139243/determine-your-languages-version/139717#139717 -
    11 bytes de código de máquina que define AL = 16, 32, ou 64(e destrói FLAGS, CX e R8B).

    • 3

relate perguntas