Uf mira tu que suertudo. Ojala veas este mensaje y no te hayas decepcionado con el mio 

Eso podria funcionar. Gracias por tu respuesta

Ahora que citaste sobre x64... leo esto:


"The caller reserves space on the stack for arguments passed in registers."

Por que reservar en la pila argumentos que ya estas pasando en registros?


Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh... Ya ya ya... Es decir, los datos que se salvan en el prologo... Porque esta hablando de la pila... Ya entendi.


En este caso lo borroso no fue la palabra sino el contexto... Era lo que no estaba captando...

Una ultima pregunta al respecto de esto mismo...

Dice que, tambien, excepto las "Frame funcions". En la definicion que citaste:

Con "Requiere de un marco en la pila" se refiere a un espacio para argumentos pasados o a un espacio para variables locales?

Gracias por tu atencion.

---

Aprovechando la primera pregunta...
Y las estructuras? Como en x86?

Es decir que, traduciendo...

La pila sera siempre mantenida en un alineamiento de 16-bytes, excepto las instrucciones que momentaneamente pueden dejar la pila desalineada...?

"Excepto"

A que se refiere exactamente con "Excepto"?

OK, entiendo. Revise el programa que habia mencioado pero no te serviria de nada (es un equivalente a tu funcion cuenta_uno pero en vez de usar ciclos como en ella, yo use recursividad). Me parece que no difiere mucho en eficiencia...

Si se hiciera hardware especifico para esto, se podrian hacer muchas cosas con el, no solo en seguridad.

Suerte en las matematicas caprichosas 

Ah... No sabia que eso tenia nombre.

OK ya entiendo que es. Sin embargo no la relacion con el alineamiento. Citas:


"Except within the prolog"

A que se refiere con "within"? No se que es lo que esta "Dentro" del prologo.

Gracias por tu ayuda...

¿Que es el prologo? ¿El procedimiento en el que se esta ejecutando el procedimiento actual?

¿Y por que 16 precisamente...? Crei que eran cuatro (la "Palabra" de la mayoria de procesadores)

Frame functions... Eso no me suena de nada. Lo acabo de buscar y me aparece en contextos diferentes.

---

Respecto al syscall... Si, me lo imagine porque persegui la excepcion hasta kernel32 que es de donde venia

    entry:
    push dx ;;;;;;;;;;;;;
    mov qword ptr [rsp + 030h], 0
    mov dword ptr [rsp + 028h], 80
    mov dword ptr [rsp + 020h], 2  
    mov r9d, 0
    mov r8d, 0
    mov edx, 040000000h
    lea rcx, offset msg
    call CreateFileA
    int 3

Ufffffff......... Casi se me desvia la vista pensando en que DX es de 16 bits y no bytes. Aqui DX desalinea la pila por 2 bytes ¿No?

Es justo lo que intento hacer... Lo habia intentado hace tiempo pero ahora crei que lo podia lograr  

No se que es exactamente lo que esta desalineado porque el mismo codigo en posiciones dadas de memoria diferentes el codigo funciona y crea el archivo.

 ¿Es decir que RSP tiene que estar alineado? Eso no lo sabia   pero tiene sentido

---

J*******deeeeeerrrrrrrrr tienes razon...
Muchisimas gracias por tu ayuda. Que tonto 

Se que la memoria principal en la arquitectura x86 se alinea a 4 bytes, o al menos eso tengo entendido. ¿Sabes por que esto es asi precisamente en Windows y en donde podria conseguir mas informacion al respecto? Siento que me voy a equivocar con esto varias veces.

Gracias de antemano...
Buenas noches.

Hola,

Estoy jugando con un depurador y cuando intente hacer una llamada a CreateFileA, LastError se setea a ERROR_NOACCESS y LastStatus a STATUS_DATATYPE_MISALIGNMENT. No entiendo que significa...

Pense que se referia a que la referencia al nombre del archivo ("hello.txt") se encontraba en una posicion de memoria desalineada a 4 bytes, pero aun cuando la alinee a 4 bytes sigue retornando lo mismo.

Aqui esta el disassemble:


(el handle lo guardo en rbp-8)

Arquitectura x86_64

7FF7552110A4: direccion del nombre del archivo ("hello.txt")

Equivalente en C:

hFile=CreateFileA("hello.txt",
                      GENERIC_WRITE,
                      0,
                      NULL,
                      CREATE_ALWAYS,
                      FILE_ATTRIBUTE_NORMAL,
                      NULL);

Gracias...

Hay empresas valoradas en mucho dinero que han sufrido el mismo tipo de ataque y las únicas opciones que han tenido han sido: olvidarse de sus archivos y tener cuidado para la próxima o dar lo que piden.

Después de tanto tiempo no te recomiendo la segunda porque no sabes si aún estan activos… Pero bueno, depende de ti.

Lo mejor que puedes hacer es tener cuidado para la próxima. Si crees que un ejecutable está infectado no lo ejecutes