Crónica de medio fracaso, u otra forma de instalar windows 7 desde el pendrive.

“Cuando no se tienen recursos, más vale tener opciones” 

(Proverbio árabe que acabo de inventar)

Este blog empezó llamándose “Informática del subdesarrollo”, para tiempo después pasar a ser “Subdesarrollados”, principalmente porque no me gusta la palabra “informática”. Como sea, siempre se trató de divertirse con poca plata y algo de tiempo: cosas que se pueden hacer con un pendrive y material que se descarga desde la red, distribuciones de linux que aparte de ser libres eran free as in free beer; circuitos armados con tres leds y anécdotas sin copyright.

Y en lo técnico, se trató de buscar herramientas novedosas, divertidas y sencillas para hacer las cosas que tenemos que hacer todos (o casi todos) los días. Novedosas, sencillas, divertidas y agregaría: redundantes.
Porque está muy bien conseguir la killer app (o killer tool) que nos soluciona siempre-de-la-misma-manera un problema X, ahorrándonos tiempo (y plata, porque "el tiempo..." etc); pero es todavía mejor tener a mano un par de no tan bonitas y no tan sencillas herramientas para el momento en que nuestra killer app (o killer tool) hace agua y nos deja a gamba.

En eso andaba pensando esta mañana (mentira, pero como enganche sirve) cuando me encontré en la necesidad de instalar un windows 7 cuya iso yo tenía en mi pendrive en una máquina que no tenía sistema. 

Lo que tenía: 

• Mi pendrive de trabajo: 16gb (2gb libres)

En el pendrive: 

• Una iso de recuperación de w7. (DaRT70.X86.iso , pero sirve cualquiera)  
• Una iso del hirens 10 (y las wintools del 15 descomprimidas afuera)
• Una iso de windows7 lite x86 (de 700 mb)
• El super iso booter.
• El WinNTSetup 2.3
• El NT6.x fast installer

Lo que NO tenía: 

• Un CD o DVD virgen.
• Un pendrive que pudiera borrar. 
• Una máquina extra.

Mi idea original era bootear con el hirens 10, correr el WinNTSetup, apuntarlo a la iso (que la versión 2.3 clama poder abrir) y dedicarme a tomar mate mientras corría la instalación. Pero a veces las cosas no son tan fáciles en la realidad como en nuestra imaginación, y me topé con que el minixp no veia el disco de la máquina host. Malditos controladores sata. Reinicié con DART70x86, pude ver los discos pero al intentar cargar la iso me choqué conque el soporte no funcionaba tan bien como decía, o no era tan intuitivo como yo pensaba.
Entonces voy a la carpeta de wintools del hirens 15 (el menú no arrancó por falta de vb6) y con 7zip extraigo el contenido en una carpeta graciosamente llamada W7. Trato de correr el WinNTSetup apuntando al archivo install.wim, me acepta y reconoce la fuente, seteo los discos, le doy play y ni bien empieza se quiebra con un error “1” que no me deja salida.
Terco, intento con el NT6.x fast installer, un instalador que es un cmd que por lo que dice extrae el install.wim a la fuerza e instala el bootsector a lo guapo. Me desayuno en ese momento que la descarga no incluye (por cuestiones de copyright) un ejecutable llamado imagex.exe que pertenece a WAIK, y se me trunca la carrera.

Derrotado, sintiéndome del siglo pasado voy a buscar un CD para grabar la imágen desde el minixp con algún programita que seguro tengo por ahí (InfraRecorder, o BurnISO), cuando me acuerdo de Grub4dos.

Copio a la raíz del pendrive el contenido de la carpeta W7 (el archivo bootmgr y las carpetas boot y sources), reinicio, voy a la cosola de grub4dos y escribo:

find --set-root --ignore-floppies /bootmgr

boot

Pongo “instalar”, y preparo mate.

Rescate (mas que) emotivo del XP

Hace aproximadamente 10 años quien les escribe instalaba por primera vez windows XP en un AMD duron 800 con 128 Mb de RAM, y comprobaba que los muchachos de Microsoft habían hecho un buen laburo: un windows 2000 con mejor aspecto, más fácil de usar, con mejores drivers y compatibilidad hacia atrás con DOS y todos sus desktop managers (lease windows ME, 98 y 95). Un par de service packs más tarde el XP se convirtió en un tanque, un sistema liviano para cualquier máquina que todavía funcione, que se colgaba mucho menos de lo que hubiera querido Stallman.
Cinco años después del lanzamiento del XP, la gente de Redmond iba a lanzar una campaña que elevaría su viejo sistema al rango de leyenda: la estrategia se llamó windows Vista, y fue tan efectiva que la gente estuvo más que contenta de comprar un sistema con 6 años de antigüedad con tal de evitarlo. El lanzamiento del SP3 le dio larga vida al rey, que para la salida de windows seven en 2009 ya llevaba 7 años como mejor opción.

El windows 7 ha demostrado ser un buen sistema, que consume mucho más espacio de disco que el XP (pero a quién le importa), que funciona bien con los 2Gb de ram mínimos que cualquier pc debería traer instalados (vender una pc con seven y 1Gb de ram debería considerarse estafa) y soporta los 8 Gb que van a ser necesarios dentro de un par de años. Y tiene una bonita cantidad de drivers, y se ve bien. Ya son pocos los clientes que piden un downgrade, los que se resisten a aprender a usar la barra de inicio, los que conservan una impresora incompatible. El futuro llegó hace rato, e instalar xp en un Intel i7 es como ponerle nafta común a un Lamborghini.

Pero los años de reinado del XP dejan sus huellas, y nuestros clientes conservan en sus máquinas agonizantes sistemas comerciales, de contabilidad, aplicaciones de cálculo y demases hechas a medida por desarrolladores inubicables, empresas que cerraron o sacaron versiones que no permiten importar los datos del 2004. Programas que se pagaron a precio de oro, llaves de puerto paralelo cuyos controladores no distinguen un W7x64 de un Ubuntu 12.

Aquí es cuando la habilidad del técnico se pone a prueba. Habilidad para convencer al cliente de que a pesar de haberse comprado una máquina nueva tiene que seguir arrastrando un sistema operativo que tiene diez años, o para montar un xp en una máquina virtual modesta adentro de la bestia y explicarle al cliente (aunque sea mínimamente) el concepto de tener su sistema en una máquina dentro de una máquina.

Desde hace un tiempo esa viene siendo mi opción preferida, y descubrí que los clientes son menos refractarios a aceptar la idea de lo que yo suponía. En parte se debe también a que VMware player hace un muy buen trabajo integrando el mouse de forma transparente, y permitiendo un manejo simple de los dispositivos.

Ahora: instalar un XP dentro de una máquina virtual supone duplicar el trabajo de instalación (un poco menos que eso, claro: no hacen falta los programas y los drivers), o haberse tomado el trabajo de pasar por VMware converter un sistema físico para llevar la máquina virtual en el pendrive. Es un trabajo que muchos de mis lectores ya hicieron. Pero estoy seguro de que algunos están todavía en veremos, por lo que, como premio por haberse aguantado este choclo autoreferente que no le hace honor al resto del blog (esto es un nuevo comienzo, entiendan), les voy a dejar justo aca una descarga de 200Mb que tiene un XP SP2 limpio de cargo y culpa (aunque todavía sin bautizar), y listo para cargar en el player. Si lo usan, recuerden agradecer a su bloguero amigo, preferentemente cobrando por la instalación lo que vale una hora de trabajo extra y gastándosela en cervezas o picadas a mi mala salud.

Por si no se vio: Link de descarga.

Enjoy!

PD: Este post fue inspirado por este sistema (Sivet), su llave de puerto paralelo y su última versión made in 2005.
PD2: Supongan los que bajaron el archivo que el dueño de la máquina que virtualizé se llama Roberto García.
PD3: Avisen si el link se cae! (Es posible, tengo la sensación de que el tema de licencias es un poco mas delicado con esto que con el grub4dos).
PD4: Feliz día a todos los maestros!
PD5: A la memoria de Salvador Allende.
PD6: I'll be back.

Dragones.

En la película “Cómo entrenar a tu Dragón” hay un momento en que al protagonista le muestran un libro que tiene un extenso catálogo de dragones, con su peligrosidad, formas de ataque y modo de combatir. Nuestro héroe no tarda en comprobar que el libro es inútil porque a pesar de contener mucha información acerca de cada dragón, a la hora de enumerar métodos de defensa todos decían lo mismo: “Muy peligroso. Tirar a matar”.

Los que hacemos soporte técnico conocemos la sensación. Quizás de un modo menos épico pero no sin entusiasmo, nos enfrentamos con distintos tipos de alimañas, entre las que cuentan los virus. Y no han sido pocas las veces en las que, buscando algun método eficiente para deshacernos de alguno, nos topamos con el famoso “tirar a matar”.

La mayor parte de las páginas con información acerca de virus y métodos de remoción son como estas: Ejemplo1 , ejemplo2 .

Estos son los primeros resultados de una búsqueda acerca de la dupla de virus mgking.exe/arking.exe, conocidos y molestos virus de pendrive. Podemos notar a simple vista que las páginas están hechas con una plantilla, en la que se han rellenado los datos de los archivos y claves de registro que crea el virus, y el modo en que los antivirus lo llaman.

Y es completamente entendible, claro. Los virus mutan mucho mas que los dragones, y mantener un archivo extenso es una tarea que reite de Sísifo. Los pobres vendedores de lo que sea que vendan estas páginas tienen demasiado trabajo persiguiendo las búsquedas mas realizadas, tratando de recibir visitas a costa de agrandar su catálogo de páginas todas-con-la-misma-recomendación.

Debo decir que al menos sus sugerencias son interesantes (sobre todo en el primer link) : arranque en modo seguro, borre tales archivos, trate de matar los procesos, borre las claves de registro, use process explorer, pase el ccleaner. Eso es tener suerte en la búsqueda, porque lo mas usual es “Instale nuestro antivirus y nuestro antimalware, haga varios escaneos completos del sistema”, proceso que por supuesto lleva varias veces mas tiempo que reinstalar todo lo que hay en la máquina, y es recomendable únicamente en el caso de tener que perder mucho tiempo pero que parezca que estamos haciendo algo: “estoy pasando el antivirus”.

En el ABC de cualquier técnico/soporte que no resuelva todo reinstalando o tirando una imagen están todos estos métodos, junto con otros que los complementan o los completan: Borrar temporales y archivos sospechosos desde un miniXP, deshabilitar entradas con autoruns, restaurar asociaciones con FixEXE o habilitar la visualizacion de ocultos con RRT.

Estas acciones son similares para todos los virus que nos encontramos, y configuran el mínimo a probar antes de tomar la decisión de reinstalar.
Ya todos sabemos que no tiene sentido mirar el manual.

PD: un apunte sobre mgking/arking: una vez que entran en el sistema, el antivirus ya no los detecta, pero si captura los autorun.inf, b9v.exe y demases que estos amigos colocan en TODAS las unidades, sean discos físicos o de red. Por eso empecé a extender el consejo acerca de la carpeta \autorun.inf a las unidades de disco comunes. Si les interesa, aca les dejo un script para limpiar/crear los autorun.inf despues de deshabilitar el virus:

cls
echo Borrando/creando autoruns.
for %%d in ( C D E F G H I J K L M N O P Q R S T U V W X Y Z ) do (
if exist %%d:\autorun.inf attrib -s -h -r %%d:\autorun.inf
if exist %%d:\autorun.inf del /A:S %%d:\autorun.*
mkdir %%d:\autorun.inf
)
echo Presione cualquier tecla para salir...
pause > nul

Disfruten!

El regreso del freak: The Super Duper ISO booter

Desde el comienzo de los tiempos el ser humano buscó un modo de bootear una imagen iso desde un pendrive de forma automágica, es decir, sin tocar un solo archivo de configuracion, por el solo expediente de colocarla en una carpeta. Siglos han pasado desde entonces, y para que semejante hazaña sea posible fue necesario que primero se inventaran (o descubrieran según seamos aristotélicos o platónicos) los pulgares oponibles, las herramientas, el lenguaje, la rueda, el fuego, la imprenta, la electricidad, las computadoras, los cds, las imagenes ISO, los puertos usb, los discos extraibles, syslinux, grub4dos y grub2.

A nosotros, seres humanos que vivimos una época en la que todo lo anterior existe, nos queda entonces la obligación de disfrutar de nuestros inpulsos frikis haciendo uso de las herramientas a nuestro alcance.

En eso me encontraba cuando empece a investigar el entonces nuevo grub2, descubriendo que incorpora un interprete LUA, que hasta donde pude ver (tengo la referencia del lenguaje para leer, solo me da paja hacerlo) es un lenguaje de programación similar a C y que puede usarse como lenguaje scripting. Y entonces me surgió la curiosidad de saber si bootmanager+scripting me podían dar el famoso boot automático de isos por el que varios lectores preguntaron al comienzo de las andadas de este, su blog amigo, cuando incursionabamos en pendrives booteables. Y resultó que sí.

Y el pueblo: ¿Quiere saber de que se trata?

O mejor dicho: si no quiere saberlo, puede saltar directamente a la sección "Todo masticado", en la que encontrara una bonita descarga con, justamente, todo masticado.

Para los que quieran saber de que se trata, les cuento: Se trata de una coleccion de utilidades, scripts archivos de configuración robados de otros proyectos y colocados todos juntos para que funcione. Para dar crédito a los autores originales vos a explicar como funciona.

El script de instalacion es una modificacion (y semi traduccion) del que se encuentra al final de la pagina del hirens para bootear por usb, y se encarga de copiar los archivos grub.exe, syslinux.conf, menu.lst, sgd.iso y m.lua a la raíz del pendrive. Luego crea el directorio /iso y mueve sgd.iso ahi, y al final instala el sector de arranque de syslinux en el pendrive. Con esto tenemos todo instalado.

Al bootear, el pendrive lee el sector de arranque y carga el syslinux. Este lee el archivo de configuración syslinux.cfg y carga el grub4dos (grub.exe modificado para que no saltee el floppy) , que lee el menu.lst y carga la iso del Super Grub Disk (modificada para agregarle la entrada del Super Duper Iso Booter) , que lee el script m.lua (que es modificacion del script bootiso.lua que trae el SGD2) y nos muestra un menú con todas las iso que haya en el directorio /iso. Cuando seleccionamos una entrada del menú, grub2 vuelve a cargar grub4dos, con parametros de configuración que mapean la iso y bootean desde el sector de arranque.

Y por qué es tan complicado?

Es complicado porque al hacerlo me encontré con algunos problemas:

- No instalo directamente grub4dos como arranque porque syslinux es mas compatible con maquinas viejas, y de todos modos uso grub.exe después.
- No puedo bootear la iso desde syslinux porque no lo soporta.
- No pude editar el floppy de SGD2 porque no pude montarlo en linux o en windows. Si alguien quiere hacerlo y poner el grub.cfg de la iso lo espero en mediafire.
- No puedo generar el menú desde grub4dos porque no soporta scripts.
- No puedo bootear las iso desde grub2 porque no soporta chainload, y eso nos deja sin bootear muchas cosas (el hirens, por ejemplo. O el silverdisk).

Verán que son muchos items, poniendo solo los que se me ocurrieron y no pude resolver. Por otra parte, la ventaja del método actual es que nos quedan a la vista un syslinux.cfg y un menu.lst para agregarle lo que queramos!

Un poco de código:

CorraMe.bat

@echo off
echo.
set udrv=
for %%x in (syslinux.cfg syslinux.exe grub.exe menu.lst sgd.iso m.lua) do if

not exist files\%%x goto error
set /p udrv=Ingrese la letra del disco USB (Por ejemplo F:)
if "%udrv%"=="" goto nodrv
echo.
echo !! CUIDADO !!
echo.
echo ESTO INSTALARA SYSLINUX EN %udrv%
echo PRESIONE CUALQUIER TECLA PARA CONTINUAR (O CIERRE ESTA VENTANA)
pause
echo Copiando archivos al pendrive ...
for %%x in (syslinux.cfg grub.exe menu.lst sgd.iso m.lua) do echo copy /y

files\%%x %udrv%\ && copy /y files\%%x %udrv%\
for %%x in (syslinux.cfg grub.exe menu.lst sgd.iso m.lua) do if not exist

%udrv%\%%x goto errcopy
mkdir %udrv%\iso
move %udrv%\sgd.iso %udrv%\iso

echo Instalando el boot en el USB...
echo files\syslinux.exe -ma %udrv% -f
files\syslinux.exe -ma %udrv%
if errorlevel 0 goto ok
echo syslinux.exe error
pause
goto end
:ok
echo done
pause
goto end
:nodrv
echo nothing is selected
pause
goto end
:errcopy
echo Error while copying
pause
goto end
:error
echo file(s) missing (syslinux.cfg syslinux.exe grub.exe menu.lst sgd.iso

m.lua)
pause
:end


Este es el "instalador", modificacion del que viene en el paquete de syslinux del hirens. Primero chequea que existan los archivos necesarios en /files, después pide la letra de la unidad y copia los archivos. crea el directorio /iso y mueve ahi el sgd.iso .Despues escribe el boot en el mbr y sale, Lo que sigue son los mensajes de error que nos muestra si algo falla. Verán que no están traducidos, con lo que notarán mi lazyness.

Syslinux.cfg

default /grub.exe

Simple, carga el grub.

Menu.lst

timeout 2
default 0

title SuperGrubDisk ISO
find --set-root /iso/sgd.iso
map /iso/sgd.iso (0xff) || map --mem /iso/sgd.iso (0xff)
map --hook
root (0xff)
chainloader (0xff)

Encuentra la iso del super grub disk, la mapea directamente o en memoria y bootea desde ahi. Esta forma de cargar las iso en grub4dos está robada del proyecto winsetupfromusb.

Grub.cfg (dentro de la iso)

...
#Super iso booter
menuentry "Super duper iso booter" {
search -f --set /m.lua
configfile /m.lua
}
...

Agregado la entrada del menu. Search es el reemplazo de find (diferencia entre grub4dos y grub2), y se pasa como archivo de configuracion el script que genera el menu

m.lua

#!lua

isofolder = "/iso"

function enum_file (name)
local title = string.match (name, "(.*)%.[iI][sS][oO]")

if (title) then
local source = "search -f --set /grub.exe \n linux /grub.exe --config-file=\"root (hd0,0); map /iso/" .. name .." (0xff) || map --mem /iso/" .. name .. " (0xff); map --hook; root (0xff); chainloader (0xff)\" "

grub.add_menu (source, title)
print ("titulo: "..title.. " ruta: "..source)
end
end

grub.enum_file (enum_file, isofolder)

Este es el mas robado (lo que implica que no hubiera podido programarlo yo sin leer muuuucho mas)! Para mas datos, está robado específicamente del script listisos.lua de esta pagina de ubuntuforums. Crea una funcion que por cada archivo terminado en .iso (mayuscula o minuscula) agrega una entrada del menu con los parametros definidos en source y title. Yo solo le cambié la llamada a la funcion bootiso.lua por la llamada directa a grub4dos con los parametros de arranque.

Y listo!

Todo masticado!


Acá tienen la descarga del instalador en rar. Se descomprime en cualquier lado (el escritorio, por ejemplo, aunque yo lo dejaría en el pendrive por si hay que restaurar) y al ejecutar CorraMe.bat pregunta la letra de la unidad y se instala ahí.
Para agregar una iso al menu solo hay que copiarla en la carpeta /iso en el pendrive.


Notas:

- Cuidado! Si hay otro sector de arranque, syslinux.cfg o menu.lst en la raiz del pendrive hagan un backup antes de instalar, porque el CorraMe.bat sobreescribe sin preguntar.
- El grub4dos intenta mapear la imagen directamente, y si falla lo hace en memoria. Esto último sucede cuando la imagen iso esta fragmentada en el pendrive, y aparte de ser lento consume memoria, por lo que si vamos a tirar isos de 700Mb en la carpeta, es recomendable wincontig.
- Desde seven o vista, hay instrucciones en la última posdata!
- Las isos booteadas no siempre andan.
- Puede fallar!



PD: para toquetear los archivos de configuracion y probar, les recomiendo este probador de boot basado en qemu (robado del paquete UBCD4Win) .

PD2: (Arreglado. No les debo nada) .Les debo los links a las paginas de hirens, grub4dos, grub2, syslinux, lua, wincontig, UBCD4WIN y mil mas. Capaz que mas tarde, es decir dentro de seis meses, con mi ritmo de publicación.

PD3: Soy lento para despedirme y escribo muchas posdatas. Pero si alguien prueba esto deje un comentario, para saber que no soy el único friki al que le interesa esto. O que si.

PD5: Enjoy!

PD4: En W7 o Vista tenemos una problema: necesitamos ser administradores para poder escribir el mbr, pero el sistema cambia el path a \windows\system32 cuando ponemos el modo administrador, con lo que el batch no encuentra los archivos. Para solucionar eso debemos:
1) Abrir una consola en modo administrador. Eso se hace buscando en el menu "cmd", y después con boton derecho sobre el ícono "Ejecutar como administrador".
2) Cambiar el path al lugar donde tenemos el archivo CorraMe.bat. En mi pendrive, el comando es cd "F:\boot tools\SuperIsoBooter"
3) Ejecutar el batch a mano desde la consola.
4) Debería funcionar!
Of course, si alguien tiene una solucion mas elegante, lo espero en los comentarios y será agradecido. No eternamente, pero agradecido.

Obsesiones surtidas: Mejorando la compatibilidad de Grub4dos en el pendrive

Grub4dos es una herramienta increíble: puede bootear directamente linux, xp, vista y seven, puede montar diskettes o imagenes iso, y tiene una linea de comandos poderosa, que nos permite buscar las opciones corectas en vivo.

En mi pendrive de laburo el grub4dos se encarga de bootear un par de mini XP, el Hirens 10, la consola de recuperacion de XP, las ISO de Acronis TrueImage y Puppy 4.21 y el Slitaz, una mini distro que es rápida y maneja bien NTFS.

Lamentablemente para nosotros, los habitantes del subdesarrollo, algunas máquinas de las que son mayoría por estos lares (maquinas con DDR y sin SATA, sin muchas opciones para bootear desde usb) tienen problemas para llegar al menú.

PROBLEMAS Y SOLUCIONES

El primer problema es en el booteo. El síntoma es que al arrancar desde el pendrive el sistema se queda colgado con un cursor parpadeante en la esquina superior izquierda, y es incapaz de cargar el grub. La solución que nos propone la gente del Hirens es cargar grub.exe desde syslinux, que es un arranque mucho más amigable. El archivo que descargamos de la página de hirens no hace mas que instalar el syslinux, copiar a la raiz del pen el grub.exe y el archivo syslinux.cfg, que contiene solo la sentencia “default /grub.exe”. Elegante y conciso. Y funciona. Por supuesto, nosotros no podemos dejar tranquilo ese syslinux.cfg, pero eso es de otros posts que ya pasaron!

El otro problema, con el que me encuentro mas veces de las que quisiera, nos deja en la línea de comandos de grub sin mostrarnos nuestro menú. Esto sucede porque la bios esta reconociendo el pendrive como un diskette, y nuestro grub4dos esta seteado explícitamente para no buscar en floppies.

Cómo sabemos si es esa la causa? Buscando nuestro menu.lst desde la linea de comandos con find /menu.lst el comando nos devuelve un bonito (fd0).

La solución más directa es hacer a mano lo que el grub no quizo hacer automáticamente.

Tipeamos:

find --set-root /menu.lst
configfile /menu.lst

Y tendremos nuestro menú. Hay que tener en cuenta que estamos booteando con fd0 como root, lo cual no suele gustarle al hirens, pero los chainloaders del xp o las iso no tienen mayores problemas para arrancar.

Pero... para los enfermos como yo existe una solucion más permanente, que nos evita el delay de cargar a mano el menú. Podemos modificar las opciones de arranque del grub4dos.

Parte de la magia de este bootloader está en su capacidad de cargar automáticamente el menu.lst. Si lo arrancamos en una máquina lenta, y tocamos las teclas del cursor al iniciar, podemos entrar en un menú intermedio, cuyas entradas buscan al archivo menu.lst en el directorio raiz /, en /grub y en /boot/grub. Al editar estas entradas vemos al culpable de nuestras desdichas. La línea que busca el menu.lst es así:
find --set-root --ignore-floppies --ignore-cd /menu.lst

y la siguiente

configfile /menu.lst

Bien! Ahora sólo nos queda sacar la parte de “ignore floppies” del menú intermedio, para que el boot funcione de primera.

Pero dónde está ese menú? Esta es la parte divertida del procedimiento. El menú está en el archivo grub.exe (y en el grldr, pero como usamos syslinux ese no nos importa), y podemos editarlo directamente con un editor hexadecimal.

Voy a usar el TinyHexer, que es el que llevo en el pendrive. No por nada en particular.

El truco es buscar la cadena de texto “--ignore-floppies --ignore-cd /menu.lst” en el archivo, seleccionar la parte de “--ignore-floppies“ y eliminarla. Acá una muestra de cómo se ve en mi editor:



That´s all folks!

PD: Para los que quieren todo cocinado, aca les dejo mis Grub.exe y grldr modificados.

PD2: Calmadas nuestras obsesiones, ya podemos seguir viendo los capitulos de Fringe que nos quedan. Hasta luego!

Cómo preparar un XP instalable desde USB en 3 pasos / Destripando WinSetupFromUSB

Los muchachos de MSFN y Boot-Land nos simplifican la vida poniendo en una gui sencilla de usar todo el conocimiento de sus foros sobre instalacion de xp desde pendrive, bla, bla, bla, etc.

Y que hay que hacer?

1) Bájese el WinSetupFromUSB desde acá e instálelo en su máquina.

2) Dígale al programita dónde está su cd de instalacion de windows y su pendrive/disco externo. Apriete GO.

3) Mientras espera, ponga un hielo grande en un vaso. Agregue una medida de Fernet Branca y cuatro o cinco de Coca Cola. Tómeselo y disfrute mientras espera.

Listo!

Y basta de intro y how-to. Pasemos a lo que nos interesa: Cómo lo hacen?

Básicamente, WinSetupFromUSB es una interfaz que maneja otras herramientas que ya conocemos. Espiando en su directorio de instalacion encontramos cosas que ya vimos (y llevamos en el pendrive por las dudas): grub4dos, syslinux, pe2usb, HP format tool, y otras que conocimos por bootland como RMprepUSB. También hay scripts y programas para preparar la instalación, y por lo que veo algún driver que reemplaza al que debíamos conseguir del SP1 del windows server 2003.

Así que cuando preparamos la instalación el programa se encarga de modificar lo necesario y copiar todo al pendrive, y además instala un boot basado en grub4dos, que divide la instalación en dos partes, arrancando la primera desde setupldr.bin (as usual) y la segunda desde el mismo pendrive corriendo ntldr, como vemos en su entrada del menú:

title First part of Windows XP Professional setup

root (hd0,0)

chainloader (hd0,0)/$WIN_NT$.~BT/SETUPLDR.BIN

savedefault 1

title Second part of Windows XP Professional setup

root (hd0,0)

chainloader (hd0,0)/NTLDR

savedefault

Todo muy lindo hasta acá. Ahora las malas noticias: La instalación sólo funciona tal como viene en mothers nuevas (que por lo menos reconozcan el pen como (hd0,0) y no como (fd0) ) y si bien dice soportar desatendidos, es necesario que hayan sido armados dejando habilitada la opcion para instalar desde DOS (que no está en nuestros desatendidos favoritos, como el winchiquito o las versiones updateadas del UE7). Como trampa, es posible engañar al instalador para que nos permita crear el usb copiando de un cd de windows original los archivos faltantes (todos los que empiezan con "winnt"), pero aun si esto pudiera hacernos pasar de la pantalla de carga de drivers (que yo no pasé) de todos modos creo que sería un dolor de cabeza: los desatendidos mas populares son muy dependientes del cd. Quizás los técnicos debamos esperar a que, ahora que existe la herramienta, algun amigo como BJ se ponga a armar el paquete con los scripts actualizados para pendrive.

Y entonces... por que tanto entusiasmo?

Bueno; para mi lo mejor que tiene este programa es algo que ya alabé en el instalador de Geexbox, y antes en unetbootin: por medio de una interfaz intuitiva, nos deja con configuraciones que funcionan para hacer las cosas que queremos hacer. Una mirada al menu.lst, por ejemplo, nos revela el modo más práctico de bootear desde una imagen iso que tenemos en el pen:

title Start AcronisMedia.iso from partition 0

root (hd0,0)

map /AcronisMedia.iso (0xff) || map --mem /AcronisMedia.iso (0xff)

map --hook

root (0xff)

configfile /grub4dos.lst || chainloader (0xff)

Esto es para mi como tener a Jaclaz (famoso en los foros que mas me interesan, y primero en la lista de agradecimientos) dictándome los comandos!

Vemos que mapean la iso a la dirección (0xff), y en la misma línea hacen lo mismo pero montándola en memoria (supongo que esa doble barra significa que hacen una cosa o la otra, segun cual funcione. Quizas sea mucho suponer). Después cambian la raiz a la iso montada, y al final se tiran a cargar bien una configfile de grub o directamente intentan cargar el bootsector con chainloader. Esta segunda opción es la que funciona con esta iso en particular (el cd de recuperacion de Acronis True Image). También funca para el silverdisk, y se me hace que entre las dos cubren gran parte de los booteables. Por suspuesto, también podemos hurgar un poco en la iso y escribir la linea correcta, que para algo venimos practicando con grub4dos!

Y no los molesto más. Si les interesa comentar lo que pudieron hacer arrancar (y cómo) los voy agregando al post. Por mi parte, pienso probar hirens, puppy y slitaz para empezar, ni bien tenga algo de tiempo para algo de diversion geek.

Mientras tanto, disfruten!

(Y si no pueden invitar, al menos cuenten).

Virus de pendrive... en pendrives, donde va a ser!

Hace algunos años, los tecnicos de pc tuvimos que empezar a lidiar con los virus. En un principio se trataba de cadenas de código autoreplicante, que se anexaban a los ejecutables y los "infectaban". En esa época los antivirus se encargaban de escanear y limpiar los ejecutables y, cuando las rutinas de deteccion descubrían el virus antes de que estuviera lista la rutina de desinfección, colocar el archivo en cuarentena esperando la cura.

Los mecanismos de infeccion eran azarosos para los que no andabamos por BBSs: el único modo era contagiarnos mediante algun diskette con archivos infectados, o un virus del sector de arranque. Cuando se popularizaron las grabadoras, quizas alguno haya llegado por un cd. Después vinieron los virus de macros en documentos de office, y luego la fauna de troyanos que conocemos ahora.

A mi siempre me interesaron los aspectos de ingeniería social en la distribución, es decir, aquellos que en vez de explotar vulnerabilidades del sistema se encargaban de explotar debilidades del usuario. Para nombrar un par, los archivos de extensión doble del tipo "miramisfotosentopless.jpg.scr" en el msn, y las páginas de falsos escaneos de disco como la que vimos aca me parecen ideas geniales.

Hace algún tiempo (dos o tres años aca en argentina, o desde que empece el blog) se popularizaron los discos extraibles en cualquiera de sus formas: pendrives, mp3, tarjetas de memoria etc, y los hacedores de virus observaron ese crecimiento con los ojitos brillantes por la emoción. Entonces se dedicaron a crear virus de pendrive.

Desafortunadamente para ellos, los diseñadores de pendrives y sistemas operativos ya no son como entonces: los discos extraibles no tienen autorun automático como los cds, y no se puede infectar el bootsector como en los diskettes. Es decir, que no hay manera de que el pendrive con virus infecte a la máquina sin intervención del usuario. Con solo enchufarlo no basta.

Y como cualquiera sospecharía de un archivo llamado "miraestevideocachondo.wmv.exe" en la raíz del disco (bueno, no cualquiera, seguro que algunos le harían doble click si se encontraran el pendrive tirado, pero digo cualquiera con dos dedos de frente, se entiende...), nuestros amigos tuvieron que buscar otras formas, principalmente de ingeniería social, para que el usuario ejecute el virus por si mismo en el uso normal del pen.

Detallo aqui los dos métodos que vi "in the field", con la esperanza de que mis lectores-técnicos de campo agreguen las joyas que hayan encontrado:

1) El viejo autorun.inf: Como ya vimos en este blog, es posible crear un autorun para asignar resultados específicos a las acciones sobre el pendrive. Así, un doble click al disco extraible desde Mi PC ejecuta sin preguntar el archivo que se indique en la linea open= o shellexecute= , mientras que si hacemos boton derecho sobre la unidad tendremos un menú que podemos personalizar a gusto. También se ejecuta la linea open= si aceptamos la accion predeterminada en el cuadro de dialogo de reproduccion automágica.

Usando este mecanismo, muchos virus de pendrive (la mayoría) se copian a la raiz del disco, y crean un autorun.inf oculto, que ejecuta el virus ante cualquier acción del desprevenido usuario. De estos vi también algunos que crearon una carpeta (oculta también) que pretendía pasar como una de sistema (recycler, por ejemplo) para dormir tranquilos ahi dentro.

El especimen mas raro que encontré de este tipo es uno que consistía en un autorun.inf solitario (sin ejecutable a la vista) ,de 140k. Al abrirlo, aparecía la maraña de caracteres especiales que uno ve cuando abre un binario con un editor de texto, con alguna cadena legible a lo largo del archivo. Me imagino que sería un combo autorun/virus, lo cual sería interesante para tratar de descubrir como corno ejecutas un .inf, o algún método para evitar el borrado del autorun, lo cual sería inteligente, o algun truco para hacerme creer eso, lo cual sería humillante. Elijan la que quieran.

2) La nunca bien ponderada falsa carpeta: Esta la vi ayer, y me parece genial. Una compañera de laburo/cliente le compro un Mp5 a la hija, y me lo trajo porque no podía cargarle música, ni sacar las fotos de adentro, y el antivirus saltaba cada vez que quería abrir una carpeta. A pesar de eso, el aparato funcaba. Cuando lo conecté encontré algo como esto:

Aqui el analisis en virustotal

El fucking virus había ocultado las carpetas reales, y había creado sendos ejecutables con el mismo nombre e icono! También había un ejecutable suelto y un autorun, para no dejar vector de ataque sin usar. El usuario entraba al aparato, y solo podía ver los ejecutables, por supuesto, sin las extensiones… lo cual es un excelente modo de hacer que cualquiera haga doble click sobre tu virus.

A pesar de la inventiva de los muchachos, hay que decir que cualquiera de estos métodos queda al descubierto cuando tenemos acceso al pendrive con vista de extensiones, archivos ocultos y de sistema; y que es posible (por ahora, al menos) explorar cualquier pendrive sin riesgo abriendo el explorador de windows a mano, y simplemente eligiendo la unidad con un click en el arbol de directorios. Por supuesto, en una máquina limpia! Porque teniendo control sobre la maquina host, cualquiera puede ocultarte lo que no quiera que veas.

Para terminar, les dejo una segunda recomendación: inmunicen su pendrive, y los de sus usuarios. No es necesario instalar nada, ni llevar un antivirus. Basta con seguir el método de CoskiBukowski, creando una carpeta en la raiz con el nombre autorun.inf, asi cuando ponemos el pendrive en una maquina con virus el maldito no puede crear su autoarranque, y el pendrive colecciona los ejecutables sin contagiar. Esto nos deja sin el bonito autoarranque, pero nos libera de revisar el pendrive cada vez que pasamos por una maquina sospechosa.

Fin. Enjoy!

Uno de herramientas

En nuestro laburo diario como técnicos, hay ocasiones en las que tenemos que poner a prueba nuestra inteligencia, inventar soluciones, hacer uso de nuestra experiencia en el manejo del usuario o simplemente aprender algo nuevo "on the fly". Estos son los trabajos que mas nos gustan y mas nos desafían. También son aquellos por los que cobramos siempre menos de lo que valen. Y son los mas escasos.

Asi, que, en general, los trabajos que tenemos que hacer son rutinarios y aburridos: reinstalar un sistema, cambiar una fuente, instalar un router wifi, compartir una impresora ,cambiar un antivirus o armar un equipo nuevo. Por eso está bueno disponer de herramientas y técnicas que nos permitan hacer esas cosas de un modo simple y rápido, mientras jugamos al Call of Duty o leemos a Feinmann en pdf (se nota que no tengo internet en casa todavía).

Como ejemplo, les presento tres herramientas que uso en casi cualquier trabajo sobre un sistema en uso: reinstalaciones, limpieza de virus, restauración de imágenes de ghost y otras.


1) Windows XP live USB Angelina edition: creo que su nombre lo dice todo. Lo baje de Taringa! hace un tiempo, antes de que saliera el hirens 9.7, y lo sigo prefiriendo sobre el mini xp que viene ahi, aunque es mas limitado. No tiene soporte para red, y algunas aplicaciones no arrancan por falta de librerías, pero el wallpaper lo vale!

Llámenme baboso...

Lo pueden conseguir acá, y buscando "XP Angelina" salen varios más.
En el rar esta la imagen, y el PeToUsb configurado para ponerlo en el pendrive. Por supuesto, yo lo tengo arrancando desde el Grub4Dos del hirens con las lineas:

title Angelina
find --set-root /minint/setupldr.BIN
chainloader /minint/setupldr.BIN

Lo uso principalmente para examinar el disco en máquinas en las que el windows no aranca, para hacer limpieza de documentos antes de reinstalar y para jugar al solitario (portable, claro) mientras se hace o se restaura una imagen de ghost. En tareas de limpieza es ideal con la próxima herramienta...

2) Scanner: Una joya que encontré en la Lupo Pensuite. Es uno de los muchos programitas que nos muestran el disco de alguna forma mas o menos gráfica. En este caso, en forma de anillos. Una muestra recursiva: el pendrive que tiene el programa:

Gasto casi 19Mb en la iso del geexbox... porque lo vale!

Es asi de simple: sirve para ver porqué un XP que parece limpio y se usa "solo para navegar" pesa mas de 20Gb; para encontrar las carpetas de descarga (por ejemplo, viejos temporales del emule, o carpetas de música y películas), y desde el Angelina sirve para borrar sin problemas el archivo de intercambio, la informacion de restaurar sistema, los temporales de internet y todo lo que no nos parezca innecesario antes de hacer el backup de un sistema usado. La verdad, creo que son pocas las maquinas en las que no termino corriéndolo para ver que onda. Lo pueden bajar desde acá.


El otro infaltable a la hora de rescatar documentos de una maquina con virus (o de una que no arranca) es el archiconocido Total Commander. Para los perdidos que no lo conocen, es un clon del viejo Norton Commander pero para windows. Es muy útil para mover grandes cantidades de información a golpe de F5, y tiene una ventaja importante con respecto al explorador de windows: cuando falla la copia de un archivo por cualquier motivo, nos permite continuar con el siguiente item. Además nos permite sincronizar directorios, puede leer y copiar desde archivos comprimidos y tiene funciones para partir y combinar archivos (split/join). Una belleza!
Para los que no lo tengan, pueden bajar una versión shareware funcional de la página oficial, o una versión portable y trucha desde acá.


Y ahora que particionamos, limpiamos, backapeamos y estamos reinstalando un desatendido en la maquina del cliente, ya podemos bajarnos la iso del último puppy para poner en el pendrive. Y para probarla de inmediato, podemos usar Mobalivecd!

Trabajen... y disfruten!

Resolviendo incompatibilidades del hirens 9.7 y grub4dos

Desde que escribi el apunte acerca del hirens 9.7 y grub4dos lo llevo conmigo en un pendrive, y tuve la oportunidad de probarlo en varias máquinas. Comprobé (al igual que algunos de los lectores de este blog) que el arranque es, digamos... mañoso. Tiende a fallar en máquinas que tienen éxito booteando syslinux, o directamente sectores de arranque de dos o ntfs. Por suerte también llevo encima otro pendrive con hirens 8.5 y slax... pero no es el caso. Nosotros queremos el oro y el moro, la chancha y los veinte. Y queremos que funcione el 9.7 con su XP live en las máquinas difíciles.

Por eso, porque somos tercos y obstinados, y porque un geek que se precie no se deja vencer por pequeñeces (en estas cosas al menos), es que vamos a poner el nuevo Hirens en el pendrive, pero con el método "old school", es decir booteando en el viejo y querido D.O.S.

Aquí un mini howto:

1. Extraemos el contenido de la iso del hirens en una carpeta, digamos /hirens.
2. De ahí extraemos el contenido del archivo /hbcd/boot.gz (que contiene el arranque en dos) a otra carpeta, digamos /boot. Es necesario extraer boot.img primero (puede ser con winrar) y después abrirlo con algún programa para manejar imagenes de diskette. Yo uso winimage (shareware).
3. Formateamos el pendrive con la utilidad de hp, que pueden bajarse aca o aca. Tenemos que chequear "Create a DOS startup disk" y apuntar a la carpeta /boot para que saque de ahi los archivos de arranque.
4. Copiamos al pendrive el contenido de las carpetas /hirens y /boot. Cuando copien /boot les tiene que pedir sobreescribir io.sys, msdos.sys y command com. Por las dudas pongan que no.
5. Bajamos el ultimo grub4dos y extraemos a la raiz del pendrive los archivos ,grub.exe, grldr y menu.lst.
6. Agregamos al menu.lst la linea para bootear el xp
   
   title Mini Windows Xp
   find --set-root /HBCD/XPLOADER.BIN
   chainloader /HBCD/XPLOADER.BIN
   
   (o si ya tenemos el grub de la pagina del hirens, usamos ese menu.lst)
   
7. Y ahora la única novedad con respecto a los varios tutorials que hay acerca del tema en este blog: agregamos grub como opcion en el menu del hirens: esto se hace editando el config.sys que tenemos en la raiz del pen, agregando esta linea. después de la entrada [MOREMENU]:
   
   [MOREMENU]
   menuitem=GRUB, Grub del hirens9.7
   submenu=BOOTTOOL, MBR (Master Boot Record) Tools...
   ...
   y al final del archivo
   
   [GRUB]
   device=GRUB.EXE
   
   

Esto agrega una opción "Grub" como primer ítem del menú "Next..." del hirens, y ejecuta grub4dos desde DOS cuando la elegimos. Así nos evitamos el problema de que grub no encuentre grldr, porque estamos trabajando desde la particion y no desde el MBR (la rima es involuntaria). Aclaro que hubiera preferido ponerlo como opcion en el primer menú, pero parece que hay un límite en 10 items. Fijense dónde les resulta mejor (por ahí mover uno de los submenus a "Next..." para hacer un lugar).

Para los que ya hayan puesto el hirens con el método viejo (como el amigo Norberto) , los pasos son menos: basta con copiar los archivos del boot.img y el grub.exe a la raiz del pendrive, modificar el config.sys y sacar el grub del mbr. Este paso puede hacerse booteando hirens con el probador de Ubcd4win (que debería funcionar, porque no depende de la bios) , arrancando hirens->next->dos->dos , cambiando a A: e ingresando fdisk /mbr, y sys c:

Avisen como les fue
Enjoy!

Actualización: al igual que con la otra entrada acerca del hirens 9.7, todo lo dicho en este apunte se ve superado por una línea al pie de la pagina de Hiren sobre el tema

Troubleshoot

If you get GRLDR error then use syslinux to boot grub4dos

En ese caso los pasos son:

1. Bajar el syslinux de hirens y decomprimirlo en cualquier carpeta.
2. Ejecutar RunMe.bat e ingresar la letra en la que se monto el pendrive.
   

Esto instala syslinux en el mbr del pen, y lo setea para correr grub.exe (incluido en el paquete).
Again, no tan entretenido, pero definitivamente mejor.
Suerte!

Hiren lo hizo: cómo poner el nuevo hiren 9.7 en el pendrive usando grub4dos

El nuevo Hiren´s boot cd 9.7 nos da una buena razón para actualizarnos; razón que les voy a dar ahora mismo, para que ustedes sigan leyendo: trae un mini windows XP con soporte para red y la posibilidad de usar todas las herramientas para windows del cd...en menos de 40Mb!

El fondo es asi, pixelado.

Debo decir (sin que a nadie le interese) que llevo un tiempo usando en mi pendrive el hirens 9.2, y no había encontrado motivos suficientes para cambiarlo: los 100 Mb de ramdisk que usaba el 9.6 me resultaban excesivos, y las herramientas no eran muy distintas.

Y ahora, que ya tengo mi pendrive funcionando con ese hirens, slax, puppy y un mini xp gracias a grub4dos, viene el amigo Hiren y me pone todo junto, mas útil, más lindo y mejor. Gracias!

Va el mini howto: Cómo poner el hirens 9.7 en el pendrive.

En esta versión del hirens cambia la forma en que se carga el boot, debido a la necesidad de arrancar un bootloader de xp. Esto nos simplifica enormemente el proceso. Resumiendo: isolinux carga los archivos de dos desde el comprimido /HBCD/boot.gz, y el bootloader de windows directamente como kernel. Nosotros vamos a hacer algo similar con grub.

Herramientas: Hiren´s boot Cd 9.7 (enlace a la página del viejo amigo Max Thrane. Ahí hay varios links de descarga.), Wingrub, grub4dos.

Procedimiento

1. Extraiga de la imagen iso del hirens la carpeta /HBCD (puede ser con winrar. Gracias Yayuca!). Eso es todo lo que necesitamos del cd. Los que hayan hecho el tuto del hirens anterior notaran que les sobra tiempo aca.
2. Instale el boot de grub con wingrub. Es conveniente fijarse cual es nuestro pendrive en la lista de discos en tools->partition list, y después usar el menú install->MBR y ahi seleccionar nuestro pendrive. Los más intrépidos pueden hacerlo desde la linea de comandos y ahorrarse wingrub, pero creo que los más intrépidos no necesitan esta guía.
3. Sobreescriba grldr, grldr.mbr y menu.lst con las versiones que vienen en el paquete grub4dos (las de wingrub son anteriores, y el chainload no anda bien). También es útil copiar grub.exe, para volver al menú de grub desde DOS.
   
4. Edite el menu.lst agregando estas lineas:

title HIRENS MINI XP
find --set-root /hbcd/xploader.bin
chainloader /hbcd/xploader.bin


title Hirens 9.7
find --set-root /hbcd/boot.gz
kernel /hbcd/memdisk
initrd /hbcd/boot.gz

Recomiendo dejar las entradas por defecto de grub4dos en el menú (son muy útiles).

listo!

PD: en la página de Hiren actualizaron el proceso de creación del usb, y están usando.....grub4dos. Así que los que quieran pueden pasarse por ahí a bajar un zip que en 170Kb simplifica los pasos 2,3 y 4 de esta guia en uno solo. Aunque seguro que no es tan divertido.

Yapa: Los muchachos de UBCD4Win pusieron (algo escondido) en su release un instalador usb que estoy usando mucho como probador. Básicamente, el botón Test USB crea una carpeta qemu con el kernel y un par de archicos esenciales, mas dos archivos de comandos que sirven para probar el boot del pendrive y el de la iso generada. Realmente es muy cómodo (y portátil) . Recomiendo bajar el paquete completo, que arma el live-xp en unos pocos clicks y tiene plugins más que interesantes; pero para los que sean impacientes y no quieran esperar 300Mb de descarga, acá subí el probador "standalone".

Disfruten!

Un boot para dominarlos a todos: Jugando con grub4dos

En un comentario en la entrada sobre grub4dos en el menu de arranque de vista, Reirok nos recomendó un manual de grub4dos mas completo que el wiki oficial.

De ahí saque la clave para manejarme mejor en la consola de grub, y aprendí un par de comandos que me resultaron útiles para hacer lo que siempre trato de hacer: bootear todo lo que se me ocurra. Aqui se los voy dejando, por si alguien con mi misma enfermedad quiere jugar un poco.

Primero los básicos:

root : sirve para decirle al grub desde que particion queremos bootear. La primera particion del primer disco rígido es (hd0,0) , y de ahi en adelante. El comando nos devuelve amablemente una linea donde nos indica el tipo de particion y el sistema de archivos: "Filesystem type is fat, partition type 0xb".

kernel : indica el nucleo de sistema a cargar. Se usa principlamente para bootear linux.
initrd: tambien para linux, indica el nombre de la imagen de sistema base que se usa.

boot : arranca el sistema usando los parametros dados antes

Y ahora los mágicos; los que nos resuelven los problemas:

Problema uno: no me acuerdo cómo de llama el kernel que tengo que bootear, en que disco se encuentra o en que directorio lo puse.

find nos devuelve el disco en el que se encuentra el archivo buscado. No hace búsqueda recursiva, por lo que necesitamos decirle en que directorio buscar, pero en caso de que no sepamos bien ese dato podemos usar TAB para autocompletar.

Por ejemplo, si queremos encontrar el archivo de imagen de floppy de win98, que esta en una carpeta img, o imagen, o images etc, basta con poner:

find / +TAB, nos da el listado de lo que hay en / en el disco (hd0,0). De ahi sacamos el nombre del directorio (imagenes, por ejemplo).

find /imagenes/ +TAB nos lista el contenido del directorio imagenes en (hd0,0), para saber el nombre de la imagen.

find /memdisk nos devuelve (hd0,0) (porque copie el archivo ahí para probar)

Ahora podemos bootear el diskette colocando

root (hd0,0)
kernel /memdisk
initrd /imagenes/win98.img
boot

Para ahorrarnos un paso, podemos combinar find y root colocando find --set-root /memdisk ; lo que nos devuelve la salida de ambos comandos.

Problema dos: me cargué el arranque de xp/vista/win98 y necesito bootearlo.

chainloader hace lo que su nombre indica: encadena el arranque del grub con otro cargador a nuestro antojo. Así podemos bootear win98 sin instalar el boot, copiando io.sys, msdos.sys y command,com al disco (hd0,0) y corriendo chainloader /io.sys, o xp con chainloader /ntldr o el menu de arranque de vista con chainloader /bootmgr.

Hay que tener en cuenta que este método requiere que el disco de arranque sea el (hd0).

Para los que vienen siguiendo el blog, esto simplifica enormemente el trabajo de colocar el hirens, el livexp y cualquier linux en el pendrive. Basta con copiar todo a la raíz del pen, instalar grub4dos y modificar el menu.lst. Quizas haga un mini howto paso a paso en otro post.

chainloader también sirve para bootear desde una particion (bootsector) o disco (mbr). Así, si queremos bootear desde el mbr del disco (hd0) usamos chainloader (hd0)+1, que le indica a grub que botee del disco hd0, el sector1 (que es donde se encuentra el mbr); y si queremos iniciar desde lilo, instalado en el bootsector del (hd0,3),. basta con poner chainloader (hd0,3)+1

Problema tres: mi disco de windows no aparece como (hd0), y no me funciona el chainloader/ntldr.

map es un comando muy útil que nos permite solucionar este tema. Basicamente nos permite engañar al sistema que queremos arrancar para que crea que el disco X esta en la posición Y. Por ejemplo, si tenemos la particion de windows xp en (hd1,1) y queremos hacer chainloader /ntldr, tenemos que decirle a grub que haga aparecer el disco hd1 como hd0:

map (hd1) (hd0)

Si ahora usamos find /ntldr el comando nos devuelve
(hd0,1)
(hd1,1)

Esto es porque el disco 1 esta mapeado en hd0, y esta realmente en hd1.
Ahora, si queremos volver a tener acceso al disco 0 anterior, o necesitamos verlo en dos, lo mejor es hacer el cambio completo

map (hd1) (hd0)
map (hd0) (hd1)

y por fin, si queremos ver los cambios antes de bootear, podemos salir de esta ambigua situacion con

map --hook

este comando hace efectivos los mapeos anteriores, con lo que el resultado de find /ntldr pasa a ser

(hd0,1)

map es una instrucción muy potente, que aparte nos permite montar una imágen de floppy o de disco rigido como (fd0) o (hd0). Lamentablemente, esta funcion requiere que la imagen en cuestión sea contigua en el disco (no fragmentada), con lo que muchas veces el mapeo nos da un error.

Para solucionar esto podemos usar el modificador --mem, que carga la imagen en memoria antes de bootear (para imágenes de disco, hay que tener en cuenta que necesitamos tener ram al menos del tamaño de la imagen).

Por ejemplo, para montar nuestra imagen del disco de inicio de win98:

map --mem (hd0,0)/images/win98.ima (fd0)

Como dato adicional, el comando map --mem puede montar imagenes comprimidas con gzip (así como memdisk puede bootear zip).

Nota extra: todos los que nos obsesionamos tratando de crear cds/pendrive multiarranque soñamos con la utilidad que nos permita montar una imagen iso y arrancarla desde un menú. Mejor aún: una que busque en el pendrive todas las iso que pongamos adentro, y nos de un menú desde el que elegir cuál queremos bootear. Bueno, grub4dos no hace eso todavía, y es posible que no lo haga. Pero la posibilidad de mapear una iso como (hd32) y bootearla con chainloader es lo mas cercano que ví hasta ahora.

Problema cuatro: tuve que reinstalar windows y me cargué el boot de linux.

Este problema podría solucionarse con una vuelta larga: bootear windows, acceder a la particion de linux con el plugin ext2 de totalcommander, extraer el menu.lst, imprimirlo, bootear grub4dos e ingresar a mano los parametros de kernel e initrd con todos sus append. O más corta, ubicar el menu.lst anterior en el disco, listarlo con cat y copiar a mano los parametros. En lugar de eso tenemos un comando que nos permite cargar el menu.lst de nuestro linux como menu de grub4dos.

configfile le indica a grub4dos cual es el archivo de configuracion que debe usar. Así, si teníamos nuestro linux en (hd1,5), que vendría a ser la primera unidad lógica de la partición extendida del segundo disco, podemos buscarla con:

find /boot/grub/menu.lst
(hd1,5)

y después cargar el menu con

configfile (hd1,5)/boot/grub/menu.lst

, con lo que tendremos todas las opciones que habíamos perdido. Hay que tener en cuenta que es posible que las opciones de arranque no funcionen sin laburo extra. Por ejemplo, si booteamos grub desde un pendrive; este se pone como (hd0,0), desplazando la nomenclatura de los discos internos, por lo que debemos hacer algo de edición "en vivo" sobre las opciones para sacarlas andando.

El comando configfile también es útil para hacer submenuses, solamente haciendo entradas que apunten a distintos archivos de configuración. Si quieren ver un excelente ejemplo vean SGD. Un estudio de los archivos de menú les va a dar una idea más clara.

Ya escribí demasiado. Chau, que lo disfruten!

PD: cada comando tiene un link a la guia del amigo diddy, en la que todo está mucho (mucho) mejor explicado. Les recomiendo que lo sigan, para hacerse una idea de que tan mala es esta mini guia.

Gardel con guitarra eléctrica: Detectando virus y spyware con Process Explorer

Esta entrada está destinada a tres grupos de personas:
1) Los que no leyeron la entrada anterior.
2) Los que, habiendola leido, no miraron la conferencia de Russinovich por falta de tiempo, o desconocimiento del inglés, o imposibilidad fisica o moral de instalar silverlight.
3) Los que la leyeron y vieron la conferencia de Mark, pero quieren seguir leyendo para discutirme algo, de barderos nomás.

Hace unos días miré la excelente presentación de Mark Russinovich: "Advanced Malware Cleaning", y aparte de quedar obsesionado con el tema de los rootkits, me lleve un par de consejos para la detección de malware con Process Explorer, que en estos días me han resultado útiles.

ProcEx es un process manager que nos da mucha información acerca de los procesos que están corriendo en nuestra máquina. Podemos distinguir de un vistazo los servicios (en rosa), los procesos del propio usuario (en celeste), los ejecutables empaquetados (en violeta), los íconos de las aplicaciones, su descripcion y la companía de la que provienen. Tamben se ve, gracias a la vista por ramas, desde que proceso se ejecuto cada tarea (por ejemplo, las aplicaciones que tengo abiertas las corri desde el explorer, mientras que los servicios se lanzan desde winlogon.exe).

Casi nada sospechoso...

Sobre esta vista básica Mark nos da una guía rápida de búsqueda: son sospechosos todos los procesos que figuran en violeta (porque el empaquetado es un método de burlar a los antivirus que buscan por firmas), los que no posean ícono, o carezcan de descripción y/o nombre de empresa.

Un segundo filtro para descartar falsos positivos es la verificación de firmas (options->verify image signature). Esto achica el rango de sospechosos a los procesos no firmados, y nos permite distinguir procesos maliciosos que pretenden ser de windows. Igualmente hay que tener cuidado con esto, porque hay algunos procesos legítimos que no estan firmados. Y el otro problema es que necesitamos estar conectados a internet, lo que no es del todo recomendable si sospechamos que tenemos virus. Aquí que cada uno haga su solucion de compromiso.

Cuando el virus/spyware tiene alguna manifestacion visible (por ejemplo, muestra un mensaje de "Su PC esta infectada"), tenemos una herramienta para encontrar el proceso que pertenece a una ventana.

Y cuando ya tenemos a los sospechosos, ProcEx nos muestra más información en las propiedades del proceso. Ahí podemos consultar la ubicación del ejecutable, ver si está conectado a internet y a que sitio; e incluso realizar un volcado de las cadenas de texto dentro del ejecutable (o en memoria, si está empaquetado) para mirarle las tripas buscando mensajes del hacker en cuestión, tratando de ubicar cadenas de texto sospechosas o páginas de internet a las que el bicho intenta conectarse (una búsqueda por "http" basta para eso).

Aqui persiguiendo a un inocente: FScapture quiere que lo registre.

Una vez que identificamos el/los procesos maliciosos, podemos proceder a matarlos y borrarlos a mano. Hay que tener especial cuidado con los procesos solidarios, que se reviven entre si haciéndos mas difíciles de borrar. En ProcEx es fácil identificarlos gracias al highlight: Los procesos que mueren se subrayan en rojo y se muestran durante un segundo (puede cambiarse en las opciones), y los que nacen lo mismo, pero en verde. Para eliminar estos Mark recomienda usar la función "suspend" sobre todos los implicados, y después matarlos sin problemas.

Y hasta aquí llega el uso que le doy al programa. No exprime toda su funcionalidad (por ejemplo, la vista de las librerías en uso no me dice nada), pero es un avance con respecto al uso que le encontré a otros visores como Procx o Dtaskmanager.

En la próxima entrega de "Russinovich´s fanatics" (la tercera) voy a ver si puedo secribir algo acerca de la otra herramienta estrella de Sysinternals: Autoruns. O por ahi no.

PD: A los amigos del gremio que pasen por aca; se aceptan sugerencias!

Jugando con fuego: rootkits

El blog del Maligno es una fuente inagotable de sabiduria y mala leche (pero con onda).

Hace unos días pasaba por ahi, y me topé con estas im-pre-sio-nantes conferencias de Mark Russinovich, que los amigos de M$ nos regalan a cambio de que instalemos su Silverlight.

Como ultimamente estoy pro M$ y estaba usando la beta del seven, no tuve ningun reparo moral en instalarlo y pasarme una hora y cuarto mirando la charla "Advanced Malware Cleaning", en la que Mark repasa los métodos de detección y remoción de malware, enfocandose principalmente en el uso de las herramientas de sysinternals, ProcessExplorer y Autoruns. A los que trabajen de ésto, les recomiendo verla. Es en inglés, pero les aseguro que mi nivel no es muy bueno, y Mark habla claro y lento, así que es difícil perderse algo. Como ayuda, les dejo un pdf con la presentación que Russinovich usaba de guia.

Lo que más me interesó de la charla fue la parte en la que habla acerca de los rootkits. Estos son programas diseñados para esconderse a si mismos, y esconder tambien otros programas que pueden ser maliciosos o no, de modo que sean indetectables para cualquier programa que intente verlos a traves de las llamadas al sistema (APIs). En resumen, una cagada para el técnico (lease yo), que puede pasarse horas mirando el ProcessExplorer, el Hijackthis, el Autoruns, el regedit o cualquier otro programa que no esté diseñado específicamente para verlos, sin sospechar que la máquina sigue infectada.

Pasada la introducción, pasamos a la diversión.

Me suscribí a www.rootkit.com, y dediqué un rato a "infectar" una máquina con pruebas de concepto, para ver cómo se ven.

Materiales:

Maquina (1)

PIII con winchiquito, usada desde la cuenta administrador (una bomba de tiempo). No es de lo más estable (se cuelga sin infectarla), pero es lo mejor que tengo para pruebas.

Rootkit (2)

HideToolz: herramienta que nos presenta una interfaz desde la que podemos ocultar procesos. No corre junto con Hacker Defender (cuelga la maquina), por lo que no lo incluyo en los análisis. para el que quiera probarlo, es bastante inocuo (igual no me hago responsable etc.)

HackerDefender: Más completo, nos permite ocultar procesos, claves del registro, archivos y más. Además puede setearse para iniciar un proceso oculto.

AntiRootkits (4)

RootkitRevealer (RKR): La herramienta de sysinternals es bastante buena detectando el problema pero no nos permite solucionarlo desde el programa. En la presentacion Mark usa un depurador en modo kernel (una herramienta que le permite "tocar" los parametros del kernel en vivo, en este caso softice) para sacar el rootkit . Véanlo. Es demasiado para mi.

Gmer: un limpiador mas amigable, con acceso a procesos ocultos (y la posibilidad de matarlos), servicios ( y cómo deshabilitarlos), vista del registro y claves ocultas e incluso archivos que no se ven en el explorador.

Rootkit Unhooker (RU): Un programita "Quick and dirty" que nos muestra facil y rápidamente si hay un bicho en nuestro sistema. También mata procesos e intenta borrar drivers y servicios malos.

System Virginity Verfier (SVV): uno de los juguetes de Joanna Rutkowska. Es una utilidad de linea de comandos que nos permite chequear rápidamente si el sistema está comprometido, e incluso tratar de repararlo. Y nada más. No nos dá mucha info, pero es muy util.

Y ahora a los bifes... Digo, a las capturas.

1) SVV nos dice que esta todo OK.

2) RU también

3) Corremos HackerDefender. Le decimos que se oculte, saque de nuestra vista todos los archivos y carpetas que lleven "hxdef*" y corra el bloc de notas pero "in the backround". Nos hace caso. Acá no hay captura: no hay nada que ver ahora!

4) SVV no está tan contento...

5) RU nos muestra el problema

6) GMER nos avisa ni bien entramos, y nos deja ver los procesos, servicios y archivos ocultos.

7) El escaneo completo del sistema, tanto con RKR como con GMER o RU, nos lleva a una bonita BSOD, asi que no hay cap.

8) Tratamos de limpiar. Gmer nos deja matar el proceso, con lo que recuperamos la vista de los archivos ocultos. También nos permite deshabilitar el servicio asociado. Con esto nuestro rootkit pasa a ser como cualquier otro virus, porque quedan a la vista los procesos, servicios, archivos y drivers que este se encargaba de ocultar. Borramos todo lo que parezca sospechoso (puede que haya que reiniciar para borrar los servicios malvados despues de deshabilitarlos).

9) Para terminar la limpieza, le pedimos ayuda a Joanna:

10) Reiniciamos y volvemos a chequear: Gmer muestra un par de entradas sospechosas (probablemente ya estuvieran ahi antes), pero ningun proceso oculto, ni driver o servicio fuera de lugar, y ninguna referencia a HackerDefender. RU no encuentra problemas, RKR no sé, porque el escaneo tarda mucho (si quieren una reseña profesional vayan a otro lado) y SVV vuelve al nivel 1 (good).

Y hasta acá llegamos con la prueba. Quien quiera repetirla y tenga algo para agregar, que no sea tímido. Para eso estamos.

FAQ

Q: Los reportes del final significan que el sistema quedó limpio?

A: No. Sólo quieren decir que está más limpio que antes. Lo fundamental de los rootkits es su habilidad para esconderse, y siempre se buscan nuevas técnicas para hacerlo. De todos modos, si uno no quiere volverse paranoico, un par de reportes limpios son buenas noticias. Y si no, siempre queda reinstalar.

Q: Por qué no hay capturas de la limpieza?

A: Porque el objetivo del post es mostrarles cómo se ven las infecciones de rootkits en general con las herramientas que probé. La limpieza es opcional (siempre queda reinstalar).

Q: Se te ocurre una pregunta mejor para terminar?

A: No. Chau.