Duda sobre ensamblador (NASM), IDE SASM

[UsuarioZ]

Hola, estoy empezando con NASM y tengo que hacer un programa que multiplique dos registros, cuando lo estaba haciendo note que uno de los registros muestra un valor que no debería mostrar.

Código [Seleccionar] Expandir


%include "io.inc"

segment .data

L1 db 34h

section .text
global CMAIN
CMAIN:
   mov ebp, esp; for correct debugging
   
   
   mov eax, [L1]
   mov BYTE [ebx], 4
   
   PRINT_DEC 4, [ebx]
   NEWLINE
   
   mul BYTE [ebx]
   
   PRINT_DEC 4, eax
   
   xor eax, eax
   ret


Muestra: 65540 como el contenido de [ebx] pero hace bien la multiplicación de eax y [ebx], da como salida 208 (52*4).

¿Por qué muestra 65540?

Edito: Esto solamente pasa al depurar, pero al ejecutar si muestra cuatro en [ebx]

[Eternal Idol]

¿Que valor tiene EBX? Indefinido. ¿A donde apunta EBX? Nadie lo sabe.

Asumo que estas trabajando en Windows aunque no lo dijiste. Ni bien arranca el programa, mucho antes del entry point con el WinDbg puedo ver:

ntdll!LdrpDoDebuggerBreak+0x30:
00007ffe`c765119c cc              int     3
0:000> r ebx
ebx=272000
0:000> dd @ebx l1
00000000`00272000  00010000

Lo que sucede al parecer es que la direccion a la que apunta EBX contiene el valor 0x10000=65536, es un puntero a una estructura (el PEB, Process Environment Block) pero igual el planteamiento de usar un registro con un valor indefinido es un error de logica (podria apuntar a 0 u otra direccion invalida provocando una excepcion no controlada). De esos cuatro bytes solo modificas el primero haciendo que el valor cambie a 0x10004=65540, despues al solo usar el primero tambien en la multiplicacion el resultado es correcto.

Esta es la razon ultima por la cual al depurar ese valor es 0x10000  Justamente el tercer byte del PEB indica si un proceso esta siendo depurado o no BeingDebugged. No deberias escribir en el PEB ...

0:000> dt ntdll!_peb
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   +0x002 BeingDebugged    : UChar
   +0x003 BitField         : UChar
   +0x003 ImageUsesLargePages : Pos 0, 1 Bit
   +0x003 IsProtectedProcess : Pos 1, 1 Bit
   +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit
   +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit
   +0x003 IsPackagedProcess : Pos 4, 1 Bit
   +0x003 IsAppContainer   : Pos 5, 1 Bit
   +0x003 IsProtectedProcessLight : Pos 6, 1 Bit
   +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit

PD. EBX es un registro a preservar en STDCALL. Al final no estas multiplicando dos registros, estas multiplicando el registro EAX por un byte al que apunta el registro EBX.

Hay un subforo de ASM donde deberia ir esta pregunta: https://foro.elhacker.net/asm-b84.0/
Lo reportare y con suerte alguien lo movera.

[UsuarioZ]

¿Que valor tiene EBX? Indefinido. ¿A donde apunta EBX? Nadie lo sabe.

Asumo que estas trabajando en Windows aunque no lo dijiste. Ni bien arranca el programa, mucho antes del entry point con el WinDbg puedo ver:

ntdll!LdrpDoDebuggerBreak+0x30:
00007ffe`c765119c cc              int     3
0:000> r ebx
ebx=272000
0:000> dd @ebx l1
00000000`00272000  00010000

Lo que sucede al parecer es que la direccion a la que apunta EBX contiene el valor 0x10000=65536, es un puntero a una estructura (el PEB, Process Environment Block) pero igual el planteamiento de usar un registro con un valor indefinido es un error de logica (podria apuntar a 0 u otra direccion invalida provocando una excepcion no controlada). De esos cuatro bytes solo modificas el primero haciendo que el valor cambie a 0x10004=65540, despues al solo usar el primero tambien en la multiplicacion el resultado es correcto.

Esta es la razon ultima por la cual al depurar ese valor es 0x10000   Justamente el tercer byte del PEB indica si un proceso esta siendo depurado o no BeingDebugged. No deberias escribir en el PEB ...

0:000> dt ntdll!_peb
  +0x000 InheritedAddressSpace : UChar
  +0x001 ReadImageFileExecOptions : UChar
  +0x002 BeingDebugged    : UChar
  +0x003 BitField         : UChar
  +0x003 ImageUsesLargePages : Pos 0, 1 Bit
  +0x003 IsProtectedProcess : Pos 1, 1 Bit
  +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit
  +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit
  +0x003 IsPackagedProcess : Pos 4, 1 Bit
  +0x003 IsAppContainer   : Pos 5, 1 Bit
  +0x003 IsProtectedProcessLight : Pos 6, 1 Bit
  +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit

PD. EBX es un registro a preservar en STDCALL. Al final no estas multiplicando dos registros, estas multiplicando el registro EAX por un byte al que apunta el registro EBX.

Hay un subforo de ASM donde deberia ir esta pregunta: https://foro.elhacker.net/asm-b84.0/
Lo reportare y con suerte alguien lo movera.

Ahh ok, gracias, si estoy usando Windows, ahí lo probé con edx en lugar de ebx y parece estar funcionando bien, saludos.