Páginas

23 septiembre, 2015

Diferencia entre las carpetas "Archivos de programa" y "System32" en arquitecturas x86 y x64

Aunque a estas alturas tecnológicas es algo tarde para explicar esto, creo que nunca viene de más dar un repaso y quizás aclarar determinados conceptos.

En una entrada anterior comentara como "listar aplicaciones y actualizaciones instaladas en Windows de forma remota". Había comentado la diferencia de las claves de registro que había entre OS de 32 bits (x86) y 64 bits (x64).

Simplemente detallaré un poco más las diferencias más considerables entre ambas arquitecturas entre directorios y algunas carpetas y como afecta esto a la compatibilidad de todo en sistemas Windows.

Saber que hay dos diferencias en cuanto a los nombres: 'WOW64' y 'x86'.

WOW64: viene de "Windows on Windows 64 bits" (algo como Windows de 32 bits en Windows de 64 bits). Es un emulador que permite a las aplicaciones basadas en Windows de 32 bits correr indistintamente en Windows de 64 bits. Se utiliza una capa de compatibilidad entre un programa de 32 bits y el sistema operativo de 64 bits.

x86: inicialmente es un nombre que viene de la arquitectura de procesadores Intel que usaba instrucciones de 32 bits. El término x86 hace referencia referirse a los procesadores de Intel que usaban instrucciones de 32 bits. Eran procesadores llamados 8086, 80186, 80286, 80386, etc, este último fue usado para referirse a procesadores de 32 bits.

Existen dos variantes diferentes de la carpeta "Archivos de programa" y la carpeta de "Sistema de Windows".

Windows de 64 bits tiene dos versiones diferentes de la carpeta program files y la carpeta de sistema de Windows. Una versión está orientada para archivos de 32 bits y la otra versión para archivos de 64 bits. Los nombres de estas carpetas y los bits a que coresponden, son de la siguiente manera:

C:\Windows\System32: Carpeta de sistema de Windows para archivos 64 bits.
C:\Windows\SysWOW64: Carpeta de sistema de Windows para archivos 32 bits.
C:\Archivos de programa: Carpeta para archivos de programa 64 bits.
C:\Archivos de programa (x86): Carpeta para archivos de programa 32 bits.
La carpeta SysWOW64 está dedicada únicamente para archivos de 32 bits
La carpeta System32 está únicamente destinada para archivos de 64 bits
Aquí seguramente veremos algo que nos puede resultar confuso, resulta que la carpeta System32 está dedicada para archivos 64 bits y la carpeta SysWOW64 está dedicada para archivos 32 bits. Esto puede verse un poco ilógico atendiendo a los nombres de las carpetas, pero hay una explicación para ello.
Tiene que ver con la compatibilidad. Muchos desarrolladores han codificado el nombre de la ruta de la carpeta de sistema en el código fuente de sus aplicaciones con el fin de preservar la compatibilidad, si la aplicación se convierte a código de 64 bits, la carpeta de sistema de 64 bits, aún se llamará System32.

¿Qué ocurre con las aplicaciones de 32 bits que tienen codificada la ruta de system y están corriendo en Windows de 64 bits? ¿Cómo pueden encontrar la nueva carpeta SysWOW64 sin cambios en el código del programa?.

La respuesta es que el emulador redirecciona las llamadas a la carpeta System32 a la carpeta SysWOW64 de manera transparente, aún si la carpeta ha sido codificada a la carpeta System32 (C:\Windows\System32), el emulador se asegurará que la carpeta SysWOW64 se use en su lugar. De modo que el mismo código fuente, que utiliza la carpeta System32, puede compilarse tanto en códigos de programas de 32 bits como de 64 bits sin cambio alguno.

Es muy importante que archivos binarios compilados en 32 bits o 64 bits se instalen en la carpeta correcta de system. De otra forma el programa que necesite determinado archivo no podrá cargarlo y probablemente no funcionará correctamente.

Si tenemos instalado un sistema Windows de 64 bits, tendremos instaladas dos carpetas para archivos de programa (Program Files):
Archivos de programa (x86) instala siempre un programa de 32 bits.
Archivos de programa instala siempre un programa de 64 bits.
En muchos casos el programa iniciará y funcionará pese a que coloques el programa en carpetas equivocadas, pero si el programa pide a Windows la ruta de archivos de programa y desea accesar los archivos instalados en la carpeta, se utilizará la carpeta errónea y el programa fallará en su función. De modo que para asegurarse de que todo funcionará como se espera, deberás siempre instalar las aplicaciones que corran a 64 bits o en 32 bits en sus carpetas correspondientes.

Por último señalar las diferencias de esto el registro de Windows. En el caso de aplicaciones tanto de 32 bits como de 64 bits, se ven reflejadas en el siguiente path del registro:

Para arquitecturas x86 (32bits):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Para arquitecturas x64 (64bits):
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Y esto viene siendo la explicación de las diferencias entre arquitecturas de x64 y x86 en sistemas Windows.

Saludos!

18 septiembre, 2015

Exportar un controlador específico de impresora incluido en el DriverStore de Windows

Si queremos exportar un controlador específico de el cual ya está incluido en el repositorio nativo DriverStore de Windows.

¿Por qué razón lo haríamos esto?

Simplemente por que en la website oficial el fabricante en cuestión no publica el controlador necesario o específico del modelo para nuevos sistemas operativos, sino que lo hace con un controlador genérico.

Sin embargo, en algunos casos Windows lo incluye en sus repositorios oficiales. Como es el siguiente caso, donde Windows incluye el controlador HP LaserJet 4200/4300 PCL6.

Figura 1: Driver de HP Laserjet 4200/4300 PCL6 el cual queremos exportar.

Para poder ver la ruta, el controlador de inicialización (.ini) y sus otros ficheros dependientes del driver podemos hacer uso de prndrvr.vbs del que ya hablara en otro artículo http://www.zonasystem.com/2014/09/administrar-impresoras-de-windows.html

Por defecto ubicados en el path:
C:\Windows\System32\Printing_Admin_Scripts\es-ES
Abrimos una consola con privilegios de administrador y ejecutamos:
prndrvr.vbs -l |more
-l: Nos listará todos los controladores instalados en el equipo local.
|more: visualización por páginas de los resultados.

Figura 2: Controlador principal y lista de todos los archivos dependientes necesarios.

Podemos hacer exactamente lo mismo de forma gráfica. Para ello abrimos una MMC y agregamos el complemento de "Administración de impresión" para el equipo local, en el apartado de "Controladores" buscamos el driver de la impresora que nos interese, en sus propiedades veremos la ruta de acceso al controlador y el resto de ficheros independientes.

Figura 3: Método gráfico con el mismo resultado que prndrvr.vbs -l

La ruta por defecto del repositorio del conjunto de todos los drivers instalados en la máquina local es:
C:\Windows\System32\DriverStore\FileRepository
Dentro de este path buscamos la carpeta del controlador en cuestión, la cual obtenemos su nombre por lo realizado anteriormente.

Aquí tendremos dos opciones:

- Copiar el propio fichero del driver y sus depencias uno a uno siguiendo el listado mostrado anteriormente (ya sea que lo hicéramos en consola o de forma gráfica).

- Si vamos a reinstalar este driver en un equipo en el que tenga las depencias de dicho driver simplemente copiaremos el fichero de inicialización del propio driver (.inf). Ya que esté llamará a sus otros ficheros dependientes.

Saludos!

15 septiembre, 2015

PsKill: Finalizar procesos en equipos remotos

Hace un tiempo comentara el uso de las PSTools: http://www.zonasystem.com/2014/03/pstools-suite-de-herramientas-para-la.html una suite de herramientas para la administración remota de una misma red de trabajo.

En esta ocasión haremos uso de pslist, pskill y psexec, las cuales nos servirán para listar procesos remotos y después finalizarlos (matarlos). Esto nos puede resultar útil en un entorno empresarial en el que remotamente queramos hacer pruebas con algún que otro software y queramos "reiniciar" el proceso.

Teniendo descargadas las PSTools, abrimos una consola en Windows y usamos pslist para listar los procesos del equipo remoto:
pslist -t \\[EquipoRemoto/IP]
-t: Lista los procesos en forma de árbol (jerarquía).
[EquipoRemoto/IP]: Es el nombre FQDN del equipo remoto o la direción IP local.

Una vez tenemos localizado el nombre del proceso remoto a finalizar o mejor aún, el PID (Process identifier).

Con pskill podremos finalizar o matar dicho proceso remoto. Manteniéndose en la misma cmd escribimos:
pskill -t \\[EquipoRemoto/IP] -u [NombreEquipo\UsuarioPrivilegiado] -p [Password] [NombreProceso/PID]
-t: Finaliza el proceso y sus dependencias.
-u: Indicar el nombre de equipo y un usuario administrador con privilegios.
-p: Contraseña del usuario administrador privilegiado.

 [NombreProceso/PID]: Nombre del proceso o PID a finalizar.

Si lo necesitáramos podríamos iniciar de nuevo el proceso que cerramos, de modo que hiceramos como un "reinicio" del software en cuestión al que afecta dicho proceso.

Simplemente con psexec para ejecutar comandos y lo que queramos en un equipo remoto, escribimos en la misma consola:
psexec \\[EquipoRemoto/IP] -u [NombreEquipo\UsuarioPrivilegiado] -p [Password] [FullPathPrograma\fichero.exe]
[FullPathPrograma\fichero.exe]: Sería la ruta del fichero binario ejecutable. (por ejemplo: C:\Program Files (x86)\Mozilla Firefox\firefox.exe)

Con esto finalizaremos el proceso y sus dependencias en el equipo remoto al que hagamos referencia y lo volveremos a iniciar en caso de que sea necesario.

Saludos!

07 septiembre, 2015

Privacidad expuesta por medio del feed de Picasaweb

Este simple y pequeño tip nos permite ver fotos de perfiles públicos en picasaweb.google.com un servicio que Google suele ofrecer sincronización con la cuenta de Google global del usuario.

Servicios que usemos de Google y en el cual compartamos de algún modo imágenes a través de ellos podrán ser publicadas de forma pública en picasaweb: La galería de imágenes del teléfono, Blogger, Hangouts, etc.

Simplemente si accedemos a feed aleatorio como por ejemplo puede ser este.
http://picasaweb.google.com/data/feed/base/all?q=IMG0015+jpg+20150815
Veremos que podremos realizar búsquedas en base a esta muestra de feed, donde:
IMG0015: Serán las palabras que llevará por título la imagen en la búsqueda.
jpg: El tipo de imagen a mostrar.
20150825: Fecha en orden año/mes/día.

Palabras que contengan en sus títulos IMG o WA, lo mas seguro es que salgan fotos de gente que no sabe que tiene el picasa sincronizado con su cuenta de Google.

Finalmente clickando en algunas de las imágenes podremos acceder al perfil de dicho usuario y de ese modo ir navegando por sus álbumes, comprometiendo así su privacidad.

Esto no es un bug ni nada por el estilo, es un "fallo" del propio usuario. Bien es verdad que Google en ocasiones sincroniza sus servicios sin avisar o avisa al usuario final de un modo "transparente" pero será el usuario quien sea el responsable de estar pendiente de su privacidad y de revisar las configuraciones de los servicios de los que forma parte y así restringir determinados accesos de una forma pública a privada.

Revisar siempre la configuración de privacidades y permisos de cuentas en las que estáis registrados, a veces dedicar un mínimo de tiempo a estas tareas evitaremos este tipo de filtraciones públicas mal intencionadas y consiguiremos la privacidad de la persona.

Saludos!

Entradas Populares