Para quien no lo conozca, las Arduino son una plataforma de desarrollo electrónico enfocada al prototipado rápido cuyas especificaciones son totalmente libres. Existen varios modelos de placas para los diseños con características más o menos avanzadas y podremos trabajar con ellas tanto en Windows, Mac OS X ó GNU/Linux, sin tener que usar compiladores y/o herramientas de desarrollo de pago.

La mía es una Arduino MEGA, que es una mejora de la Duemilanove y la Diecimila gracias a su mayor I/O y capacidad de memoria, entre otras cosas. Las specs principales son:

• Microcontrolador Atmel AVR 8-bit MEGA1280 @16MHz
• 128kB FLASH MEM (4kB usados por el bootloader incluído, usado para poder cargar cógido directamente)
• 8kB SRAM
• 4kB EEPROM
• 54 pines digitales (soportan hasta 40mA): I/O, comunicación serie, interrupciones, 8-bit PWM, SPI, I2C, …
• 16 pines de entrada analógica con una resolución de 10bits, útil para todo tipo de sensores.

Lo primero que tenemos que hacer para empezar a jugar es instalar las herramientas necesarias. En el árbol de paquete de Gentoo hay bastante para microcontroladores AVR ($ eix -S avr ) pero si además queremos afinar e ir a por el kit completo para Arduino tampoco tendremos problemas.

Necesitaremos una versión de Java (yo uso sun-jdk-1.6) además de los siguiente paquetes:

# emerge crossdev jikes uisp rxtx

Yo, de antes, ya tenía instalado avra (AVR Assembler) y avrdude (para subir y bajar código a las microcontroladoras) que había usado para trastear con las AVR Tiny2313, ATmega32 y ATmega64 aunque en realidad casi siempre usé el IDE que te proporciona ATMEL de forma gratuita para Windows y alguna vez Bascom-AVR.

Una vez tengamos los paquetes básicos instalados necesitamos generar el toolchain con el que vamos a trabajar para generar código compatible con la arquitectura AVR. Para ello nos ayudaremos de la herramienta crossdev:

# crossdev -t avr -s4 --without-headers

Tardará un ratillo pero una vez termine ya dispondremos de nuestro flamante compilador avr-gcc. Ahora nos bajamos el IDE que nos proporciona Arduino en http://www.arduino.cc/en/Main/Software, lo descomprimimos y lo dejamos por ahora ahí. Dependiendo de versiones puede que algunos tengan que hacer un enlace (por supuesto respetando paths y versiones de tu sistema):

$ ln -s /usr/lib/binutils/avr/2.19.1/ldscripts/ ~/programs/arduino-0017/ldscripts

Dependiendo de distribuciones o la configuración será necesario estar en los grupos tty y uucp, pero para ahorrarte problemas añade el usuario a esos grupos.

Mmmm ¿qué mas necesitamos? Arduino se conecta por USB a nuestro ordenador y el kernel de linux nos proporciona el driver, yo ya lo tenía instalado pero si no:

Device Drivers -> USB support -> USB Serial Converter support -> USB FTDI Single Port Serial Driver (EXPERIMENTAL)

Lo ponemos como módulo, compilamos y lo cargamos:

# make && make modules_install
# modprobe ftdi_sio

Conectamos la Arduino y podremos ver si todo funciona:

# dmesg
usb 4-2: new full speed USB device using uhci_hcd and address 5
usb 4-2: configuration #1 chosen from 1 choice
ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
usb 4-2: Detected FT232RL
usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0

OK!

Volvemos al IDE que ya tenemos descomprimido y lo ejectuamos

$ ./arduino
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ahora sólo nos faltará elegir en la configuración que queremos el /dev/ttyUSB0 y que estamos usando una placa Arduino MEGA, et voilà!

Para probar el funcionamiento haremos un “Hello Word” al estilo electrónica, es decir, hacer parpadear un LED

Hay ejemplos por ahí pero el código sería:

const int ledPin =  13;    // LED connected to digital pin 13
 
void setup()
{
	pinMode(ledPin, OUTPUT); // set pin 13 as output
}
 
void loop()
{
	digitalWrite(ledPin, HIGH);   // set the LED on
	delay(1000);                  // wait for a second
	digitalWrite(ledPin, LOW);    // set the LED off
	delay(1000);                  // wait for a second
}

A ver si busco ratos y hago algo interesante con mi nuevo juguete, ya no hay excusa. Si quieres saber por donde empezar acude a http://arduino.cc

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] La implemetación del driver
• [HOW TO] Cómo recuperar GRUB
• Para los amantes de XKCD llega…

El asunto es que NTFS almacena todo en streams (flujos), cada fichero tiene un stream sin nombre pero puede tener muchos con nombre. El tamaño del fichero será sin embargo el tamaño del stream sin nombre, el principal. Se podría resumir diciendo que ADS son ficheros dentro de ficheros.

Prácticamente ya todo el mundo usa NTFS-3G para acceder desde linux a sus particiones en este sistema de fichero pero por defecto NTFS-3G sólo lee y escribe los flujos de datos sin nombre.

Si queremos acceder a los flujos secundarios tendremos que montar el sistema de ficheros con la opción streams_interface=windows. De este modo podremos acceder a esos datos del modo:

cat file.dat:label1

y de este modo tratarlo como otro fichero más, pudiendo usar directamente el resto de utilidades GNU. Para listar todos los streams que contiene un fichero tendremos que comprobar el contenido del atributo ntfs.streams.list.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Lectores de huellas en linux
• Dejar bonito un server SSH – Parte 1
• [Fprint] Los dispositivos

Una pequeña recopilación de juguetes para escalar privilegios a root desde local. Aprovechan fallos distintos y de distintos tipos. Algunos no tienen por qué funcionar siempre, debido a su idiosincrasia y en realidad los posteo aquí para tenerlos más a mano y recopilados xD

2.6.29 ptrace_attach – shoryuken.c

2.6.x ptrace_attach – xploit_2.6.x.c

<2.6.29 exit_notify – xploit_till2.6.29_exit_notify.sh

2.6.23 ~ 2.6.24 vmsplice – xploit_2.6.23~24_vmsplice

2.6.17 ~ 2.6.24.1 vmsplice – xploit_2.6.17~24_vmsplice

2.6.13 ~ 2.6.17.4 prctl (made in Spain) – xploit_2.6.13~17_prctl.c

2.6.13 ~ 2.6.17.4 prctl & logrotate – raptor_prctl2.c

2.6.13 ~ 2.6.17.4 prctl – raptor_prctl.c

<2.6.17.4 proc – h00lyshit.c

Un poco más de prctl aquí, aquí y aquí, más de lo mismo.

<2.6.11 CPL 0 – k-rad3.c

¡Qué post más scriptkiddie! ¿no?

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• HP Mobile Data Protection System 3D
• [Fprint] Los dispositivos
• Para los amantes de XKCD llega…

Os pongo una lista de conferencias que más me llaman del Fahrplan que hay:

- Solar-powering your Geek Gear: Alternative and mobile power for your all you little toys.

- FAIFA: A first open source PLC tool: PowerLineCommunication has now their open source tool.

- Security Failures in Smart Card Payment Systems: Tampering the Tamper-Proof. Esta para TuXeD

- Chip Reverse Engineering

- Cracking the MSP430 BSL

- Advanced memory forensics: The Cold Boot Attacks: Recovering keys and other secrets after power off.

- Locating Mobile Phones using SS7

- coreboot: Beyond The Final Frontier: Open source BIOS replacement with a radical approach to boot.

- Messing Around with Garage Doors: Breaking Remote Keyless Entry Systems with Power Analysis.

- Algorithmic Music in a Box: Doing music with microcontrollers.

- Anatomy of smartphone hardware: Dissecting contemporary cellphone hardware.

- Scalable Swarm Robotics: Formica: a cheap, open research platform.

- Console Hacking 2008: Wii Fail: Is implementation the enemy of design? Que gran pregunta.

- The Ultimate Commodore 64 Talk: Everything about the C64 in 64 Minutes. Brutal, enlace a su blog http://www.pagetable.com/?p=53

- Predictable RNG in the vulnerable Debian OpenSSL package: the What and the How. Aunque ya esté muy visto… para echarse unas risas.

Me ha llamado la atención lo que han denominado como Lightning Talks, rondas de 10 presentaciones de 4 minutos donde puedes exponer tu idea más descabellada, presentar tu proyecto, enseñar un cacho de hardware que te emocione, etc y así ganar adeptos para colaborar o simplemente echarte unas risas.

Y por supuesto, además de todo lo anterior, workshops sobre microcontroladores, el quadrocopter, etc.

En fin, otro año será, siempre me quedará youtube.com para ver las charlas.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Para los amantes de XKCD llega…
• [Campus Party 08] Taller de antenas y charla sobre servidores
• [Fprint] La implemetación del driver

…el XKCD Retriever!

Esta tarde me comentaba aldraia que quería hacer un script para bajarse todas las imágenes de XKCD y tenerlas ordenadas y tal. El tema es que el tipo las tiene en el servidor en un mismo directorio sin orden (más que la fecha obviamente xD) y se podría hacer un wget -r pero bueno, cuando hay aburrimiento las ganas de hacer algo inútil aumentan.

Habrá mil maneras de hacerlo y esta es una de ellas: xkcd_retriever-v0.1

Tiene opciones para bajar una tira en concreto, bajarlas todas o bajar tantas tiras desde la más nueva. Nuevas opciones serán bienvenidas

ACTUALIZACIÓN: aldraia ha añadido unas cuantas opciones y ha hecho un ebuild para gentoo. La última versión se podrá descargar desde http://geek.eternitat.net/

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• HP Mobile Data Protection System 3D
• Dejar bonito un server SSH – Parte 2
• Port-Knocking y Crypt-Port-Knocking

La lógica dice que para que un capa pueda trabajar de modo asíncrono, todas sus capas por debajo puedan hacerlo y aquí es donde nos encontramos con este problema. Se miró la posibilidad de migrar a OpenUSB, desarrolado por SUN Microsystems, pero al final se descartó por diversos motivos.

¿Qué problemas supone esto? Pues por ejemplo, yo ejecuto una función donde quiero verificar una huella:

r = fp_verify_finger(dev, enroll_data);

El proceso sería activar el dispositivo, libfprint escanearía la huella, se procesan los resultados, se comparan los resultados y se devuelve el resultado de la comparación. Y el problema sería que la ejecución del programa se para hasta que el usuario escanee su huella, ¿y si estuviera alejado del ordenador en ese momento? Por ejemplo una interfaz GUI se quedaría sin responder hasta escanear el dedo. ¿Soluciones? Lo primero que pensamos para evitar este comportamiento sería programa la GUI usando un thread distinto cuando se vaya a escanear pero lo propio sería migrar a libusb-1.0 que permite I/O asíncrono.

Hasta ahora el desarrollo de libusb se encontraba parado así que Daniel Drake, el responsable principal de fprint, que últimamente se ha dedicado a desarrollar y estabilizar la versión 1.0.

Otra posible mejora sería incluir funciones para cancelar las operaciones en curso y otra sería tener un daemon global de sistema que funcionara por ejemplo con DBUS.

Aparte de la propia libfprint disponemos de unos cuantos extras para poder jugar. El primero de ellos sería pam_fprint, que es un módulo de PAM que nos proporciona la posibilidad de autenticación en el sistema. La idea es integrarlo con shadow, GDM y KDM aunque en los 2 últimos existen ciertos problemas por el propio diseño de GDM y KDM. Es un módulo muy básico y su función inicial casifue sólo demostrar el uso de libfprint.

Por último, actualmente disponemos de dos frontends, el primero fprint_demo y el segundo “QT Fingerprint Scanning GUI“.

Después de todos estos posts sobre fprint, ya no tenéis excusa para hacer un #include <fprint.h> y desarrollar vuestros pequeños monstruitos.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Lectores de huellas en linux
• [Fprint] La implemetación del driver
• [Fprint] Los dispositivos

El driver está desarrollado en C, como no, ¿por qué? pues porque:

• es adecuado para programar drivers porque nos proporciona funcionalidad a ‘bajo nivel’ siendo un lenguaje de ‘alto nivel’.
• facilmente podremos crear bindings en c++, java, python, ruby, …
• será fácil luego adaptarlo a sistema embebidos (empotrados, embedded o como se les quieran llamar)

Está implementado en forma de librería y recibe el nombre de libfprint y depende de otras librerías como:

• libusb: nos proporciona I/O al bus USB y además es portable a FreeBSD, Mac OSX, Windows y más.
• glib: un gran librería de rutinas en C de las cuales usaremos unas poquitas (listas enlazadas, operaciones sobre strings, para reservar memoria, etc)

A continuación os pongo un esquema de como está estructurado:

Como se puede ver, tendremos una API de alto nivel donde se nos proporcionan funciones para registrar huellas de dedos (enrollment), verificar (comprobar que la huella escaneada coincide con la almacenada contra la que se ha pedido confirmación) y identificar (encontrar entre las huellas almacenadas una que coincida con la escaneada). La diferencia entre verificar y identificar sería la misma que entre elegir tu nombre de usuario y escanear tu dedo y en lugar de eso escanear tu huella y que el sistema reconozca tu usuario y te confirme.

De estas funciones tendríamos 2 variantes, la que nos devuelve la imagen por si además si quisiéramos hacer alguna cosa con ella y que simplemente realiza su función:

- fp_enroll_finger( )
- fp_verify_finger( )
- fp_identify_finger( )
- fp_enroll_finger_img( )
- …

luego podríamos usar un trozo de código similar a esto:

if (is_imaging_device(dev))
fp_enroll_finger_img(&data, &img);
else
fp_enroll_finger(&data);

Para empezar a usar los dispositivos tendremos disponibles las siguiente funciones que son bastante autoexplicativas:

- fp_discover_devices()
- fp_dev_open() / fp_dev_close()

Para detectar qué dispositivo tenemos es fácil ya que el descriptor del dispositivo incluye un código con el Vendor (fabricante) y el Product ID (identificación de producto) que lo identifica inequívocamente. Por ejemplo, podremos obtener ese código con un simple  ‘lsusb’.

Por debajo de la capa “Imaging layer” para escanear necesitaremos las funciones para detectar la presencia del dedo, escanear y detectar la ausencia de dedo.

Como ya hemos contado en otros posts, el dispositivo upek al ser autónomo no requerirá de estas funciones.

Igualmente dispondremos de una serie de funciones para el almacenamiento.

Para el que quiera entretenerse un rato aquí hay más información sobre la API disponible: http://www.reactivated.net/fprint/api/

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Mejoras en el driver y algunos extras
• [Fprint] Los dispositivos
• [Fprint] Procesado de la imagen – Huellas dactilares

Para el primer grupo de lectores de huellas necesitaremos pues una serie de algoritmos que nos permitan analizar y comparar las imágenes de las huellas dactilares.

A la hora de desarrollar fprint se consideró programar todos estos algoritmos pero ya existían, además en forma de código libre, unas posibles soluciones que ahora veremos.

Pero primero, ¿qué buscamos en una huella dactilar? ¿cuáles son los puntos de interes? En una huella tenemos una serie de crestas y surcos que van dibujando un laberinto en el cual podemos de reconocer ciertos puntos de interés, comunmente llamados minutiae. Lo que tenemos que detectar son principalmente las terminaciones o bifurcaciones de las crestas. Existen otros puntos de interés como: el corazón (centro del patrón de la huella), islas, deltas y discontinuidades. En la siguiente imagen podemos ver un ejemplo de cada caso:

Decía antes que ya existe una colección de herramientas libres que tenían los algoritmos implementados. Se llama NBIS (NIST Biometric Image Software) y fue creada por el grupo de imagen del NIST (National Institute of Standards and Technology). Inicialmente fue desarrollada para el FBI (Federal Bureau of Investigation) y el DHS (Department of Homeland Security) y fue usada para el control del crímen y el control fronterizo respectivamente. Vamos, que cuando vamos a USA y nos escanean las huellas usan este software.

MINDTCT

Dentro del paquete NBIS esta es la herramienta que se usa para detectar las minutiae, como bien su nombre indica: minutiae detector. Antes de buscar los puntos de interés deberemos tratar la imagen para que facilitar esa detección. Se realiza un aumento de contraste en la imagen para binarizarla a 2 colores sólidos. De ese modo las crestas se convertirán en zonas negras sobre blanco. Luego se escanea durante varias pasadas buscando patrones de píxeles. La realidad es que se generan bastante falsos positivos así que seguidamente se eliminan las minutiae de las zonas de la imagen con menos calidad y las que no están claras.

Deberíamos quedarnos no solo con las coordenadas de la minutiae sino también con la dirección de la cresta, que tipo de punto de interés es (bifurcación, terminación, etc, y muy importante un factor de confianza sobre  la formalidad de ese punto detectado.

BOZORTH3

El siguiente paso sería tener la capacidad de concordar diferentes huellas para buscar casos coincidentes y para ello se puede usar este algoritmo. Fue creado por el FBI (un tal Allan S. Bozorth, original, eh?) y detecta coincidencias independientemente de la traslación y rotación de las imágenes. Posteriormente el NIST lo adoptó y lo mejoró. Tiene un umbral configurable para ser más o menos estrictos en las concordancias.

Existe otro sistema open source de procesamiento de huellas digitales, se llama Fingerprint Verification System junto con efinger,  pero no es tan eficaz como el creado por el NIST.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Los dispositivos
• [Fprint] Lectores de huellas en linux
• [Fprint] La implemetación del driver

• aes1610: Authentec AES1610
• aes2501: Authentec AES2501
• aes4000: AuthenTec AES4000
• fdu2000: SecuGen FDU 2000
• upeksonly: UPEK TouchStrip sensor-only
• upektc: UPEK TouchChip
• upekts: UPEK TouchStrip with biometric co-processor
• uru4000: Digital Persona U.are.U 4000/4000B
• vcom5s: Veridicom 5thSense

Poco a poco se van añadiendo modelos, de hecho, inicialmente sólo se dió soporte a 4 modelos distintos así que para ilustrar un poco las características que suelen tener estos cacharros vamos a ver los 4 primeros que se implementaron (empezando por el mio!) :

AuthenTec AES2501

Este es el que tengo yo en mi HP nc6400. Es “swipe-type fingerprint sensor” lo que viene a ser de barrido, es decir el usuario tiene que pasar el dedo y dependiendo de como lo haga la imagen resultante podrá ser distinta. Lo que hace es escanear durante distintos instantes de tiempo el trocito de huella que está encima del sensor en sí y luego presenta al sistema una serie de imagenes en ‘rebanadas’ de 192×16 píxeles en escala de grises. Con esas lonchas de imágenes el driver deberá eliminar el overlap entre los diferentes trozos y juntarlos para obtener la huella. Cuando este sensor viene montado en portátiles a veces se da el caso de que lo han puesto al revés así que, además de eliminar el overlap, se deberá también determinar la dirección de escaneo. Pero nos falta un detalle, digamos que unos dispositivos son más ‘tontos’ que otros, así que en este modelo también se deberá detectar cuando se ha puesto el dedo en el sensor y cuando se ha quitado. (lo cierto es que cuanto más tonto sea el dispositivo más guay porque al no hacer cosas automáticamente podremos hacer más cosas como queramos). Lo cierto es que a pesar que no tener implementadas en hardware funciones para detectar el dedo tiene un modo de captura en el cual devuelve el histograma de la imagen capturada pero SIN transferir los datos de esa imagen. Esto simplifica mucho las cosas porque calculando el area el histograma y teniendo un valor umbral podremos determinar la presencia de un dedo o no.

Respecto a la captura de las imágenes es un poco más complicado que en otros dispositivos, como hemos dicho devuelve una serie de imágenes de 192×16 pero el caso es que vienen codificadas y ordenadas de una forma un poco rara. Gracias a la especificación del fabricante se puede reordenar el churro de bytes y así obtener las imagenes en escala de grises.

Estos dispositivos suelen estar presentes en los portátiles de HP y Fujitsu.

AuthenTec AES4000

Este modelo, a diferencia del anterior es “press-type USB fingerprint sensor” es decir, se coloca el dedo en lugar de arrastrarlo por el sensor. Devuelve una imagen cuadrada en escala de grises al sistema y tiene implementado en hardware funciones básicas para detectar la presencia del dedo. Es bastante común en periféricos autenticadores. Al igual que AES2501 ordena los bits de las imágenes del mismo modo extraño made in AuthenTec.

Su mayor problema es que lleva un sensor muy pequeño, de 223ppi (pixels per inch), comparado otros modelos y con los 500ppi recomendados por los algoritmos de identificación y verificación de huellas (mindtct, del cual hablaremos más adelante) . Originalmente las imágenes que se obtenían eran malísimas pero escalando la imagen antes del procesado se solventa gran parte del desastre.

A continuación el resultado de la binarización de la imagenes con ambos tamaños:

Digital Persona U.are.U 4000B

Es un press-type USB fingerprint sensor también. Usa un sistema optico para capturar una imagen de alta resolución de la huella. Tiene implementado en hardware detección de la presencia del dedo y 2 modos de captura. Este dispositivo lo vende por separado la empresa Digital Persona y se encuentran en varios dispositivos de entrada embebidos de Microsoft. También se vende el módulo sensor por separado que, de hecho, otras empresas han integrado en más de uno de sus productos.

Devuelve imágenes de 8 bits en escala de grises estandar que no requiere de ningún tipo de reordenación como los casos anteriores.

UPEK TouchStrip

Es un “swipe-type USB fingerprint scanner” pero este dispositivo guarda una diferencia clave respecto al resto, lleva un coprocesador biométrico que realiza el procesado de la imagen en hardware y en lugar de presentar una imagen el sistema tan sólo presenta un resultado booleano de autenticación concedida o denegada. Por un lado eso nos ofrece desventajas a la hora de usar los algoritmos que queramos para el tratamiento de imágenes pero por otro nos podría simplificar el sistema a la hora de crear un sistema embebido y la ventaja de poder disminuir el tamaño del driver.

Este dispositivo se puede encontrar en portátiles de IBM/Lenovo, DELL y Toshiba. Existe un driver propietario de UPEK para linux y tambień tenemos disponible el driver Thinkfinger.

En las próximas entregas veremos que algoritmos se usan para tratar las imágenes. Y bueno, no hace falta decir que gran parte de lo que se conoce de todos estos dispositivo es gracias a la ingeniería inversa y a esnifar el bus USB. Si tienes un dispositivo que no esté soportado no dudes enviar tus chorrizos de bytes a la lista de correo de fprint.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] La implemetación del driver
• HP Mobile Data Protection System 3D
• [Fprint] Procesado de la imagen – Huellas dactilares

Ya es bastante común encontrarse con portátiles que llevan incorporado lectores de huellas que pueden ser usados para loguearse u otros menesteres menos útiles, incluso con algún gadget geek para jugar a ser Macgyver.

Históricamente, por algun razón absurda de pensar que es algo tecnólógicamente avanzado, se ha asociado estos dispositivos a las pelis de acción con un espías que entran en la sala super segura de la muerte usando el dedito (a veces se lo curran más y hacen escáneres de retinas y análisis in situ de ADN) pero lo cierto es que la experiencia ha demostrado que la seguridad de estos dispositivos no es tal. Por ello, para cualquiera que se lo plantee, ya lo avanzo: “Jamás uséis un escáner de huellas como método de autenticación a un sistema o servicio que sea crítico o susceptible”. Este sistema se debe usar como añadido (como confirmación extra) para aumentar la seguridad de una clave por ejemplo.

El soporte de estos dispositivos en linux ha sido prácticamente nulo y cojo hasta la llegada del proyecto fprint que ha conseguido dar soporte a la gran mayoría de los dispositivos más extendidos en el mercado. La parte más grande e importante viene en forma de librería (libfprint) que nos permite acceder interactuar estos lectores. En Gentoo el paquete está disponible en el overlay wschlich-testing y existen paquetes para otras distros porque el proyecto ya ha cogido fama, de todas formas no hay mayor problema en descargar las fuentes y compilar directamente.

En los próximos posts nos adentraremos un poquito en como funcionan estos dispositivos y como se ha desarrollado el driver.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Procesado de la imagen – Huellas dactilares
• [Fprint] Los dispositivos
• [Fprint] La implemetación del driver