martes, 10 de octubre de 2017

Troyano bancario Trickbot - webinjects y bancos españoles.

Trickbot es un troyano bancario que se estima que lleva funcionando desde el 2016 y que afecta a una gran cantidad de bancos y de entre ellos a muchos españoles.

Se han escrito varios artículos sobre su funcionamiento, persistencia, tipos de inyecciones, etc. De modo que sólo quiero tratar el tema de los webinjects o inyecciones dimámicas (dinj).

Una vez Trickbot se ha instalado en el sistema y demás, inspecciona la lista de procesos en busca de los tres principales navegadores: firefox, chrome y iexplore. Si encuentra uno de ellos, reserva espacio de memoria dentro de cada uno de los procesos e inyecta una dll que es la encargada de realizar el hooking para inspeccionar y alterar el tráfico entre nuestro navegador y el servidor web del banco.

De entre la lista de bancos afectados, están los siguientes españoles:

caixaontinyent.es
cajamar.es
bancopopular.es
caja-ingenieros.es
caixabank.es
lacaixa.es
finconsum.es
cetelem.es
liberbankbancaprivada.es
openbank.es
bmn.es
cajasur.es
kutxabank.es
y más...

Voy a realizar una prueba con mi banco, ya que me preocupa especialmente porque es dónde tengo mi dinero.

Al conectar a cajamar.es con el navegador Internet Explorer versión 11, se puede apreciar que Trickbot ha instalado un hook en la función HttpSendRequestW dentro de la librería WININET.DLL realizando un salto incondicional JMP hacia la dirección 0x0A1EBFA0:

Hook instalado en la función HttpSendRequestW
Para que se pueda apreciar la diferencia entre la función hookeada y la que no lo está, hice la misma prueba pero sin Trickbot instalado.

Sin hook instalado
Una vez da el salto al hook, Trickbot realiza las comprobaciones para determinar si el sitio al que se ha conectado el usuario está entre la lista de las inyecciones dinámicas o "dinj". En ese caso, realiza una petición con el servidor malicioso y devuelve, entre otra información, la inyección a realizar en el sitio web:

Inicio de la inyección en cajamar.es

Función Javascript que roba credenciales de acceso a la banca electrónica de cajamar.es

Para que la inyección pueda realizarse sobre el sitio legítimo, Trickbot tiene que hookear la función InternetReadFile dentro de la librería WININET.DLL que es la encargada de leer la respuesta del servidor web bancario y alterarla para poder incluir la inyección correspondiente:

Hook instalado encargado de devolver a petición al navegador con la inyección
Una mitigación que se puede implementar desde el lado del servidor web del banco, es leer la cookie "tknz_referrer" para determinar si el usuario/cliente del banco está infectado y actuar en consecuencia.

martes, 3 de octubre de 2017

TOR con Python y cambiar circuito programáticamente

En este artículo voy a mostrar cómo tunelizar todas las conexiones de nuestro script Python y además la posibilidad de cambiar de circuito para salir cada vez por una IP distinta.

Los ingredientes necesarios son Python y TOR, obviamente. Una vez tenemos nuestro sistema listo, debemos configurar TOR habilitando la directiva ControlPort para poder interactuar con el servicio por medio del puerto configurado:

/etc/tor/torrc
Para esta prueba de concepto, he deshabilitado la autenticación del puerto de control CookieAuthentication con el valor 0. Para sistemas en producción configurar este valor adecuadamente.

Reiniciamos nuestra instancia TOR y vamos al código:


Ejemplo de ejecución:


Para cambiar el circuito, básicamente se establece una conexión en texto plano al puerto 9051 sin autenticación y se envía el comando "SIGNAL NEWNYM". Establecemos un tiempo de espera de 10 segundos para dar tiempo a que se cambie el circuito. 

domingo, 1 de octubre de 2017

Wordlist para fuzzing web con Apache y Logrotate

Crear una wordlist para fuzzing web puede ser relativamente sencillo, efectivo y sin apenas esfuerzo aprovechando la tecnología y la "inteligencia" que nos brindan los diferentes actores que ponen a prueba nuestro servidor web Apache donde tenemos alojadas nuestras webs, honeypots, etc.

Los ingredientes necesarios son un servidor web Apache y Logrotate. Para el que no sepa que es Logrotate, como su nombre indica, nos permite realizar rotación de archivos evitando que crezcan y nos colapsen el espacio de disco duro. Para ello se vale de varias directivas y demás. Para nuestro propósito nos valdremos de la directiva "prerotate".

Abrimos el archivo "/etc/logrotate.d/apache2" y justo debajo de "prerotate", añadimos:

PATH_LOGS="/var/log/apache2/*.log"
PATH_WORDLIST="/home/cukz"
grep "HTTP/1.1\" 404" $PATH_LOGS | awk '{print $7 } ' | sort | uniq | sort >> $PATH_WORDLIST/wordlist.tmp && cat $PATH_WORDLIST/wordlist.tmp | sort | uniq > $PATH_WORDLIST/wordlist.txt

Modificar la variable "PATH_LOGS" y "PATH_WORDLIST" con los valores adecuados según nuestro sistema.

Quedaría algo así:


Logrotate se ejecutará diariamente gracias a cron y en la ruta "PATH_WORDLIST" tendremos un archivo ordenado con todas las peticiones 404 que se hayan realizado sobre nuestro servidor web.
Hay que tener en cuenta que no todas las peticiones nos valdrán para nuestro diccionario, nos tocará filtrarlo y eliminar lo que no nos interese.

Esta wordlist también nos puede valer para realizar un posterior análisis forense, estudiar tendencias de ataques, etc.

domingo, 29 de noviembre de 2015

Problemas con el HDMI de la app de Orange TV en Android y cómo solucionarlo.

La app de Orange TV para Android viene de serie capada para que no podamos usar el HDMI de nuestra tablet o smartphone para poder ver los canales en nuestro flamante televisor.

Tal día como hoy, me dispuse a conectar mi tablet por HDMI al televisor. Arranqué la app de Orange TV y puse un canal al azar. Conecté el cable HDMI a la tablet y WTF!

Error HDMI Orange TV

A santo de que los lumbreras de Orange deciden capar el HDMI para poder ver el contenido desde mi televisor? No me parece justo, ya que además de cliente de TV, también lo soy de móvil y ADSL / Fibra y me gasto los cuartos para que encima decidan si puedo usar o no el HDMI!

Ante esta indignación e imagino que la de mucha gente, indico una serie de pasos básicos para poder usar el puerto HDMI con la app de Orange TV de Android.
Básicamente consiste en eliminar el IntentFilter para que la aplicación no se entere cuando ocurran los eventos / acciones relacionados con:

  • HDMI_AUDIO_PLUG
  • HDMI_PLUGGED

Asumo que tienes conocimientos de reversing en Android, por lo que no voy a comentar muchos de los pasos por lo que los doy por sabidos.
  • Hazte con una copia del apk de Orange TV.
  • Decompilamos con apktool
    • ./apktool d com.orange.es.orangetv-1.apk
  • Modificar constructor privado ".method private constructor <init>()V" de la clase "com/discretix/drmdlc/api/DxBroadcastReceiver.smali" eliminando estas líneas:

    const-string v1, "android.intent.action.HDMI_AUDIO_PLUG"

    invoke-virtual {v0, v1}, Landroid/content/IntentFilter;->addAction(Ljava/lang/String;)V

    const-string v1, "android.intent.action.HDMI_PLUGGED"

    invoke-virtual {v0, v1}, Landroid/content/IntentFilter;->addAction(Ljava/lang/String;)V
  • Compilamos con apktool: 
    • ./apktool b com.orange.es.orangetv-1
  • Firmar (Me he generado el keystore "apktool.keystore" con contraseña "apktool" para firmar con el certificado "apktool")
    • jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore apktool.keystore -storepass apktool com.orange.es.orangetv-1.apk apktool
  • Verificamos firma
    • jarsigner -verify -verbose -certs com.orange.es.orangetv-1.apk
  • Alineamos
    • zipalign -v 4 com.orange.es.orangetv-1.apk "com.orange.es.orangetv-1.align.apk"
  • Desinstalamos la app original de Orange TV.
  • Conectamos nuestro dispositivo e instalamos la app "tuneada"
    • adb install com.orange.es.orangetv-1.align.apk
Para los más perezosos, dejo una copia del apk modificado. Es la versión 1.3.2, la tenéis aquí.

Saludos,

viernes, 9 de octubre de 2015

Exploit KCodes NetUSB disponible en GitHub y Google Play

Buscando y buscando el exploit de NetUSB y nunca dí con nada, así que decidí investigar para intentar sacarlo y poder determinar si alguno de nuestros dispositivos está afectado por la vulnerabilidad CVE-2015-3036.

Tienes a tu disposición el exploit de NetUSB descubierto a últimos de mayo de 2015.



For fun & profit!

saludos,

miércoles, 18 de abril de 2012

Google Translate sin SSL

Vaya, de nuevo Google parece que se toma en serio la seguridad, a ratos.

Este problema de "implementación" puede acarrear que, en redes inseguras, nuestras cookies sean interceptadas y por lo tanto una suplantación de identidad, session hijacking.

El logado se realiza de forma segura, el problema se encuentra cuando navegamos hacia:

http://translate.google.com/

y de esa forma deja de estar cifrada la información que transmitimos.
Al igual ocurre con:

http://translate.google.com/toolkit/

cuidadito cuando accedáis a estas webs mientras Google no implemente el cifrado SSL.

saludos,

sábado, 17 de marzo de 2012

Concienciación en seguridad tecnológica

La tecnología nos ayuda en nuestra labor diaria, por todos es sabido que en el mundo en el que actualmente vivimos, pocas son las personas que pueden prescindir, por mínimo que sea, de usarla.
El usarla de manera imprudente sin la concienciación adecuada, puede ocasionar que la perdamos, roben, manipulen, intercepten, etc. Debemos de salvaguardar toda la información que precisemos importante. Con importante no quiere decir que sea privada. Podemos tener información importante y pública e información para nada importante para los demás pero con caracter privado y confidencial para nosotros. Analizar que información manejamos, nos ayudará a protegerla. Cual consideramos pública y cual privada. Unas recomendaciones básicas para el uso correcto de la información y mantenernos en la medida de lo posible actualizados.
  • Cifrar. Con cifrar nos referimos a cualquier nivel de la capa OSI. Ya sean archivos, particiones, comunicaciones, etc.
  • Actualizar. Mantén en la medida de lo posible tu software actualizado. Este software puede ser cualquier que sea ejecutado por cualquier dispositivo tales como routers, pc, móvil, etc.
  • Monitorizar. De vez en cuando, no está de más realizar pequeñas auditorías sobre nuestros datos, revisar logs, fechas de modificaciones de archivos, software instalado, conexiones realizadas, etc.
  • Autenticidad. Parece difícil saber cuando algo es auténtico y cuando no, pero en cuanto a las comunicaciones con entidades bancarias (por poner un ejemplo), podemos siempre verificar los certificados digitales si han sido emitidos por entidades de confianza y si éstos a su vez no han sido revocados (las entidades de confianza). Al igual pasa con verificar la firma del software que vamos a instalar si está firmado digitalmente por una entidad de confianza.Véase PKI.
  • Desconfiar. Hasta que no se demuestre lo contrario, en internet, nada es lo que parece ser. No abrir enlaces no solicitados, no abrir archivos sospechosos y que no hayamos solicitado, no transferir información personal y privada por redes inseguras,  si sospechas de algo, en vez de proporcionar información real, que sea falsa, etc.
Son unos pequeños consejos para sobrevivir en la red de redes. El día en el que para entrar, tengamos que acreditar nuestra identidad, paquete a paquete, byte a byte, bit a bit... todo cambiará.

saludos,

domingo, 12 de diciembre de 2010

Volver al pasado...

Hace algún tiempo di con esta página y me resulta de lo más curiosa. Te permite ver páginas webs desde el año 1996 en adelante. Como han evolucionado, como han desaparecido, cambios de propietario... todo un historial con sus cambios a lo largo de la vida de una web.

enlace: http://www.archive.org/

domingo, 13 de junio de 2010

Página curiosa http://www.superbad.com/

Dejo un enlace de una página muy curiosa donde cada una de ellas contiene enlaces a otras páginas con otros diseños y formas totalmente diferentes!

Algo desconcertante, curioso, desordenado y divertido!. Merce la pena que le eches un vistazo.

http://www.superbad.com

domingo, 25 de abril de 2010

Ejecutar procesos en PHP (Windows)

Después de mucho tiempo sin escribir nada voy a hacerlo con una pequeña pero útil prestación de php.

El proceso que voy a realizar aquí va dedicado para Windows mediante COM, que a resumidas cuentas un objeto COM permite la comunicación entre procesos dando igual el lenguaje, implementación, etc desde donde proceda.

Veamos un ejemplo:


Supongamos que necesito ejecutar dede php un script también escrito en php.
Podría hacerlo mediante una redirección desde el navegador que apuntase al script que necesito ejecutar, ¿pero qué ocurre si no deseo que se ejecute por la salida del navegador y sea como un proceso independiente?, pues ahí radica el kid de la cuestión. Necesitamos ejecutar un script como si se tratase de un proceso independiente del sistema donde ejecutamos el servidor web.

Estableciendo el escenario.
Nuestro script se va a encargar de rastrear un sitio web completo en busca de direcciones de correo electrónico.
Por un lado, tenemos el script que se encargará de realizar la llamada al script que se ejecutará como proceso independiente pasándole como parámetro le URL del sitio web a rastrear.

lanzadera.php


A continuación el script que procesa la petición para buscar emails

buscas_emails.php


El resto del código te lo dejo pendiente para que lo finalices, pero la idea es:
  • Tener un formulario de entrada donde recibir por GET la dirección del sitio web a rastrear.
  • Realizar la llamada al script que se va a ejecutar como un proceso independiente
  • Tras realizar la llamada, rastrear el sitio web completo en busca de todos los emails
  • Los emails encontradros los almacenamos en memoria mediante un vector
  • Finalizado el rastreo del servidor, volcamos todos los emails encontrados en un fichero en el sistema
  • Mediante Ajax, realizar un seguimiento del fichero donde se encuentran todos los emails para comprobar si tal fichero tiene o no contenido. En caso de tenerlo mostrarlo


Espero te sirva de utilidad y completes el ejemplo satisfactoriamente!

viernes, 18 de diciembre de 2009

Subir archivos con Java mediante HTTP y tratamiento con PHP

Más de una vez me ha surgido la necesidad de subir varios archivos al servidor asíncronamente y de tal forma que muestre al detalle el total de archivos subidos, progreso, tamaño total ,etc.
Pues bien, en uno de mis experimentos, me decidí a desarrollar mi propio uploader en Java, que es lo que voy a tratar de explicar aquí. Para ello analizaremos los paquetes que son enviados al servidor mediante el protocolo HTTP, oséase al servidor web y así poder implementar dicho protocolo en Java.

La subida de archivos por el protocolo HTTP mediante PHP y un servidor web tal como APACHE, para un programador experimentado es bien conocida, no obstante, vamos a repasar algunos conceptos de cómo se hace con este método tan rudimentario y tan usado por muchos.

upload.html

Tenemos preparado el documento html para la entrada de datos, una vez que se pulsa el botón "Subir!", la petición se redirige al script especificado en el atributo "action", en este caso vamos a parar a "tratar-upload.php".

tratar-upload.php
Bien, ya tenemos todo listo, ahora nos toca analizar cómo hace intrínsicamente la operación de subir archivos. Para ello nos valemos de un analizador de protocolos de red tal como wireshark. Ponemos a la escucha en el interfaz de red pertinente, seleccionamos archivos en el documento html y pulsamos el botón "Subir!".

Análisis de subida de archivos por el protocolo HTTP usando el método POST.

Petición HTTP
Quiero hacer una objeción respecto a -RETORNO DE CARRO + SALTO DE LINEA-. Indica que existen 2 bytes no visibles adicionales para el salto a la siguiente línea. Véase más sobre secuencias de escape, pero para el ejemplo sólo usaremos dos:

Retorno de carro:\r
Salto de línea: \n

Donde se indica "2 x", es que existen dos saltos.
Pasemos a analizar paso a paso cada campo de la cebecera de la petición.

Realizamos petición para "mandar, fijar, poner" en el script "tratar-upload.php" los datos de la petición.
POST tratar-upload.php HTTP/1.1
Dirección completa del servidor desde donde realizamos la petición.
Host: localhost
Agente-navegador usado desde donde realizamos la petición.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.16)
Tipos de datos que acepta el agente-navegador para procesar la respuesta una vez concluida la petición.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Lenguajes aceptados para la respuesta por parte del navegador.
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Tipos de codificación aceptados para la respuesta por parte del navegador.
Accept-Encoding: gzip,deflate
Conjunto de carácteres aceptados para la respuesta por parte del navegador.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Representa el número máximo de segundos entre envío y respuesta de paquetes sobre una conexión persistente.
Keep-Alive: 300
Indica que el navegador soporta conexiones persistentes sobre una misma conexión TCP.
Connection: keep-alive
Indica desde donde procede la petición.
Referer: http://localhost/upload.html
Muy Importante.
Establece que la petición puede estar formada por diferentes partes de datos y se indica el separador (límite) entre las partes involucradas. Oséase, que cada archivo debe estar separado convenientemente por el límite establecido boundary. La serie numérica que le sigue está formada aleatoriamente y no sigue ningún tipo de lógica.
Content-Type: multipart/form-data; boundary=---------------------------265001916915724
Tamaño en bytes del conjunto de datos que vamos a enviar excluyendo la cabecera.
Content-Length: total_bytes_de_los_ficheros_incluyendo_los_delimitadores<2 x RETORNO DE CARRO + SALTO DE LINEA>

A continuación voy a explicar las partes de cada archivo que enviamos al servidor.

Indica el comienzo de una parte, osea, los datos de un archivo
-----------------------------265001916915724
Aquí se establece el nombre del campo del fichero especificado en el form y el nombre del archivo que vamos a enviar.
Content-Disposition: form-data; name="f1"; filename="archivo1.ext"
Tipos de datos que contiene el archivo. Normalmente binarios.
Content-Type: application/binary<2 x RETORNO DE CARRO + SALTO DE LINEA>
Los datos en bruto del fichero son colocados aquí, acabamos con un salto de línea.


Para terminar la retransmisión de datos hacia el servidor, debemos indicarlo con el siguiente campo.
-----------------------------265001916915724--
(nótese que acaba con dos guiones -- más retorno de carro y el salto de línea correspondiente.)

Ya creo que estamos listos para ver el código fuente del programa que desarrollé en Java para la subida de ilimitado número de archivos. El código se corresponde con la clase más significativa del programa, el uploader. He suprimido algunas partes del código para exponer más claramente lo que estamos tratando aquí.

Uploader.java

Si estás interesado en todo el desarrollo del applet, puedes ponerte en contacto conmigo.
Para poder usarlo correctamente, el applet está firmado para poder explorar el disco duro del cliente con los archivos que desea subir al servidor.

martes, 1 de diciembre de 2009

Implementando cliente DNS para resolver servidores MX (MAIL EXCHANGE) con C

A continuación listo el codigo fuente totalmente comentado para resolver servidores de correo saliente a partir de un email, un servidor DNS y el puerto usado por el servidor (normalmente el 53 por UDP).

Uso del programa:

DNS-MX.exe <Email> <Servidor DNS> <Puerto servidor DNS>

DNS-MX.c

Analizando la respuesta DNS

Procederemos a analizar la respuesta que nos devuelve el servidor DNS.



Voy a pasar a comentar sólo algunos campos que nos resultan de interés para la práctica que estamos realizando.
  • Transaction ID: Como vemos, coincide el ID de la consulta con la de la respuesta.
  • Answer RRs: Nos indica que el número de servidores tipo MX resueltos.
  • Additional RRs: Son campos adicionales donde se muestran las direcciones IP de cada servidor MX resuelto.

Ahora vamos a desglosar los campos Answers donde se encuentran los servidores MX resueltos por el servidor DNS.



Datos de la estructura Answers:
  • Name: gmail.com = 0xc00c. c0 indica que hay compresión y el siguiente byte establece el byte de desplazamiento donde se encuentra la información, osea: 0c, que en decimal se traduce a 12. En la posición 12 de la respuesta se encuentra lo que buscamos. Los primeros 12 bytes de la respuesta corresponden a parámetros de la consulta, el byte siguiente, osea, el 13, nos deja justo en el campo Name de la estructura Queries, que es nada más ni nada menos que: gmail.com. Todo este procedimiento se traduce como compresión.
  • Type: MX = 0x000f. Indica el tipo de servidor (servidor de correo saliente)
  • Class: IN = 0x0001. Indica la clase de servidor (servidor de internet)
  • Time to live: 47 minutes, 52 secons = 0x00000b38. Marca de tiempo que establece el tiempo que puede ser el servidor cacheado hasta vovler a interrogar para resolverlos de nuevo.
  • Data length: 27 = 0x000b. Indica el tamaño de la cadena en bytes del servidor resuelto.
  • Preference: 5 = 0x0005. Indica preferencia de uso del servidor entre los resueltos.
  • Mail exchange: gmail-smtp-in.l.google.com

Nos detenemos en el campo Mail exchange ya que merece la pena para analizar la compresión.



Este tipo de procedimiento se repite una y otra vez mientras se pueda hacer uso de la compresión.
Como ya dije, se hace uso de la compresión para dar una rápida respuesta y demorar lo menos posible en resolver las consultas de los clientes. Es un buen mecanismo pero un tanto engorroso, se deben de tener bien claros los conceptos porque en el capítulo siguiente veremos la implementación de un cliente DNS para resolver servidores tipo Mail exchange.

Analizando la consulta DNS

Hace algún tiempo, desarrollé un cliente DNS para resolver consultas tipo MX(MAIL EXCHANGE), que no son más que consultas para resolver  servidores de correo saliente a partir de un nombre de dominio.

Para obtener más información sobre DNS RFC 1035

La siguiente captura está realizada con wireshark para ilustrar un poco que campos intervienen a la hora de realizar una consulta DNS.



Voy a explicar un poco que significan los siguientes campos.
  • Transaction ID (2 bytes): Identifica la consulta del cliente que debe conincidir con la respuesta del servidor.
  • Flags (2 bytes): Son parámetros para la consulta a realizar, si es una consulta inversa, el mensaje está truncado, etc. De momento nos basta saber que la consulta a que hemos realizado es recursiva, es decir, si el servidor DNS al que hemos realizado la consulta no contiene la información que necesitamos, éste acude a otros servidores para obtener la respuesta.
  • Questions (2 bytes): Número de consultas a realizar, por defecto sólo una.
  • Answer RRs (2 bytes): Número de entradas que aparecen en la sección de respuesta, siempre a cero en la consulta.
  • Authority RRs (2 bytes): Número de entradas que aparecen en la sección de autoridad, siempre a cero en la consulta.
  • Additional RRs (2 bytes): Número de entradas que aparecen en la sección adicional, siempre a cero en la consulta.
  • Queries
    Este campo especifica las consultas a realizar.
    En este caso es de 15 bytes
  • Name (11 bytes): Nombre del dominio a consultar para obtener los servidores de correo saliente para enviar el mensaje
  • Type (2 bytes): Tipo de consulta a realizar. En este caso es 0x000f para especificar que es tipo MX.
  • Class (2 bytes): El tipo de consulta pertenece a internet, la más usada.

A excepción del campo Queries, la cabecera de la consulta DNS tiene siempre una constante de 12 bytes.
Vamos a ver al detalle el campo Name que contiene el dominio a consultar ya que resulta un tanto interesante en la forma en la que lo hace.

1 2 3 4 5 6 7 8 9 10 11
05 g m a i l 03 c o m 00

El dominio es gmail.com, y como vemos en la anterior tabla, los puntos '.' los sustituye por un campo numérico que indica la longitud del siguiente campo. El final de la cadena siempre acaba en cero.

Parece fácil, no?

En el siguiente capítulo veremos la respuesta que nos devuelve el servidor DNS y veremos también la compresión de los mensajes que es utilizada para ahorrar tamaño en el paquete y por consiguiente demorar lo menos posible para obtener un respuesta rápida.

domingo, 29 de noviembre de 2009

Cómo emitir imágenes con la webcam en tu página web con PHP

El procedimiento que voy a explicar va a consistir en la captura de imágenes de la webcam cada X segundos y la posterior subida de la imagen a un servidor mediante FTP.

La receta:
  • Yawcam (software para captura imágenes de la web cam)
  • Máquina virtual de java (para Yawcam, ya que está desarrollado en Java)
  • Servidor FTP.
  • Y por supuesto, PHP ;)

Una vez te hayas hecho con todo, hay que configurar en Yawcam el intervalo de las capturas cada 5 segundos (a tu gusto) y el acceso al FTP.

Si ha detectado correctamente tu webcam, accede a Configuración->Editar configuración->Salida->FTP

  • Tipo de archivo: JPG
  • Calidad: 30% (no pongas un valor muy alto para que el tamaño de la imagen no sea excesivo
  • Servidor FTP: mihosting.com
  • Puerto: normalmente 21
  • Usuario: miusuario
  • Contraseña: micontraseña
  • Directorio: /www/webcam (directorio absoluto)
  • Nombre de archivo: webcam.jpg (el archivo se sube cada 5 segundos y sobreescribe el actual, si actualizamos la página que muestra el archivo de captura cada 5 segundos, obtenemos una secuencia casi real por streaming)
  • Intervalo: 5 segundos (a tu gusto)

Bien, ya tenemos configurado el programa. Para activarlo, en el panel de control, FTP->Activar
Haz la prueba para ver si sube el archivo al servidor y se actualiza cada 5 segundos debidamente.

Ahora procederemos a crear el script PHP que se encargará de leer el archivo webcam.jpg y mostrarlo.

Aconsejo crear un archivo .htaccess en el directorio de las imagenes tomadas de la webcam sin permisos de lectura desde los clientes que intentan acceder al recurso donde se aloja el archivo webcam.jpg:

.htaccess

Order Deny,Allow
Deny from all
Options None
AllowOverride None

El siguiente script PHP va a leer el archivo webcam.jpg y lo va a devolver para insertarlo en una etiqueta img de html.

webcam.php

/**
* Aquí puedes incluir código para verificar si el cliente que está accediendo
* al recurso puede leer el archivo webcam.jpg o no
*/
$webcam = "webcam/webcam.jpg";
header("Content-Type: image/jpeg");
header("Content-Length: ".filesize($webcam));
readfile($webcam);

Ahora necesitamos el código html necesario para mostrar la imagen y que se actualice cada 5 segundos

webcam.html

<html>
<head>
<title>Probando webcam</title>
<!-- Le decimos al navegador que no almacene esta página en la caché -->
<meta http-equiv="Pragma" content="no-cache" />
<!-- No tiene fecha de expiración -->
<meta http-equiv="expires" content="-1" />
<!-- El navegador se refresca cada 5 segundos realizando peticiones una y otra vez a esta misma página para mostrar la imagen actualizada -->
<meta http-equiv="refresh" content="5" />
</head>
<body>
<img src="webcam.php" title="Sesión WebCam en directo" alt="Sesión WebCam en directo"/>
</body>
</html>

Y ya esta, es en esencia lo que necesitamos para poder emitir imágenes en semi-directo con nuestra webcam y verlas a través de nuestra página web.
Se puede elaborar de mejor forma dando acceso a usuarios registrados por ejemplo, para ello recurririamos a las variables de sesión para identificar si el usuario que solicita ver la webcam está logueado o no, pero bueno, eso os lo dejo a vosotros.

Espero os sea de utilidad.

Inyectar código directamente en la memoria de otro proceso con C

A continuación expongo el código fuente para cómo inyectar código directamente en la memoria de otro proceso remoto con C, se ha compilado con GNU GCC Compiler en el entorno Code::Blocks 8.02.

Me he tomado la molestia de comentar todo el código para que lo podáis perfeccionar, depurar, cambiar, etc, todo el procedimiento de inyección.

api.h

funcionInyectar.h

funcionInyectar.c


main.c


Espero os sea de utilidad.