Foro de elhacker.net

Hola


Es el sensor de temperatura.

Tengo el siguiente código:

movb $0x2e, %dl ; movw $0x228, %dx
in %dx, %eax

El resultado es un core dumped, que estoy haciendo mal?

Un saludo.

No tenes permisos, usa ioperm antes.

Además necesitarás darle permisos al proceso.

Saludos.

Estoy utilizando openbsd, la función ioperm solo esta disponible en la arquitectura alpha, hay otra función llamada i386_set_ioperm, pero nada para la amd64.

¿Qué puedo hacer?

Un saludo.

P.D: Probaré esa función en un i386 que tengo, ya os contaré como fue.

Cuando compilo me dice que no encuentra referencia ala función.


Incluyo todas la librerias y al compilar ese -li386.

¿Por qué root no puede acceder a los puertos directamente, sin utilizar esas funciones?

Un saludo.

Porque es parte de la proteccion de los niveles de ejecucion (Modo usuario y modo kernel)
Tendrias que darle permisos al proceso para poder usar los puertos I/O

Saludos

Gracias por las respuestas, pero no puedo hacer nada porque no dispongo de ioperm.

Un saludo.

Estoy intentando darle permisos desde ASM, leyendo los manuales me estoy enterando un poco de que va el tema, pero no hay manera de que funcione.

Tengo que tener CPL en 0 para poder acceder a la flag IOPL, con las instrucciones popf y iret, iret no funciona, y acceder ala base TSS que nose como acceder.

No encuentro ningun código ni nada, la verdad es que un ejemplo me ayudaría.
Por cierto estoy en long mode, el manual casi todo lo que dice es para virtual-8086.

Un saludo.

P.D: Perdón por el doble post.

lo primero, estas en modo kernel o ring0? si no lo estas, no vas a poder tocar nada de eso en asm

Saludos

No, estoy en mode long.

Por lo que dices tengo que entrar en modo kernel, pero como?
Al igual que in y out ese iret tampoco puedo ejecutarlo, sera por los permisos.

Pero ahora tambien tengo otra duda, como se accede a la base TSS?

Un saludo.

la direccion de los TSS se encuentra en la GDT que se obtiene con la instruccion SGDT.

Te explico, si estas arrancando bajo el SO. el procesador tiene varios modos de ejecucion a parte de los de modo largo y demas. Se les llama anillos de ejecucion. cuando arrancas estas en el anillo 0 (Modo Kernel) en el que puedes ejecutar todas las instrucciones que quieras. pero al cargar el SO carga las aplicaciones en el anillo 3 (Modo Usuario) que es el que menos permisos de ejecucion tiene

Saludos

Vale, no puedo ejecutar esas instrucciones porque al comparar CPL dice que estoy en el anillo 3.
Así que no puedo hacer nada?

Pero ensamblando el código y hacer un módulo y compilarlo junto al kernel, no tendría que dar problemas no?
No tendría que añadir nada más solo el in?

Un saludo.

¿Probaste el primer resultado de openbsd ioperm en Google?

http://wiki.gudinna.com/200

Ese código parece hacer referencia a llamadas específicas de la arquitectura i386; y él ya dijo que estaba usando un amd64 y no encontraba una equivalente para esta arquitectura.

Saludos.

P.D: Probaré esa función en un i386 que tengo, ya os contaré como fue.

Por cierto, si no hay equivalente por algo sera.

Exacto, hay esta el problema con la amd64.



Quiero implementarlo en ASM, no quiero funciones escritas en C.

Del manual de AMD:


Si estoy en modo usuario, anillo 3, CPL es mayor que IOPL y por eso no tengo permisos para acceder al puerto, para eso tengo que utilizar ese bitmap del que habla el manual?
Al estar en modo kernel anillo 0, CPL no sería mayor que IOPL y tendría acceso a los puertos sin la necesidad de chequear el bitmap permission?

Un saludo y gracias a todos por el interés.

Eso no representa ningun problema, desensambla el resultado en C y listo. Lo unico que hace es llamar a un servicio y seguramente es un int 0x80, un syscall/sysenter o lo que sea.


¿No hay otro servicio para obtener este dato? De ser asi yo que vos haria el parche, un modulo de modo Kernel no es un programa, es otro paradigma diferente.

Ya no puedo usar ioperm, fue eliminado de la arquitectura amd64.


Creo que no, si estoy en ring 3 tendré que acceder a ese bitmap tal y como dice el manual.

Un saludo.

Por logica no es una buena idea que programas de modo Usuario accedan al hardware directamente, eso se hacia en la epoca en que no habia multitarea y la sincronizacion no era lo que es ahora. Es una lastima que no hayas dicho que pretendes hacer EXACTAMENTE desde el primer mensaje del hilo. ¿Es una prueba? ¿Es solo por verlo funcionar? ¿O prentedes hacer un software que se ejecute en produccion? Desde que mencionaste el parche asumo que es lo primero y para eso hacerlo en x86 es suficiente ... aunque tal vez lo queres para tu propio uso nada mas ... vaya uno a saber.


Justamente si estas en modo Usuario no podes acceder, la gracia esta en que solo se puede acceder desde modo Kernel, asi es como se implementa la proteccion.

Es un poco de todo, el código del primer mensaje del hilo no es más que una prueba, queria obtener la temperatura sin tener que utilizar systat sensors ni ninguna función escrita en C o interrupción, un ASM puro.

Las funciones como scanf o commandos como systat sensors, en algún momento tendrán que comunicarse con los puertos i/o, bueno más bien el núcleo, scanf con el teclado que es el predeterminado y systat sensors con el sensor de temperatura, mi idea era hacer mis propias funciones a medida de mi avancé.

Pero no puedo utilizar ese ioperm no fue implementado en amd64, no lo quiero hacer en el x86, esa funcion si puede dar permisos y yo desde ASM no, pues vaya.


Si, tienes razón ya me he dado cuenta, ya se donde esta el I/O permission bitmap se encuentra en la TSS en el registro TR, devuelve 16 bytes, obtienes la dirección con la instrucción ltr:

pushq %rax
pushq %rax
movq %rsp, %rdi
ltr (%rdi)

Ahora en teoria tendría que tocar el bitmap y volver a cargarlo en el registro TR.
Pero el resultado es un Bus error (core dumped) que hace referencia a la dirección de ltr. Bueno el manual lo deja bien claro.


Así que la única forma de poder hacer lo que pretendo es en ring 0, o de un ioperm que no dispongo?

Un saludo.

Creo que la clave esta en que programar en assembly no implica que puedas acceder al hardware, un programa de modo Usuario en C puede hacer exactamente lo mismo que uno en assembly.

Y si, al final de cuentas para hacer algo asi correctamente tenes que hacerlo en modo Kernel, incluso aunque tuvieras disponible ioperm para mi no es mas que un hack.

Tenia pensado hacer algo en el núcleo, pero las pruebas pfff, bueno ya vere que pienso porque ahora mismo estoy en blanco.

Un saludo y gracias por el tiempo a todos.

Ya he realizado algunas pruebas, no fue en el núcleo si no en el boot del sistema.

Modifiqué el código del boot de esta forma.

asm ( "xorl %eax, %eax\n\t"
      "in $0x60, %eax\n\t"
      "movl %eax, 0x4b659" );

Luego los imprimo en pantalla con un printf, pero el carácter no es el correcto, si no tecleo nada es una z, si es una b = 0, c = . y  la h = #, no lo entiendo de el todo, pero el fragmento de código funciona bien pero no son los carácteres indicados.

Y sobre el puerto del sensor obtengo lo siguiente 0xe0000000, que no es el valor correcto. Bueno que opinan.

Un saludo.

P.D: Siento el doble post.

Aunque soy nuevo con el asm , si que conozco bien el lenguaje C. ¿ Intentas manejar el puerto paralelo , verdad ? El puerto paralelo no suele ser 278 decimal , sino 378 hexadecimal o 278 hexadecimal. La verdad que lo de los permisos aunque sea bueno para la seguridad es un horror para este tipo de cosas. Yo en mi caso con lo nuevo que soy con el asm creo un binario puro sin llamadas al sistema y lo emulo con qemu
creo que en asm existe una instruccion llamada out , para el tema de los puertos , echale un vistazo ;)

Eso pensé yo ayer despúes de un rato de a ver escrito el anterior mensaje, he estado mirando la tabla extendida ascii y los valores que muestra ese printf no aparecen.

1 = una cara sonriente, 2 = corazón, 3 = diamante, 4 = trébol, 5 = pica.

Conclusión: Pokerstarts  ::).

No ahora enserio, que tabla ascii utiliza y donde le puedo echar un ojo?


Curioso, que traduces el opcode a binario no?

incl %eax   ; 0xffc0 1111111111000000
syscall     ; 0x0f05 0000111100000101

Si, pero de momento no quiero enviar nada a los puertos.

Un saludo.

@cpu2, si lees del puerto del teclado directamente te devolverá un keycode, lógico que no te devuelva un código ASCII. Busca cómo puedes hacer esta conversión.

Saludos.

Exacto eso era Dani, he comparado los keycode y son los correctos.

Esta claro que el teclado tiene que ser uno de los dispositivos más simples que hay, sguiré investigando a ver si soy capaz de controlar dispositivos más complejos como puede ser el ethernet, pero eso ya es otra cuestión y tiene que ir en otro hilo.

Doy el tema por resuelto, gracias a todos por vuestro tiempo.

Un saludo.

P.D: Dani que paso con FreeBSD?

Lo estuve intentando, pero tuve un montón de problemas y no pude instalarlo :'(