elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Tutorial básico de Quickjs


+  Foro de elhacker.net
|-+  Informática
| |-+  Software
| | |-+  Ejecutar programa antes que un SO.
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Ejecutar programa antes que un SO.  (Leído 3,647 veces)
777Rubenix777

Desconectado Desconectado

Mensajes: 150



Ver Perfil
Ejecutar programa antes que un SO.
« en: 15 Febrero 2011, 17:23 pm »

Hola a todos :D

¿Se puede ejecutar un programa antes que se cargue el SO?
Si, es decir, ejecutar una aplicación antes de que salga el logotipo(win, linux, apple).
Por si no me entienden lo que me gustaría es ejecutar una aplicacion nada más cargar los perifericos(Mouse & Keyboard).

Si alguien sabe como le estaria muy agradecido ;D un saludoo.

PD: Si saben que no hay nada que hacer avisen gracias :D


En línea

Saberuneko


Desconectado Desconectado

Mensajes: 2.182



Ver Perfil WWW
Re: Ejecutar programa antes que un SO.
« Respuesta #1 en: 16 Febrero 2011, 10:50 am »

En teoría, el que administra los programas que arrancan es el SO... Se pueden arrancar ciertas utilidades de boot con un liveCD (o bootCD), pendrive...

Pero si lo que buscas es cargar algo específico, no digo que sea imposible, pero lo veo muy difícil.


En línea

NikNitro!


Desconectado Desconectado

Mensajes: 1.309


Galletaaa!!!


Ver Perfil WWW
Re: Ejecutar programa antes que un SO.
« Respuesta #2 en: 16 Febrero 2011, 16:14 pm »

si ese programa llevara su sistema operativo integrado... puede xD
En línea

Saberuneko


Desconectado Desconectado

Mensajes: 2.182



Ver Perfil WWW
Re: Ejecutar programa antes que un SO.
« Respuesta #3 en: 16 Febrero 2011, 18:26 pm »

En ese caso sí... pero es que si el programa trae su propio SO integrado, ya estás arrancando un SO para arrancar el programa.
Por tanto, no resuelve el problema del todo, no?
En línea

SuperDraco


Desconectado Desconectado

Mensajes: 2.505


Crew Dragon


Ver Perfil
Re: Ejecutar programa antes que un SO.
« Respuesta #4 en: 16 Febrero 2011, 18:35 pm »

Una respuesta muy buena de Hystd, sacada de HackHispano... Bueno, de mi gran amigo Google... y en la primera página! ...¿No es increible?... Te invito a visitarlo a menudo :).

Edito: http://foro.hackhispano.com/showthread.php?t=31444

__________________________________________________________________________________


La respuesta a que si un programa se puede ejecutar en cualquier momento es SI. La respuesta a que si CUALQUIER programa puede ejecutarse en cualquier momento es NO.

Me explico. Tienes una máquina con procesador, y memoria (conectadas mediante un bus), pues si logras cargar el código de tu programa en memoria y posteriormente escribir en el registro EIP del procesador la dirección de comienzo de dicho código dentro de un segmento de código indicado por el registro CS del procesador, entonces ya lo tienes solucionado.

Pues bien, ¿quien hace todo esto? el sistema operativo, por supuesto, ya sea Windows, linux, mac, o pepitogrillo.

Evidentemente, esto es posible hacerlo manualmente... Cuando la máquina inicia, lo primero que ocurre es que el procesador accede a las posiciones de memoria ocupadas por la ROM, esto es, se carga el firmware de la BIOS. Ejecuta dicho programa que es un "mini sistema operativo", cuya función es ver qué cosas hay alrededor (periféricos, memoria principal, discos, etc...), una vez finalizado, el Firmware de la BIOS pasa el control a la unidad que tenga especificada en su orden de secuencia (por ejemplo 1ºHD, 2º CD-ROM, 3º Floppy, 4º USB), en ese ejemplo a tu disco duro.

Por tanto una primera opción para poder ejecutar un programa antes del inicio del sistema es configurar la BIOS para que arranque desde otro dispositivo que no sea el disco duro principal.

A continuación, en el caso normal (sin reconfigurar BIOS), el disco lee su primer sector (primeros 512 bytes), para mayor referencia continuar leyendo por aquí (en referencia a otro post de los mios buenos xD):

Cita:
En la arquitectura x86, cuando se inicia el sistema, el procesador accede a la memoria ROM (BIOS), para empezar a ejecutar instrucciones. Dichas instrucciones corresponden a un pequeño firmware, que permite tomar el control del sistema y hacer un breve chequeo de los componentes hardware. Si todo ha ido correctamente inicia el arranque desde la primera unidad física indicada por dicho programa en la secuencia de arranque. Si el intento es fallido, repite la operación con la segunda unidad de la lista y así hasta que encuentre una unidad arrancable.

Suponiendo que, como es lo normal, la unidad arrancable es el disco duro, entonces el programa de la BIOS accederá al dicho disco y procederá a leer su primer sector. (Primeros 512 bytes, que corresponden al Sector de Particiones, es decir al Sector 0, según direccionamiento LBA, o cilindro 0, cabeza 0, sector 1, según direccionamiento CHS).

Una vez leidos esos 512 bytes, se transfieren a la memoria RAM, y allí suceden varias cosas...

De esos 512 bytes, los primeros 446 bytes corresponden al Master Boot, que no es más que un programa el cual tomará el control después de haberlo hecho el programa de la BIOS (el firmware). Los siguientes 64 bytes corresponden a la tabla de particiones, que cometaré a continuación, y por último los 2 últimos bytes, que corresponden con la firma (siempre tienen el mismo valor).

Los primeros 446 bytes, son los que solían modificar los antiguos virus de MSDOS, para corromper el sistema y hacerlo no arrancable. Es decir el virus machacaba el código bueno del masterboot, por el suyo propio, cuya única misión era mostrar un mensajito en pantalla, y si sobraba espacio se ponían NOP's para completar los 446 bytes... (qué tiempos...xD).

Este detalle puede ser el que te esté provocando todos los problemas, !y no!, no quiere decir que tengas un virus, sino que algún/os byte/bytes de esos 446 se haya modificado, que puede ocurrir... no obstante continúa leyendo...

Los siguientes 64 bytes, que corresponden con la tabla de particiones, indican como estarán distribuidas las particiones. En esa tabla hay 4 entradas (4 filas) de 16 bytes cada una. Es por ello por lo que sólo se pueden tener 4 particiones primarias. Dependiendo del contenido de cada uno de esos 16 bytes harán que la partición signifique una cosa u otra. Por ejemplo el primer byte indica que si la partición es activa (valor 80h) o no (valor 00h), es decir, si en el byte 447 del sector de partición hay un 80, quiere decir que esa partición es arrancable, y si hay un 00 quiere decir que vaya a buscar los siguientes 16 bytes de la tabla de particiones para ver si hay un 80.

Esto supone otra hipótesis para tu problema, puede que de esos 64 bytes, tengas el primer byte de todas las entradas de la tabla a 00h. Y piénsalo, es muy facil modificar un 80h por un 00h, (80h=1000 0000, y 00h=0000 0000), sólo varía un bit!!! es muy fácil que se pueda modificar un bit, pero muy improbable que de todos los gigas que tenga el disco precisamente se tenga que cambiar ese... xD

Otra información adicional que aparece en las entradas de la tabla, (de las 4 entradas de 16 bytes) son: el número de sectores que tendrá dicha partición (corresponde con los últimos 4 bytes de esos 16). Los 4 bytes, a partir del octavo byte indican en dónde se encuentra el sector de arranque de dicha partición (dónde comienza el sistema operativo instalado), así como el cuarto byte indica el tipo de formato que tendrá la partición (FAT32, NTFS, EXT, SWAP, etc... o si será una partición extendida, la cual contendrá particiones lógicas).

Por ultimo, los dos últimos bytes del sector de partición, (los primeros 512 bytes del disco), corresponden a la firma, siempre tienen el mismo valor: AA55h

Y vale, la teoría está muy bien, y dirás ¿para qué me sirve a mi eso?, pues bien, si verdaderamente quieres diagnosticar el problema, lo mejor es leer esos 512 bytes, volcarlos a un fichero o en pantalla, y ponerte a contar bytes, como un verdadero l33t, y ver si esos bytes son correctos. De no serlos, puede proceder a modificarlos (en vez de leer esos 512 bytes, ahora los escribes xD).

Para poner un ejemplo, aquí muestro mi sector de partición, lo he hecho en mi equipo, sólo tiene una partición y corresponde a NTFS:

Cita:
33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04 38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5 83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88 4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B 80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83 46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0 B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56 00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC 43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56 0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C 8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A 56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD 13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60 6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A 01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C 44 63 DA 65 DA 65 00 00 80 01 01 00 07 FE FF FF 3F 00 00 00 82 E4 50 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Lo azul => master boot (primeros 446 bytes)
Lo verde => tabla de particiones (64 bytes)
Lo rojo => la firma (2 bytes).

Analicemos la tabla de particiones. Como dije, sólo tengo una partición y es con NTFS, por tanto de las 4 entradas de 16 bytes:

Cita:
80 01 01 00 07 FE FF FF 3F 00 00 00 82 E4 50 09
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
El 80 indica que es una partición arrancable (partición activa), y observa como en las demás permanece a 00h

Los tres siguientes bytes (01 01 00), indican el comienzo de la partición.
El siguiente, el cuarto byte que indica el formato, que en mi caso es 07h => NTFS.

Los tres siguientes (FE FF FF), indican el fin de la partición.

Los cuatro bytes siguientes, es decir los cuatro siguientes a partir del octavo (3F 00 00 00), indican la dirección de comienzo del sector de arranque de la partición.

Y por último, los cuatro últimos (82 E4 50 09), corresponden al número de sectores que tendrá partición. En concreto, al tener una sóla partición que ocupa el tamaño máximo del disco, tenemos que: 0950E482, (cuidado con la notación little endian), son: 156296322 sectores, si cada sector son 512 bytes, tenemos 80023716864 bytes, que traducidos a GigaBytes son 80 GB aproximadamente...

¿Cómo implementar esto? Pues bien, si es posible arrancar el sistema entonces es muy fácil hacerlo mediante la API de Windows. Pero en tu caso como no es posible hacerlo arrancable, lo único que queda son dos opciones:

Instalas un segundo disco duro, el cual debes ponerlo como maestro. Arrancas desde ese disco duro, y a través de la API leer del otro disco el primer sector (suponemos que en el disco con el que arrancas hay Windows). Si no lo hubiera tendrías que acceder a los registros de la controladora IDE (suponiendo que el disco es ATA y se conecta a través de la interfaz IDE) para especificar el disco, el cilindro, la cabeza, el sector, etc...

O bien, (es lo que me mola xD, pero requiere de un poco más de tiempo), hacer un programa en algún PC disponible, que llame a las interrupciones de la BIOS para el manejo del disco. Esto es, la INT 13h.

Optando por esta última opción, debes especificar:
1) en AH la función: un 2 para indicar que es una lectura.
2) en AL el número de sectores a leer: un 1 porque solo vas a leer un sector
3) en CX el cilindro/sector. (los bits 0-5 indican el número de sector, los bits 6-7 lo dos bits más significativos del cilindro, y bits 8-F los 8 bits menos significativos del cilindro). Por tanto debes especificar CX=01, (cilindro 0, sector 1).
4) en DH el número de la cabeza: cabeza 0, por tanto DH=0;
5) en ES:BX debes especificar el puntero al bufer donde se almacenarán los datos. Puedes poner un offset (desplazamiento cualquiera), dentro del espacio de memoria de tu código, y luego ir allí para recoger la información.
Bien, una vez leido el primer sector, ejecuta el código del MBR el cual indica a qué partición acceder para cargar el Sistema Operativo. Pues bien, si modificas el MBR a tu necesidad o para cumplir tus objetivos, podras bifurcar el flujo de ejecución del sistema a lo que hayas especificado. (Similar a lo de los virus que modiifican el MBR).

Ahora bien, si descartas la opción de modificar el MBR entonces debes esperar a que cargue el Ssitema Operativo. En el caso de Windows, se carga el kernel, e inmediatamente los controladores (ficheros .SYS y .DRV), indicados por el fichero System.ini. Tras la carga del Sistema Operativo, el sistema pasará a estar protegido. Dicho de otro modo, hasta antes del comienzco de la carga del sistema operativo, la CPU podía ejecutar cualquier instrucción (modo supervisor). Tras la carga, la CPU pasa a modo usuario.

Entonces, otra posible opción sería crear un driver (.SYS), añadirlo al fichero system.ini, y hacer que el sistema operativo, cuando cargara, ejecutara dicho código del driver.

Si descartáramos esta posibilidad, entonces continuamos... Tras cargar los controladores, Windows, da paso a la ejecución del modo usuario, es decir, carga toda su API (ficheros .DLL), en memoria, para dar comienzo a la interfaz gráfica. Estos ficheros contienen las rutinas de ejecución del sistema que permiten todo el funcionamiento de Windows. Desde que te logeas, hasta que apagas, pasando por poder mover el ratón, pulsar el teclado, visualizar ventanas, gestionar procesos, administrar memoria, paginación, registro, y por suspuesto, posibilidad de interactuar con los drivers cargados (evidentemente ). Las rutinas, funciones y procedimientos de dichos ficheros (de los .DLL), son llamados desde programas que se ejecutan desde el modo usuario.

En cuanto a la gestión del entorno gráfico de Windows, tenemos el ejemplo claro de Explorer.exe el cual utiliza la mayor parte de las funciones contenidas en user32.dll.

Pues bien, supuesto el caso de que hemos llegado a este punto y aun no nos hemos decidido a "colar" nuestro programa, lo que nos queda es ayudarnos del propio Sistema operativo para ello. La opción más rápida es el registro (regedit.exe), en concreto:

Cita:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run
Creamos una clave con la ruta a nuestro programa. Dicho programa debe poseer la estructura de un fichero ejecutable Windows (.EXE). Una vez el sistema inicie, nuestro programa será ejecutado.

En este caso, para conseguir lo que propones sobre:
Cita:
si esque tego un programa de ventas y solo quiero que se bea el programa
y no windows xp que entre automaticamente al programa sin ber rastros de windows
Tu programa debe cerrar EXPLORER.EXE, si es a eso a lo que te refieres. Recuerda que un proceso de usuario (tu programa), puede cerrar o hacer lo que quiera con otro proceso de usuario (en este caso EXPLORER.EXE).

No obstante, eso de "no dejar rastros de Windows", como verás, a estas alturas de la lectura de este post, es incoherente: "Un programa con estructura de Windows, que se ejecuta sin la estructura Windows"... aunque no veas los iconos, ventanas, y demás, seguirás teniendo dos modos "usuario y kernel", seguirás administrando la memoria tal como lo hace Windows, seguirás paginando como lo hace Windows, y seguirás en WINDOWS..., vamos que el control lo sigue teniendo Windows...

De todas maneras, y suponiendo que al final te decantarás por esta opción, por su simmplicidad es que, cargues tu programa al inicio del sistema bajo la clave antes mencionada, tu programa debe cerrar explorer.exe, y llamar a la API de user32.dll que te convenga, y para una mayor protección para conseguir tus propósitos es que deshabilites la pulsación de CTRL+ALT+SUPR para que ningún "listillo" vuelva a ejecutar EXPLORER.EXE.

Resumiendo, si ejecutas un programa antes de la carga de cualquier sistema operativo (como un bootloader, por ejemplo), este debe contener las instrucciones máquinas (ejecutables por el procesador), tal cual, sin poseer estructura, ni cabeceras ni similares. Puedes hacerlo con lenguaje ensamblador para ello, ya que los entornos normales conocidos, generan el ejecutable en función del Sistema operativo sobre el que se va a ejecutar. Por ejemplo Visual Studio, Visual Basic, Delphi, etc... para Windows, o Kylix, gcc, etc.. para Linux.

Si, por contra, optas por esperar a la carga del Sistema operativo, el cual dominará la gestión de toda la máquina, con sus protecciones, limitaciones, etc... entonces puedes usar cualquier entorno de programación.

Un saludo.
« Última modificación: 16 Febrero 2011, 18:42 pm por pitoloko » En línea

No he vuelto, solo estoy de paso.
777Rubenix777

Desconectado Desconectado

Mensajes: 150



Ver Perfil
Re: Ejecutar programa antes que un SO.
« Respuesta #5 en: 17 Febrero 2011, 12:09 pm »

En teoría, el que administra los programas que arrancan es el SO... Se pueden arrancar ciertas utilidades de boot con un liveCD (o bootCD), pendrive...

Pero si lo que buscas es cargar algo específico, no digo que sea imposible, pero lo veo muy difícil.
En ese caso sí... pero es que si el programa trae su propio SO integrado, ya estás arrancando un SO para arrancar el programa.
Por tanto, no resuelve el problema del todo, no?

En verdad no lo resuelve del todo pero puede valer.. xD

Una respuesta muy buena de Hystd, sacada de HackHispano... Bueno, de mi gran amigo Google... y en la primera página! ...¿No es increible?... Te invito a visitarlo a menudo :).

Edito: http://foro.hackhispano.com/showthread.php?t=31444

__________________________________________________________________________________

O bien, (es lo que me mola xD, pero requiere de un poco más de tiempo), hacer un programa en algún PC disponible, que llame a las interrupciones de la BIOS para el manejo del disco. Esto es, la INT 13h.

Optando por esta última opción, debes especificar:
1) en AH la función: un 2 para indicar que es una lectura.
2) en AL el número de sectores a leer: un 1 porque solo vas a leer un sector
3) en CX el cilindro/sector. (los bits 0-5 indican el número de sector, los bits 6-7 lo dos bits más significativos del cilindro, y bits 8-F los 8 bits menos significativos del cilindro). Por tanto debes especificar CX=01, (cilindro 0, sector 1).
4) en DH el número de la cabeza: cabeza 0, por tanto DH=0;
5) en ES:BX debes especificar el puntero al bufer donde se almacenarán los datos. Puedes poner un offset (desplazamiento cualquiera), dentro del espacio de memoria de tu código, y luego ir allí para recoger la información.
Bien, una vez leido el primer sector, ejecuta el código del MBR el cual indica a qué partición acceder para cargar el Sistema Operativo. Pues bien, si modificas el MBR a tu necesidad o para cumplir tus objetivos, podras bifurcar el flujo de ejecución del sistema a lo que hayas especificado. (Similar a lo de los virus que modiifican el MBR).

Esto me gustaria pero lo veo muy complicado.. lo del autorun ya lo conocia pero es una chapuza.. xD bueno.. muchas gracias por la informacion :D :xD
En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
como ejecutar programa en memoria sin ejecutar el archivo « 1 2 »
Programación Visual Basic
Sai-To 13 10,965 Último mensaje 25 Mayo 2008, 18:14 pm
por Sai-To
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines