L-1 Identity Solutions PIER™ 2.3 Iris Scanner Teardown

Introduction⌗

PIER™ (Portable Iris Enrollment and Recognition) is a rugged handheld device that uses the unique patterns and textures of the human iris to enroll and identify individuals. The PIER™ 2.3 can store a database of 100,000 individuals (both left and right eye) and quickly return the identity of the subject. When connected to a Network, the device can identify an individual compared to a database of millions with very high accuracy.

The device was developed around 2005 and as of 2007, over 4000 units were sold to the U.S. Department of Defense. A newer version with twice as much RAM and data storage was launched a year later under the name PIER™ 2.4. The iris scanner was deployed primarily in Afghanistan and Iraq. Among other applications, they were used to identifying local tribal leaders. In addition, biometric data of detainees and civilians were also recorded in order to identify potential threats. This data was then collected in a central database called Automated Biometric Identification System (ABIS).

My device came without any accessories and was in battle-tested condition. After a somewhat longer charging time, I could switch it on, and it turned out that it technically works flawlessly.

How does it work?⌗

The device is equipped with advanced lenses, a grayscale video sensor, dual-band IR illumination and a bright LCD to capture high-quality images of the iris. The integrated Daugman algorithm [wikipedia.org] processes the detailed information in the iris image and converts it into a binary template. This stored template is then used to quickly, accurately, and effectively identify an individual by matching a newly captured iris image to the onboard database. PIER™’s ease of use and speed of identification made it the most effective means of iris identification available at the time.

Specifications⌗

There are several sources from which the device specifications can be determined. However, I could find some deviations from my present device. Therefore, I have gathered all the information and compared it with the real hardware configuration.

Sources:

• PIER™ 2.3 (Product Page) [archive.org]
• PIER™ 2.4 (Product Information) [pdf]

Hardware⌗

Teardown⌗

At this point, many thanks to a good friend who took the photos in a really professional setting.

The device can be taken apart very easily and by all means non-destructively. Only the screen and the keyboard were glued to the housing. Presumably to meet the high requirements of military standards. I only needed three tools for the teardown: a Philips screwdriver, a hex nut driver and a pair of tweezers. There are four screws on the back that must be removed to separate the two housing shells.

Three ports are found on the bottom:

• 5V DC Barrel Jack
• RJ45 100BASE-TX Ethernet
• RJ45 Serial Port

After carefully pulling the two shells apart, the inside of the back part can be viewed. Two IR-permeable plastic windows are glued in there. One is for the LED illumination and the other for the camera.

A total of three circuit boards are installed in the device. The first one is for power supply and has linear regulators to regulate the voltage from 5V to 3.3V for the motherboard as well as to charge the battery to 3.7V. It is connected to the motherboard via a pin strip and is fixed by three screws on hex brass spacers.

The connector for the lithium-ion battery is located on the back. In addition, an PCI interface and a CompactFlash card slot were apparently prepared on the PCB. Probably this is a leftover from the development process or a preparation for another series of devices of a different form factor. The battery consists of two welded 18650 lithium-ion cells. The product page specified a total capacity of 4000 mAh. According to the label, however, the capacity is 4400 mAh. This information can also be found on the manufacturer’s homepage in 2007, which has been shut down in the meantime: EAC.com: Battery Sizes [archive.org]

To remove the motherboard from the camera board, three flat ribbon cables must be removed from the top of the board. These are used exclusively for the touchscreen. The two hex brass spacers in the center of the board can remain screwed in place. They are only parts that are attached to the back with a nut and serve to promote stability.

The main processor is a rom-less AMD Élan™ SC520 microcontroller with a 32-bit low-voltage Am5x86 CPU, a 32-bit PCI bus and a 32-bit SDRAM interface. It was developed both for real-time and PC/AT-compatible embedded applications and has also an integrated FPU and hardware UART. AMD Élan™ SC520-133AC (Product Page) [archive.org] Unlike the industrial version SC520-100AI, the SC520-133AC is for commercial use, which has a narrower temperature range but a higher clock rate of 133MHz instead of 100MHz. I would like to remind you that this device was developed for the DoD and was used, among other things, in desert regions. Therefore, I am surprised by the sloppy selection of components.

Datasheets:

• AMD Élan™ SC520-133AC (Datasheet) [pdf]
• AMD Élan™ SC520-133AC (Manual) [pdf]
• AMD Élan™ SC520-133AC (Product Overview) [pdf]
• AMD Élan™ SC520-133AC (Technical Details) [pdf]
• Xilinx Spartan-II XC2S100 (Datasheet) [pdf]

In addition to the main processor, there is a large Xilinx Spartan™-II XC2S100 FPGA package which delivers 100,000 system gates at speeds of 200 MHz and has 40Kb on-chip RAM. This FPGA is running low-powered at 2.5V and features I/Os that operate at up to 3.3V with full 5V tolerance. Xilinx Spartan-II FPGA (Product Page) [archive.org] By the way, Xilinx now belongs to AMD 🤓 In our case it is used for fast and reliable processing of the image data coming from the camera. A lot of computing power can be offloaded from the CPU to the FPGA this way.

Since the board is a complete PC, there is of course an EEPROM for the BIOS on the board. A TODO on my part is to dump this EEPROM. However, this has not yet been necessary because the ETS operating system also runs with SeaBIOS as described in the QEMU chapter.

A Realtek RTL8139CL [pdf] network chip for 10/100BASE-TX Ethernet and two Samsung K4S511632B-TC75 64Mb B-die SDRAM [pdf] chips are installed on the back of the motherboard. Both SDRAM packages have a total capacity of 128Mb. Again, soldering pads were prepared on the PCB to have the possibility to add more RAM to the device in the future. The PIER™ 2.4, a second revision of the device with 256Mb RAM, has four packages soldered. The network chip supports Wake-On-LAN and has power management capabilities, it is connected via PCI.

In the upper right part of the board, there is a Sharp LZ9FC22 TFT-LCD Timing Control IC [pdf], which is used to drive the LCD. It seems to be an industrial version. Furthermore, underneath the ribbon cable which is connected to the LCD there is an Epson SED1376F0A Controller IC [pdf] that can display text and graphics on the LCD panel. It stores text, character codes and bit-mapped graphics data in external frame buffer memory. Presumably the Epson IC is used like a GPU to create the graphics and the Sharp IC is used to generate the LCD timing signals.

On the top of the camera board, the lens is screwed on with two screws. The camera sensor is an OmniVision OV7120 1/3" 8-bit grayscale CMOS [pdf]. It has a sampling rate of up to 60 FPS and a VGA resolution of up to 640x480 pixels. This CMOS can be controlled via a Serial Camera Control Bus (SCCB), a serial working 3-wire bus system, comparable to an I2C bus. Via the SCCB, which was developed by OmniVision, a CMOS functions such as color saturation, brightness, contrast, white level, exposure time and other parameters can be controlled. Fortunately, the SCCB configuration parameters are stored in the file CMSETUP.I2C. Otherwise, I would never have found out which kind of sensor is behind the lens. There is another identical sensor, OV7620, which can take pictures in 16-bit color.

However, the B/W version used in the PIER™ is four times more sensitive to light, because with the same number of pixels, all four are used for the B/W image instead of one pixel per basic color and one for the light intensity. The CMOS can be programmed to write its image data directly into external RAM. An FPGA can then access the allocated memory area and perform an analysis of the image material. The result is then used by the CPU in the user program. For the time, a highly integrated sensor was installed here.

On the back of the camera board is the CompactFlash slot with a 256Mb SanDisk SDCFB-256-201-00 CompactFlash (Standard Grade) installed. Ardence has put a sticker on it to indicate that it holds the ETS system. As already mentioned in the case of the CPU, it is remarkable that this is not an industrial version. The CF card contains the entire operating system and the entire database, including all iris records. Later on, we will dump this card and boot the system with QEMU on a x86_64 Linux computer.

I would have expected to see a CompactFlash card like shown below. It has not only a higher temperature tolerance, but also a longer life in terms of write cycles. Probably, the “Industrial Grade” version was much more expensive at the time.

The keyboard and display are glued into the housing to prevent dust and water from getting inside.

Overall, the device has a very tidy appearance and achieves very good repairability through the use of standard screws and as little adhesive as possible. In addition, the CF card slot even gives the device an upgrade option. Only the wildly mixed use of consumer and industrial hardware seems inappropriate for a MIL-SPEC device. The intention here was apparently to save money.

Software⌗

Operating System⌗

The PIER™ 2.3 runs Phar Lap ETS®, a fully Win32 compliant real-time operating system. Originally, ETS was created by Phar Lap Software, Inc [wikipedia.org] a software company founded in 1986, specialized in DOS software development. Phar Lap is now part of IntervalZero [wikipedia.org], formerly Ardence [wikipedia.org], which continues the further development of ETS. Currently, the OS is used for instance on LabVIEW real-time targets.

Ardence described the operating system’s features back in 2007 as follows:

• Real-time file system: High-speed media access with FAT16 and FAT32 support
• Fully Win32 compliant: No need to use code wrappers for API mapping
• Complete IA32 x86 support: 386, 486, Pentium I, II, III, 4, Multicore, M, Xenon, as well as AMD CPUs
• Smallest operational footprint: < 500 KB with I/O graphics and TCP/IP
• Support for all standard BIOS implementations: Support includes ACPI-compliant PIC and uniprocessor APIC
• Integrated WinSock-compliant real-time TCP/IP stack: Fully Windows independent

The device has a fully functional BIOS, which boots the ETS from a CompactFlash card.

As can be seen in the diagram, there are architectural parallels to the RTOS from Espressif, which runs on the very well-known microcontroller ESP8266. The software developer writes a program and bundles the entire operating system in his IDE into a runnable image.

Phar Lap ETS - Real-time Operating System (Product Information) [pdf]

Device Features⌗

The device has a built-in FTP server that allows the user to access and manage the entire root file system of the device over an unsecured remote connection. It also has a self-updater that runs automatically at boot and attempts to pull a zip archive from a predefined FTP location.

In addition, it also includes an embedded web server written in C++, which is part of a never-released MJPEG-like camera live feed demo. Which, if it’s functional, allows the user to watch a live video stream from the device using a simple web browser. Probably, this was a preparation to be able to operate the device in a tethered environment connected to a laptop or a central server, like its sister device PIER™-T (Product Information) [pdf].

In addition, the device responds to ICMP packages, commonly known as “ping”, to check if the device is online and reachable on a network. The settings menu is secured by a password to ensure that only authorized users can access and make changes to the device’s settings. There is also an option allowing records to be stored in an encrypted manner, but the default setting is sadly unencrypted. In total, the device has two large databases: one for records of individuals and another for IrisCodes.

Screenshots⌗

After the device is turned on, it beeps and displays the following boot screen.

After a while, the main menu appears. From here, we can register or identify a new person. Furthermore, we can access the system settings and the help menu. Last but not least, the device status can be displayed which includes information about the storage space, serial number and device version, as well as the battery charge.

Unfortunately, the help page is completely useless on my device, since all references lead nowhere. Only this help overview is displayed.

In the setup screen, classic options such as date, time and network address can be set. If you want to make the device use DHCP, the IP needs to be set to 255.255.255.253. Additionally, the version of the iris recognition software can be selected, the system can be rebooted, and security options can be configured here.

In the security settings, it is possible to reset the database and set a master key for its optional encryption. Furthermore, the setup menu password can be changed here.

In the Enroll Menu, a new record including iris can be created. Three images of one iris each are taken for this purpose. These are stored in a database under a unique IrisCode. Another database holds the information about the individual, including first and last name, which eye was enrolled and a reference to the corresponding IrisCode. Optionally, a comment can be added to the record.

The Recognition Menu works similarly to the Enrollment Menu, but it is used to identify a subject. After scanning the iris, if a match is obtained, the information about the person is displayed.

The user interface has been kept very simple and has no complex graphical elements. This is surely very beneficial for the intended use of the device. However, I do not understand the purpose of the touchscreen. Not a single menu has been designed for being used with a touchscreen. Except for the big gray button in some menus, the integrated keyboard has to be used for any practical use. Furthermore, it looks like the software was originally developed for command line use and then expanded to include the utilization of a display. Weird, but functional.

Folder Structure⌗

The FAT16 file system contains a total of 159 files, all of them have an 8.3 filename [wikipedia.org]. This means that the name of the file can be a maximum of 8 letters and the extension 3 letters long. The application and its configuration files, as well as assets like a splash screen bitmap, are located in the root.

There are 7 folders located in the root directory:

• BACKUP: All default configurations are stored here. To reset the device or to start an initial setup, the files are simply copied into the root directory and, if available, the old ones are overwritten.

• DATA: Both databases are located in this folder. One stores the records and the other the IrisCodes.

• DOS: Since the ETS kernel still needs the right tooling to do useful things, all programs belonging to the operating system are located here.

• HTML: Here are some C++ files and assets for a MicroWeb demo application. Probably part of the already described prototype web application.

• IMAGES: The existence of this folder is unknown to me. Normally, no photos of the iris are kept. But maybe, this can be changed by a setting. Then I could imagine that the photos of the iris would be stored here.

• TMP: This folder is empty, and if I understood right, it’s used during the enrollment process to calculate the IrisCodes from the raw image material.

• UTIL: This is where the developers put their own tools. Most of the files belong to the Realtek network chip.

For copyright reasons I cannot upload the file system image. Nevertheless, I have attached the file list below for closer examination.

├── 240X320.BMP
├── ADVASCRN.BMP
├── AUTOEXEC.BAT
├── AUTOEXEC.FPY
├── AUTOEXEC.HD
├── BACKUP
│   ├── 8139C.CFG
│   ├── CMSETUP.I2C
│   ├── MFGONCE.BAT
│   ├── NETDIG.INI
│   ├── NET.INI
│   ├── NET.INS
│   ├── NET.MFG
│   ├── NETVID.INI
│   ├── STRTONCE.BAT
│   ├── STRTONCE.CMD
│   ├── WATTCP.CFG
│   ├── WATTCP.MFG
│   └── X8139C.CFG
├── CMSETUP.I2C
├── COMMAND.COM
├── DATA
│   ├── MASTER1K.F02
│   ├── RECFIL1K.F02
│   ├── UPDATED.TXT
│   └── XUPDATED.TXT
├── DEMOAI.DLL
├── DISKMON.BIN
├── DISKMON.STD
├── DISKS24.BIN
├── DLLTABLE.DLL
├── DOS
│   ├── ANSI.SYS
│   ├── ATTRIB.EXE
│   ├── CHKDSK.EXE
│   ├── COMMAND.COM
│   ├── DELTREE.EXE
│   ├── DISKCOMP.EXE
│   ├── DISKCOPY.EXE
│   ├── DISKVIEW.EXE
│   ├── DOS.SYS
│   ├── EMM386.EXE
│   ├── FDISK.EXE
│   ├── FIND.EXE
│   ├── FORMAT.EXE
│   ├── GETKB.EXE
│   ├── HIMEM.SYS
│   ├── INSTBOOT.EXE
│   ├── INTERSVR.EXE
│   ├── LABEL.EXE
│   ├── LOADHIGH.EXE
│   ├── MEM.EXE
│   ├── MODE.EXE
│   ├── MORE.EXE
│   ├── POWER.SYS
│   ├── RAMDISK.SYS
│   ├── ROMCLONE.SYS
│   ├── ROMDRIVE.SYS
│   ├── RTSPKT.COM
│   ├── SERDRIVE.SYS
│   ├── SETNET.EXE
│   ├── SHARE.EXE
│   ├── SORT.EXE
│   ├── SYS.EXE
│   ├── TREE.EXE
│   ├── VDISK.SYS
│   ├── VDRIVE.SYS
│   └── XCOPY.EXE
├── DOSBOOT.EXE
├── DOS.SYS
├── E1STSCRN.BMP
├── E2NDSCRN.BMP
├── ENRLSCRN.BMP
├── ENRTSCRN.BMP
├── F.BAT
├── FTP.CMD
├── FTP.EXE
├── HELP1.BMP
├── HELPF1.BMP
├── HELPF2.BMP
├── HELPF3.BMP
├── HELPF4.BMP
├── HELPF5.BMP
├── HELPF9.BMP
├── HELPFN.BMP
├── HELPMENU.BMP
├── HLPMENU2.BMP
├── HTML
│   ├── HTMLTEST.C
│   ├── HTMLTEST.DLL
│   ├── IMAGE.JPG
│   ├── INDEX.HTM
│   ├── PAUSE.GIF
│   ├── PLAY.GIF
│   ├── SEARCH.HTM
│   ├── STOP.GIF
│   ├── XIMAGE.HTM
│   └── YIMAGE.HTM
├── HTMLTEST.DLL
├── IMAGES
├── IRIS2PI.DLL
├── ISB8VERY.BIT
├── IVAJPEG.DLL
├── MACHINE.INI
├── MAINSCRN.BMP
├── MATRIX1.BMP
├── MATRIX2.BMP
├── MFGDONE.BAT
├── MLOGO240.BMP
├── MLOGO241.BMP
├── MLOGO242.BMP
├── NET157.INI
├── NET164.INI
├── NET167.INI
├── NETDIG.INI
├── NET.INI
├── NET.INS
├── NET.MFG
├── NETVID.INI
├── ONLDEBUG.DLL
├── PING.EXE
├── PR156B.EXE
├── PR156.EXE
├── PR157.EXE
├── PR164.EXE
├── PR167.EXE
├── PV11.EXE
├── PV11M157.ZIP
├── PV11UTIL.DLL
├── RCOGSCRN.BMP
├── RCOTSCRN.BMP
├── RUNIT.BAT
├── RUNNOW.BAT
├── RUNWAIT.BAT
├── SEBAD.BMP
├── SECRSCRN.BMP
├── SECUSCRN.BMP
├── SEENAUTO.BMP
├── SEENROLL.BMP
├── SEGOOD.BMP
├── SEMAIN.BMP
├── SETMSCRN.BMP
├── SETRSCRN.BMP
├── SETSSCRN.BMP
├── SETUSCRN.BMP
├── SLOGO160.BMP
├── SLOGO240.BMP
├── SLOGO241.BMP
├── SLOGO242.BMP
├── SLOGO256.BMP
├── START0.BAT
├── STRTDONE.BAT
├── STRTONCE.BAT
├── TMP
├── UTIL
│   ├── 8139C.CFG
│   ├── PCITOOL.EXE
│   ├── PG8139.EXE
│   ├── PGEM.BAT
│   ├── PKUNZIP.EXE
│   ├── PKZIP.EXE
│   ├── SETMAC.EXE
│   ├── SETMACS.EXE
│   └── X8139C.CFG
├── WATTCP.CFG
└── WATTCP.MFG

7 directories, 159 files

Booting Phar Lap ETS in QEMU⌗

First, we need to remove the CompactFlash card from the device and insert it into a CF card reader. Now we can use dd to make a bit-precise image of the memory card. In my case, the card was mapped to /dev/sdb. The location can change depending on your system configuration and may be found out via lsblk in case of doubt.

# dd if=/dev/sdb of=/root/pier.img

Since the image contains not only the main file system of the PIER™ 2.3 but also the boot records, we need to determine the offset of the system partition.

# fdisk -l pier.img
Device     Boot Start    End Sectors   Size Id Type
pier.img   *       32 501247  501216 244.7M  6 FAT16

So the system partition starts in sector 32. Now to calculate the offset, we have to multiply the sector number with the sector size in bytes. Since we did not give dd a setting for the sector size when reading, in our case it is the default size of 512 bytes. This results in an offset of 32 * 512 = 16384 bytes. With the help of this offset, we can mount the image under /mnt.

# mount -o rw,loop,offset=16384 /root/pier.img /mnt

To go deeper into the analysis of the software on the PIER™ 2.3, it is also possible to emulate the i386 architecture in a virtual machine through QEMU. Since I instruct QEMU not to start any graphical output with -nographic, it is possible to observe the entire boot process.

# qemu-system-i386 -drive format=raw,file=pier.img -m 128M -nographic

Starting Embedded DOS-ROM...

[C:\]prompt $p$g
C:\>rem c:\dos\getkb.exe 1 "1 for optional startup modes, 0 or kbhit is standard
: "

C:\>rem if errorlevel 1 goto strttest
C:\>path c:\;c:\dos
C:\>if exist net.std copy c:\backup\net.ini net.ini
C:\>if exist net.std del net.std
C:\>if exist strtdone.bat goto start0b
C:\>goto start0b

C:\>if exist start0.bat call start0
C:\>call start0

C:\>if not exist PR167.EXE goto start0b

C:\>dosboot diskmon.bin -appname PR167.EXE -nowaithost
DOSBoot: 10.0 -- Copyright (C) 1986-2000 Phar Lap Software, Inc.

The only catch at the time of my analysis is the missing possibility to fake the native display or the serial interface in QEMU. Therefore, I was only able to use the debugging interface of the ETS kernel which is called ETS Monitor.

Accessing the Database⌗

On the PIER™ 2.3 there are two large files containing information under /DATA. The Python script below was written to read the RECFIL1K.F02 file. To be honest, this is not a real database format, but a simple series of structs dumped to a file comparable to a flat file database. This method is a very simple approach, but only suitable for small amounts of data. The larger this file gets, the slower the device performance becomes. There is no way to search in the file without reading it completely. There is no sorting, because the data structures are appended to the file during an enrollment.

#!/usr/bin/python

# RECFIL1K.F02 has a chunk size of 128 bytes
# Each chunk contains a struct with following members:
# 16-bytes: "First Name"
# 16-bytes: "Last Name"
#  2-bytes: "Eye Side (L/R)"
# 30-bytes: "ID"
# 64-bytes: "Comment"

import sys
import struct
from tabulate import tabulate

data = [ ]

try:
    with open(sys.argv[1], 'rb') as f:
        while True:
            raw = f.read(128)
            if len(raw) != 128:
                break
            ln, fn, ey, cm, id = struct.unpack('@16s16s2s30s64s', raw)

            id_str = id.decode('ASCII')
            fn_str = fn.replace(b'\xff', b'').decode('ASCII')
            ln_str = ln.replace(b'\xff', b'').decode('ASCII')
            ey_str = ey.replace(b'\xff', b'').decode('ASCII')
            cm_str = cm.replace(b'\xff', b'').replace(b'\xf0', b'').decode('ASCII')

            data.append([fn_str, ln_str, id_str, ey_str, cm_str])

    print(tabulate(data, headers=["No.", "First Name", "Last Name", "ID", "Eye", "Comment"], showindex="always", tablefmt="simple"))
except:
    print("Can't read file!")

Default Passwords⌗

Since the developers have, in an exemplary manner, stored several default configuration files on the device, it was quite easy to get the two default passwords. The joke is that both passwords, even if they are changed by the user, are stored in plain text in a file.

Built-In FTP Server Login

root:root

System Setup Password

shadow

Conclusion⌗

I think this is a very exciting device with great hardware. I especially liked the different free soldering pads and markings on the PCB, which give an idea of the iterative development process. Similar hints can be found in the software. The incompletely developed and never released web demo of the iris scanner still makes me smile. I was surprised about the mix of consumer and industrial components. This is not what I expected in a MIL-SPEC device. I was shocked at the general security measures in the software. If I’m going to offer a database encryption, why the heck isn’t that set default? And why are passwords stored in plain text in a configuration file? Any IT-savvy guy who gets his hands on such a device can read the CF card and get full access to all sensitive information on it. Hopefully, recent devices are designed to be much more secure…

Anyway, maybe I’ll install Linux on it later. Bye!

Disclaimer: All information in this article should be used responsibly.