arc-fl-código fuente 001 acceso desprotegido en windows xp

5/10/2018 aRC-FL-C digo Fuente 001 Acceso desprotegido en Windows XP - slidepdf.com

http://slidepdf.com/reader/full/arc-fl-codigo-fuente-001-acceso-desprotegido-en-windows-x

aRC-FL-Código Fuente 001 (22/03/2006)

Acceso desprotegido en

Windows XP(por Furious Logic [aRC])

Advertencia

ntes de poner en práctica el presente documento y cualquier material asociado al mismo, sea

éste de naturaleza tangible o intangible usted debe estar totalmente de acuerdo con todos los

términos y condiciones siguientes:

Del software

Cualquier software se proporciona tal como está, sin ninguna garantía expresa ni implícita de

ningún tipo.

aRC no garantiza ni asume responsabilidad alguna en cuanto a la integridad o exactitud de

cualquier información contenida en el software.

Ni los miembros ni los colaboradores ni los invitados aRC se hacen responsables por el uso que

se le pueda dar al software.

Al examinar, copiar, ejecutar, instalar o utilizar el software, el lector está aceptando su total

conformidad con todos los términos y condiciones enunciados.

Del documento

Al abrir este documento, el lector acepta incondicionalmente su total y exclusiva

responsabilidad legal, de acuerdo a las leyes vigentes en su país, por el uso de las técnicas

experimentales, educativas y/o de investigación aquí vertidas en materia de programación especializada

de computadoras.

En caso de discrepar con alguno de los puntos descritos, deberá eliminar inmediatamente el

presente documento y todo material asociado al mismo.

Agradecimientos

A Lotus Word Pro de Lotus Corporation, incluido en la suite de oficina Lotus Millenium 9.7.

A FontLab Studio 5.0 de Fontlab Ltd. por permitirnos asignar permiso completo a las fuentes

true type protegidas contra copia

A Acrobat 7.0 Professional de Adobe Systems Incorporated por su excelente resultado en la

creación del documento electrónico en formato PDF.

A Corel Corporation por su producto Corel Paint Shop X que nos ha sido imprescindible para la

generación de las pantallas que hemos incluido en este documento.

Objetivo

Demostrar la hipótesis de que la compatibilidad que las aplicaciones recientes de 32 bitsarrastran con programas de 16 bits, constituye un enorme forado en la seguridad de nuestros sistemas,

porque si bien es cierto que los programas de 32 bits son restringidos, los programas de 16 bits tienen

las puertas de acceso abiertas.

aRC-FL-Código Fuente 001 Acceso desprotegido en Windows XP – Página 1 de 11

aDVANCED rESEARCH cOMMUNITY (aRC) http://www.arc666.com

A



Introducción

A raíz de una pregunta realizada por guan en la lista CRACKSLATINOS, hemos seleccionado el

tema del acceso al BIOS por ser uno de los más grandes problemas que tienen los programadores. Sin

embargo, explicada la técnica, es muy fácil para el programador pensar en decenas de modificaciones

al código núcleo que permitan que un programa de 32 bits implemente uno de 16 bits para obtener

acceso a lo que hasta el momento le ha sido prohibido en windows familia NT (NT/2000/XP/2003).

Prueba 1 de acceso a memoria: Memoria BIOS

Adjuntamos el Ejemplo 001 \En Delphi\Ejem_001.dpr realizado bajo Delphi, un compilador de

32 bits. El ejemplo intenta acceder al área de memoria en donde comúnmente los fabricantes de

programas BIOS ubican la fecha del mismo. Código:

// Ejemplo 001 por Furious Logic [aRC]program Ejem_001;

uses

Windows, // para MessageBoxSysUtils; // para try-except

varFecha_BIOS : String;

begin try

Fecha_BIOS := String(PChar(Ptr($FFFF5))); except

Fecha_BIOS := 'No hay acceso a esta dirección de memoria' ; end;

MessageBox( 0, @Fecha_BIOS[1], 'Fecha del BIOS', MB_ICONINFORMATION );end.

Como se puede observar, este sencillo programa intenta leer la dirección de memoria que

guarda la fecha del BIOS: F000h:FFF5h, que convertida a dirección absoluta es:

dir_absoluta = segmento*10h + desplazamiento = F000h*10h + FFF5h = FFFF5h

Compilemos el programa Delphi utilizando compilar.bat o si lo prefiere, desde la misma

interfase gráfica Delphi.

Si ejecutamos el programa bajo Windows 9x/ME obtendremos acceso y el resultado será la

fecha del programa BIOS de la computadora: (no todos los fabricantes utilizan esta dirección de

memoria)

Prueba 1a: Resultado bajo Windows

Por el contrario, al ejecutarlo bajo Windows familia NT (NT/2000/XP/2003), el acceso directo a

todo el rango de memoria del BIOS está bloqueado (para programas de 32 bits) y obtenemos un

resultado diferente.





Prueba 1b: Resultado bajo Windows familia NT (NT/2000/XP/2003)

Si volvemos a ver el código fuente, notaremos que el bloque try-except ha capturado la

excepción EXCEPTION_ACCESS_VIOLATION que ocurre cuando se intenta leer o escribir en una dirección

virtual a la que no se tiene acceso (consultar la documentación Platform SDK ).

Prueba 2 de acceso a memoria: Memoria BIOS

Abrimos una consola de comandos e intentaremos realizar la misma prueba anterior, pero esta

vez manualmente con la ayuda del programa debug.exe, un programa depurador muy elemental, que se

incluye en todas las versiones Windows. En la consola de comandos cargaremos debug y dentro de él

escribiremos el comando d F000:FFF5 (d es la letra inicial de dump, "volcar" ). Para salir escribimos el

comando q (letra inicial del comando quit , "salir")

Si el sistema operativo es Windows 9x/ME el resultado es que tendremos acceso irrestricto a la

memoria BIOS de la computadora correspondiente a la fecha del mismo.

Prueba 2a: Resultado bajo Windows 9x/ME

Equivale al mismo resultado obtenido desde Delphi. Es decir, tenemos acceso a la dirección

de memoria del BIOS en donde está grabada la fecha.

No obstante, cuando realizamos el mismo procedimiento utilizando una plataforma Windows

familia NT (NT/2000/XP/2003), no ocurre la excepción EXCEPTION_ACCESS_VIOLATION, sino que

obtenemos acceso irrestricto al área de memoria en donde se guarda la fecha del BIOS.





Prueba 2b: Resultado bajo Windows familia NT (NT/2000/XP/2003)

¿Qué sucedió con la memoria protegida? No obtuvimos ningún aviso o advertencia alguna.

¿No hay protección alguna? Es un resultado muy interesante.

Hipótesis

Sabemos que Delphi es un programa de 32 bits.

Sabemos que Debug es un programa de consola de 16 bits.

Al parecer, el arrastrar compatibilidad con programas de 16 bits por parte de windows, crea un

hoyo, o más bien un forado del tamaño de una cantera, dentro de los sistemas operativos Windowsfamilia NT (NT/2000/XP/2003), lo que podría servir para cualquier propósito.

Entonces, ¿es probable que los programas de consola de 16 bits tengan las puertas abiertas,

en tanto que para los programas de 32 bits estas mismas puertas están cerradas? ¿O es que Microsoft

proporciona libre acceso exclusivamente al programa Debug y/o depuradores de su mismo género?

Experimento

Utilizando un compilador de 16 bits tal como Turbo C++ 1.0 o cualquier otro compilador de 16

bits, vamos a intentar acceder a la misma memoria del BIOS bajo Windows familia NT

(NT/2000/XP/2003). Adjuntamos el programa \En Turbo C++\Ejem_002.cpp, realizado bajo Turbo C++,

un compilador de 16 bits. Código:

// Ejemplo 002 por Furious Logic [aRC]#include "stdio.h"

typedef unsigned char byte;

int main (void){ byte far *mem_fecha_bios; char fecha_bios[9]; // 8 caracteres dd/mm/aa + NULL

mem_fecha_bios = (byte far *) 0xF000FFF5; for ( register byte i=0; i<8; i++ )

{ fecha_bios[i] = mem_fecha_bios[i];

}fecha_bios[8] = '\0'; printf( "%s", &fecha_bios ); return 0;}





En este caso estamos utilizando la dirección con segmento y desplazamiento unidos como

F000FFF5h, copiamos 8 caracteres desde esa dirección, agregamos un caracter nulo de terminación de

cadena e imprimimos el resultado copiado.

Experimento: Resultado bajo Windows familia NT (NT/2000/XP/2003)

Resulta innecesario probarlo bajo Windows 9x/ME porque bajo esa plataforma no hay

restricción alguna sea en 32 bits o en 16 bits.

ejem_002.exe es un programa de consola de 16 bits y no debemos confundirlo con los

programas de consola generados por Delphi, Dev-C++, HLA, Visual C++, C++Builder, entre otros.

Estos últimos crean programas de consola de 32 bits (formato ejecutable PE), en cambio ejem_002.exees un programa de consola en formato ejecutable D.O.S. compilado con Turbo C++.

Deducción y tesis 1

Hemos demostrado uno de los problemas que acarrea el mantener compatibilidad con

programas de 16 bits: el libre acceso a lo que pareciera protegido. Utilizando nuestras deducciones

como punto de partida, planteamos la idea de crear un programa de 32 bits que sea capaz de

aprovechar las facilidades que se le otorgan a los programas de 16 bits. Para lograrlo necesitaremos

utilizar ambos 2 compiladores, el de 16 bits y el de 32 bits.

Es posible que esté pensando en unir el código objeto .obj del compilador de 16 bits al

compilador de 32 bits, pero ello lo incorporará automáticamente en el código de 32 bits y nuevamente

el acceso está restringido.

Una solución práctica y fácil de implementar, es crear un programa de 32 bits que capture lasalida de un programa de consola de 16 bits. Es útil cuando necesitamos un resultado.

Utilizando Delphi uniremos nuestro programa de 16 bits con nuestro programa de 32 bits.

Adjuntamos el programa en \tesis 1\project1.dpr cuyo código es:

//... procedure TForm1.SpeedButton1Click(Sender: TObject); var

tmp : PChar;res : TResourceStream;sInfo : TStartupInfo;pInfo : TProcessInformation;h_salida : THandle;

begin // Extraemos el programa de 16 bits en el directorio temporalGetMem( tmp, MAX_PATH );GetTempPath( MAX_PATH, tmp );





res := TResourceStream.CreateFromID( HInstance, 100, RT_RCDATA );lstrcat( tmp, PChar('prueba.exe') );res.SaveToFile( tmp );res.Free;

// Ejecutamos con salida hacia un temporal y borramos el programaFillChar( sInfo, SizeOf(TStartupInfo), 0 );sInfo.cb := SizeOf( TStartupInfo );

sInfo.dwFlags := STARTF_USESHOWWINDOW;sInfo.wShowWindow := SW_HIDE;CreateProcess( nil, PChar(tmp + ' > salida'), nil, nil, false,

HIGH_PRIORITY_CLASS, nil, nil, sInfo, pInfo );WaitForSingleObject( pInfo.hProcess, INFINITE );CloseHandle( pInfo.hThread );CloseHandle( pInfo.hProcess );DeleteFile( tmp );

// Leemos la salidah_salida := FileOpen( 'salida', fmOpenRead );FileRead( h_salida, tmp^, 8 );FileClose( h_salida );

DeleteFile( 'salida' );Edit1.Text := Copy( tmp, 1, 8 );FreeMem( tmp );

end;//...

El programa muestra el siguiente formulario:

Y el código mostrado líneas arriba corresponde a la pulsación del botón Función 16 bits. Lo

que hemos hecho es agregar el programa que tiene acceso completo (el de 16 bits en Turbo C++),

como parte de los recursos del programa de 32 bits. Al presionar el botón, extraemos ese pequeño

programa hacia la ruta de archivos temporales de windows, lo ejecutamos y en seguida lo eliminamos.

El hecho particular es que estamos redirigiendo la salida por consola del programa de 16 bits hacia un

archivo que arbitrariamente llamamos 'salida'. El archivo 'salida' contiene la fecha del BIOSdevuelta por nuestro programa de 16 bits. Leemos el archivo 'salida', copiamos su contenido hacia el

campo de texto de nuestro formulario y borramos el archivo 'salida'.

Primero compile los recursos con compilar_recursos.bat y luego compile el código Delphi.

Como se puede apreciar, la técnica es muy sencilla y el poder de nuestro programa se basa

casi exclusivamente en el contenido del programa de 16 bits, el núcleo. En el núcleo podemos incluir

interrupciones, salida/entrada hacia puertos, acceso directo a disco, etc.

Tesis 2: TASM + MASM32

El rendimiento de la aplicación de 16 bits puede ser mejorado si programamos directamente en

ensamblador. En cambio, el rendimiento de la aplicación de 32 bits es de por sí óptimo debido a sureducido código. No obstante, también podríamos migrarla hacia lenguaje ensamblador.

Actualmente el programa de 16 bits ejem_002.exe pesa 8,870 bytes y el programa de 32 bits

project1.exe pesa 404,480 bytes (incluyendo en su sección recursos a ejem_002.exe).





TASM: El núcleo en 16 bits

Empecemos por reducir el tamaño del programa de 16 bits utilizando Turbo Assembler 5.0

(TASM) en lugar de Turbo C++. Adjuntamos el programa en \tesis 2\TASM\fec_bios.asm cuyo código

fuente es:

.model tiny

.stack 100h.datafecha db "00/00/00$"

.code

.8086inicio: mov ax,@data mov ds, ax mov es, ax and sp, not 3 call obtener_fecha_bios call mostrar mov ax, 4C00h int 21h

obtener_fecha_bios proc push es mov ax, 0F000h mov es, ax mov bp, 0FFF5h xor bx, bx

sig: mov al, es:[bp] mov fecha[bx], al inc bp inc bx cmp bx, 8

jb sig pop es retobtener_fecha_bios endp

mostrar proc mov dx, offset fecha mov ah, 9h int 21h retmostrar endp

end inicio

Compilamos con compilar.bat o si preferimos hacerlo manualmente utilizamos los comandos:

tasm fec_bios.asmetlink fec_bios.obje

No debemos confundir la pareja tasm/tlink con la pareja tasm32/tlink32, ya que estos últimos

son para compilar y obtener programas en 32 bits; en tanto que los primeros son para compilar y

generar un resultado ejecutable de 16 bits.

Al compilar habremos obtenido el archivo ejecutable fec_bios.exe cuyo peso es de 579 Bytes.

Es decir, hemos reducido el programa original en Turbo C++ ejem_002.exe de 8,870 Bytes a tan solo

un 6.5% de su tamaño original utilizando TASM.

El lector puede probar reemplazar Turbo C++ por cualquier otro compilador o intérprete de 16

bits que conozca bien para desarrollar su programa núcleo. En el caso particular de que utilice TurboPascal, asegúrese de que sea la versión 7.1 para evitar un bug que la versiones anteriores presentan

debido a la elevada velocidad de los microprocesadores actuales.





MASM32: La interfase

El programa interfase creado en Delphi para la tesis 1 será mejorado en cuanto a tamaño,

utilizando MASM32 8.2 SP2a en su lugar. Adjuntamos el programa en el directorio \tesis 2\MASM32\que para beneficio del lector está realizado bajo RadAsm 2.2.07. Código fuente central:

.elseif (uMsg==WM_COMMAND)

.if (wParam==BTN_FUNCION); Extraemos el programa de 16 bits en el directorio temporalinvoke FindResource,hInstance,200,RT_RCDATApush EAXinvoke LoadResource,hInstance,EAXinvoke LockResource,EAXmov res,EAXinvoke GetTempPath,MAX_PATH,addr tmpinvoke lstrcat,addr tmp,addr fecha_biosinvoke _lcreat,addr tmp,0mov h_archivo,EAXpop EAXinvoke SizeofResource,hInstance,EAXinvoke _lwrite,h_archivo,res,EAXinvoke _lclose,h_archivo

; Ejecutamos con salida hacia un temporal y borramos el programainvoke RtlZeroMemory,addr sInfo,sizeof STARTUPINFOmov sInfo.cb,sizeof STARTUPINFOmov sInfo.dwFlags,STARTF_USESHOWWINDOWmov sInfo.wShowWindow,SW_HIDEinvoke lstrcpy,addr aux,addr tmpinvoke lstrcat,addr aux,addr canalizarinvoke CreateProcess,NULL,addr aux,NULL,NULL,FALSE,

HIGH_PRIORITY_CLASS,NULL,NULL,addr sInfo,addr pInfoinvoke WaitForSingleObject,pInfo.hProcess,INFINITEinvoke CloseHandle,pInfo.hThread

invoke CloseHandle,pInfo.hProcessinvoke DeleteFile,addr tmp

; Leemos la salidainvoke RtlZeroMemory,addr tmp,sizeof STARTUPINFOinvoke _lopen,addr salida,OF_READmov h_salida,EAXinvoke _lread,h_salida,addr tmp,8invoke _lclose,h_salidainvoke DeleteFile,addr salidainvoke SendDlgItemMessage,hWin,EDT_FECHA,WM_SETTEXT,0,addr tmp

.endif

Con esta traducción del código de Delphi hacia MASM32 hemos obtenido un archivo

ejecutable interfase.exe de 6,144 Bytes (incluyendo el núcleo de 16 bits dentro de su sección

recursos) que al compararlo con project1.exe de 404,480 Bytes significa que hemos reducido su

tamaño al 1.5%





Tesis final: Mejorar el núcleo de 16 bits utilizando Debug

La tesis final que planteamos nos permitirá reducir los 579 Bytes del programa núcleo de 16

bits a tan solo 49 Bytes de código. Al mismo tiempo, modificaremos ligeramente el código en

MASM32 para evitar utilizar la sección recursos.

Debug: El núcleo de 16 bits

Si migramos nuestro código núcleo en TASM hacia Debug, obtendremos un reducido código

de tan solo 49 bytes. Adjuntamos el programa como \tesis final\nucleo.com escrito íntegramente

con Debug. La forma de codificarlo se muestra aquí:

El comando a proviene de assembly ("ensamblar") y se utiliza para ensamblar directamente.

El comando n de name ("nombre") y se emplea para asignarle un nombre al archivo.

El comando r proviene de registers ("registros") y se utiliza para ver/modificar los registros.

El comando w proviene de write ("escribir") y se utiliza para grabar nuestros cambios. El registro

CX deberá contener la cantidad de bytes a escribir en el archivo especificado por el comando n.

Cuando escribimos en el Debug estamos haciéndolo directamente en el archivo. Es decir, no

hay nada que compilar. Escribimos los mnemónicos y estos serán grabados en su formatohexadecimal como parte del archivo ejecutable que deberá ser .com obligatoriamente. En términos de

porcentajes, el núcleo anterior hecho en TASM ha sido reducido de 579 Bytes a tan solo 49 Bytes lo que

gracias al programa Debug se interpreta como una reducción a un 8.5% de su tamaño previo.





MASM32: Mejorar la interfase

Con MASM32 ya tenemos un código bastante reducido, pero intentaremos reducirlo un poco

más aplicando una modifición ligera para evitar la necesidad de agregar algo a la sección recursos.

Adjuntamos el programa en el directorio \tesis final\MASM32\interfase.asm cuyo contenido

principal es:

//...; Creamos el archivo a partir de una variableinvoke GetTempPath,MAX_PATH,addr tmpinvoke lstrcat,addr tmp,addr nucleoinvoke _lcreat,addr tmp,0mov h_archivo,EAXinvoke _lwrite,h_archivo,addr programa,49invoke _lclose,h_archivo

; Ejecutamos con salida hacia un temporal y borramos el programainvoke RtlZeroMemory,addr sInfo,sizeof STARTUPINFOmov sInfo.cb,sizeof STARTUPINFOmov sInfo.dwFlags,STARTF_USESHOWWINDOWmov sInfo.wShowWindow,SW_HIDEinvoke lstrcpy,addr aux,addr tmpinvoke lstrcat,addr aux,addr canalizarinvoke CreateProcess,NULL,addr aux,NULL,NULL,FALSE,

HIGH_PRIORITY_CLASS,NULL,NULL,addr sInfo,addr pInfoinvoke WaitForSingleObject,pInfo.hProcess,INFINITEinvoke CloseHandle,pInfo.hThreadinvoke CloseHandle,pInfo.hProcessinvoke DeleteFile,addr tmp

; Leemos la salidainvoke RtlZeroMemory,addr tmp,sizeof STARTUPINFOinvoke _lopen,addr salida,OF_READmov h_salida,EAX

invoke _lread,h_salida,addr tmp,8invoke _lclose,h_salidainvoke DeleteFile,addr salidainvoke SendDlgItemMessage,hWin,EDT_FECHA,WM_SETTEXT,0,addr tmp//...

Lo que hemos hecho es almacenar los 49 Bytes que componen el programa nucleo.com en una

variable. Es esta variable la que grabamos directamente en un archivo.

Compilamos y obtenermos un archivo ejecutable de 5,120 Bytes. Es decir 1 KiB, 1,024 Bytes,

menos que el programa anterior de 6,144 Bytes.

Conclusiones

Windows XP está totalmente desprotegido, señalándonos una puerta que podemos utilizar para

reingresar al mundo del acceso irrestricto a direcciones de memoria, acceso directo al hardware,

ejecución de interrupciones de software, etc.

Al mismo tiempo hemos aprendido como probar y optimizar la implementación de una técnica

determinada. Tomamos como punto de partida un compilador de alto nivel para probar una técnica sin

tener que preocuparnos demasiado por la sintaxis. Si la técnica funciona, migramos el código hacia un

compilador de nivel más bajo que nos permita mejorar su rendimiento (tamaño del ejecutable y

velocidad de respuesta). Esta técnica robustece nuestros conocimientos en todos los compiladores

involucrados.

Finalmente, hemos aprendido a integrar el contenido de un programa como parte de una

variable para ahorrar algunos bytes de tamaño que se agregarían si utilizamos la sección recursos.

La desventaja de esta técnica se encuentra en que los programas de 16 bits no son tan velocescomo los programas de 32 bits. Por lo tanto, si lo que buscamos es rendimiento para un concurso de

programación optimizada, aconsejamos crear un driver en lenguaje ensamblador, que por otra parte

requiere más líneas de código y mayores conocimientos que la solución rápida que hemos presentado.





Derechos de autor

El presente documento puede ser libremente distribuido únicamente con fines educativos,

experimentales y/o de investigación, siempre que se mantenga inalterado en su contenido y se

reconozca la autoría del mismo a Furious Logic [aRC].

Los nombres y/o marcas de productos utilizados en este documento son mencionados

únicamente con fines de identificación y son propiedad de sus respectivos creadores.

Las preguntas, consultas, sugerencias y correcciones son todas bienvenidas aunque lasrespuestas puedan tardar unos días en llegarles.

El autor puede ser contactado en:

Email: [email protected]

Furious Logicmiembro de

KopyLight (k) 2003,2006 LIMA - [email protected] aRC:Dalnet #aRC666IRC aRC:http://www.arc666.comWeb aRC:

"Porque buscamos la libertad que sólo en el conocimiento podemos encontrar"



arc-fl-código fuente 001 acceso desprotegido en windows xp

Documents