Hola a todos. A menudo ocurre que queremos ejecutar una aplicación Java en un servidor pero tiene algo, alguna librería, algo que ejecuta que necesita el sistema de ventanas X y que provoca una excepción java.awt.HeadlessException. Para evitar que esto ocurra hay dos formas, la simple y la compleja.
La forma simple, aunque no siempre funciona, es ejecutar la máquina virtual Java con los siguientes parámetros: -Djava.awt.headless=true -Dawt.toolkit=sun.awt.HToolkit
Si esto funciona perfecto, si no os funciona tendréis que recurrir a la compleja. Esta otra forma es utilizar las librerías de GhostAWT (https://github.com/Danielku15/GhostAWT).
La librería GhostAWT simulará ciertos componentes de AWT para intentar engañar a la aplicación para que funcione.
Y si la aplicación no te funciona con ninguna de estas dos alternativas, me temo que no te quedará otra que instalar el sistema de ventanas.
Salu2 a to2
jueves, 23 de marzo de 2017
miércoles, 22 de febrero de 2017
Error en la definición de políticas "inetres.admx"
Hola a todos, me ha ocurrido que un una máquina virtual con Windows Server 2008 R2, que tenía instaladas actualizaciones para tener el Internet Explorer 11, al abrir el "gpedit" para configurar las políticas de Internet Explorer me apareció el siguiente error:
Error al analizar
No se pudo encontrar el recurso "$(string.Advanced_EnableSSL3Fallback)" al que se hace referencia en el atributo displayName.
Archivo c:\Windows\PolicyDefinitions\inetres.admx, línea 795, columna 308
Tras mucho darle vueltas, resulta que es un fallo de una actualización de Windows y que se arregla con otra.
La cuestión es corregir ese fichero c:\Windows\PolicyDefinitions\inetres.admx sobreescribiéndolo con uno más actualizado y os recomiendo el de la actualización https://technet.microsoft.com/en-us/library/security/MS14-051 tal y como indica el siguiente blog del propio Microsoft https://blogs.msdn.microsoft.com/askie/2014/08/12/how-to-manage-the-new-blocking-out-of-date-activex-controls-feature-in-ie/
Tan sólo queda comentarios que para sobreescribir esos ficheros necesitaréis cambiarles el propietario y luego darles permiso de escritura a vuestro usuario. No basta con ser administrador ya que por defecto el propietario de esos ficheros es el Trusted Installer.
Salu2 a to2
viernes, 20 de enero de 2017
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:
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
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
viernes, 18 de noviembre de 2016
Añadir una resolución de nombres a Ubuntu
Hola chavales, hoy he descubierto que si quieres añadir una ruta estática en tu Linux Ubuntu, hay que hacer alguna configuración extra.
De toda la vida para añadir una ruta estática a tu Linux, editas el fichero /etc/hosts y la añades ahí:
127.0.0.1 localhost
127.0.1.1 mycomputer
192.168.1.219 test.ldap.server
El problema viene cuando quieres resolver el nombre "test.ldap.server" por DNS mediante un:
host test.ldap.server
Ubuntu resuelve las DNS internamente mediante un "dnsmasq", y eso nos permite meterle cierta configuración. Para que "dnsmasq" pille el fichero /etc/host hay que crear un fichero de configuración "/etc/NetworkManager/dnsmasq.d/hosts.conf" con el siguiente contenido:
addn-hosts=/etc/hosts
Tras esto sólo hay que hacer un "sudo /etc/init.d/network-manager restart", y ya tendremos respuesta de:
usuario@mycomputer ~ $ host test.ldap.server
test.ldap.server has address 192.168.1.219
Salu2 a to2
De toda la vida para añadir una ruta estática a tu Linux, editas el fichero /etc/hosts y la añades ahí:
127.0.0.1 localhost
127.0.1.1 mycomputer
192.168.1.219 test.ldap.server
El problema viene cuando quieres resolver el nombre "test.ldap.server" por DNS mediante un:
host test.ldap.server
Ubuntu resuelve las DNS internamente mediante un "dnsmasq", y eso nos permite meterle cierta configuración. Para que "dnsmasq" pille el fichero /etc/host hay que crear un fichero de configuración "/etc/NetworkManager/dnsmasq.d/hosts.conf" con el siguiente contenido:
addn-hosts=/etc/hosts
Tras esto sólo hay que hacer un "sudo /etc/init.d/network-manager restart", y ya tendremos respuesta de:
usuario@mycomputer ~ $ host test.ldap.server
test.ldap.server has address 192.168.1.219
Salu2 a to2
miércoles, 2 de noviembre de 2016
Accediendo a la base de datos PostgreSQL de Chef 12
A veces uno desea conectarse a la base de datos PostgreSQL de Chef 12 para echar un vistazo.
Para hacerlo hay que instalar el cliente de PostgreSQL:
yum install postgresql
Una vez tengamos el cliente, necesitamos saber cuales son los datos de conexión. Para esto edita el fichero "/etc/opscode/chef-server-running.json" y busca la configuración de "opscode-erchef":
"opscode-erchef": {
"enable": true,
"ha": false,
"dir": "/var/opt/opscode/opscode-erchef",
"log_directory": "/var/log/opscode/opscode-erchef",
"log_rotation": {
"file_maxbytes": 104857600,
"num_to_keep": 10,
"max_messages_per_second": 1000
},
"vip": "127.0.0.1",
"listen": "127.0.0.1",
"port": 8000,
"auth_skew": "900",
"authz_pooler_timeout": "0",
"bulk_fetch_batch_size": "5",
"udp_socket_pool_size": "20",
"sql_user": "opscode_chef",
"sql_password": "10f0e1d74d73a38e4062257a6b14d771ae37f4871199c4d0954309229ab4",
"sql_ro_user": "opscode_chef_ro",
"sql_ro_password": "88792696490ab97c2740f1a6450fb995f7dbafe3d299acd3a99df218e108",
"db_pool_size": 20,
"db_pool_queue_max": 20,
Una vez tenemos estos datos, ya podemos conectarnos mediante:
psql -h 127.0.0.1 -U opscode_chef
La clave es ese "chorizo" escrito en hexadecimal. Que la veas en hexadecimal no significa que esté codificada de ningún modo.
Una vez conectado puedes listar las tablas mediante:
SELECT * FROM pg_catalog.pg_tables WHERE schemaname = 'public';
Salu2 a to2
Para hacerlo hay que instalar el cliente de PostgreSQL:
yum install postgresql
Una vez tengamos el cliente, necesitamos saber cuales son los datos de conexión. Para esto edita el fichero "/etc/opscode/chef-server-running.json" y busca la configuración de "opscode-erchef":
"opscode-erchef": {
"enable": true,
"ha": false,
"dir": "/var/opt/opscode/opscode-erchef",
"log_directory": "/var/log/opscode/opscode-erchef",
"log_rotation": {
"file_maxbytes": 104857600,
"num_to_keep": 10,
"max_messages_per_second": 1000
},
"vip": "127.0.0.1",
"listen": "127.0.0.1",
"port": 8000,
"auth_skew": "900",
"authz_pooler_timeout": "0",
"bulk_fetch_batch_size": "5",
"udp_socket_pool_size": "20",
"sql_user": "opscode_chef",
"sql_password": "10f0e1d74d73a38e4062257a6b14d771ae37f4871199c4d0954309229ab4",
"sql_ro_user": "opscode_chef_ro",
"sql_ro_password": "88792696490ab97c2740f1a6450fb995f7dbafe3d299acd3a99df218e108",
"db_pool_size": 20,
"db_pool_queue_max": 20,
Una vez tenemos estos datos, ya podemos conectarnos mediante:
psql -h 127.0.0.1 -U opscode_chef
La clave es ese "chorizo" escrito en hexadecimal. Que la veas en hexadecimal no significa que esté codificada de ningún modo.
Una vez conectado puedes listar las tablas mediante:
SELECT * FROM pg_catalog.pg_tables WHERE schemaname = 'public';
Salu2 a to2
miércoles, 17 de agosto de 2016
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
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
viernes, 15 de julio de 2016
Problemas de la librería "SmartcardIO" de Java
Hola a todos, hoy quiero hablar de los problemas de la librería SmarcardIO de Java.
https://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/package-summary.html
En la empresa en la que trabajo tenemos un software que se comunica con las Smartcards mediante una librería de código nativo que llama a la librería PC/SC del sistema. Y en un momento dado hicimos el cambio para usar la librería "SmartcardIO" de forma que nuestra solución fuera "Java puro" y no requiriese de librerías de código nativo. Y ahí empezaron los problemas.
El primer problema que tuvimos que afrontar es el hecho de no tener un control de los "contextos". La librería SmartcardIO utiliza un sólo contexto para todas las llamadas, y eso da problemas cuando quieres trabajar con varios hilos en paralelo.
El segundo problema que encontramos es que el SmartcardIO, a pesar de forma parte de Java desde el Java 1.6, sólo está implementado en la JVM de Oracle (y la OpenJDK) y no está implementado en otras JVM como la de IBM.
Y para rematar, hoy me he dado cuenta de que cuando se llaman con varios hilos a operaciones sobre la Smart card, el hecho de intentar liberar una terja con "endExclusive" puede generar una excepción desde la Smart card SDCARD_W_RESETCARD:
https://msdn.microsoft.com/es-es/library/windows/desktop/aa379477(v=vs.85).aspx
Tras lo cual hay que hacer una reconexión forzosamente, y la implemetación de SmartcardIO no contempla el "SCardReconnect".
El resultado de todo esto es que tenemos que hacer una "marcha atrás" y volver a la librería de códio nativo.
Salu2 a to2
https://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/package-summary.html
En la empresa en la que trabajo tenemos un software que se comunica con las Smartcards mediante una librería de código nativo que llama a la librería PC/SC del sistema. Y en un momento dado hicimos el cambio para usar la librería "SmartcardIO" de forma que nuestra solución fuera "Java puro" y no requiriese de librerías de código nativo. Y ahí empezaron los problemas.
El primer problema que tuvimos que afrontar es el hecho de no tener un control de los "contextos". La librería SmartcardIO utiliza un sólo contexto para todas las llamadas, y eso da problemas cuando quieres trabajar con varios hilos en paralelo.
El segundo problema que encontramos es que el SmartcardIO, a pesar de forma parte de Java desde el Java 1.6, sólo está implementado en la JVM de Oracle (y la OpenJDK) y no está implementado en otras JVM como la de IBM.
Y para rematar, hoy me he dado cuenta de que cuando se llaman con varios hilos a operaciones sobre la Smart card, el hecho de intentar liberar una terja con "endExclusive" puede generar una excepción desde la Smart card SDCARD_W_RESETCARD:
https://msdn.microsoft.com/es-es/library/windows/desktop/aa379477(v=vs.85).aspx
Tras lo cual hay que hacer una reconexión forzosamente, y la implemetación de SmartcardIO no contempla el "SCardReconnect".
El resultado de todo esto es que tenemos que hacer una "marcha atrás" y volver a la librería de códio nativo.
Salu2 a to2
Suscribirse a:
Entradas (Atom)