Foro de elhacker.net

Buenas, la consulta es la siguiente: Que tan complicado puede ser escribir en el MBR del disco? Se puede solo con ensamblador o tiene que ser en Ring0?

Saludos!

Hay que partir de la siguiente base: bajo un S.O. moderno podes hacer lo mismo con ensamblador que con C/C++. Con la API de Windows podes hacerlo (ver CreateFile (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx), Physical Disks and Volumes).

Jamas pense que CreateFile podria hacer eso.. un poco inseguro por parte del equipo microsoft  :silbar:

Ahora tengo mas para estudiar.. Gracias!!!  ;-)

Necesitas privilegios de administrador (con los mismos podes cargar un modulo de modo Kernel).

Si, el tema de los privilegios me lo habia imaginado.. pero ta, en realidad no es lo que me preocupa..  aparte tambien sigo leyendo "programming the windows driver model"  :silbar:

La idea es leer un poco de ambas cosas, asi como para cambiar un poco el tema y no enloquecerme  :xD
Si surgen dudas, vuelvo a preguntar.. Gracias!!

De nada; no lo decia como problema sino que la barrera de seguridad es esa.

Tambien tienes la opcion en ASM de usar la direccion 0x7c00, en ring0 claro.

Cualquier cosa de estas que hagas en ring0, podrias compartirla si quieres.

Un saludo.

Si logro algo lo comparto, claro! Igual dudo que sea dentro de poco.. Aun no caigo del todo en el Ring0, ya tengo algunas dudas, pero voy a esperar a leer un poco mas, para no quedar tan molesto..

Por el momento estoy viendo CreateFile y DeviceIoControl (que me la vuelvo a cruzar tambien aca, digo porque tambien la he visto con el tema de los drivers.. )

Ahora me surge la duda con CreateFile si tengo que crear un dispositivo, abrirlo, o escribirle dentro un archivo, el problema es que siquiera se que rutina se ejecuta ahi dentro.. digamos que quiero empezar por escribirle en el MBR un llamado a un programa, asi lo ejecuto, pero no desde el registro de windows, por el momento voy a seguir buscando, se agradece cualquier fuente de estudio o dato importante  :silbar:

PD: Aca hay un ejemplo muy bueno para obtener informacion del disco:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363147(v=vs.85).aspx
Se puede ver como "llama" al disco para ser leido: #define wszDrive L"\\\\.\\PhysicalDrive0" y otras cositas importantes  ;-)

¿Vos probaste esto? No te olvides que toda la memoria que manejas directamente es virtual (esa que mencionas es una direccion fisica) y no estas trabajando en modo Real sino en modo protegido o largo. Mas alla de esto que es elemental la BIOS lee de un disco la MBR poniendola en MEMORIA RAM, modificar esa memoria no afecta a los datos del disco ...

Vaagish: mira que lo que hay en la MBR es codigo de 16 bits ... no esperes que sea capaz de llamar a la API de Windows para ejecutar un programa tuyo ... CreateFile con OPEN_EXISTING como dice la documentacion es lo que tenes que hacer.

http://wiki.osdev.org/MBR_%28x86%29

Buenas!!  ;D Bueno, esto se puso interesante, al momento de hacer la consulta, no tenia idea que escribir en el MBR tenia tanta similitud con los drivers, pero me vino como anillo al dedo.. y ahora si voy a consultar algunas cosas, ya que despejo dudas de drivers y del mbr...

Por lo que vengo entendiendo, para comunicarse con el disco, lo hace de igual manera que se comunica una aplicación con un driver, no? O es que en realidad estoy llamando a algún driver?
Una duda que tengo con los drivers es si siempre es necesario "hablar" de un dispositivo,, o sea,, los drivers solo sirven para la comunicación con hardware, o puedo ejecutar en un driver una rutina cualquiera? (Hacer alguna cuenta, inyectar algo, etc..)
Y volviendo al tema, hasta CreateFile entiendo, que puedo "comunicarme" con el dispositivo y obtener un handle al mismo.. ahora.. lo que me esta quemando es saber si tengo que escribir ahí dentro en alguna dirección especifica, y algo como que?? Puedo empezar a escribirle dentro cualquier cosa,, pero seguro que no va a arrancar mas el SO  :silbar:
Estaría bueno ver un código de MBR, pero no creo que sea posible eso..

Saludos y Gracias!!

No tiene ninguna similitud en realidad, es simplemente un enfoque errado al asunto. Si, obviamente que el driver del disco sera llamado para tus IRPs (lee sobre esto, es algo basico en WDM y te va a servir para entender un poco mas el asunto). Un modulo de modo Kernel trabaja al mismo nivel de privilegios que el S.O. y puede ejecutar rutinas no relacionadas con un dispositivo.

Despues de CreateFile podes usar WriteFile para escribir, aca lo que tenes que aprender primero es la API de Windows ...

¿Queres ver una MBR? Hace un programa con CreateFile y ReadFile  :silbar:

Genial! Capto.. voy a probar leer el mbr entonces, seria un buen comienzo para después escribirle.. (igual me queda la duda en que dirección, pero supongo me falta entender como funciona para eso..)
El IRP según leí, es una estructura que encapsula un "I/O request packet",, necesario para la comunicación de drivers (entre drivers solamente??)
Bueno, voy a poner manos a la obra! Tnks!

Me explique fatal, no escribi nunca tampoco tengo la necesidad de hacer algo asi, pero si la e leido en ring0 sin ningun tipo de funcion. Supongo que tambien se podra escribir en esas direcciones, pero lo que tu me dices es que luego se perderan los datos ya que es una direccion virtual.


Creo que si, porque no podrias escribir una rutina strlen o lo que sea, en un controlador. Algunos codigos que e leido son funciones que luego se comunican con los puertos I/O.

Un saludo.

Mas que una direccion es un offset donde queres leer y escribir, pensalo como un disco o archivo, no como memoria RAM. Por cierto, tenes que trabajar por sectores a ese nivel.


No, no se pierden por ser una direccion virtual, en este caso la que vos mencionas es una direccion fisica. El punto es que no esta mappeado a RAM el disco sino que la BIOS accedio a el en durante el boot, leyo ese sector y lo escribio en memoria. ¿Podes escribir en esa memoria? Si. ¿Tendra algun efecto en el disco? No, en lo absoulto. Si podes escribir en el disco como lo hace la BIOS (con ins y outs) pero no tiene sentido, para eso esta el S.O. y los drivers, para abstraer el hardware.


Si podes perfectamente, hasta el Kernel exporta strlen, aunque normalmente se trabaja en Unicode. No todos los modulos de modo Kernel son drivers (controladores de hardware), el ejemplo clasico es un filtro o un sistema de archivos (el NTFS no trabaja a nivel de sectores, para eso estara por debajo el driver de disco).

@cpu2: He vistov varios post tuyos refiendote a ASM como el unico capaz de hacerlo,  C/C++ se puede hacer el 95-98% de todo
lo que ASM puede hacer en cuanto a escribir codigo. Cuando se habla de este tipo de asuntos, no importa el lenguaje en el se haga,
este tema puede estar en la sección C/C++, Delphi, etc.
aunque generalmente se pone cuando se supone que el lenguaje que se esta usando es ASM como en este caso o a menos que te estes
refiriendo a modo real, aunque a pesar de eso, se podria tener un tema en la sección C/C++ acerca de modo real si tu compilador es capaz
de generar codigo para modo real. Simplemente estoy aclarando.
Además, Para escribir desde modo kernel se mapea la direccion fisica y se escribe.

#include <windows.h>
#include <winioctl.h>
#include <stdio.h>
#include <iostream>
using namespace std;
 
#define wszDrive L"\\\\.\\PhysicalDrive0"
#define BUFFERSIZE 8192
 
int wmain(int argc, wchar_t *argv[]){
 
	HANDLE hDevice = INVALID_HANDLE_VALUE;
	DWORD  dwBytesRead = 0;
    char   ReadBuffer[BUFFERSIZE] = {0};
	FILE *File;
 
	hDevice = CreateFileW(wszDrive, GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
 
	if (hDevice == INVALID_HANDLE_VALUE){
		return (FALSE);
	}
 
	ReadFile(hDevice, ReadBuffer, BUFFERSIZE-1, &dwBytesRead, NULL);
 
	File = fopen("c://MBR.txt","w");
	for(int i=0; i<=BUFFERSIZE-1; i++){
		fprintf(File, "%c", ReadBuffer[i]);
	}
 
	fclose(File);
	return 0;
}
 

MBR.txt

Bueno, algo estoy leyendo.. podria representarlo de una forma mas clara esto ?

Igual que un editor hex primero (0x%.2X) pero deberia tener codigo de 16 bits directamente igual asi que buscate un desensamblador para continuar.

El Ida sirve? Le puedo mandar "reensamblar" este txt?

¿No es mas rapido probar uno mismo? Como .com parece ir bien.

Si, pero hay algo que no estoy entendiendo, al fprintf le pongo este formato: "0x%.2X", eso me da un montón de hexadecimales,, y eso lo paso por el IDA (por ejemplo), para reensamblar el código, y así ver que hace el MBR en ensamblador, pero todo esto, es en 16 bits?

Y otra cosa,, si pongo el buffer de lectura como tamaño máximo 512 bytes, no lee nada.. no se supone estoy en el offset 0 del disco, donde hay código maquina? y son unos 446 bytes? :/

Seria muy bueno que leyeras el enlace ese ...



Si lees el tamaño del buffer sin restarle -1 podes leer un sector.

Y ya que estamos, con mi MBR.com en IDA, arrancamos con el enlace de arriba:

Typical MBR bootstrap code will do the following:
relocate itself away from the 0x7c00 physical address (using a memory copy, and usually a far jump)

seg000:0100                 public start
seg000:0100 start:
seg000:0100                 xor     ax, ax
seg000:0102                 mov     ss, ax
seg000:0104                 assume ss:seg000
seg000:0104                 mov     sp, 7C00h
seg000:0107                 mov     es, ax
seg000:0109                 assume es:seg000
seg000:0109                 mov     ds, ax
seg000:010B                 mov     si, 7C00h
seg000:010E                 mov     di, 600h
seg000:0111                 mov     cx, 200h
seg000:0114                 cld
seg000:0115                 rep movsb
seg000:0117                 push    ax
seg000:0118                 push    61Ch
seg000:011B                 retf

http://faydoc.tripod.com/cpu/movsb.htm
MOVSB    Move byte at address DS:SI to address ES:DI

61Ch es justamente el codigo que sigue a retf.

PD. Si, habria que ponerlo en 7C00 pero la verdad es que soy mas de WinDbg y no domino muy bien el IDA.

Gracias por tu tiempo Eternal! Voy a investigar mejor.. mi MBR.com sale malo.. algo estoy haciendo mal,, cuando llegue a casa veo que es..

Tnks again!

De nadas  ::)

Creo que solo le cambie esto:
#define BUFFERSIZE 512
ReadFile(hDevice, ReadBuffer, BUFFERSIZE, &dwBytesRead, NULL);

Pues es lo que pretendo en futuros codigos que escriba en ring0, nada de funciones ni de syscall, creare yo las funciones y las comunicaciones de hardware con in y out.


Si, pero con ASM siempre puedes optimizar al maximo el codigo, y como no saber 100% lo que estas haciendo.

@Vaagish

Bueno creo que con la explicacion de EI es bastante. Del 0x0 - 0x1ff que sumando el ultimo byte son 512 bytes, se cargan en la direccion 0x7c00 si creas algo en ring0 y recorres esta direccion veras que es el mismo codigo que aparecen en los offset del 0x0 - 0x1ff.

Si quieres algun fragmento de la MBR de OpenBSD dimelo, es algo distinta, menos los dos ultimos bytes que seran igual que tu MBR, 0x55,0xaa.

Un saludo.

Apuesto 95% de todas las ocasiones que uno programa si comparamos un codigo escrito en ensamblador por nosotros mismo con el de
uno generado por VC++ (ejemplo), el del compilador sera mucho más rapido y más en proyectos grandes donde se requiere de miles de lineas de ensamblador.
Toma en cuenta que el compilador variables locales y utiliza los registros tanto como se pueda, optimiza los jcc's, acceso de memoria,etc. Pero a pesar de eso me gustaria ver que grandes optimizaciones hay en tus programas escritos en ensamblador.

Y Quizas te referis a lo que uno lee acerca de escribir en ensamblador a como funcionan las cosas internamente pero eso no quiere decir
que escribir en C/C++ no sepas que es lo que estas haciendo.

-

Para saber el tamaño exacto de cada sector se parsea el MBR, asi como para obtener la informacion acerca de los cabezales,cilindros y demás informacion.
Aunque el tamaño es de 512 bytes por sector. Además, si se quiere cargar y depurar el MBR pues se puede usar IDA+bochs (http://www.hexblog.com/?p=103).
Ahi hay un proceso algo largo ya depuesta de saber como funciona simplemente se escribe el codigo del MBR el cual queres depurar.

Si se quiere depurar el proceso de arraque de un SO (MBR...etc), se puede usar IDA+GDB.
Se prepara la maquina virtual, se añade IDA al proceso de la maquina virtual, bp -> 0x7C00, a depurar.
Y el lo mismo si quieres depurar la BIOS/UEFI,VBR,IPL,etc

Cuidado con la sincronizacion si lo haces bajo un S.O. en funcionamiento.

Y vuelvo a coincidir con x64Core, parece haber grandes mitos con assembly y la realidad es que en la amplia mayoria de las veces ni siquiera es necesario.

@x64Core

Creo que malinterpretaste mi mensaje, yo no dije que un programador de C/C++ no supiera lo que esta haciendo, solo dije que con ASM te obliga a saber que hacen las instrucciones y los cambios internos en la maquina nada mas, los lenguajes de alto nivel y los libros de estos no me gustan, simplemente es una opinion y gusto personal  nada mas.

Y sobre el compilador y que te gustaria ver esas grandes optimizaciones que escribo, no se si eso ultimo era una ironia...
Podriamos seguir hablando por privado para no desviar este hilo.

@EI

Quiero saber mas sobre la sincronizacion, un ejemplo seria cuando la ethernet a establecido mas de una conexion, yo podria tener ese problema por lo que veo.

Un saludo.

Chicos, creo que pregunte por algo que todavía me faltaba mucho por investigar.. ustedes manejan los desensambladores, y el ensamblador bastante mejor que yo, creo que pise muy ondo con esta pregunta jeje, pero eso es bueno, aunque sea a golpes contra la pared voy a aprender..

Yo creo que en parte es así también, supongamos que tengo una aplicación en ASM, que yo se que NO puede fallar, entonces puedo omitir algunas cosas, sin comprometer la estabilidad del programa, claro.. y quizás ahorrar algunas instrucciones que el compilador no "debe" omitir,, me explico?

Esa es muy buena, pero voy a tener que aprender a depurar mejor..  :silbar:

Si, aunque sea para ir aprendiendo en general me sirve..  (0x55, 0xAA) "Valid bootsector" signature bytes ( Ajam, compatibilidad? )

EDITADO: Listo,, ahora si pude leer el mbr,, amigos, les presento al sector 0 de mi disco duro:
Ahora solo me falta aprender mucho...