RFID & NFC Hacking #1: Flashear el firmware Iceman en la Proxmark3

Temporada 1 · Entrega 1. De una Proxmark3 Easy con firmware de 2016 a Iceman, con comandos explicados desde cero, los fallos encontrados y la verificación final de ambas antenas.

Empezamos por el principio: preparar nuestra herramienta

Esta es la primera entrega de RFID & NFC Hacking desde cero. Vamos a aprender juntos, desde conectar una herramienta al ordenador hasta entender protocolos y evaluar sistemas completos de laboratorio. No hace falta saber clonar una tarjeta ni conocer criptografía para empezar.

Hoy no vamos a leer ni modificar tarjetas. El objetivo de esta entrega es dejar preparada la Proxmark3: identificar el equipo, comprobar cómo lo detecta Linux, averiguar qué firmware lleva y, después de verificar su compatibilidad, instalar Iceman y comprobar el resultado.

Usaremos únicamente material propio o entornos expresamente autorizados. Tener una herramienta capaz de interactuar con una credencial no concede permiso para probar sistemas ajenos.

Antes de comprar: no todo lo que pone RFID sirve

La Proxmark3 es una plataforma de investigación de RFID. Trabaja con tecnologías LF y HF; en nuestra serie utilizaremos etiquetas de 125 kHz y tarjetas de 13,56 MHz. Un lector USB que introduce un número como si fuera un teclado, un módulo RC522 o un lector NFC basado en PN532 no es una Proxmark3 y no admite este firmware por el mero hecho de leer RFID.

También hay varias revisiones y derivados de Proxmark3. La compatibilidad depende de la placa, el microcontrolador, la memoria, la FPGA y el soporte del proyecto, no del color de la carcasa ni del nombre comercial del anuncio.

Firmware, cliente y bootloader: tres piezas distintas

• Firmware: el programa que se ejecuta dentro de la Proxmark3.
• Cliente: el programa que ejecutamos en el ordenador para comunicarnos con ella.
• Bootloader: el código de arranque que interviene en la carga y actualización del firmware. Modificarlo requiere especial cuidado.

Cuando hablamos de Iceman, nos referimos aquí al proyecto RfidResearchGroup/proxmark3. Su documentación recomienda mantener cliente y firmware sincronizados. Comprar una unidad preflasheada no significa que cualquier cliente descargado después vaya a ser compatible.

Qué modelos considerar

Esta tabla resume la documentación oficial de parámetros de compilación, consultada el 10 de septiembre de 2026. No sustituye la identificación del ejemplar que tengamos delante.

Los 512 KB de flash del microcontrolador no son lo mismo que la memoria SPI externa de ciertas placas. Pedir simplemente «más memoria» al vendedor puede llevar a confusión.

El dispositivo que usamos en este laboratorio

Para esta serie utilizamos una Proxmark3 Easy de 512 KB, comprada en AliExpress. Es una alternativa económica a la RDV4, con antenas LF y HF y conexión USB al ordenador.

Nuestra unidad incorpora un AT91SAM7S512 Rev A, con 512 KB de flash y 64 KB de SRAM, confirmado mediante el cliente Proxmark3. Para preparar Iceman usamos el objetivo de compilación PM3GENERIC. Más adelante veremos cómo consultar esos datos en tu propio dispositivo antes de seleccionar el firmware.

El equipo llegó con firmware de 2016. Ese será nuestro punto de partida: comprobar su funcionamiento y preparar la actualización a Iceman, documentando cada paso y los problemas que encontremos.

Alternativas de compra con documentación y soporte

• Proxmark3 Easy de KSEC: su ficha anuncia 512 KB de flash ARM y bootloader y firmware Iceman preinstalados y comprobados. Es una opción a considerar para empezar sin realizar la migración inicial desde un firmware de fábrica desconocido. Sigue siendo necesario preparar un cliente compatible.
• Proxmark3 RDV4.01 de Lab401: alternativa de la plataforma RDV4, con antenas modulares y opciones de expansión. La ficha enlaza el proyecto RRG para compilación y flasheo. Antes de comprar, confirma con la tienda la versión de firmware que entrega y el cliente recomendado; en la ficha consultada no hemos verificado una promesa explícita de entregar una versión concreta de Iceman.

No hace falta comprar la opción más cara para aprender lo básico. Una Easy compatible de 512 KB puede ser suficiente para los primeros laboratorios; una RDV4 aporta prestaciones de hardware que no aparecen al flashear una Easy. Las condiciones y versiones de las tiendas pueden cambiar.

Paso 1. Conectar la Proxmark3 sin modificar nada

Necesitamos el dispositivo, sus antenas y un cable USB de datos. Que se enciendan los LEDs solo demuestra alimentación, no comunicación con el ordenador.

En la unidad utilizada en este laboratorio también hay que accionar el pequeño botón de encendido para dejarla encendida. No des por hecho que conectar el cable basta: comprueba que has activado el equipo antes de buscarlo con lsusb. Durante nuestras pruebas la dejamos apagada y eso provocó una parte del diagnóstico de «dispositivo no detectado».

Esta indicación corresponde a nuestra variante Easy, no a todas las Proxmark3. No confundas el encendido con mantener el botón de usuario al conectar para entrar en bootloader, procedimiento que explicaremos en la actualización. No pulses botones ni desconectes el cable mientras se escribe firmware.

En nuestro caso la primera conexión se hizo a un USB delantero del PC. Había dudas sobre ese puerto, así que empezamos comprobando si el sistema enumeraba el dispositivo. Para actualizar firmware usaremos una conexión fiable: si hay dudas sobre el panel frontal, es preferible probar un puerto trasero directo a la placa base y un cable conocido.

En una terminal de Linux ejecutamos:

lsusb

lsusb lista los dispositivos USB que conoce el sistema. Esta es la línea real correspondiente a nuestra Proxmark3, extraída de la salida completa:

Bus 003 Device 032: ID 2d2d:504d proxmark.org Proxmark3

El identificador USB observado es 2d2d:504d. Los números de bus y dispositivo pueden cambiar al reconectar. Esta línea confirma que hay comunicación USB, pero no identifica por sí sola la revisión de placa, la capacidad de flash ni el firmware instalado.

Si no aparece ningún dispositivo nuevo, revisamos cable, puerto y conexión física antes de instalar firmware. No tiene sentido intentar resolver un problema de alimentación o de cable con un flasheo.

Paso 2. Localizar el puerto de comunicación

Para localizar el puerto sin adivinar su nombre, listamos los enlaces que Linux ha creado para los dispositivos serie identificados:

ls -l /dev/serial/by-id/

La opción -l muestra el listado detallado y, en los enlaces simbólicos, el destino al que apuntan. Esta fue la salida de nuestra comprobación:

total 0
lrwxrwxrwx 1 root root 13 sep 10 12:23 usb-proxmark.org_504d-if00 -> ../../ttyACM0

La entrada usb-proxmark.org_504d-if00 corresponde a nuestra Proxmark3. La flecha -> ../../ttyACM0 indica que el enlace apunta a /dev/ttyACM0: los dos .. suben desde /dev/serial/by-id/ hasta /dev/. Al unir el directorio consultado con el nombre de la entrada obtenemos la ruta completa:

/dev/serial/by-id/usb-proxmark.org_504d-if00

Para inspeccionar sus propiedades ejecutamos:

udevadm info --query=property --name=/dev/serial/by-id/usb-proxmark.org_504d-if00

udevadm consulta la información que Linux mantiene sobre el dispositivo. Estas son algunas líneas reales de la respuesta:

DEVNAME=/dev/ttyACM0
ID_VENDOR_ID=2d2d
ID_MODEL_ID=504d
ID_USB_DRIVER=cdc_acm

En esta conexión el puerto es /dev/ttyACM0 y el controlador es cdc_acm. El cliente usará ese puerto para comunicarse con la Proxmark3. En otro ordenador, o tras reconectarla, la numeración puede ser diferente. Si el enlace por identificador no existe en tu sistema, habrá que localizar la interfaz que realmente haya creado; no copies nuestra ruta a ciegas.

Crear el puerto no demuestra todavía que nuestro usuario pueda abrirlo ni que un cliente pueda intercambiar comandos con el firmware. Esas son comprobaciones separadas.

Paso 3. Buscar errores de conexión, sin confundir permisos con averías

Para buscar eventos recientes ejecutamos:

journalctl -k --since "10 minutes ago" --no-pager --grep='(?i)usb|cdc_acm|ttyACM|proxmark' -n 70

Este comando consulta mensajes del kernel de los últimos diez minutos, filtrados por términos relacionados con USB y el puerto serie. El resultado de nuestra sesión fue:

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

Esto no demuestra que no existan errores USB. El aviso indica que no teníamos acceso suficiente a los registros. La detección USB funciona, pero no podemos descartar desconexiones recientes a partir de esa consulta.

Repetimos la consulta con permisos administrativos autorizados:

sudo journalctl -k --since '2 hours ago' --no-pager --grep='(?i)3-14|ttyACM|cdc_acm|proxmark' -n 60

El filtro 3-14 corresponde a nuestra conexión inicial, no a una ruta universal. Extractos reales, sin el nombre del ordenador y ordenados cronológicamente:

11:38:16 usb 3-14: device descriptor read/64, error -110
11:38:17 cdc_acm 3-14:1.0: ttyACM0: USB ACM device
11:38:33 usb 3-14: USB disconnect, device number 29
11:38:53 usb 3-14: device descriptor read/64, error -110
11:38:53 cdc_acm 3-14:1.0: ttyACM0: USB ACM device

Durante estas pruebas desconectamos y reconectamos el cable de forma intencionada. Las entradas USB disconnect corresponden a esas acciones, no son evidencia de desconexiones espontáneas. -110 es un timeout durante la identificación USB; su presencia en este contexto no demuestra por sí sola una avería. Cambiamos al USB trasero y consultamos de nuevo el registro:

sudo journalctl -k --since '5 minutes ago' --no-pager --grep='(?i)usb|ttyACM|cdc_acm' -n 45

Extracto real, sin hostname:

12:21:18 usb 3-14: USB disconnect, device number 32
12:21:33 usb 3-8: device descriptor read/64, error -71
12:21:49 usb 3-8: new full-speed USB device number 46 using xhci_hcd
12:21:50 cdc_acm 3-8:1.0: ttyACM0: USB ACM device

-71 indica un error de protocolo USB observado durante la conexión. Después el equipo enumeró y respondió a consultas. Para valorar la estabilidad necesitamos observarlo sin manipular el cable, separando esa prueba de los cambios de puerto y cable que estamos realizando.

La comprobación posterior sí confirmó la reconexión con el cable cambiado. Extracto real, sin hostname:

12:23:27 usb 3-8: USB disconnect, device number 46
12:23:29 usb 3-8: new full-speed USB device number 47 using xhci_hcd
12:23:44 usb 3-8: device descriptor read/64, error -110
12:23:45 cdc_acm 3-8:1.0: ttyACM0: USB ACM device

Este registro también corresponde a una reconexión manual. Estos eventos por sí solos no demuestran una inestabilidad persistente del dispositivo. Tampoco podemos asegurar que retirar el cable explique todos los timeouts. La comprobación sin manipular el cable se describe en el paso 8, separada de estos cambios de conexión.

Paso 4. Comprobar Linux, permisos y posibles interferencias

Dependencias de diagnóstico

En Debian, Ubuntu y Kali, fuser pertenece al paquete psmisc y mmcli al paquete modemmanager. Podemos comprobar si los comandos están disponibles con:

command -v fuser
command -v mmcli

Si falta fuser, instalamos su paquete:

sudo apt-get update
sudo apt-get install --no-install-recommends psmisc

mmcli permite consultar ModemManager. Si necesitas esa herramienta, se instala con:

sudo apt-get install --no-install-recommends modemmanager

ModemManager no es una dependencia de Proxmark3. Instalar ese paquete también incorpora el servicio que queremos comprobar y puede activarlo. Si no está instalado y no lo necesitas para un módem, no lo añadas solo para este laboratorio: omite mmcli -L y los pasos para detener/restaurar ese servicio. En nuestro PC ambos paquetes ya estaban instalados; estos comandos de instalación se incluyen para quien no disponga de ellos.

Comprobaciones

El entorno real es Debian GNU/Linux 13 (trixie), 13.6. La sesión pertenece al grupo dialout. Comprobamos permisos y posibles procesos que ocupen el puerto:

id
stat -Lc '%n %a %U %G' /dev/serial/by-id/usb-proxmark.org_504d-if00
fuser -v /dev/ttyACM0
systemctl is-active ModemManager
mmcli -L

El puerto tiene permisos 660, propietario root y grupo dialout. fuser no mostró procesos, ModemManager respondió active y mmcli -L devolvió No modems were found. No necesitamos cambiar permisos ni añadir grupos.

ModemManager puede sondear puertos serie e interferir con Proxmark3. En nuestras consultas lo detuvimos temporalmente y lo restauramos al terminar, sin desinstalarlo, deshabilitarlo ni alterar su configuración permanente. En otro equipo hay que comprobar antes que no se depende de un módem para la conexión. Antes de cualquier futuro flasheo volveremos a garantizar que no interfiere; que esté libre el puerto en una consulta aislada no es suficiente.

Paso 5. Preparar y compilar Iceman, sin flashear

No había un cliente Proxmark3 ni compilador ARM en el PATH. Sí estaban disponibles GCC, Make, Git y pkg-config. Siguiendo la documentación de Linux de RRG, simulamos primero la instalación y después instalamos las dependencias que faltaban:

sudo apt-get --simulate install --no-install-recommends git ca-certificates build-essential pkg-config libreadline-dev gcc-arm-none-eabi libnewlib-dev qt6-base-dev libbz2-dev liblz4-dev zlib1g-dev libbluetooth-dev libpython3-dev libssl-dev libgd-dev
sudo apt-get install -y --no-install-recommends libreadline-dev gcc-arm-none-eabi libnewlib-dev qt6-base-dev liblz4-dev libbluetooth-dev libgd-dev

La segunda orden refleja nuestro equipo: los demás paquetes ya estaban instalados. En una instalación limpia hay que instalar la lista completa. Se añadieron 27 paquetes, sin actualizar ni eliminar paquetes existentes. La simulación avisó de fuentes APT duplicadas preexistentes; no cambiamos repositorios, no hicimos una actualización general ni ejecutamos autoremove.

Descargar el código oficial con Git

Usaremos Git, sin necesitar GitHub CLI (gh), una cuenta de GitHub ni un token. Si no lo tienes instalado:

sudo apt-get install --no-install-recommends git ca-certificates
git --version

El repositorio oficial es https://github.com/RfidResearchGroup/proxmark3. Un repositorio contiene el código del proyecto y su historial de cambios; clonarlo descarga una copia a nuestro ordenador.

Estos pasos reproducen la descarga con Git y guardan el código en nuestra carpeta personal, en lugar de usar una ruta temporal del laboratorio:

mkdir -p "$HOME/rfid-lab"
cd "$HOME/rfid-lab"
git clone https://github.com/RfidResearchGroup/proxmark3.git proxmark3
cd proxmark3

• mkdir -p crea la carpeta de trabajo si no existe. $HOME representa tu carpeta personal.
• cd cambia el directorio en el que trabajamos.
• git clone descarga el repositorio de la URL completa y crea la subcarpeta proxmark3. No instala programas ni flashea el dispositivo.
• El último cd nos sitúa dentro del código descargado: $HOME/rfid-lab/proxmark3.

Si Git avisa de que proxmark3 ya existe y no está vacía, no la borres: comprueba si ya contiene tu copia del proyecto antes de continuar.

La revisión utilizada en nuestro laboratorio fue 0884083530e2bab92499c4ae5db040eff5d99c97. Para trabajar con ese mismo código, en vez de una versión que haya cambiado desde la publicación, seleccionamos ese commit y comprobamos el resultado:

git checkout --detach 0884083530e2bab92499c4ae5db040eff5d99c97
git log -1 --format='%H %cs %s'

Un commit identifica una versión concreta del código. El aviso detached HEAD es normal aquí: estamos trabajando sobre esa versión, no siguiendo los cambios de una rama. git log -1 muestra el último commit seleccionado; %H imprime su identificador completo, %cs su fecha y %s su descripción. Comprueba que el identificador coincide antes de compilar.

Crear el archivo de configuración

Vamos a crear un archivo llamado Makefile.platform dentro de la carpeta del proyecto. Su ruta será $HOME/rfid-lab/proxmark3/Makefile.platform. No va dentro de client ni de ninguna otra subcarpeta.

Primero entramos en la carpeta y comprobamos dónde estamos:

cd "$HOME/rfid-lab/proxmark3"
pwd

pwd muestra la ruta del directorio actual. Debe terminar en /rfid-lab/proxmark3. Si cd devuelve un error porque la carpeta no existe, vuelve al paso de descarga; no continúes creando el archivo en otro sitio.

Usaremos el editor vi. Comprueba si está disponible:

command -v vi

Si no muestra ninguna ruta, puedes instalarlo en Debian con:

sudo apt-get install --no-install-recommends vim-tiny

Abre el archivo desde la carpeta del proyecto, sin sudo:

vi Makefile.platform

Si no existe, vi abrirá un archivo nuevo. Si ya tiene contenido de una configuración anterior, revísalo antes de cambiarlo: no añadas líneas duplicadas de PLATFORM o PLATFORM_SIZE.

Para crear el archivo nuevo:

1. Pulsa i para entrar en modo de inserción. Ahora puedes escribir.
2. Introduce estas dos líneas exactamente, respetando las mayúsculas. Son contenido del archivo, no comandos para ejecutar en la terminal:

PLATFORM=PM3GENERIC
PLATFORM_SIZE=512

1. Pulsa Esc para salir del modo de inserción.
2. Escribe :wq y pulsa Enter. Esto guarda el archivo y cierra el editor. Si necesitas salir sin guardar, usa Esc, después :q! y Enter.

De nuevo en la terminal, comprueba lo que has guardado:

cat Makefile.platform

Debe mostrar las dos líneas anteriores. PLATFORM=PM3GENERIC selecciona la plataforma genérica utilizada por nuestra Easy; PLATFORM_SIZE=512 configura el límite de tamaño de la imagen para 512 KB de flash.

En ese momento era la configuración candidata según las etiquetas y la descripción comercial; más abajo confirmamos la memoria mediante el cliente legacy. Escribir 512 en este archivo configura la compilación, no detecta el chip.

Compilar desde la carpeta del proyecto

Sin salir de $HOME/rfid-lab/proxmark3, ejecutamos:

make -j4

Compilamos con cuatro trabajos en paralelo, sin ejecutar el cliente como root ni instalarlo globalmente. Extractos reales:

Version info:      Iceman/master/0884083
Platform name:     Proxmark3 generic target
PLATFORM:          PM3GENERIC
PLATFORM_FPGA:     xc2s30
PLATFORM_SIZE:     512
Firmware size: 415417 bytes (405kb) = 79% of 512kb

La compilación terminó correctamente con GCC ARM 14.2.1 y cliente con Qt6 6.8.2. Se generaron cliente, bootloader, fullimage e imagen de recuperación localmente. La imagen de recuperación generada no es una copia del firmware original del dispositivo. Hasta este punto no habíamos escrito ninguno de esos archivos en la Proxmark3.

Paso 6. Primer intento: el cliente moderno no entiende el firmware de fábrica

Desde la carpeta del proyecto RRG (cd "$HOME/rfid-lab/proxmark3"), y con ModemManager detenido temporalmente, ejecutamos:

timeout 35s ./client/proxmark3 /dev/ttyACM0 -c 'hw version'

El límite temporal solo se usó para esta consulta sin escritura, no para interrumpir un flasheo. Resultado real:

[+] Using UART port /dev/ttyACM0
unknown command:: 0x61334d50[!!] ERROR: cannot communicate with the Proxmark3

El dispositivo se enumera y responde, pero no reconoce el intercambio del cliente moderno. No interpretamos esto como una prueba de hardware averiado ni usamos --force. Restauramos ModemManager y probamos un cliente del proyecto upstream legacy para consultar el firmware existente.

Paso 7. Cliente legacy: identificar antes de actualizar

Para este diagnóstico utilizamos el repositorio legacy https://github.com/Proxmark/proxmark3, distinto del proyecto RRG/Iceman. Lo descargamos en otra carpeta para no mezclar los dos clientes. La secuencia con Git es:

cd "$HOME/rfid-lab"
git clone https://github.com/Proxmark/proxmark3.git proxmark3-legacy
cd proxmark3-legacy
git checkout --detach 118eca80df79f9bb6604f896faafeb2fd425893e
git log -1 --format='%H %cs %s'

La carpeta de destino es ahora $HOME/rfid-lab/proxmark3-legacy. Seleccionamos la revisión 118eca80df79f9bb6604f896faafeb2fd425893e, utilizada en este diagnóstico. Desde esa carpeta intentamos compilar:

make -j4 client

Falló con Package 'libpcsclite' ... not found y fatal error: winscard.h: No existe el fichero o el directorio. Instalamos la dependencia del cliente legacy y repetimos:

sudo apt-get install -y --no-install-recommends libpcsclite-dev
make -j4 client

La compilación terminó con advertencias del código antiguo; usamos este cliente solo para el diagnóstico de versión, no para experimentar con otros protocolos ni flashear sus imágenes.

En una subshell para restaurar ModemManager al terminar, el procedimiento de consulta fue:

(
  sudo systemctl stop ModemManager || exit 1
  trap 'sudo systemctl start ModemManager' EXIT
  timeout 35s ./client/proxmark3 /dev/ttyACM0 -c 'hw version'
)

Este ejemplo restaura el servicio porque inicialmente estaba activo en nuestro PC. Extracto real de la respuesta, omitiendo el correo del modificador del firmware:

bootrom: /-suspect 2016-11-09 00:59:56
os: /-suspect 2016-11-14 03:06:26
HF FPGA image built on 2015/03/09 at 08:41:42
uC: AT91SAM7S512 Rev A
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 0 bytes ( 0%). Free: 524288 bytes (100%).
Internal SRAM Size: 64K bytes

Ahora sí tenemos una identificación por software de 512 KB de flash y 64 KB de SRAM. Rev A es la revisión del microcontrolador, no la revisión de toda la placa. Las fechas y /-suspect son lo que reporta ese firmware; no son una identificación verificable de un commit. Tampoco debemos creer que la flash esté vacía porque el cliente muestre Used: 0: el dispositivo está ejecutando firmware y ese cálculo no es fiable en esta combinación legacy.

Tras la consulta verificamos que ModemManager volvía a estar active. No hemos cambiado permanentemente servicios ni permisos del puerto.

Paso 8. Comprobaciones antes de escribir

Con el cable quieto, repetimos tres consultas de hw version mediante el cliente legacy, dejando diez segundos entre ellas. Las tres respondieron; al consultar el registro del kernel para ese intervalo obtuvimos -- No entries --. No garantiza ausencia de cualquier problema futuro, pero no observamos errores nuevos durante esa prueba.

Para reproducir esa comprobación, desde $HOME/rfid-lab/proxmark3-legacy, con ModemManager detenido como en el paso anterior, ejecuta la consulta tres veces, esperando diez segundos entre cada ejecución:

./client/proxmark3 /dev/ttyACM0 -c 'hw version'

Después revisa los eventos de ese intervalo con sudo journalctl -k --since '2 minutes ago' --no-pager. Si aparecen errores nuevos sin tocar el cable, detente antes de escribir. No confundas los eventos de un intervalo anterior con los de esta prueba.

Ahora volvemos al proyecto RRG, que contiene el cliente y las imágenes nuevas:

cd "$HOME/rfid-lab/proxmark3"
pwd
sha256sum bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf

sha256sum calcula una huella de cada archivo, útil para conservar un registro de qué imagen usamos. No certifica su compatibilidad ni sustituye una firma del mantenedor. Nuestras imágenes tuvieron estas huellas; otra compilación puede diferir por fechas o herramientas:

4137ad4cc4a01c9d452103d22a90a9396d7d39c5eb92087d5fef6acfa80fc29a  bootrom/obj/bootrom.elf
feb45e86e1c02066af443ef576e736a0599ba2b6609d3c9e80dcaa7d6d946b83  armsrc/obj/fullimage.elf

No tenemos una copia restaurable del firmware de fábrica. Antes de continuar revisamos la guía oficial de compilación y flasheo: para esta migración antigua actualizamos primero el bootloader y después el firmware principal, en operaciones separadas. Tener 512 KB de flash no garantiza que el bootloader antiguo sepa escribir por encima de 256 KB.

No desconectes el cable, pulses el botón, cierres la terminal ni suspendas el PC durante una escritura. Una interrupción del bootloader puede exigir recuperación por JTAG. Los siguientes comandos corresponden a nuestra Easy identificada y a las imágenes compiladas para ella, no a cualquier lector RFID.

Como ModemManager estaba activo, lo detuvimos antes de la operación completa:

sudo systemctl stop ModemManager
systemctl is-active ModemManager

La segunda orden debe mostrar inactive. Si el servicio no existe, no necesitas instalarlo. Cierra también cualquier otro cliente que use la Proxmark. Mantendremos el servicio detenido hasta terminar o pausar la recuperación de forma segura.

Paso 9. Actualizar únicamente el bootloader

Desde $HOME/rfid-lab/proxmark3, con el puerto comprobado en los pasos anteriores:

./client/proxmark3 /dev/ttyACM0 --flash --unlock-bootloader --image bootrom/obj/bootrom.elf

• ./client/proxmark3 es el cliente que acabamos de compilar, no el legacy.
• /dev/ttyACM0 es el puerto de nuestra conexión; comprueba el tuyo antes de ejecutar.
• --flash selecciona el modo de escritura de firmware.
• --unlock-bootloader permite escribir la región de arranque: se necesita en este paso y no en el siguiente.
• --image indica el archivo que se va a escribir. Aquí solo pasamos bootrom.elf.

El cliente reinició automáticamente el dispositivo para entrar en bootloader. Extractos de la salida real:

Entering bootloader...
Note: Your bootloader does not understand the new CMD_BL_VERSION command
Bootloader does not support CMD_CHIP_TYPE, assuming AT91 platform
Note: Your bootloader does not understand the new CHIP_INFO command
Your bootloader is outdated, but this operation will update it
Available memory on this board: UNKNOWN
Permitted flash range: 0x00100000-0x00140000
Writing segments for file: bootrom/obj/bootrom.elf
0x00100000..0x001001ff [0x200 / 1 blocks]
0x00100200..0x0010129f [0x10a0 / 9 blocks]
All done

Estos avisos indican que el bootloader antiguo no entiende determinadas consultas modernas. Habíamos identificado el AT91SAM7S512 con el cliente legacy; UNKNOWN aquí no invalida esa consulta. El flasher limitó el rango a los primeros 256 KB y la pequeña imagen de arranque cabía en él. No usamos --force.

All done confirmó que el flasher terminó esa escritura. Todavía no significaba que el equipo estuviera operativo con el firmware nuevo: faltaban la imagen principal y la verificación posterior.

Paso 10. Completar la imagen principal

Con la escritura del bootloader terminada y el dispositivo encendido, comprobamos el puerto antes de continuar:

lsusb -d 9ac4:4b8f
ls -l /dev/serial/by-id/

En nuestro equipo obtuvimos:

Bus 003 Device 080: ID 9ac4:4b8f J. Westhues ProxMark-3 RFID Instrument
usb-proxmark.org_proxmark3_iceman-if00 -> ../../ttyACM0

El nombre J. Westhues procede de la base de identificadores USB; no significa que hayamos cambiado físicamente de dispositivo. El enlace por identificador ha cambiado respecto al firmware de fábrica, aunque el puerto sigue siendo /dev/ttyACM0.

Si no aparece el puerto, no ejecutes todavía el flasheo. Comprueba el encendido y la conexión. Si necesitas entrar manualmente en el bootloader Iceman, desconecta solo cuando no haya escritura en curso, mantén el botón de usuario al conectar y suéltalo una vez dentro. No vuelvas a pulsarlo durante la escritura.

Con el puerto disponible, ModemManager aún detenido y la huella de fullimage.elf comprobada, ejecutamos desde la carpeta RRG:

./client/proxmark3 /dev/ttyACM0 --flash --image armsrc/obj/fullimage.elf

Esta vez no incluimos --unlock-bootloader: escribimos solo la aplicación principal. Salida real resumida, sin la animación de progreso:

Available memory on this board: 512K bytes
Permitted flash range: 0x00102000-0x00180000
Writing segments for file: armsrc/obj/fullimage.elf
0x00102000..0x001636b8 [0x616b9 / 780 blocks]
All done

El nuevo bootloader ya reconoce los 512 KB. La región permitida comienza en 0x00102000, después del bootloader. Terminó la escritura de 780 bloques y el dispositivo volvió a enumerar automáticamente; no fue necesario desconectarlo manualmente para la siguiente comprobación.

Paso 11. Comprobar versiones y comunicación

Desde la misma carpeta, ejecutamos cada comprobación por separado:

./client/proxmark3 /dev/ttyACM0 -c 'hw version'
./client/proxmark3 /dev/ttyACM0 -c 'hw status'

En el laboratorio enviamos ambas en una llamada con -c 'hw version; hw status'; aquí se separan para facilitar la lectura. Extractos reales:

Communicating with PM3 over USB-CDC
Firmware.................. PM3 GENERIC
Bootrom.... Iceman/master/0884083-suspect 2026-09-10 12:16:58 ed8df9283
OS......... Iceman/master/0884083-suspect 2026-09-10 12:17:15 ed8df9283
Embedded flash memory 512K bytes ( 78% used )
Transfer Speed PM3 -> Client... 627744 bytes/s

El cliente también reportó Iceman/master/0884083-suspect y ed8df9283. Las horas de compilación difieren entre componentes, pero coinciden la revisión y el identificador de compilación. Conservamos el sufijo -suspect tal como lo reporta la herramienta; no presentamos esta compilación local como una versión certificada. A diferencia de los intentos previos, hay comunicación funcional con el firmware nuevo y una transferencia de datos completada.

Paso 12. Comprobar las antenas LF y HF

Retira las tarjetas de las antenas y aleja el equipo de superficies metálicas. Ejecuta desde la misma carpeta:

./client/proxmark3 /dev/ttyACM0 -c 'hw tune'

hw tune mide las antenas; no las ajusta automáticamente. En nuestra sesión sin ventana gráfica utilizamos QT_QPA_PLATFORM=offscreen delante del comando; en un escritorio normal no necesitas esa variable. Resultados reales:

125,00 kHz ........... 28,23 V
134,83 kHz ........... 17,25 V
121,21 kHz optimal.... 30,09 V
LF antenna............ ok
13.56 MHz............. 23,39 V
HF antenna ( ok )

Ambas antenas recibieron la valoración ok. Los valores dependen de la antena y del entorno: no tienen que coincidir exactamente con los nuestros, ni demuestran compatibilidad con todas las tarjetas. Los avisos This plugin does not support propagateSizeHints() procedieron de Qt en modo sin ventana; no impidieron completar las medidas.

Por último restauramos ModemManager, que inicialmente estaba activo:

sudo systemctl start ModemManager
systemctl is-active ModemManager

Respondió active. Para futuras sesiones habrá que impedir de nuevo que sondee la Proxmark, mediante una parada temporal controlada o reglas específicas verificadas según la documentación de RRG. No lo desinstalamos ni cambiamos permisos globales.

Resultado del laboratorio

La Proxmark3 ya está operativa con Iceman: hemos comprobado las versiones, la comunicación y ambas antenas. Las comprobaciones realizadas no sustituyen una prueba prolongada ni la lectura de vuelta de toda la flash.

Fuentes y continuidad

• RRG/Iceman: código y documentación.
• Plataformas, opciones de compilación y limitaciones de 256 KB.
• Compilación y flasheo.
• Fichas de AliExpress, KSEC y Lab401 enlazadas en la sección de compra. Las afirmaciones comerciales se atribuyen al vendedor, no a pruebas nuestras.

El laboratorio ya está preparado. En la siguiente entrega explicaremos los fundamentos de RFID/NFC y las diferencias entre LF y HF antes de trabajar con nuestras tarjetas. Las entregas posteriores se enlazarán aquí a medida que se publiquen.