Iniciando Windows desde un USB externo

Hola a todos, resulta que mi novia tiene un Asus VivoBook E403SA del cual presume que la batería dura 14 horas. Y resulta que daba un error de que no podía actualizar el Windows 10 porque no tenía espacio en disco. Así que me puse a comprobar qué tenía que se pudiera borrar para liberar espacio y poder actualizar, hasta que me di cuenta de que era sencillamente imposible, ya que tiene 32Gbytes de disco (lo que para un Windows 10 es totalmente insuficiente).

Lógicamente lo primero que me pasó por la cabeza fue cambiarle el disco duro por otro de más capacidad, pero esto es imposible ya que este "portatil" por dentro es una tablet, y el disco duro no es más que una memoria eMMC soldada en placa.

Las opciones que se presentaban entonces eran 3:

• Cambiar la placa por una más potente (se pueden comprar en AliExpress pero son caras y más te vale comprobar que es el modelo exacto que necesitas).
• Instalar un Linux
• Iniciar Windows desde un pen USB.

Descartada la primera opción, pensé que lo más sencillo sería la tercera. De hecho encontré un programa llamado Win2USB que en teoría permite clonar el disco de la máquina a un USB (digo en teoría porque al ser de pago no lo he probado). Pero tras probar que la funcionalidad gratutita que debería permitir iniciar un Windows 10 desde USB no funcionaba bien, desistí de usarlo.

Lo que sí funcionó correctamente es usar el Rufus de toda la vida, que tiene una opción para esto. De hecho, tras mucho buscar (sin éxito) una ISO de Windows 10 Home OEM (la que viene instalada en los equipos al comprarlos) resultó que no hacía falta. Con una simple ISO de Windows 10 descargada de la web oficial de Windows al iniciar detectó automáticamente el número de serie de Windows que está en la BIOS UEFI del equipo. Con lo que al final, tras probar las opciones más complejas, resultó que todo era muy sencillo. Pero es importante iniciar Windows en esa máquina y sólo en esa máquina (no vale iniciar digamos iniciar Windows en otra máquina para completar la instalación y luego querer pinchar el pen USB en el Asus).

Como pen USB, compré un USB 3.0 SanDisk Ultra Fit de 128 GB, de forma que tenga espacio suficiente para Windows y un par de aplicaciones, sea lo suficientemente rápido y sea lo suficientemente pequeñito para que no estorbe.

Y como han ido pasando semanas entre las primeras pruebas y este final de tener el Windows 10 Home correctamente licenciado generado con el Rufus y correctamente funcionando, lo primero que hice fue instalarle un Linux (que era la opción 2).

El Linux elegido (por mi) fue el ElementaryOS, ya que es supersencillo de manejar y muy agradable a la vista. Le instalé las cuatro aplicaciones que suele usar (Firefox, Dropbox, LibreOffice y Skype), le instalé el driver de la impresora, y listo.

Si os sorprende que usara el LibreOffice en vez del Office de Microsoft, os remito al inicio de este artículo donde os digo que tenía 32Gbytes de disco (imposible meter ahí el Office de Microsoft). De hecho, deberíais haber visto la cara de sorpresa que puso tras instalar el ElementaryOS y el software, cuando me preguntó cuanto espacio libre tenía ahora, y le dije que 20Gbytes.

Como entre unas cosas y otras ha pasado un mes y ya se ha acostumbrado a ElementaryOS, ella me dice que ya el Windows para qué. Pero yo he preferido que lo tenga por si algún momento tuviera que hacer algo que no sabe hacer con un Linux (instalar un software concreto o un driver concreto).

Simplemente le he puesto el arranque del pen drive USB como una entrada más en el menú del Grub y listo.

Salu2 a to2

Ingeniería inversa de DLLs en Windows

Hola a todos. Hace tiempo escribí un POST sobre como comparar la ejecución de dos programas (o del mismo programa instalado en dos máquinas distintas):
  http://paridasinformaticas.blogspot.com.es/2015/03/comparando-antes-y-despues-con-windows.html

Pero el "Process Monitor" sólo traza las siguientes cosas:

• Operaciones con disco
• Operaciones con registro
• Operaciones de red
• Operaciones de procesos e hilos

Y a veces necesitamos trazar otras cosas. No sólo para comparar la ejecución de programas, sino también a veces para hacer ingeniería inversa de forma que podamos saber cómo funciona un programa por dentro.

Como primer paso, se puede utilizar el software "API Monitor" de http://www.rohitab.com/

Este es un software genial que trazará las llamadas a las distintas DLLs del sistema y que nos permite además filtrar aquellas llamadas que queremos ver y las que no. También podemos marcarlo todo, trazarlo todo, y tener una traza supercompleta aunque bastante lenta de generar.

Esto para comparar es sencillamente genial, pero para ingeniería inversa tiene una pequeña pega. La pega es que hay ciertas APIs de Microsoft que permiten digamos "saltarse" las llamadas a DLLs. Por ejemplo existe la función "InitializeSecurityContext", que puede ser llamada a través de la DLL, o por el contrario, podemos hacer una llamada a "InitSecurityInterface", traernos la tabla de funciones de seguridad y hacer la llamada a través de ella (con lo cual esa llamada no se trazaría con el API Monitor).

Para esto tenemos otra herramienta, pero que esta vez requiere codificar exactamente lo que queremos trazar, la librería "Detours". Mediante esta librería se carga el software en memoria y luego se parchean las llamadas a las funciones de las DLLs en memoria. Esto no sólo parchea las llamadas del software en sí, sino también las llamadas de las DLLs que son dependencia de ese software.

Por ejemplo, si se parchea la llamada a "AcquireCredentialsHandle", y hacemos una llamada a "AcquireCredentialsHandle" usando el paquete de seguridad "CredSSP", veremos que internamente la librería "credssp.dll" hace otras dos llamadas a "AcquireCredentialsHandle", una con "TSSSP" y otra con "Schannel" como parametros.

Para hacer esto lo más sencillo es seguir el tutorial de:
  https://blogs.msdn.microsoft.com/jannemattila/2009/12/03/modifying-application-behavior-with-detours-for-application-compatibility-reasons/

Tutorial que seguramente tendrás que complementar con algún sencillo tutorial sobre cómo crear una DLL (encontraras cientos con una búsqueda con Google).

Lo mejor de este tutorial es que me permitió conocer el software "PEBrowse" (http://www.smidgeonsoft.prohosting.com/), con el que desensamblar una DLL resulta bastante fácil.

RESUMIENDO: Si aprendes a manejar estas dos herramientas y a crear tus propias DLLs para parchear funciones con "Detours", la ingeniería inversa de una DLL (o de un software) te resultará más sencilla.

Salu2

Py2exe y las DLLs de Windows

Creo que todo el que haya alguna vez trabajado con el Py2exe para "convertir" un programa en Python a un EXE para Windows se ha dado cuenta de lo mal que gestiona las DLLs.

A esa mala gestión hay que añadir unos mensajes de error nada esclarecedores. Y además, algunas de las DLLs que Py2exe toma del sistema, son dependientes del propio sistema. Lo que hace que si compilas en un Windows 10 (por ejemplo) no te funcione el software en un Windows 7.

Ayer me topé con el siguiente error:

Traceback (most recent call last):
  File "c:\Python27\lib\site-packages\gi\__init__.py", line 42, in <module>
    from . import _gi
  File "gi\_gi.pyc", line 12, in <module>
  File "gi\_gi.pyc", line 10, in __load
ImportError: DLL load failed: El sistema operativo no puede ejecutar %1.

El software si lo compilaba en Windows 10 funcionaba en Windows 10 pero no en Windows 7, y viceversa. Luego estaba claro que había alguna DLL del sistema y que sobraba pero ¿cuál?

Con Winmerge comparé los directorios "lib" de ambas compilaciones y vi que sólo había 3 DLLs distintas, con lo que sólo tuve que probar a ir reemplazando una a una. Al final resultó que la DLL que molestaba era IPHLPAPI.DLL.

Así que simplemente hay que borrar esa DLL tras la compilación para que el software compilado en Windows 7 funcionara en Windows 10.

        # Delete System dependent DLLs
        os.remove(os.path.join('dist', 'lib', 'IPHLPAPI.DLL'))

Y luego para que el software compilado en Windows 10 funcionara en Windows 7, tuve que borrar las otras dos DLLs que eran distintas:

        # Delete System dependent DLLs
        os.remove(os.path.join('dist', 'lib', 'IPHLPAPI.DLL'))
        os.remove(os.path.join('dist', 'lib', 'DNSAPI.DLL'))
        os.remove(os.path.join('dist', 'lib', 'MPR.dll'))

RESUMIENDO: Hay que borrar aquellas DLLs que sean distintas (si hay más DLLs al compilar en un Windows que en otro no importa, las que estorban son las que son distintas).

Salu2 a to2

Enviando datos en crudo a una impresora

Hola chavales, en el curro me he topado con un problema con unas viejas impresoras matriciales.
Resulta que el programa que envía los datos a imprimir, los manda "en crudo" ("raw" para los colegas).

Explico, nosotros tenemos un driver que suplanta una impresora Postscript y crea un PDF. Pues bien, la impresión "en crudo" lo que hace básicamente el saltarse el driver a la torera y enviar los datos directamente al puerto.

Para hacer las pruebas pertinentes, utilizamos un programita de Micro$oft:
 https://support.microsoft.com/es-es/kb/138594?wa=wsignin1.0

Gracias a las pruebas con este programita detectamos que el driver no se ejecutaba, y que los datos iban del tirón al puerto en cuestión.

Así que ya sabéis que si una impresora matricial no funciona, quizá la culpa no sea del driver.

Salu2 a to2

Trabajo con impresoras desde la línea de comandos en Windows

Hola a todos, hoy se ma ha planteado la necesidad de ver cómo se puede cambiar el nombre de una impresora desde la línea de comandos de Windows.

Pues bien, resulta que Microsoft incorpora una serie de Scripts VBS para trabajar con las impresoras.

https://technet.microsoft.com/es-es/library/cc771846%28v=ws.10%29.aspx

Lo primero es localizar estos scripts en el ordenador. En el servidor donde estaba trabajando se encontraban en la ruta C:\Windows\System32\Printing_Admin_Scripts\es-ES\

A partir de ahí puedes utilizar estos scripts para hacer cosas como listar las impresoras del sistema:

   cscript prnmngr.vbs -l 

O cambiar el nombre de una impresora:

  cscript prncnfg.vbs -x -p "Microsoft XPS Document Writer" -z XPS

Salu2 a to2

Comparando antes y después con Windows

Hola a todos. En un servidor con Windows Server 2012 tenemos una aplicación que cuando un usuario con privilegios de administrador instalaba, dicha aplicación funcionaba correctamente.

Pero si se borraba el perfil local de la máquina (teniendo "roaming profiles" en el Active Directory), tras iniciar sesión en el servidor la aplicación ya no funcionaba.

Dicha aplicación se instala en el perfil del usuario, algo nada recomendable pero por lo que se ve los programadores de esta aplicación lo hicieron así. Así que cuando ese "perfil movil" se movía, había algo de la aplicación que no se estaba moviendo correctamente.

Después de muchos quebraderos de cabeza y muuuuuuuchas horas de trabajo, conseguimos averiguar qué era y solucionar el problema. Para ello usamos el software "Process Monitor".

  https://technet.microsoft.com/es-es/sysinternals/bb896645.aspx

Partiendo de un perfil limpio, instalamos la aplicación y luego lanzamos el process monitor.

Aplicamos todos los filtros necesarios para excluir de la captura de eventos los procesos típicos del sistema (como el "task manager", o el "svchost"), y lanzamos la apliación que lógicamente funcionó correctamente. Luego guardamos la captura como CSV.


Tras esto, cerramos sesión, borramos el perfil local y a tras traerse el perfil móvil hicimos otra captura de eventos con el Process Monitor, pero esta vez sabíamos que la aplicación fallaría.

Una vez que teníamos 2 ficheros CSV (una con los eventos cuando la aplicación funciona y otra cuando no funciona). Los abrimos con Excel y quitamos las columnas de fecha y hora, y del ID de proceso. De esta forma los dos ficheros CSV son similares hasta el punto donde falla la aplicación.

Finalmente, comparando ambos ficheros CSV con Winmerge (que para algo son ficheros de texto), pudimos ver que nos faltaban algunas entradas del registro e incluso una librería DLL.

RESUMIENDO: Si queréis comparar un "antes" y un "después" del comportamiento de una aplicación, el "Process Monitor" es un buen aliado.

Salu2 a to2

Wine para windows?

Hola a todos, recientemente he visto que ciertas personas han empezado un proyecto para portar Wine a Windows.

¿Para qué? Pues para lograr una mejor compatibilidad con aplicaciones "legacy" de la que tiene WoW64.

La verdad es que me parece una gran idea y pienso que merece la pena echarle de cuando en cuando un ojo a este proyecto a ver qué tal evoluciona.

Hoy por hoy parece que las opciones para utilizar en un Windows moderno (como Windows 7) aplicaciones legacy que funcionaban en un Windows XP son:

• WoW64 (incluido en Windows de 64 bits)
• Windows XP mode (se instala un Virtual PC y se ejecuta la aplicación en él)
• Herramientas de virtualización de aplicaciones tipo Ulteo OVD

El uso de herramientas tipo Ulteo OVD puede servir si la aplicación se puede ejecutar bajo Wine en Linux. Es una buena solución ya que no tendría coste de licencias.

Salu2 a to2