Hola


Seguramente que vengas de algun lenguaje de alto nivel, en realidad no hace falta usar ebp para hacer referencia a variable locales etc... Podrias usar incluso eax.

Se utiliza ebp por defecto ya que esa es su funcion, para tener la base por asi decirlo una referencia, piensa que cada vez que vayas colocando valores en la pila esta se restara en 4 bytes en tu caso.


Sobre las tres preguntas de abajo, pues todo depende de como estes administrando la pila y demas. Sobre el code pues no lo veo la verdad.

Para empezar que valor tiene la X?

Cargas en la pila los parametros, substraes 16 bytes en la pila con los push, luego el call son otros 4 bytes ya que cargas el offset que viene despues del call, para continuar la ejecucion del code despues de la llamada, serian 20 bytes.

Si te fijas cuando carges los valores de ebp en los registros de uso general, no seran los parametros correctos. El code lo veo mal planteado.

Cuando estas en la funcion cargas de nuevo en valor de ebp, y copias el valor de esp actual a ebp, la X la dejo.

La pila estara con 24 bytes para abajo, en realidad en el primer mov a eax, estas copiando el ret offset.

Un saludo.

P.D: Desde mi punto de vista veo una tonteria, que un programador de ASM, tenga que hacer el tipico esquema de pila como si estuviera en C, no quiero ofender a nadie pero lo veo de esa forma.

Ni que estuvieramos en C.

Creo que este tema se esta desviando y hay un malentendido.

Si las instrucciones trabajan con 16 bits, si las son, pero en realidad no son las originales de un 80x86, como dije anteriormente. Eso es lo que intento decir @EI y se malinterpreto, por eso le pregute para que pudiera aclarar el tema.

El prefijo 66h esta reservado, simplemente para que se sepa de que se esta trabajando con 16 bits, y el prefijo 48h para 64 bits pero no dejan de ser iguales todas simplemente que con prefijos:

mov rbx, rax      48 89 c3
mov ebx, eax      -- 89 c3
mov bx, ax        66 89 c3
 
test rbx, rax     48 85 d8
test ebx, eax     -- 85 d8
test bx, ax       66 85 d8

Supongo que esto ayudara, los opcodes no coinciden con los originales de un 80x86 puro, modo real.


Hay excepciones como por ejemplo xchg, tambien serian dos bytes en 64 bits pero con el prefijo indicado, con 16 igual con su prefijo, y por ultimo el 32 bits pues con el byte solo.

Fue un malentendido no se ofusquen de esa manera xD.

Un saludo.

Si claro, me explique mal, yo te entendi de que no se podia poner instrucciones en 16 bits, se utiliza el prefijo 66 con los 16 bits, no son los opcodes originales de 80x86, es como un x86 pero con el prefijo, pense de que Windows x64 no toleraba ese tipo de cosas, me extrañaba por eso pregunte.

Un saludo.

Depende del enfoque que le des, no tiene porque ser mas complicado/tedioso, creo a ver leido y recuerdo algo, una de las razones por el cambio a x64 fue para tener/administrar mas memoria RAM. Pero eso no viene al caso.

Tambien tienes registros de 128 bits, depende de tu CPU de 256 bits y hasta los hay ya de 512 bits en los Intel mas actuales, ojo son CPU's de 64 bits, pero con registros por asi decirlo especiales para realizar otro tipo de calculos. Y hay mas aun...

El programa sera todo lo tedioso que tu quieras.


Sobre el libro tienes chinchetas y demas, sera mejor que esperes a que alguien te recomiende algo enfocado a Windows, si no quieres que te recomiendo algo puro ASM, me mandarias a la playa...

Un saludo.

P.D: Tambien lo que quieras programar si es con API, no tiene porque suponerte mas problemas.

Si es lo mas aconsejable, tienes chinchetas en este mismo subforo hablando de libros, documentacion etc... Seguramente eres nuevo en esto, y habras acabado en un manual viejo, y de hay el code en 16 bits y con llamadas al DOS.

Ya te recomendaron una forma de empezar bien.


A lo mejor lo entendi mal @EI, pero enserio no se puede colocar code en 16 bits? No me refiero a las llamadas a DOS, si no a instrucciones y demas.

Un saludo.

Como te dijeron arriba, estas usando un esquema por asi decirlo obsoleto usas llamadas al viejo DOS, no estoy familiarizado con estos sistemas pero se ve a leguas de que no es logico programar en 16 bits y con llamadas a DOS.

16 bits para modo real, y si funciona en DosBox es porque lo esta emulando.


Depende de tu CPU podras trabajar en 32 bits o en 64 bits, si es x64 en ambos modos, son casi similares las dos arquitecturas, por ejemplo en x64 tienes registros adicionales de calculo general r8-r15, y la arquitectura es algo distinta pero para eso tienes que informarte mejor.

Un saludo.

Fijate antes de matar el proceso, con un simple:


Para saber la ruta del proceso, ejemplo de ps:


Bastaria con ejecutarlo desde esa direccion y ya tendrias el proceso activo de nuevo, y creando conflictos  .

Con ejecutar en la consola esa direccion ya lo vuelves a restablecer, aunque no hace falta que escribas la ruta entera, ya que esta en sbin.

Un saludo.

No se si ese tipo de error se corregia con algun parche, ya que hace tiempo que no estoy en esto, cambia el canal por el que quieres hacer el scan:


El 2 por ejemplo, te comento lo de los parches, por el canal -1 ya que este no existe y eso podria se un indicio de algun error de ese estilo.

Si tienes problemas con esa orden, recuerda hacer un down aplicar los cambios y por ultimo el up.

Un saludo.

Lo se, simplemente dije esto porque seguro que tiene una politica en ACCEPT, desde mi punto de vista y desde el de mucha gente, es mucho mejor tener una politica en DROP, para lo que el quiere hacer.

No colocar un DROP a 1.2.3.4 y luego crear otra con un ACCEPT y el puerto.

Solo dije una recomendacion ya se que el problema no va de eso, la proxima no digo nada.

Un saludo.

No es mejor, establecer una politica DROP en INPUT y luego dejar paso a las direcciones y puertos convenientes?

iptables -F
iptables -X
iptables -P INPUT DROP
 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 --syn -m state --state NEW -j ACCEPT

Un saludo.